Flower rocm7.2

README.md

@@ -28,6 +28,7 @@ These dockerfiles will also be pushed and actively maintained in their original
 | Vision                  | [`OpenCV`](packages/vision/opencv), [`SAM`](packages/vision/sam), [`MobileSAM`](packages/vision/mobilesam), [`ncnn`](packages/vision/ncnn), [`DINOv3`](packages/vision/dinov3), [`SAM3`](packages/vision/sam3), [`Ultralytics`](packages/vision/ultralytics) |
 | Ryzen AI NPU                |  [`XDNA`](packages/npu/xdna), [`IRON`](packages/npu/iron), [`NPUEval`](packages/npu/npueval), [`Ryzen AI CVML`](packages/npu/ryzenai_cvml)  |
 | Adaptive SoCs           | [`PYNQ.remote`](packages/adaptive-socs/pynq-remote) |
+| Federated Learning      | [`Flower`](packages/federated/flower-base) ([`SuperLink`](packages/federated/flower-superlink), [`SuperNode`](packages/federated/flower-supernode), [`SuperExec`](packages/federated/flower-superexec)) |
 | Utilities   | [`JupyterLab`](packages/ide/jupyterlab), [`amdgpu_top`](packages/init/amdgpu_top) |
 
 ---

packages/federated/flower-base/Dockerfile

@@ -0,0 +1,21 @@
+# Copyright(C) 2026 Advanced Micro Devices, Inc. All rights reserved.
+# SPDX-License-Identifier: MIT
+
+ARG BASE_IMAGE
+FROM ${BASE_IMAGE}
+
+ENV DEBIAN_FRONTEND=noninteractive
+
+# Flower CLI binaries (flower-superlink, flower-supernode, flower-superexec)
+# all come from this single pip package. Torch + ROCm is provided by the
+# default rocm/pytorch base image, so no torch install is needed here.
+ARG FLWR_VERSION=1.30.0
+RUN pip3 install --no-cache-dir --break-system-packages \
+    "flwr[simulation]==${FLWR_VERSION}" \
+    "flwr-datasets[vision]>=0.5.0"
+
+WORKDIR /ryzers
+COPY test.sh /ryzers/test_flower-base.sh
+RUN chmod +x /ryzers/test_flower-base.sh
+
+CMD /ryzers/test_flower-base.sh

packages/federated/flower-base/README.md

