0 Fork 0

Files

T

Frank a5fe045b58 docs(vault): one fact, one owner — repair the doubled pages, single-source the facts

Structural repair:
- 13 pages were the same document twice (each exactly 2x its HEAD size),
  a second frontmatter block whose closing fence had been glued onto a body
  line by a frontmatter rewrite that re-read its own output. Un-doubled by
  cutting at the second frontmatter and keeping the copy whose body is a
  superset; the orphan census reports 0 lost tokens against HEAD.
- log.md: one entry per date, bare `## YYYY-MM-DD` headings, newest first —
  66 dated headings merged into 34, titles demoted to bold leads, every
  content line verified present. The file had been descending at the head
  and ascending at the tail.

Ownership moves:
- New `LLM/frank-medium.md` is the locator for the retired Dankserver
  endpoint: era windows quoted from each era page's own banner, no numbers
  restated, and the two unresolved date conflicts recorded instead of
  silently resolved. `frank-archon.md` links to it instead of restating the
  pre-rename window.
- The four Pipeline-Parallelism stubs (frontmatter only, no body) are gone;
  `Multi-Node Runtimes.md` owns runtime construction, launch, mixed-vendor
  verdicts and cross-split spec decode, and the four links that pointed at
  the stubs were repointed at it or at the drafter page.
- Authentik's three stub pages fold into `Authentik.md`, with the process
  detail and the outpost reference split out so the parent stays under the
  length hint.

Verified corrections (host census + live probe, 2026-10-19):
- The MXFP4 checkpoint two pages called the "on-disk rollback" is gone:
  /home/dank/models/ holds StillDeadcode, rad and tpl.jinja. Stated once, on
  the era page that owns that payload; the swap page now links to it.
- frank-medium-radiance-mxfp4: the 4.24/7 accept rate belongs to the DFlash2
  arm measured on the FP8 target, not to the MXFP4 era; the 3-family soak run
  census is kept once (155 requests) instead of twice (~120 and 155).
- Fleet shapes re-confirmed against the live endpoints before touching any
  page: 3x200000 fp8 KV, 2x200704, 2x262144.

Index rows are regenerated, not hand-carved. Net -1,849 vault lines.

2026-10-19 05:00:43 -07:00

6.1 KiB

Raw Permalink Blame History

type, description, tags, timestamp

type

description

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 (way 1 applied 2026-08-19):

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).
Build PyTorch for gfx1151 (export PYTORCH_ROCM_ARCH=gfx1151 before build). Slow build, but a self-contained wheel afterwards.
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

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:

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

6.1 KiB Raw Permalink Blame History