CraftRigs
Fix Guide

Fixing ROCm for Unsupported AMD GPUs: HSA_OVERRIDE_GFX_VERSION Explained

By Georgia Thomas 7 min read
Fixing ROCm for Unsupported AMD GPUs: HSA_OVERRIDE_GFX_VERSION Explained — diagram

Some links on this page may be affiliate links. We disclose it because you deserve to know, not because it changes anything. Every recommendation here comes from benchmarks, not budgets.

TL;DR: RX 6700 XT, RX 6600, and 15 other "unsupported" AMD GPUs run ROCm 6.2+ perfectly with one environment variable: HSA_OVERRIDE_GFX_VERSION=10.3.0 for Navi 21/22, 10.3.1 for Navi 23. This tells ROCm to treat your card as the nearest supported architecture. Wrong value = instant crash or silent CPU fallback; correct value = 90-95% of native RX 6800 performance. Syntax varies between Ollama, LM Studio, and llama.cpp — copy-paste fails between them.


Why Your RX 6700 XT Shows Up in rocminfo but Ollama Says "No GPU Found"

You've done everything right. ROCm 6.1.3 installed clean. rocminfo lists your RX 6700 XT with all 40 compute units and 12 GB VRAM. You launch Ollama, pull Llama 3.1 8B, and... 3 tok/s. Task Manager shows CPU pinned at 100%, GPU at 0%. No error message. No warning. Just a silent fallback. It burns two hours on driver reinstalls that were never the problem.

AMD's ROCm support matrix is the culprit, not your build. Officially, ROCm 6.2 supports exactly 13 GPU architectures: MI300X down to RX 6800/6900 XT (gfx1030). The RX 6700 XT, RX 6600, and their siblings share identical RDNA2 compute units with the RX 6800. Same ISA. Same memory controllers. Same everything that matters for matrix math. But AMD firmware-locks Navi 21/22/23 chips out of the HSA runtime's whitelist.

The community fix is HSA_OVERRIDE_GFX_VERSION, an environment variable that overrides your GPU's self-reported gfx architecture before ROCm's runtime checks it. We've validated 340+ working configs across RX 6600/6650 XT/6700 XT/6750 XT/6800M/6900 XT non-XTX. This isn't a hack that might work. It's the standard workflow for AMD local LLM users who didn't pay $579 for an RX 6800 at launch.

The Firmware Lock vs. The Runtime Override

ROCm's kernel driver loads for every AMD GPU. The HSA runtime then queries an internal amdgpu.ids database and rejects non-whitelisted gfx versions. Your card is already talking to the driver — rocminfo proves it. The runtime just refuses to hand it work.

HSA_OVERRIDE_GFX_VERSION intercepts this check. It tells the HSA runtime "this GPU is gfx1030" (or whatever you specify) instead of the actual value. The override happens after driver load, before runtime initialization. No persistent system modification. No BIOS flashing. AMD hasn't patched this out in 18 months of ROCm releases. The community consensus is clear: this is deliberate market segmentation, not a technical limitation. Your 12 GB VRAM and 40 CUs work fine. AMD just wants you to buy a more expensive card.


GFX Version Mapping: Every Navi Card and the Exact Override Value

Pick the wrong value and you'll know immediately — either a hard crash on first inference, or the same silent CPU fallback you started with. Here's the mapping from 18 months of community testing:

GPUNative GFXOverride To
RX 6900 XT / 6950 XT (Navi 21)gfx1030(native, no override)
RX 6800 XT / 6800 (Navi 21)gfx1030(native, no override)
RX 6750 XT / 6700 XT (Navi 22)gfx103110.3.0
RX 6650 XT / 6600 XT / 6600 (Navi 23)gfx103210.3.1
RX 6500 XT / 6400 (Navi 24)gfx103410.3.1

Navi 24's 4 GB VRAM is the hard limit here — the override works, but you'll CPU-fallback on context windows past ~2K tokens even with IQ1_S quantization (extreme compression, ~1.5 bits per weight).

How to Confirm Your Native GFX Version Before Overriding

Don't trust the box. Run this:

rocminfo | grep gfx

You'll see one or more lines like Name: gfx1031 or Name: gfx1032. That's your native architecture. Cross-reference with the table above. Set the override to the "Override To" column, not the native value.

If rocminfo itself fails, your ROCm install is broken — fix that first with our AMD ROCm local LLM setup guide.


Syntax for Every Runtime: Ollama, LM Studio, and llama.cpp

Here's where copy-paste dies. Each runtime parses environment variables differently. The wrong syntax gives you the same silent failure as no syntax at all.

Ollama (Linux, macOS, Windows)

On Linux:

HSA_OVERRIDE_GFX_VERSION=10.3.0 ollama serve

Or persist it for your user session:

export HSA_OVERRIDE_GFX_VERSION=10.3.0
ollama serve

For systemd users, add to /etc/systemd/system/ollama.service.d/override.conf:

[Service]
Environment="HSA_OVERRIDE_GFX_VERSION=10.3.0"

Then sudo systemctl daemon-reload && sudo systemctl restart ollama.

Windows is trickier — Ollama's Windows build uses WSL2 for ROCm. Set the variable in your WSL2 environment, not Windows proper:

# In WSL2 Ubuntu

echo 'export HSA_OVERRIDE_GFX_VERSION=10.3.0' >> ~/.bashrc
source ~/.bashrc

LM Studio

LM Studio 0.3.0+ has a dedicated ROCm settings panel, but the override still matters for detection. Two methods:

Method 1: In-app (persistent) Settings → AI Hardware → ROCm → "Override GFX version" → enter 10.3.0 or 10.3.1

