ComfyUI on AMD: ROCm Noise, Black Image and Crash Fixes

If ComfyUI already detects your Radeon and the run completes but the picture is wrong, the fix is almost never "reinstall ROCm" — it is one of four launch-line changes, and which one depends on your gfx target rather than your card's marketing name. On gfx1151 (Strix Halo) the reported fix for NaN output is --force-fp32. On gfx1201 (RX 9070 XT) an all-black image from an int8_convrot checkpoint is fixed by swapping the diffusion model to an fp8_scaled build, not by touching flags. On RDNA4 builds whose torch wheel ships no AOTriton kernels, a HIP "invalid argument" crash in the text encoder is fixed by keeping ComfyUI off the flash-attention path. And on RDNA1/RDNA2 a Triton INT8 hang is fixed with --disable-triton-backend. Get your arch from the startup log first; everything below is indexed by it.

This page starts one step after "does ROCm see the card at all". If rocminfo does not list your GPU, or ComfyUI falls back to CPU, that is an HSA_OVERRIDE_GFX_VERSION problem and a different article. Here the assumption is that ComfyUI boots, prints your arch, loads the checkpoint, fills the progress bar — and then hands you mosaic, noise, a grey frame, a black frame, or a traceback in the text encoder.

Everything below is attributed. Flag names and the arch gating logic were read from comfy/cli_args.py and comfy/model_management.py on master (current release v0.33.1, published 13 August 2026). Every failure and every "this fixed it" is credited to the person who reported it, with the issue number, so you can check whether it has been closed since. We do not own one of every RDNA generation and we are not going to pretend otherwise — nothing here is presented as a first-hand reproduction.

Which gfx target are you actually on?

Read it out of the startup log. Do not infer it from the card name. ComfyUI prints two lines you need, one after the other, before it loads anything:

[INFO] AMD arch: gfx1201
[INFO] ROCm version: (7, 14)

Those exact lines appear in the logs attached to #15674 and #15653, and they are printed from the AMD block in model_management.py. The mapping that matters for this page:

• gfx1100 / gfx1101 — RDNA3. gfx1100 is the RX 7900 XTX and XT; gfx1101 is the RX 7800 XT and 7700 XT class.
• gfx1150 / gfx1151 — RDNA3.5 integrated graphics. gfx1151 is Strix Halo, which ComfyUI reports as Radeon 8060S Graphics.
• gfx1200 / gfx1201 — RDNA4. gfx1200 is the RX 9060 XT; gfx1201 is the RX 9070 and 9070 XT.
• gfx1030 / gfx1031 / gfx1035 / gfx1010-gfx1012 — RDNA2 and RDNA1. These are the archs ComfyUI keeps on a slower, safer path by name.

That last group is not arbitrary. model_management.py carries a literal list, AMD_RDNA2_AND_OLDER_ARCH, containing exactly gfx1030, gfx1031, gfx1035, gfx1010, gfx1011, gfx1012, gfx906, gfx900, gfx803. If your arch is not in that list, ComfyUI sets torch.backends.cudnn.enabled = False at startup — the code comment beside it reads "Seems to improve things a lot on AMD" — and logs Set: torch.backends.cudnn.enabled = False for better AMD performance. Remember that line. It comes back later and it has bitten at least one person badly.

Which ROCm failure is which?

This is the table. Find your arch, then read across. Every row is a specific report, not a category, and the "what worked" column is what the reporter said worked — not a guess.

Two things to take from the shape of that table. First, there is no single "AMD fix" — the gfx1201 int8 fix is a file swap, the gfx1151 fix is a precision flag, and the RDNA2 fix is a backend flag. Second, the newest arch is not the safest one. RDNA4 owners are hitting more distinct bugs than RDNA3 owners right now, because RDNA4 is where the new quantised kernels and the ROCm 7.x wheel reshuffles are landing.

Why does the output come out as noise or mosaic?

Noise is not NaN. That distinction is the whole diagnosis, and it is worth internalising before you start changing flags.

