AMD GPU Not Supported by ROCm? HSA_OVERRIDE Values

Short answer: set HSA_OVERRIDE_GFX_VERSION to the nearest supported gfx target in your card's own family, written as major.minor.stepping — 10.3.0 for RDNA 2 cards below the RX 6800 (RX 6600/6700 series), 11.0.0 for RDNA 3 parts ROCm has not validated by name. And check first whether you need it at all: as of ROCm 7.14, RDNA 4, the RDNA 3 desktop line and the Ryzen 780M/860M/890M/8060S iGPUs are all officially supported, and an override on those is more likely to break your install than fix it.

The variable does exactly one thing: it changes the architecture string the runtime reports for your GPU, so the loader picks a different pre-compiled code object. It does not recompile anything, it does not add features, and when the substituted target is from a different instruction-set generation it will happily hand you corrupted output instead of an error.

---

Which ROCm Error Message Are You Seeing?

If your terminal shows one of these strings, you are in the right place:

• hipErrorNoBinaryForGpu — the HIP error name. Its human-readable form in ROCm's own error table is "no kernel image is available for execution on the device". It means the fat binary contained no code object matching your GPU's target.
• invalid device function — the string for hipErrorInvalidDeviceFunction, and the one PyTorch surfaces most often. Same root cause, different call path.
• device ID 0x**** is not supported in libhsakmt — logged by the ROCm topology layer when the kernel-thunk library has no entry for your PCI device at all.
• HSA_OVERRIDE_GFX_VERSION <value> is invalid — you set the variable, but not in major.minor.stepping form. This is a hard error, not a warning.
• failure during GPU discovery ... error="failed to finish discovery before timeout" with bootstrap discovery took duration=30s — this one is not a support problem. See the driver section below.

The first four come from ROCm's HIP error table, the libhsakmt topology source and the ROCm runtime; the last is quoted from Ollama's troubleshooting documentation.

---

How Do I Find My gfx Target?

Nothing else on this page is usable until you know your card's LLVM target name, and there are two one-line commands that print it.

# The direct route — every ROCm install ships this
rocminfo | grep -i gfx

# The clean route — prints just the target names, one per line
rocm_agent_enumerator

rocm_agent_enumerator is a small Python tool shipped with rocminfo; it runs rocminfo, matches lines of the form amdgcn-amd-amdhsa--gfxNNNN and prints the targets. If it prints nothing, or prints only gfx000, your problem is device access or the kernel driver, not GPU support — jump to the section on causes that an override cannot fix.

Note that rocminfo reports your CPU as an agent too. The GPU is the agent with a nonzero compute-unit count; the gfx string you want is the one that is not gfx000.

Deriving the override value from the target. The runtime parses the variable as three decimal numbers, so read your gfx name the same way — the last digit is the stepping, the digit before it is the minor version, and everything before that is the major version:

The runtime rejects anything that is not exactly three numbers, with major ≤ 63, minor ≤ 255 and stepping ≤ 255. HSA_OVERRIDE_GFX_VERSION=11.0 is not a shorthand — it is an error that aborts topology setup.

---

Which HSA_OVERRIDE_GFX_VERSION Value Does My Card Need?

The one table this page exists for: product name, gfx target, whether ROCm 7.14 supports it officially, and what to set if it does not.

Support status is read from AMD's ROCm 7.14.0 compatibility matrix (dated 2026-07-16). Product-to-target mappings are from AMD's GPU specifications reference and the LLVM AMDGPU processor table. Where LLVM lists a target's product names as "TBA" — gfx1032 and gfx1034 are both in that state — the mapping is the long-established community one from rocminfo output, and we have flagged it rather than dressing it up as official.

How to set it, per tool:

# One-off, for a single command
HSA_OVERRIDE_GFX_VERSION=10.3.0 ollama serve

# For the systemd service (survives restarts)
sudo systemctl edit ollama
# then add:
#   [Service]
#   Environment="HSA_OVERRIDE_GFX_VERSION=10.3.0"
sudo systemctl daemon-reload && sudo systemctl restart ollama

# Per-GPU, when your machine has two different AMD targets
export HSA_OVERRIDE_GFX_VERSION_0=10.3.0
export HSA_OVERRIDE_GFX_VERSION_1=11.0.0