@@ -0,0 +1,49 @@
+# Flower Base Docker Setup
+
+Shared base layer for the Flower federated-learning Ryzers. Installs the
+[Flower](https://flower.ai) framework (`flwr[simulation]==1.26.1`) on top
+of the default ROCm/PyTorch base image, so the three flower binaries
+(`flower-superlink`, `flower-supernode`, `flower-superexec`) and a
+ROCm-enabled PyTorch are available to layers that build on this one.
+
+You usually don't build or run this Ryzer on its own — chain it with one of
+the role Ryzers:
+
+```sh
+# --name sets the final image tag (it defaults to "ryzerdocker", not the
+# last package name), so each role gets its own image + run-script.
+ryzers build --name flower-superlink flower-base flower-superlink   # server box
+ryzers build --name flower-supernode flower-base flower-supernode   # client box
+ryzers build --name flower-superexec flower-base flower-superexec   # serverapp or clientapp runner
+```
+
+## Build & Run (standalone smoke test)
+
+```sh
+ryzers build flower-base
+ryzers run
+```
+
+The default `CMD` runs `test_flower-base.sh`, which verifies the CLI
+binaries are installed and that `torch.cuda.is_available()` returns true
+under ROCm.
+
+## Local single-machine smoke test
+
+For an end-to-end test on one host (SuperLink + ServerApp + two
+SuperNode/ClientApp pairs) run [`../run-local.sh`](../run-local.sh). It
+builds the three role Ryzers, brings everything up under `--network host`
+on the loopback (with ClientAppIo ports offset by partition ID), submits
+the quickstart-pytorch run, and tears down on exit.
+
+The same three role Ryzers (`flower-superlink`, `flower-supernode`,
+`flower-superexec`) are also what you run in a distributed deployment —
+just set `SUPERLINK_IP` to the server's IP on the client boxes. See each
+role Ryzer's README for the multi-machine flow.
+
+## References
+
+- [Flower documentation](https://flower.ai/docs/framework/)
+- [Multi-machine Docker tutorial](https://flower.ai/docs/framework/docker/tutorial-deploy-on-multiple-machines.html)
+
+Copyright(C) 2026 Advanced Micro Devices, Inc. All rights reserved.

packages/federated/flower-base/config.yaml

@@ -0,0 +1,12 @@
+# Copyright(C) 2026 Advanced Micro Devices, Inc. All rights reserved.
+# SPDX-License-Identifier: MIT
+
+# flower-base is a composable layer. It provides the flwr CLI on top of the
+# default ROCm/PyTorch base image. Most users will not run it directly;
+# instead chain it with one of:
+#   ryzers build --name flower-superlink flower-base flower-superlink
+#   ryzers build --name flower-supernode flower-base flower-supernode
+#   ryzers build --name flower-superexec flower-base flower-superexec
+
+build_arguments:
+- "FLWR_VERSION=1.32.0"

packages/federated/flower-base/test.sh

@@ -0,0 +1,29 @@
+#!/bin/bash
+
+# Copyright (C) 2026 Advanced Micro Devices, Inc. All rights reserved.
+# SPDX-License-Identifier: MIT
+
+set -e
+
+echo "Running tests for flower-base..."
+
+# Verify all three flower CLI entrypoints are installed
+for bin in flower-superlink flower-supernode flower-superexec flwr; do
+  if ! command -v "$bin" >/dev/null 2>&1; then
+    echo "FAIL: $bin not on PATH"
+    exit 1
+  fi
+  echo "Found: $(command -v "$bin")"
+done
+
+# Verify flwr Python package and torch+ROCm
+python3 - <<'PY'
+import flwr
+import torch
+print(f"flwr version:  {flwr.__version__}")
+print(f"torch version: {torch.__version__}")
+print(f"torch.cuda.is_available(): {torch.cuda.is_available()}")
+print(f"torch HIP version:         {torch.version.hip}")
+PY
+
+echo "Tests passed!"

packages/federated/flower-superexec/Dockerfile

@@ -0,0 +1,28 @@
+# Copyright(C) 2026 Advanced Micro Devices, Inc. All rights reserved.
+# SPDX-License-Identifier: MIT
+
+ARG BASE_IMAGE
+FROM ${BASE_IMAGE}
+
+# Install the example Flower app (quickstart-pytorch). The pyproject.toml
+# shipped here has torch dependencies stripped so we don't overwrite the
+# ROCm PyTorch provided by the base image.
+WORKDIR /app
+COPY app/ /app/
+RUN pip3 install --no-cache-dir --break-system-packages /app
+
+WORKDIR /ryzers
+COPY test.sh /ryzers/test_flower-superexec.sh
+COPY run-superexec.sh /ryzers/run-superexec.sh
+RUN chmod +x /ryzers/test_flower-superexec.sh /ryzers/run-superexec.sh
+
+RUN mkdir -p /app/certificates
+
+# When running --plugin-type clientapp this connects out to the SuperNode
+# at supernode:9094; when running --plugin-type serverapp it connects out
+# to the SuperLink at superlink:9091. No inbound ports are exposed.
+
+# Default CMD is the role launcher (reads FLOWER_PLUGIN_TYPE etc. from
+# config.yaml). To run the install-validation smoke test instead:
+#   ryzers run /ryzers/test_flower-superexec.sh
+CMD /ryzers/run-superexec.sh

packages/federated/flower-superexec/README.md

@@ -0,0 +1,116 @@
+# Flower SuperExec Docker Setup
+
+`flower-superexec` is Flower's process runner. The same binary runs both
+the **ServerApp** (server-side aggregation logic) and the **ClientApp**
+(client-side training), selected with `--plugin-type {serverapp,clientapp}`.
+
+This Ryzer is the only one in the federation that actually executes
+PyTorch training, so it sits on top of the ROCm/PyTorch base image and
+inherits GPU access. It ships with the `quickstart-pytorch` example app
+preinstalled at `/app/`.
+
+A third plugin type, `submit`, runs `flwr run /app local` once and
+exits — the `local` federation in `/app/pyproject.toml` points at the
+SuperLink ExecApi on `127.0.0.1:9093`. Used by
+[`../run-local.sh`](../run-local.sh) to kick off the example run after
+everything else is up. The container uses `--network host`, so the
+ServerApp/ClientApp/submit roles all reach SuperLink and SuperNode via
+loopback in single-machine deployments and via the host network
+directly in multi-machine ones.
+
+## Build
+
+```sh
+ryzers build --name flower-superexec flower-base flower-superexec
+```
+
+## Run
+
+SuperExec flags are driven by environment variables declared in
+`config.yaml` (with shell-expansion defaults). The role
+(`serverapp` vs `clientapp`) is selected via `FLOWER_PLUGIN_TYPE`.
+
+### Run as ServerApp (server machine)
+
+```sh
+export FLOWER_PLUGIN_TYPE=serverapp
+export FLOWER_APPIO_ADDR=127.0.0.1:9091      # local SuperLink
+ryzers run
+```
+
+### Run as ClientApp (client machine)
+
+```sh
+export FLOWER_PLUGIN_TYPE=clientapp
+export FLOWER_APPIO_ADDR=127.0.0.1:9094      # local SuperNode
+ryzers run
+```
+
+## Putting it together (mirrors the upstream tutorial)
+
+**On the server machine** (SuperLink + ServerApp superexec):
+
+```sh
+# --name sets the final image tag; without it both builds would clobber
+# the default "ryzerdocker" image and `ryzers run --name <role>` would
+# not find its generated run-script.
+ryzers build --name flower-superlink flower-base flower-superlink
+ryzers build --name flower-superexec flower-base flower-superexec
+
+# Terminal 1 — SuperLink
+ryzers run --name flower-superlink
+
+# Terminal 2 — ServerApp superexec
+export FLOWER_PLUGIN_TYPE=serverapp
+export FLOWER_APPIO_ADDR=127.0.0.1:9091
+ryzers run --name flower-superexec
+```
+
+**On each client machine** (SuperNode + ClientApp superexec):
+
+```sh
+ryzers build --name flower-supernode flower-base flower-supernode
+ryzers build --name flower-superexec flower-base flower-superexec
+
+# Terminal 1 — SuperNode (connects to remote SuperLink)
+export SUPERLINK_IP=192.168.2.33
+export FLOWER_PARTITION_ID=0
+export FLOWER_NUM_PARTITIONS=2
+ryzers run --name flower-supernode
+
+# Terminal 2 — ClientApp superexec (runs the PyTorch training)
+export FLOWER_PLUGIN_TYPE=clientapp
+export FLOWER_APPIO_ADDR=127.0.0.1:9094
+ryzers run --name flower-superexec
+```
+
+Then from any machine with the `flwr` CLI installed:
+
+```sh
+flwr run /app remote-deployment      # see config.toml in upstream tutorial
+```
+
+For TLS, set `FLOWER_INSECURE=0` on each component and stage the certs
+generated by `flower-superlink/gen-certs.sh` (see that Ryzer's README).
+
+### Env-var reference
+
+| Variable | Default | Purpose |
+|----------|---------|---------|
+| `FLOWER_PLUGIN_TYPE` | `serverapp` | `serverapp`, `clientapp`, or `submit` |
+| `FLOWER_PARTITION_ID` | `0` | For `clientapp`, picks which SuperNode ClientAppIo port to attach to |
+| `FLOWER_APPIO_ADDR` | derived | `127.0.0.1:9091` (serverapp) or `127.0.0.1:$((9094 + FLOWER_PARTITION_ID))` (clientapp); ignored for `submit` |
+| `FLOWER_INSECURE` | `1` | `1` = `--insecure`; `0` = TLS via `FLOWER_CA_CERT` |
+
+## Bundled example
+
+`/app/` contains a copy of [`examples/quickstart-pytorch`](https://github.com/adap/flower/tree/v1.26.1/examples/quickstart-pytorch),
+modified to drop the `torch==2.8.0` pin so the ROCm PyTorch from the
+base image is used unchanged.
+
+## References
+
+- [SuperExec / process isolation](https://flower.ai/docs/framework/how-to-deploy-flower-server-using-process-isolation.html)
+- [Multi-machine Docker tutorial](https://flower.ai/docs/framework/docker/tutorial-deploy-on-multiple-machines.html)
+
+Copyright(C) 2026 Advanced Micro Devices, Inc. All rights reserved.

packages/federated/flower-superexec/app/README.md

@@ -0,0 +1,75 @@
+---
+tags: [quickstart, vision, fds]
+dataset: [CIFAR-10]
+framework: [torch, torchvision]
+---
+
+# Federated Learning with PyTorch and Flower (Quickstart Example)
+
+This introductory example to Flower uses PyTorch, but deep knowledge of PyTorch is not necessarily required to run the example. However, it will help you understand how to adapt Flower to your use case. Running this example in itself is quite easy. This example uses [Flower Datasets](https://flower.ai/docs/datasets/) to download, partition and preprocess the CIFAR-10 dataset.
+
+## Set up the project
+
+### Fetch the app
+
+Install Flower:
+
+```shell
+pip install flwr
+```
+
+Fetch the app:
+
+```shell
+flwr new @flwrlabs/quickstart-pytorch
+```
+
+This will create a new directory called `quickstart-pytorch` with the following structure:
+
+```shell
+quickstart-pytorch
+├── pytorchexample
+│   ├── __init__.py
+│   ├── client_app.py   # Defines your ClientApp
+│   ├── server_app.py   # Defines your ServerApp
+│   └── task.py         # Defines your model, training and data loading
+├── pyproject.toml      # Project metadata like dependencies and configs
+└── README.md
+```
+
+### Install dependencies and project
+
+Install the dependencies defined in `pyproject.toml` as well as the `pytorchexample` package.
+
+```bash
+pip install -e .
+```
+
+## Run the project
+
+You can run your Flower project in both _simulation_ and _deployment_ mode without making changes to the code. If you are starting with Flower, we recommend you using the _simulation_ mode as it requires fewer components to be launched manually. By default, `flwr run` will make use of the Simulation Engine.
+
+### Run with the Simulation Engine
+
+> [!TIP]
+> This example runs faster when the `ClientApp`s have access to a GPU. If your system has one, you can make use of it by configuring the `backend.client-resources` component in your Flower Configuration. Check the [Simulation Engine documentation](https://flower.ai/docs/framework/how-to-run-simulations.html) to learn more about Flower simulations and how to optimize them.
+
+```bash
+# Run with the default federation (CPU only)
+flwr run .
+```
+
+You can also override some of the settings for your `ClientApp` and `ServerApp` defined in `pyproject.toml`. For example:
+
+```bash
+flwr run . --run-config "num-server-rounds=5 learning-rate=0.05"
+```
+
+> [!TIP]
+> For a more detailed walk-through check our [quickstart PyTorch tutorial](https://flower.ai/docs/framework/tutorial-quickstart-pytorch.html)
+
+### Run with the Deployment Engine
+
+Follow this [how-to guide](https://flower.ai/docs/framework/how-to-run-flower-with-deployment-engine.html) to run the same app in this example but with Flower's Deployment Engine. After that, you might be intersted in setting up [secure TLS-enabled communications](https://flower.ai/docs/framework/how-to-enable-tls-connections.html) and [SuperNode authentication](https://flower.ai/docs/framework/how-to-authenticate-supernodes.html) in your federation.
+
+If you are already familiar with how the Deployment Engine works, you may want to learn how to run it using Docker. Check out the [Flower with Docker](https://flower.ai/docs/framework/docker/index.html) documentation.