ROCm doesn't support your AMD card — HSA_OVERRIDE and Vulkan

Name: LLM Configurator — GPU VRAM Checker
Author: LLM Configurator

Linux

Written by Jakub Rusinowski · Last updated September 1, 2026

Founder, LLM Configurator — AI educator & workshop leader on local LLM deployment

The error

Error: no compatible GPUs were discovered

HSA Error: HSA_STATUS_ERROR_OUT_OF_RESOURCES

hipErrorNoBinaryForGpu: Unable to find code object for all current devices!

Which one is it?

If you see	The cause is	Go to
`rocminfo` lists a CPU agent but no GPU agent	ROCm does not target your card, or the driver stack is not installed	Fix 1: confirm what ROCm sees
`hipErrorNoBinaryForGpu` naming a gfx target	ROCm ships no kernels compiled for that architecture	Fix 3: override to the closest supported target
`rocminfo` works under sudo and not as your user	Device permissions, not ROCm support	This is the /dev/kfd page, not this one
ROCm refuses the card but Ollama still finds a GPU	The Vulkan backend is doing the work instead	Fix 4: lean into Vulkan rather than fighting ROCm
It runs after an override, then hangs or emits garbage	The override is wrong for this architecture	Fix 6: read the honest limits of HSA_OVERRIDE

When you see it

The card is installed, the kernel sees it, and the compute stack will not claim it. Depending on which layer you ask, you get a different flavour of the same refusal — an empty agent list, an error about missing code objects, or Ollama simply announcing that it found no compatible GPUs.

You have a consumer Radeon that is not on ROCm's supported list — an RX 5000-series card, an older RDNA part, or an APU.
You installed ROCm from your distribution's repositories rather than AMD's installer.
Ollama ran on the CPU from the first launch and has never used the GPU.
A tutorial told you to set HSA_OVERRIDE_GFX_VERSION and now inference hangs or produces nonsense.
You have two AMD GPUs and only one of them is being used.

What's actually going on

AMD compute on Linux goes through ROCm, which ships pre-compiled kernels for a specific list of LLVM targets — the gfx numbers. Your card reports its architecture, ROCm looks for kernels built for it, and if none exist the stack declines rather than falling back. That is what hipErrorNoBinaryForGpu says almost literally. Ollama on Linux now expects the AMD ROCm v7 driver, installed through AMD's amdgpu-install, and its supported list covers the Radeon RX, Radeon AI PRO, Radeon PRO, Ryzen AI and Instinct families. A card outside that list is not broken and is not necessarily unusable — it simply has no kernels, which is why the two ways forward are to lie about the architecture (HSA_OVERRIDE_GFX_VERSION) or to take a different path to the GPU entirely (Vulkan).

How to fix it

1. Find out what ROCm actually sees, and what target your card reports

Everything downstream depends on two facts: whether ROCm enumerates a GPU agent at all, and which gfx target the card reports. rocminfo gives you both. If it lists only a CPU agent, either the driver stack is absent or the card is unsupported. If it names a gfx number, write it down — that number decides which override, if any, has a chance.

bash

# bash
rocminfo | grep -E "Marketing Name|gfx|Agent"
amd-smi version
amd-smi list

# Which kernel driver is bound to the card?
lspci -k | grep -A3 -iE "vga|display"

Did it work? A GPU agent with a gfx target means ROCm can see the hardware. Only a CPU agent means it cannot, and fix 2 comes before anything else.

rocminfo | grep -c gfx

2. Install the ROCm v7 stack with amdgpu-install

Ollama expects the ROCm v7 driver on Linux, installed via AMD's own amdgpu-install. Distribution-packaged ROCm is often an older major version, and a mismatch between the bundled ROCm libraries and the kernel driver produces failures during GPU discovery that look like unsupported hardware. After installing, put the ROCm library paths on the loader search path — this step is easy to skip and produces link errors later that look unrelated. Verified against Ollama's GPU documentation and AMD's ROCm installation docs, 1 September 2026.

bash

# bash — follow AMD's current instructions for your distro and release
sudo amdgpu-install --usecase=rocm

# Post-install: put ROCm on the loader path
echo -e "/opt/rocm/lib\n/opt/rocm/lib64" | sudo tee /etc/ld.so.conf.d/rocm.conf
sudo ldconfig

Did it work? rocminfo names your card and amd-smi reports a version. If discovery still fails here, the card is genuinely outside ROCm's support and fixes 3 and 4 are your options.

rocminfo | grep -i "Marketing Name:"
amd-smi version

3. Force the closest supported target with HSA_OVERRIDE_GFX_VERSION

For a card ROCm does not target, you can tell it to use kernels built for a near relative. Ollama's own worked example is the RX 5400, which reports gfx1034; ROCm does not support that target, and the closest supported one is gfx1030, giving HSA_OVERRIDE_GFX_VERSION=10.3.0. The value is the gfx number written as a dotted version. On a machine with several AMD GPUs there is a per-device form — HSA_OVERRIDE_GFX_VERSION_0, _1 — so you can override one card without touching the other. Because Ollama runs as a systemd service, set this in a service drop-in rather than in your shell.

bash

# bash — one GPU
sudo systemctl edit ollama.service
# [Service]
# Environment="HSA_OVERRIDE_GFX_VERSION=10.3.0"

# Several GPUs, overriding only the first
# Environment="HSA_OVERRIDE_GFX_VERSION_0=10.3.0"
# Environment="HSA_OVERRIDE_GFX_VERSION_1=11.0.0"