A NaN failure produces a uniform frame — pure black, or grey — and usually prints RuntimeWarning: invalid value encountered in cast at save time. Noise and mosaic are different: the numbers are finite, the pipeline ran, the decoder decoded something. What you are looking at is a quantised matmul kernel producing wrong-but-valid values, which means precision flags will not touch it.

The reference case is #15314 on an RX 7900 XTX (gfx1100, Ubuntu 24.04, ROCm 7.2.4, torch 2.13.0+rocm7.2). The reporter went through nvfp4_awq and int8_convrot text encoders, native and emulated quantisation paths, several samplers and resolutions — noise every time, while the video VAE decoded correctly, proving the model files were intact. Their read is that it is an RDNA3-specific operator in the quantised DiT forward, and they note that RDNA4 owners report the same workflow generating fine.

There is a second, less exotic cause of noise on ROCm that costs nothing to rule out. #12839 is a long, careful report of Qwen-Image-Edit 2511 turning black or "mosaicked" partway through sampling on gfx1101 with ROCm 7.2.0 — Docker, clean venv, custom nodes disabled, the lot. It was eventually closed by the reporter with a conclusion worth quoting:

"As it appears, it has been a fault on my end all along... discovered the main perpetrator to be an unnoticed 'voltage offset' set into my 'Default' GPU profile which I was using all along. It wasn't too much to notice from day-to-day use (-225mV) but was significant enough to alter edge-case scenarios like these."

So: before you spend an evening on kernels, put the card back to stock. Clear any undervolt, any curve offset, any memory-timing tweak, and retest. Diffusion sampling is a far harsher stability test than the game you validated the undervolt on, and this failure mode looks exactly like a software bug.

Why is the image pure black on ROCm?

Black means the tensor went to NaN somewhere before or during decode. On AMD there are three distinct routes to that, and they take three different fixes.

Route 1 — a bf16 code path the arch does not survive. #14249, on a gfx1151 Strix Halo box, has native PiD pixel-space sampling emitting NaN in bf16: the run finishes suspiciously fast, the image is black, and the console shows

RuntimeWarning: invalid value encountered in cast
  img = Image.fromarray(np.clip(i, 0, 255).astype(np.uint8))

The reporter's finding is clean and specific: --force-fp32 produces a correct image, the Z-Image Turbo base stage is fine either way, and the NaN originates only inside the PiD stage. Note that they were already running --fp32-vae — so a full --force-fp32 was required, not just an fp32 decode.

python main.py --force-fp32

That is the sledgehammer. It costs memory and speed everywhere in the graph, so treat it as a diagnosis, not a permanent setting: once it proves the failure is precision-related, you can hunt for a cheaper fix on the specific stage that NaNs.

Route 2 — a quantisation format your arch has kernels for, but broken ones. #15084 is the sharpest report in this whole family, because the reporter isolated it with a 2×2 matrix on an RX 9070 XT (gfx1201, Windows 11, torch 2.9.1+rocm7.2.1):

The UNET column decides it. The identical quantisation format is fine in the text encoder and NaNs in the diffusion model, which is why "my quantised model is broken" is the wrong summary — only the diffusion path is. The fix is a file swap, not a flag: download the fp8_scaled build of the same model. The reporter notes int8_convrot is meaningfully faster for them, so this is a real cost, and the issue was still open at the time of writing.

Route 3 — a memory manager returning garbage. #15436 has grey (not black) images on gfx1201 with ROCm 7.14 wheels and dynamic VRAM enabled, alongside a HIP allocator OOM warning in the log and video renders that complete every step then die at save with av.error.ArgumentError. Turning dynamic VRAM off fixed it; so did going back to the ROCm 7.13 wheels; and the reporter later confirmed AMD's own nightlies after 18 August cleared it. If your grey frames started with a driver or wheel upgrade, that is the shape of the bug.

If none of those three routes fits, the cause is probably not AMD-specific at all. fp16 VAE overflow, the wrong VAE for the checkpoint's latent space, and a stale warm model under the memory manager all produce the same uniform frame on any vendor's hardware — the memory-management and VAE sections of our complete ComfyUI guide are the better starting point for those.