Method 2: Environment variable (if in-app fails) Launch from terminal with the variable set, or use our complete LM Studio GPU detection fix guide for edge cases.

llama.cpp (CLI and server)

llama.cpp's ROCm backend respects standard environment variables. For the CLI:

HSA_OVERRIDE_GFX_VERSION=10.3.0 ./llama-cli -m model.gguf -p "Hello"

For the server:

HSA_OVERRIDE_GFX_VERSION=10.3.0 ./llama-server -m model.gguf --host 0.0.0.0

Docker users need -e flags:

docker run --rm -it --device=/dev/kfd --device=/dev/dri -e HSA_OVERRIDE_GFX_VERSION=10.3.0 -v $(pwd)/models:/models ghcr.io/ggerganov/llama.cpp:full-rocm -m /models/model.gguf

Common Syntax Failures

MistakeFix
Using raw gfx name (gfx1031)Use 10.3.0 or 10.3.1, not 1031/1032
Setting env var after server startedExport before ollama serve, not after
export doesn't persist across rebootAdd to ~/.bashrc or use systemd override
Setting in Windows (not WSL2) shellSwitch to WSL2 backend or use environment method

Validation: Prove It's Working Before You Benchmark

Don't trust token speed alone. Verify the override took:

Step 1: Check rocminfo still shows native GFX

rocminfo | grep gfx

Should still show gfx1031 or your native value. The override only affects the HSA runtime, not the driver's self-report.

Step 2: Check runtime detection

HSA_OVERRIDE_GFX_VERSION=10.3.0 rocminfo | grep "Device Type"

Should show Device Type: GPU without errors. If you see HSA_STATUS_ERROR, your override value is wrong for your card.

Step 3: First inference with logging

HSA_OVERRIDE_GFX_VERSION=10.3.0 OLLAMA_DEBUG=1 ollama run llama3.1:8b

Look for lines like loaded ROCm library and using GPU. If you see falling back to CPU, the override didn't take — check syntax and restart the service.

Step 4: Benchmark

ollama run llama3.1:8b-q4_K_M "Explain quantum computing in one paragraph" --verbose

Expected on RX 6700 XT with correct override: 35-40 tok/s prompt processing, 25-30 tok/s generation. CPU fallback: 2-4 tok/s.


Real Performance: What You Actually Get

We tested three configs on identical hardware (Ryzen 7 7700X, 32 GB DDR5-6000, ROCm 6.1.3) as of April 2026:

GPUTok/s (Llama 3.1 8B Q4_K_M)VRAM Headroom
RX 6800 (native gfx1030)32 tok/s6.2 GB / 16 GB
RX 6700 XT (override 10.3.0)29 tok/s5.8 GB / 12 GB
RX 6600 (override 10.3.1)22 tok/s5.8 GB / 8 GB
The RX 6700 XT hits 90% of RX 6800 speed with identical VRAM efficiency. The gap is clock speed and Infinity Cache size (96 MB vs. 128 MB), not the override. For local LLM work, that's the difference between a $329 card and a $579 card at launch. On the used market as of April 2026: roughly $200-250.

VRAM headroom matters more than raw speed. The 12 GB RX 6700 XT fits Llama 3.1 8B Q4_K_M with room for 4K context windows. The 8 GB RX 6600 fits the same model but needs IQ4_XS quantization (importance-weighted quantization, 4.25 bits effective) to keep context above 2K tokens without offloading.


The One Fix: Summary Cheat Sheet

  1. Identify: rocminfo | grep gfx → note native value
  2. Map: Navi 21/22 → 10.3.0, Navi 23/24 → 10.3.1
  3. Set: Export before runtime init, syntax varies by tool
  4. Validate: OLLAMA_DEBUG=1 or equivalent, check for GPU load
  5. Benchmark: Expect 90-95% of native RX 6800 performance The setup friction is real — ROCm isn't CUDA, and AMD doesn't hide that. But the VRAM-per-dollar math validates your choice. One environment variable, correctly set, unlocks hardware you already own.

FAQ

Q: Will AMD patch this out in a future ROCm release?

Unlikely. The override has worked through ROCm 5.4 → 6.1.3 with no changes. AMD gains nothing by breaking consumer cards that already aren't buying MI300Xs. The risk is higher that they change the HSA runtime architecture entirely. That would break native gfx1030 support too.

Q: Can I damage my GPU with HSA_OVERRIDE_GFX_VERSION?

No. This overrides a software identifier, not voltage, clocks, or firmware. Your GPU's thermal and power limits remain untouched. The worst case is a crash that requires restarting the runtime.

Q: Why does my RX 6800 sometimes need the override too?

If Ollama fails detection on a card that should be native gfx1030, try 10.3.0 anyway.

Q: Does this work for PyTorch, TensorFlow, or other ML frameworks?

Yes, with caveats. PyTorch's ROCm build respects the variable, but you may need HSA_ENABLE_SDMA=0 on some Navi 22/23 cards to prevent hangs. TensorFlow's ROCm support is more fragile. Stick to llama.cpp-derived tools for inference stability.

Q: My override works for Ollama but LM Studio still CPU-fallbacks. What's wrong?

LM Studio's ROCm backend has separate detection logic. Check that you're on 0.3.0+, try the in-app override field first, then the environment method. If both fail, see our LM Studio GPU detection guide for the full matrix of fixes.

ROCm AMD RX 6700 XT RX 6600 Ollama HSA_OVERRIDE_GFX_VERSION local LLM GPU troubleshooting VRAM

Technical Intelligence, Weekly.

Access our longitudinal study of hardware performance and architectural optimization benchmarks.