sudo systemctl daemon-reload && sudo systemctl restart ollama
journalctl -u ollama --no-pager -n 40

Did it work? The log reports a GPU rather than falling back to CPU, and a loaded model shows GPU placement.

ollama run gemma3:1b "hi" && ollama ps

4. Try Vulkan — often the more stable path on consumer Radeons Most common fix

Ollama ships a Vulkan backend, enabled by default on Linux and Windows when the backend is installed. On Linux that usually means installing the Vulkan runtime for your distribution; Windows drivers tend to bundle it. This path frequently works on cards ROCm will not target, and without the fragility of an architecture override. GGML_VK_VISIBLE_DEVICES selects a device (=1 picks the discrete GPU on a machine that also has an integrated one), and OLLAMA_VULKAN=0 or GGML_VK_VISIBLE_DEVICES=-1 turns it off — worth checking neither is set before you conclude Vulkan does not work.

bash

# bash — Ubuntu / Debian
sudo apt install -y libvulkan1 mesa-vulkan-drivers vulkan-tools
vulkaninfo --summary | head -20

# Fedora
sudo dnf install -y vulkan-loader mesa-vulkan-drivers vulkan-tools

# Pick the discrete GPU when an iGPU is also present
sudo systemctl edit ollama.service
# [Service]
# Environment="GGML_VK_VISIBLE_DEVICES=1"

Did it work? vulkaninfo --summary lists your Radeon as a physical device, and Ollama reports GPU rather than CPU placement.

vulkaninfo --summary | grep -i -A2 deviceName
ollama ps

Check what fits your hardware — see which models run acceptably on your AMD card or on CPU
Open the VRAM checker →

5. Fix the permissions and VRAM reporting Vulkan needs

Two Linux-specific details bite after Vulkan is installed. The ollama service user must be in the render group on distributions where the device nodes are owned by it, or the service cannot open the GPU even though your own account can. And accurate VRAM reporting may need the cap_perfmon capability on the binary — without it Ollama can misjudge available memory and place layers badly, which looks like a performance problem rather than a permissions one.

⚠️ setcap cap_perfmon+ep grants a performance-monitoring capability to the ollama binary for every user who can run it. It is documented for this purpose; grant it knowingly, and re-apply it after upgrades since a replaced binary loses it.

bash

# bash
sudo usermod -a -G render,video ollama
sudo setcap cap_perfmon+ep /usr/local/bin/ollama
sudo systemctl restart ollama

# Confirm both took
groups ollama
getcap /usr/local/bin/ollama

Did it work? groups ollama includes render, getcap shows the capability, and the log reports plausible VRAM for your card.

journalctl -u ollama --no-pager -n 30 | grep -i -E "vram|memory|gpu"

6. Be honest about what HSA_OVERRIDE can and cannot do

The override is a hack, and pretending otherwise wastes people's evenings. It is reliable for gfx1030-class overrides — the RDNA2 family it was popularised on — and flaky elsewhere, because you are running kernels compiled for different hardware and nothing checks that the assumption holds. The practical consequence matters: a hang, a crash, or garbage output after setting an override is the override's fault, not the model's. If you see any of those, unset it before you go looking for a quantisation problem. On a card ROCm genuinely will not support, Vulkan or CPU is usually the more stable answer, and choosing it deliberately beats fighting the override for a week.

bash

# bash — remove the override and re-test cleanly
sudo systemctl edit ollama.service   # delete the HSA_OVERRIDE_GFX_VERSION line
sudo systemctl daemon-reload && sudo systemctl restart ollama
systemctl show ollama --property=Environment

Did it work? With the override gone, output is coherent again — which tells you the override was the cause rather than the model or the quant.

ollama run gemma3:1b "Write one sentence about the sea."

If none of this worked

If rocminfo works under sudo and not as your user, this is a permissions problem rather than a support problem and the /dev/kfd page fixes it in one command. If you are running ROCm in containers, the device-group and SELinux details are on the Docker page.

Include this when you report it

Output of rocminfo | grep -E "Marketing Name|gfx" and amd-smi version
Your card model and the gfx target it reports
The value of any HSA_OVERRIDE_GFX_VERSION you have set, and where you set it
journalctl -u ollama --no-pager -n 50 around the failed discovery

A model that fits most setups:

View model & requirements →

Frequently asked questions

What does HSA_OVERRIDE_GFX_VERSION actually do?

It tells ROCm to treat your GPU as a different LLVM target so it loads kernels compiled for that architecture instead. Ollama's documented example is the RX 5400, which reports gfx1034; the closest supported target is gfx1030, so the value is 10.3.0.

Is the override safe?

It is reliable for gfx1030-class overrides and unpredictable beyond them, because the kernels assume hardware you do not have. Hangs, crashes and garbage output after setting one are caused by the override. Unset it before investigating anything else.

Should I use ROCm or Vulkan on an unsupported Radeon?

Vulkan, usually. Ollama enables it by default on Linux when the backend is installed, and it frequently works on cards ROCm will not target without needing an architecture lie. ROCm remains the better choice on cards it actually supports.

Why does Ollama see no GPU when rocminfo does?

Most often because the ollama service user lacks render-group membership, so the service cannot open a device your own account can. Accurate VRAM reporting under Vulkan may also need cap_perfmon on the binary. Both are one command each.

Which ROCm version does Ollama expect?

ROCm v7, installed via AMD's amdgpu-install, on Linux — and a ROCm v7 / HIP7-capable driver stack on Windows. Distribution packages are often an older major version, and the mismatch shows up as failures during GPU discovery.