ComfyUI on AMD Radeon 780M: retiring ZLUDA for AMD's TheRock

The ZLUDA setup I wrote up before worked, but getting there took eight separate manual fixes, from a locale bug to a security layer quarantining ZLUDA’s injected DLLs to a rocBLAS kernel bug that needed a HIP SDK version swap. AMD’s own tooling has since started catching up. TheRock is AMD’s own rebuilt ROCm build and release pipeline, still in preview, and it now publishes nightly PyTorch wheels with gfx1103 as an actual build target.

Installing TheRock

There’s no native Windows installer yet, but the pip index works directly:

pip install --index-url https://rocm.nightlies.amd.com/whl-multi-arch/ \
    "torch[device-gfx1103]" "torchvision[device-gfx1103]" torchaudio

Right after install, torch already reports the right device:

torch version: 2.12.0+rocm7.15.0a20260728
hip available: True
device name: AMD Radeon 780M Graphics

A 4096x4096 fp16 matmul ran 20 iterations in 1.3 seconds. A Conv2d op that hard-crashed under ZLUDA with “unable to find an engine to execute this computation” now just logs a warning: MIOpen: CK grouped conv library not found for device gfx1103. Both checks exercise real ComfyUI code paths.

What ZLUDA needed that TheRock doesn’t

No DLL injection. ZLUDA needed Windows Defender exclusions and Smart App Control turned off, a one-way change that needs a Windows reinstall to reverse. TheRock ships as a plain PyTorch wheel. Neither issue comes up.
CLIP runs on the GPU. The ZLUDA setup needed a permanent patch forcing the CLIP text encoder onto the CPU, to dodge an access-violation crash. The startup logs show the difference plainly:
```
ZLUDA:   CLIP/text encoder model load device: cpu
TheRock: CLIP/text encoder model load device: cuda:0
```
No manual cuDNN patch. The ZLUDA setup needed hand-editing zluda.py to set torch.backends.cudnn.enabled = False globally. This build of ComfyUI does the same thing on its own once it detects an AMD GPU, right there in the startup log:
```
Set: torch.backends.cudnn.enabled = False for better AMD performance
```

Tuning: attention algorithm choice

Out of the box, TheRock’s default attention algorithm, sub-quadratic, won on SD1.5 and lost on SDXL. Adding --use-pytorch-cross-attention flipped that, and roughly doubled speed across both model sizes:

Test	ZLUDA	TheRock (default)	TheRock (cross-attention)
SD 1.5, 512x512, 20 steps	1.11-1.22 it/s (26.6-27.3s)	1.25 it/s (24.1s)	2.44 it/s (12.6s)
SDXL, 1024x1024, 20 steps	4.63 s/it (110.3-112.2s)	5.16 s/it (135.5s)	2.86 s/it (77.9s)

A warm run, with the checkpoint already loaded in memory, holds even steadier: SDXL sat at 2.82-2.95 s/it across repeated passes. I also tried --use-split-cross-attention. It landed within noise of the default, no real change either way.

One thing that made it worse

I carried over --disable-async-offload and --disable-pinned-memory from the ZLUDA tuning, assuming they’d help the same way here. They didn’t: SDXL went from 77.9 seconds to 98.25. ZLUDA’s translation layer struggled with async offload and pinned memory, and disabling both was a real fix there. TheRock’s native HIP driver handles both correctly by default, so turning them off here just throws away a working optimization. I reverted.

Results

ZLUDA is retired. TheRock is the default backend on port 8188 now. ComfyUI-Manager, a custom node maintained outside core, got migrated over by hand. The ZLUDA-specific cuDNN workaround nodes are gone too, since nothing needs them anymore.

I also tested GPU sharing with Ollama on the same box, a 14.8GB pool split between both. With --reserve-vram 6 set on ComfyUI, an SDXL generation and an Ollama chat request ran at the same time without a crash, and the SDXL run barely slowed down: 2.87-2.97 s/it, the same range as running it alone.

(Update: that same Ollama setup went on to run a local codegen loop and, later, a full coding-agent harness on this box. This same ComfyUI-TheRock install later ran a 20B-class image model via GGUF quantization.)

Open issues

TheRock’s gfx1103 target isn’t on AMD’s official list of sanity-tested chips. This is a nightly build, and instability comes with that territory.

Two gaps are worth knowing about. ComfyUI’s VAE decode crashing on cuDNN for gfx1103 is a known, open issue. It didn’t come up here. My guess is that ComfyUI’s automatic cuDNN disable already routes around it, but the underlying gap is still open. MIOpen still has no Composable Kernel-based convolution kernels for gfx1103, which is also why sage-attention and flash-attention builds, both of which depend on CK, aren’t an option on this chip yet.

Same caveat as the ZLUDA post: this whole stack is nightly and unofficial-adjacent. Fine for a personal machine. I wouldn’t run it near anything that matters.