Why does the text encoder crash with a HIP invalid-argument error?

This one has a name, a commit and a pending fix, so it is worth recognising on sight. The failure looks like this:

torch.AcceleratorError: CUDA error: invalid argument
Search for `hipErrorInvalidValue' in https://rocm.docs.amd.com/projects/HIP/en/latest/index.html for more information.
CUDA kernel errors might be asynchronously reported at some other API call, so the stacktrace below might be incorrect.

That is copied from the log in #15647, and the traceback lands in nodes_minimax_h3.py → clip.encode_from_tokens_scheduled. Note what the error text itself tells you: HIP reports launch failures asynchronously, so the line the traceback points at is not the line that failed. The reporter traced the real failure to the optimized_attention call in the Qwen3-VL vision tower one loop above.

The mechanism, per the report, is a regression from commit 2220d111 (PR #15412). Before it, aotriton_supported() listed the torch/lib/aotriton.images directory; on builds where that directory does not exist the resulting FileNotFoundError escaped to a bare except: pass and pytorch attention was quietly left off. After it, the function probes with a small tensor and returns True — so on gfx1201 with ROCm ≥ 7.0, ComfyUI enables flash SDPA on a build that has no kernel images to run it with. The reporter's own one-line reproduction, outside ComfyUI entirely:

python -c "import torch; print('built:', torch.backends.cuda.is_flash_attention_available()); q=torch.empty((1,1,8,64),dtype=torch.float16,device='cuda'); p=torch.backends.cuda.SDPAParams(q,q,q,None,0.0,False,False); print('can_use:', torch.backends.cuda.can_use_flash_attention(p,True))"

On the affected build that prints built: True and can_use: True while torch/lib/aotriton.images is absent. PR #15648 — "Verify aotriton kernels actually launch before enabling pytorch attention" — fixes it by running a real flash-attention op and forcing a throwaway launch to surface the pending error. It was still open when this was written, so check before you work around it.

The workaround, and where it comes from. The reporter's confirmed fix was patching aotriton_supported() to return False. If you would rather not edit source, read the guard around that call in model_management.py:

if args.use_split_cross_attention == False and args.use_quad_cross_attention == False:
    if aotriton_supported():  # AMD efficient attention implementation depends on aotriton.

Passing either of those two flags skips the whole AOTriton block, so ENABLE_PYTORCH_ATTENTION is never set on the AMD path:

python main.py --use-split-cross-attention

That inference is ours, read straight off the source; it is not what the issue reporter tested, and split cross-attention is a slower attention path than SDPA. Treat it as the no-source-edits option, not as the recommended end state. If you want to understand what you are trading away — and what --use-flash-attention, --use-sage-attention and --use-ck-attention do instead — that is its own subject, covered in SageAttention and Flash Attention errors in ComfyUI.

Also worth knowing from the same report: the affected commit sits inside a shared try block with the SUPPORT_FP8_OPS detection, so it silently flipped fp8 op support on too. The reporter judged that harmless on gfx1201, where fp8_e4m3fn is native, but it explains why more than one behaviour changed at once.

What if it runs, but suddenly 20 times slower?

Check your own environment variables before you file a bug. #15674 is titled "ComfyUI on Radeon RX 9070 XT is unusable" and reads like a driver catastrophe: the default template that used to finish in well under a second was taking over a minute, the whole desktop went unresponsive during generation, and the reporter had already reinstalled ComfyUI, the venv and torch.

The resolution, in their own words:

"I found the culprit for my slow speed. When i updated to Rocm 7.14 i added a new variable to my startup script. It was: export COMFYUI_ENABLE_MIOPEN=1. I disabled it and now it runs almost as it used to be."

That variable is not folklore, and it is not junk — it is real, it is named in ComfyUI's source as AMD_ENABLE_MIOPEN_ENV, and it is recommended in AMD's own ROCm blog post on ComfyUI attention backends. Here is what it does, from model_management.py:

if os.getenv(AMD_ENABLE_MIOPEN_ENV) != '1':
    torch.backends.cudnn.enabled = False  # Seems to improve things a lot on AMD
    logging.info("Set: torch.backends.cudnn.enabled = False for better AMD performance.")

Setting it to 1 suppresses ComfyUI's AMD default. That is a legitimate thing to want if you have tuned MIOpen for your workload, and a disastrous thing to inherit from a copy-pasted startup script if you have not. The tell is a missing log line: if Set: torch.backends.cudnn.enabled = False for better AMD performance. is absent from your startup output and your arch is newer than RDNA2, something in your environment turned it off.

The same principle applies to PYTORCH_ALLOC_CONF, TORCH_ROCM_AOTRITON_ENABLE_EXPERIMENTAL, FLASH_ATTENTION_TRITON_AMD_ENABLE and TORCH_ROCM_FA_PREFER_CK, all of which circulate in AMD optimisation guides. Print your environment and audit it before you audit ComfyUI.

Which launch flags actually matter on AMD?

Read from comfy/cli_args.py on master. Help text is quoted verbatim from the file.

One flag deserves an explicit warning. --fast is described in the source as "Enable some untested and potentially quality deteriorating optimizations. This is used to test new features so using it might crash your comfyui." That is the maintainers' own wording. If it is in your launch script from a tutorial, take it out before you debug anything else.

The arch allow-list is also worth knowing, because it explains why two AMD owners get different behaviour from the same flags. In model_management.py, pytorch attention is auto-enabled only when AOTriton reports usable and the arch is one of gfx90a, gfx942, gfx950, gfx1100, gfx1101, gfx1150, gfx1151 on torch ≥ 2.7 — or, separately, gfx1200 / gfx1201 on ROCm ≥ 7.0. If your arch is outside both sets, you were never on that path to begin with.

What should you try, in order?

Change one thing at a time and keep the console visible. The order matters because the cheap tests eliminate the most cases.

1. Read the arch and ROCm version off the startup log. Everything else is indexed by those two lines.
2. Put the GPU back to stock. Undervolt off, curve offset off, memory timings default. #12839 ended here after weeks.
3. Print your environment. COMFYUI_ENABLE_MIOPEN, PYTORCH_ALLOC_CONF, FLASH_ATTENTION_TRITON_AMD_ENABLE, TORCH_ROCM_FA_PREFER_CK. #15674 ended here.
4. Classify the failure. Uniform black or grey = numerical. Noise or mosaic = a wrong-but-finite kernel. A traceback = an unsupported launch. They do not share a fix.
5. If it is numerical, test --force-fp32 once. Not as a setting — as a yes/no answer to "is this precision?"
6. If it is a quantised checkpoint, swap the build. int8 → fp8, or fp8 → GGUF. #15084 is the argument for doing this before anything else on RDNA4.
7. If it is a crash in the text encoder, get off the flash-attention path. Then check whether PR #15648 has merged.
8. If it is RDNA1/RDNA2 and it hangs, --disable-triton-backend.
9. Only then, change the ROCm wheel. It is the slowest test and the one most likely to introduce a new variable. When you do, note that #15585 documents real packaging differences between wheels — 2.12.0+rocm7.14.0 shipping libaotriton_v2.so without the kernel-image directory, 2.13.0+rocm7.2 shipping both.

If you are still deciding what to buy rather than fixing what you have, our RX 9070 XT for local AI and Radeon RX 7900 XTX write-ups cover the same two archs from the other end, and the AMD ROCm setup guide covers getting the runtime installed in the first place.

What we could not verify

Being explicit about this, because a page like this is easy to pad:

• We did not reproduce any of it. Every failure, environment and fix above is attributed to a named GitHub issue or read out of ComfyUI's source. We do not have a 7900 XTX, a 9070 XT, a 9060 XT and a Strix Halo box on a shelf, and inventing a bench for them would make this page worse, not better.
• No performance numbers appear here at all. Several of the linked issues contain timings. They are single-machine, single-configuration measurements taken during a bug, and republishing them as though they characterise an architecture would be dishonest. The AMD ROCm blog linked above is the place to go for backend comparisons.
• Half these issues are open and will move. #15314, #15084, #15647, #15585 and #14249 were open when this was written; #15653, #15436, #14868 and #12839 were closed. PRs #15648, #15586 and #15525 were all unmerged. Click through before you rebuild your workflow around a workaround.
• The arch allow-lists in model_management.py change. They carry TODO: more arches comments in the source. Read your own copy rather than trusting a table, including this one.
• One inference is ours, and it is labelled. The --use-split-cross-attention route around the AOTriton regression is derived from the source guard, not from a tested report. We say so where it appears.

FAQ

Does --force-fp32 fix black images on every AMD card?

No — it fixes the case where the failure is genuinely a precision overflow, which is what #14249 documents on gfx1151. On gfx1201, the black-image report in #15084 is a quantised-kernel problem in the diffusion path, and no precision flag addresses it; the fix there is loading an fp8_scaled build of the model instead of the int8_convrot one. Use --force-fp32 as a one-shot diagnosis to find out which of the two you have.

My 7900 XTX generates noise on one model and is fine on everything else. Is my ROCm broken?

Probably not. #15314 is exactly that pattern on gfx1100: MiniMax H3 produces noise across every quantisation and backend combination while the video VAE decodes correctly and other workflows are unaffected. When one model family breaks and the rest of your library is fine, the suspect is a per-model quantised kernel, not your runtime. Test a second model family before you reinstall anything.

Why does the traceback point at torch.cat when the problem is attention?

Because HIP reports kernel launch failures asynchronously, which the error message itself warns about: "CUDA kernel errors might be asynchronously reported at some other API call, so the stacktrace below might be incorrect." In #15647 the visible frame was torch.cat in the Qwen3-VL vision tower while the actual failure was the optimized_attention call in the loop above. On ROCm, read the traceback as "somewhere near here", not "here".

Is it safe to set COMFYUI_ENABLE_MIOPEN=1?

Only deliberately. It suppresses ComfyUI's default of setting torch.backends.cudnn.enabled = False on AMD archs newer than RDNA2 — a default whose source comment says it "seems to improve things a lot on AMD". In #15674 that single variable, picked up from a ROCm optimisation guide, was what made a 9070 XT slower than the reporter's old Vega 56. If you have not tuned MIOpen for your specific workload, leave it unset.

Should I turn the comfy-kitchen Triton backend on?

It depends entirely on whether your arch has the matrix cores its INT8 kernels need — WMMA on RDNA3 and RDNA4, MFMA on CDNA. Per #14868, RDNA1 and RDNA2 have neither, and the INT8 path hangs the GPU rather than falling back, which is why --disable-triton-backend exists. On RDNA4 the picture is still moving: one commenter on that same thread reports an "unspecified launch failure" at the first step on RDNA4 under Windows with the Triton backend auto-enabled.

My AMD build worked last month and broke after an update. Where do I start?

With the two things that changed and are not ComfyUI: the ROCm wheel and your environment. #15436 was a ROCm 7.14 wheel regression that the 7.13 wheels did not have and AMD's post-18-August nightlies fixed. #15674 was an environment variable added during a ROCm upgrade. #15647 was a ComfyUI commit, but even there the trigger was a torch build shipping without AOTriton kernel images. Pin one variable at a time and you will find it faster than by reinstalling everything.

Sources

• ComfyUI — comfy/model_management.py (AMD arch lists, AOTriton probe, COMFYUI_ENABLE_MIOPEN) and comfy/cli_args.py (flag names and help text), master, release v0.33.1 published 13 Aug 2026
• AMD ROCm Blogs — "Understanding Attention Algorithms and Their Backends for Image and Video Generation" (20 July 2026)
• Comfy-Org/ComfyUI issues #12839, #14249, #14868, #15084, #15314, #15436, #15585, #15647, #15653, #15674
• Comfy-Org/ComfyUI pull requests #15412, #15586, #15648