The per-node form is real, not folklore: the topology code builds the name HSA_OVERRIDE_GFX_VERSION_<node_id> and checks it before falling back to the global variable. Ollama's hardware documentation describes the same mechanism.

---

What Does HSA_OVERRIDE_GFX_VERSION Actually Do?

It rewrites the reported architecture of a device node. That is the entire mechanism, and it explains every quirk on this page.

In ROCm's kernel-thunk topology code, the variable is read while a GPU node's properties are being assembled, parsed as major.minor.stepping, and stored in the node's override engine-ID field — a separate field from the real one that was read off the hardware. Downstream, the code-object loader asks for a binary matching the reported architecture and gets one built for a chip you do not own.

Three consequences follow directly:

1. It cannot add capability. If the code object uses instructions your silicon lacks, you get an illegal-instruction fault or silent garbage. Nothing checks.
2. It only works within an ISA family. gfx1031, gfx1032 and gfx1034 are RDNA 2 variants of gfx1030 that differ in configuration rather than instruction set, which is why 10.3.0 is safe there and why the same trick across gfx10 to gfx11 is not.
3. It is global by default. One value applies to every AMD node in the system unless you use the numbered form. On a mixed box that is how you convert a working GPU into a broken one.

There is a fourth, quieter consequence: AMD does not document this variable in ROCm's official environment-variable reference. It is a runtime implementation detail that the community turned into a support policy. That is precisely why the mapping in this article does not exist in AMD's docs and has to be assembled from the compatibility matrix, the LLVM target table and the runtime source.

---

What If It Is Not an Override Problem at All?

Before you set anything, rule these out — they present identically to "unsupported GPU" and an override will not touch them. We have ordered them by how cheap they are to check, not by a frequency figure we cannot honestly measure.

1. Device permissions (/dev/kfd)

Ollama's troubleshooting documentation states plainly that AMD GPU access on Linux typically requires video and/or render group membership to reach /dev/kfd. Check and fix:

ls -l /dev/kfd /dev/dri
groups                      # are you in render and video?
sudo usermod -aG render,video $USER
# log out and back in — group changes do not apply to a live session

2. Containers missing the device groups

This is the same problem wearing a hat. Numeric group IDs inside the container will not match the host's names, so pass them numerically:

ls -lnd /dev/kfd /dev/dri /dev/dri/*   # read the numeric GID column
docker run --device /dev/kfd --device /dev/dri \
  --group-add 44 --group-add 105 \
  ollama/ollama

On SELinux distributions, containers may also need sudo setsebool container_use_devices=1 on the host — Ollama documents this as a distinct failure.

3. A kernel driver older than the userspace stack

If discovery hangs for thirty seconds and then falls back to CPU, this is your cause. Ollama bundles ROCm 7 libraries that require a compatible ROCm 7 kernel driver; on a ROCm 6.x or older driver, GPU initialisation hangs during device discovery and times out. The log signature is the failure during GPU discovery / failed to finish discovery before timeout pair quoted earlier. The fix is upgrading the driver with AMD's amdgpu-install utility, then rebooting — not an override.

4. A leftover override on a now-supported card

ROCm 7.14 supports far more silicon than the stack that most of the internet's advice was written against. If you added HSA_OVERRIDE_GFX_VERSION to .bashrc or a systemd drop-in in 2024 for a 780M or a Strix Halo box, remove it and retest before anything else. A wrong override on supported hardware is a very common cause of the exact errors people then go looking for override advice about.

env | grep HSA_OVERRIDE          # is one already set?
systemctl show ollama -p Environment

Diagnostics worth turning on while you work through this:

AMD_LOG_LEVEL=3 OLLAMA_DEBUG=1 ollama serve
sudo dmesg | grep -i amdgpu
sudo dmesg | grep -i kfd

AMD_LOG_LEVEL=3 raises the HIP/ROCm libraries to info level and surfaces the underlying error codes; OLLAMA_DEBUG=1 adds detail during GPU discovery. Both are documented in Ollama's troubleshooting guide.

---

When Should I Use Vulkan Instead of ROCm?

There are now three distinct states, and only the middle one is an override problem: officially supported, unsupported-but-close-enough-to-override, and genuinely dead on ROCm — where Vulkan is the answer rather than a consolation prize.

Ollama ships a Vulkan backend that is enabled by default when the backend is installed on Windows and Linux. On Windows most vendor drivers already include Vulkan; on Linux you usually need to install a Vulkan driver (Mesa's RADV or AMD's own package). Two practical notes from Ollama's documentation:

• The AMD Vulkan path on some distributions needs the ollama user in the render group.
• Vulkan does not expose available-VRAM data without extra capability, so the scheduler falls back to approximate model sizes. Granting it fixes scheduling accuracy:

sudo setcap cap_perfmon+ep /usr/local/bin/ollama

To steer or disable it:

GGML_VK_VISIBLE_DEVICES=1     # pick the discrete GPU on a mixed iGPU/dGPU box
OLLAMA_VULKAN=0               # turn Vulkan off entirely

Take the Vulkan route for RDNA 1 cards (gfx1010/gfx1012) and for gfx906 parts like the MI50 and Radeon VII, where no current code object exists to substitute into. It is generally slower than a well-matched ROCm path, but "slower" beats "wrong answers". If you are weighing an AMD card against the alternatives before buying, our AMD vs NVIDIA vs Intel comparison is the place to start, and the MI50 guide covers that specific card's software situation in detail.

---

Can an Override Break Things Silently?

An override that "works" and an override that is quietly wrong look the same for the first few hundred tokens. Test for it deliberately.

• Gibberish output. Ollama's troubleshooting guide documents gibberish responses when models load across multiple AMD GPUs on Linux, and points to AMD's multi-GPU known-issues page. Stack an override on top of a multi-GPU box and you have two independent ways to get nonsense. Run a fixed prompt with a fixed seed, twice, and read the output before you trust the setup.
• NaNs and black images in diffusion workloads. Attention kernels are the most target-sensitive code in the stack, so this is where a wrong code object shows up first — but it is also where the override gets blamed for something else entirely. The next section separates the two.
• Global blast radius. One HSA_OVERRIDE_GFX_VERSION in a shell profile follows every ROCm process you launch, including PyTorch and ComfyUI. Prefer the systemd drop-in scoped to the service, or the numbered per-node form.
• It is not a performance tuning knob. Overriding a supported card to a "faster-sounding" target does nothing useful and can silently disable optimisations built for your actual chip.

Stop and switch to Vulkan when: the override produces wrong tokens, the process faults with an illegal instruction, or your target is more than one gfx minor version away from anything on the supported list. Grinding through more override values at that point is how people lose an evening.

For everything downstream of getting the GPU recognised — install order, distro choice, llama.cpp and PyTorch builds, tuning — the AMD ROCm local LLM setup guide is the companion page, and the complete Ollama guide covers the serving side. Once the GPU works, our 16GB VRAM model picks match what most of the cards in the table above can actually hold.

---

It Runs Now, So Why Are My Images Black?

Getting the card detected moves you to a completely different failure. Text models degenerate into repetition, image and video graphs return black frames or NaN latents — and on Windows in particular the culprit is often the attention backend rather than anything the override did.

Work out which of these you are looking at before you change the value again. The rightmost column is the cheapest thing that distinguishes them:

The flash-attention warning that names a GPU you do not own

PyTorch's ROCm path takes its scaled-dot-product-attention kernels from AOTriton, a library of ahead-of-time compiled Triton kernels, and it picks them using the architecture the runtime reports — precisely the field HSA_OVERRIDE_GFX_VERSION rewrites. When no kernel image matches, sdp_utils.cpp warns:

Flash attention was not compiled for current AMD GPU architecture. Attempting to run on architecture
Mem Efficient attention was not compiled for current AMD GPU architecture. Attempting to run on architecture

The architecture printed after that sentence is the reported one. Set an override and the warning names a chip you do not own, which is how people end up reading it as proof the override "worked" or "broke everything" when it is only echoing the string they injected. On targets PyTorch treats as not yet validated, the same file gates the kernels behind an opt-in rather than dropping them:

Flash Efficient attention on Current AMD GPU is still experimental. Enable it with TORCH_ROCM_AOTRITON_ENABLE_EXPERIMENTAL=1.

On Windows this is frequently not your fault at all. AOTriton's own README states that "AOTriton on Windows currently isn't able to build kernel images by itself" because "triton is not officially available on Windows yet", and points builders at AOTRITON_NOIMAGE_MODE plus the aotriton.images folder from a Linux build. A Windows ROCm stack can therefore be missing attention kernels on a card ROCm 7.14 lists by name — an RX 9070 XT at gfx1201 included — with no override anywhere in the picture. Unset the variable, restart, and see whether the warning changes before you go hunting for a different gfx value.

If it survives that, move the front end off the fused path instead of guessing new override values. ComfyUI's --use-split-cross-attention and --use-quad-cross-attention flags select attention implementations that do not route through PyTorch's fused SDPA, which is the fastest way to prove whether attention is the component producing the black frame.

Two neighbouring failures that look similar and are not this: a tensor landing on the wrong device throws its own distinct traceback, covered in the ComfyUI device mismatch error, and a graph that never finished loading is a node problem, not a kernel one — the complete ComfyUI guide is the setup reference for that. If you are sizing what to run once the pipeline is clean, the FLUX picks for 16GB cards cover what an RX 6800 or 7800 XT actually holds, and the RX 9070 XT guide covers the gfx1201 side specifically.

---

Verdict

The override is a smaller tool than the internet thinks, and in 2026 it is needed by a much shorter list of cards.

1. Check rocminfo first. Everything depends on the gfx string, and a great deal of the advice online is written for cards ROCm 7.14 now supports without any override at all.
2. 10.3.0 is the workhorse value — for gfx1031, gfx1032 and gfx1034, all RDNA 2 relatives of the supported gfx1030.
3. RDNA 4, RDNA 3 desktop and the modern Ryzen iGPUs need nothing. ROCm 7.14 lists them by name. If you have an override set on one, delete it.
4. Permissions and driver version cause more "unsupported GPU" reports than actual unsupported GPUs. They are two minutes to rule out.
5. If the substitution is not within the family, use Vulkan. RDNA 1 and gfx906 are not override problems, they are backend-choice problems.
6. Always check output quality after an override. The failure mode that costs you the most is the one that does not throw an error.
7. If the card is detected and the output is still wrong, look at the attention backend before the gfx value. On Windows especially, missing AOTriton kernel images produce black images and NaNs that have nothing to do with the override.

---

Sources and How This Table Was Built

• ROCm 7.14.0 compatibility matrix (published 2026-07-16) — the authoritative list of supported products with their gfx targets. Every "Official in ROCm 7.14?" cell traces to this page.
• AMD GPU specifications reference — product-name to LLVM-target mapping for Radeon, Radeon PRO, Instinct and Ryzen APUs, including the 780M/860M/890M/8060S rows.
• LLVM AMDGPU usage documentation — the processor table listing which retail products map to each gfx target, and where those names are still "TBA".
• ROCR-Runtime libhsakmt/src/topology.c — the parsing and semantics of HSA_OVERRIDE_GFX_VERSION and its numbered per-node form, including the validity limits.
• ROCm HIP error table (ROCm/clr) — the exact strings behind hipErrorNoBinaryForGpu and hipErrorInvalidDeviceFunction.
• Ollama hardware support and troubleshooting docs — the ROCm v7 driver requirement, the /dev/kfd group and container --group-add guidance, the multi-GPU gibberish note, and the Vulkan backend behaviour.
• PyTorch sdp_utils.cpp — the verbatim source of the "Flash attention was not compiled for current AMD GPU architecture" and TORCH_ROCM_AOTRITON_ENABLE_EXPERIMENTAL messages quoted above.
• ROCm AOTriton — the README statement that AOTriton cannot build kernel images on Windows, and the AOTRITON_NOIMAGE_MODE workaround.

How this page was built: every row above is a documentation lookup, not a bench result, and it is worth being blunt about that. LocalAIMaster does not own an RX 6600, a 780M laptop or an RDNA 1 card, so nothing here is presented as a measurement — the support column comes from AMD's compatibility matrix, the target mapping from the LLVM processor table and AMD's specifications reference, the variable's semantics from the ROCm runtime source, and every error string from the project that emits it. Where a mapping is community-derived rather than official — gfx1032 and gfx1034 — the table says so instead of dressing it up. If you run one of these configurations and a value is wrong for your card, send the ROCm version and the rocminfo target and the row gets corrected.

---

FAQ