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

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:

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:

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)