serverAppConfigs/docs/Research/ComfyUI ROCm and Vulkan.md

# ComfyUI on ROCm and Vulkan

Research into whether ComfyUI can use GPU acceleration — not just CPU — on the AMD Strix Halo APU (gfx1151) in Dankclaw. Verified on live hardware 2026-08-14. This page corrects the persistent "ROCm unavailable on Strix Halo" claim.

## TL;DR

| Path | Works on gfx1151? | Evidence |
|------|-------------------|----------|
| pytorch.org ROCm wheels | **No** | wheels are built for `gfx906/gfx90a/gfx942/gfx1100` etc. — no gfx1151 kernels |
| Official `rocm/comfyui` image | **No** | built with `PYTORCH_ROCM_ARCH=gfx942;gfx950` — datacenter archs only |
| AMD gfx1151-tagged PyTorch build | **Yes** | `torch 2.9.1+rocm7.12.0rc1` → `avail: True`, `Radeon 8060S`, cap `(11,5)` |
| Vulkan (torch.backends.vulkan) | **No** | compiled out of standard wheels; experimental/mobile even when present |
| ComfyUI `--cpu` | **Yes (slow)** | current stack config |

## The core insight

PyTorch's ROCm support is not one thing. The wheels you install for poke at torch, the wheels AMD builds for specific APUs are different, and the kernels compiled in are fixed at build time via `PYTORCH_ROCM_ARCH`.

Standard wheels (pytorch.org and the `rocm/comfyui` image) target **CDNA datacenter archs** (`gfx942`/`gfx950`) or the older common set. **gfx1151 (Strix Halo / Radeon 8060S)** is not included, so `torch.cuda.is_available()` returns `False` and everything falls back to CPU.

AMD does publish gfx1151 builds — but you have to pick the right image.

## Live verification (Dankclaw, 2026-08-14)

### Fails: official rocm/comfyui image

```bash
podman pull docker.io/rocm/comfyui:comfyui-0.18.2.amd0_rocm7.2.0_ubuntu24.04
podman run --rm --device=/dev/kfd --device=/dev/dri --entrypoint python <img> -c "
import torch
print(torch.__version__)          # 2.10.0a0+git…
print(torch.cuda.is_available())  # False
print(torch.cuda.get_arch_list()) # []"

# Env in that image:
#   PYTORCH_ROCM_ARCH=gfx942;gfx950
#   ROCM_PATH=/opt/rocm-7.2.0
```

The image bundles ROCm 7.2 and compiles kernels only for `gfx942;gfx950`. No gfx1151. `HSA_OVERRIDE_GFX_VERSION` does not help because the kernels simply are not compiled in.

The official ComfyUI ROCm image is 68 GB and unusable on Strix Halo. It was pulled on Dankclaw for this test; remove it to reclaim space.

### Works: AMD gfx1151-tagged PyTorch build

The `rocm/vllm` image exists in two flavors. The one tagged `gfx1151` works on Strix Halo:

```bash
podman run --rm \
  --device=/dev/kfd --device=/dev/dri \
  --entrypoint python \
  docker.io/rocm/vllm:rocm7.12.0_gfx1151_ubuntu24.04_py3.12_pytorch_2.9.1_vllm_0.16.0 \
  -c "
import torch
print(torch.__version__)        # 2.9.1+rocm7.12.0rc1
print(torch.version.hip)        # 7.12.60610
print(torch.cuda.is_available()) # True
print(torch.cuda.get_device_name(0))  # Radeon 8060S Graphics
print(torch.cuda.get_device_capability(0)) # (11, 5)  = gfx1151
"

# Env in that image:
#   PYTORCH_ROCM_ARCH=gfx1151
```

Key facts:
- `avail: True`, device `Radeon 8060S`, capability `(11, 5)` = gfx1151.
- Device access requires passing `/dev/kfd` and `/dev/dri` to the container (and `--group-add video`/`realtime` or a user with those groups).
- ROCm HIP runtime vars matter: this image has HIP 7.12; the older `rocm/vllm:rocm7.14.0_rdna_*` (48.6 GB) targets the newer "RDNA" set.

## What this means for ComfyUI

ComfyUI is a PyTorch app. If you give it a PyTorch wheel with gfx1151 kernels — the AMD `/opt/python` build used by the working vLLM image, or a custom build with `PYTORCH_ROCM_ARCH=gfx1151` — ComfyUI **will** use the GPU via ROCm. The blocker is not ComfyUI; it is shipping it in a container that contains a gfx1151-enabled torch.

Three ways forward (future work, none applied yet):

1. **Base a ComfyUI image on the AMD gfx1151 torch build.** Take `rocm/vllm:...gfx1151...pytorch_2.9.1...` (or AMD's PyTorch wheel index) and install ComfyUI on top. This is the direct path to GPU ComfyUI.
2. **Build PyTorch for gfx1151** (`export PYTORCH_ROCM_ARCH=gfx1151` before build). Slow build, but a self-contained wheel afterwards.
3. **Use a ggml-family runtime instead** — stable-diffusion.cpp / Lemonade's `sd.cpp` backend ship their own gfx1151 HIP kernels and work today (see [[Lemonade and sd.cpp]]).

## Vulkan

- PyTorch's Vulkan backend (`torch.backends.vulkan`) is **compiled out of standard Linux wheels**. The installed `torch 2.11/2.13` on Dankclaw reports `hasattr(torch.backends, 'vulkan')` → `False`.
- Even when built in, PyTorch Vulkan is a mobile-oriented experimental backend, not a desktop inference path, and ComfyUI exposes no `--vulkan` flag.
- The system has a working Vulkan driver (RADV, `libvulkan_radeon.so` + `radeon_icd.json`), so Vulkan apps work — but ComfyUI/PyTorch cannot consume it here.
- Conclusion: **Vulkan is a dead end for ComfyUI.** If GPU is wanted, ROCm is the realistic path; a ggml-family engine (sd.cpp/Lemonade) is the pragmatic one.

## Consequence for this repo

The current `dankclaw/compose.yaml` runs ComfyUI with `--cpu`. That remains correct **until a gfx1151-enabled torch image is built**. When GPU priority arrives, swap the image for one based on the AMD Strix-savvy build and drop `--cpu`.

## Cleanup note

These images were pulled on Dankclaw during this research:

```bash
podman rmi docker.io/rocm/comfyui:comfyui-0.18.2.amd0_rocm7.2.0_ubuntu24.04   # 68 GB, unusable on gfx1151
podman rmi docker.io/rocm/vllm:rocm7.12.0_gfx1151_...                         # 32.5 GB, keep if pursuing ComfyUI ROCm
```

## See Also

- [[ComfyUI]] — the service page (CPU config)
- [[Lemonade and sd.cpp]] — the ggml-family alternative with working gfx1151 kernels
- [[Observability]], [[Dankclaw Stack]]
- KB: [[ComfyUI]] (tools), [[ComfyUI Troubleshooting]] (the "ROCm unavailable" claims here are now qualified)