Frank
327e78b950
The vault was 155 pages / 31,210 lines, most of it measurement ledgers for payloads that no longer run. A throughput figure for a runtime nobody operates is not a record: AI moves faster than the vault, so the number is wrong before anyone reads it, and a wrong number in a runbook gets believed. Per the new purpose test in `AGENTS.md` → *Documentation Policy*, it is destroyed. Gone (`.AGENTTRASH/20261019-destruction/`, KILL-LIST.txt is the manifest): - the `frank-medium` endpoint and its five era pages, `frank-npu`, FastFlowLM, the ikllama/kingjones/dealign/frank-redo eras, the ling/swift15/freetoken/ubatch campaign pages, qwen3.8 spec-matrix and strix-optimizations, the two "Running Qwen3.6 …" pages; - the whole `Pipeline Parallelism/` folder (no live script passes a pipeline flag) and the multi-device/x4-pair/hybrid/offload experiment pages; - every vLLM page — no vLLM endpoint exists on this fleet; - `LLM/deployment.md` (`Architecture/Deployment Flow.md` is the test-referenced owner) and the external surveys (SGLang, Lemonade, llama.cpp forks/diff, self-hosted app census, the TTS survey) that were obsolete by construction; - `log.md`, 2,380 lines. Git holds the chronology; a causal law belongs to the page that owns the thing it governs, never to a diary. Survivors: 101 pages, 17,542 lines, 0 OKF violations, 0 unresolved links. Eras tables keep the window, payload, runtime, reason and rollback pointer; the rate columns are blanked. The live shapes stay verbatim — those numbers are what the deployer and `models.yml` consume.
116 lines
6.0 KiB
Markdown
116 lines
6.0 KiB
Markdown
---
|
|
type: reference
|
|
description: "Whether ComfyUI can use the Strix Halo APU at all, and which backend path actually reaches the GPU."
|
|
tags:
|
|
- research
|
|
- rocm
|
|
- comfyui
|
|
timestamp: 2026-08-28
|
|
---
|
|
|
|
# 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 (way 1 applied 2026-08-19):
|
|
|
|
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. **Applied:** the running `comfyui-rocm:gfx1151` image does exactly this (see `dankclaw/Containerfile.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 ).
|
|
|
|
## 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
|
|
|
|
**Applied 2026-08-19.** `dankclaw/compose.yaml` now builds `comfyui-rocm:gfx1151` from `dankclaw/Containerfile.comfyui` (based on the AMD gfx1151 base), passes `/dev/kfd` + `/dev/dri`, adds the `video` group, and drops `--cpu`. The container runs on the Radeon 8060S (gfx1151) and is boot-persistent via a user systemd unit. See [[ComfyUI]] for the running config.
|
|
|
|
## 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)
|
|
- the ggml-family alternative with working gfx1151 kernels
|
|
- [[Observability]], [[Dankclaw Stack]]
|
|
- KB: [[ComfyUI]] (tools) (the "ROCm unavailable" claims here are now qualified) |