ROCm on consumer Radeon GPUs

AMD's ROCm compatibility matrix is written around Instinct datacenter cards first — official consumer Radeon support arrives later, and only for specific chips (see GPU target (gfx)), not a whole product line at once. This page pulls the consumer-card angle out of the full ROCm version list and GPU spec collection: 19 consumer Radeon cards, which ROCm release first covered each one, which 4 AMD has never validated at all, and which one has had support withdrawn.

Which cards are covered, and since when

ROCm grants support per gfx target, not per card, so cards sharing a die share a fate — the RX 6800, 6800 XT, 6900 XT and 6950 XT are all gfx1030 and were all covered the moment gfx1030 was. That also cuts the other way: two cards one model number apart can land on different targets with years between their support dates.

The popular cards with no ROCm support at all

4 of the 19 cards above have never appeared in any ROCm release's supported-target list — not in 5.x, not in 6.x, not in 7.x, not in 10.x:

• Radeon RX 6700 XT — gfx1031, Radeon RX 6700 XT / 6750 XT (Navi 22) — no ROCm support
• Radeon RX 6600 — gfx1032, Radeon RX 6600 / 6600 XT / 6650 XT (Navi 23) — no ROCm support
• Radeon RX 6650 XT — gfx1032, Radeon RX 6600 / 6600 XT / 6650 XT (Navi 23) — no ROCm support
• Radeon RX 6750 XT — gfx1031, Radeon RX 6700 XT / 6750 XT (Navi 22) — no ROCm support

This is the single most common source of confusion about ROCm on Radeon. The RX 6700 XT sits between the RX 6600 and the RX 6800 in AMD's own product stack, and the cards on either side of it in that stack are different dies: the 6800 is Navi 21 (gfx1030, supported since ROCm 5.0.0), while the 6700 XT is Navi 22 (gfx1031, supported never). Nothing in the product name signals that. If you are buying a used card specifically for ROCm work, check the target, not the tier.

The gap between launch and ROCm support is shrinking — with one big exception

Lining up each card's launch date against its first supporting ROCm release shows AMD closing the gap generation over generation:

• The RX 6800 / 6800 XT (RDNA 2, launched 2020-11) didn't get official support until ROCm 5.0.0 in 2022-02 — about 15 months. The later RX 6950 XT (2022-05) shipped into an already-supported target, so it worked on day one.
• The RX 7900 XTX and XT (RDNA 3, launched 2022-12) waited about 12 months, until ROCm 6.0.0 in 2023-12.
• The RX 7800 XT and 7700 XT (RDNA 3, 2023-09) didn't land until ROCm 6.3.0 in 2024-12 — about 15 months, and three releases after the gfx1100 cards they share an architecture generation with. Support isn't uniform even within one generation, since each gfx target is added on its own schedule.
• All four RDNA 4 cards tracked here — RX 9070 XT, 9070 (launched 2025-03) and RX 9060 XT in both memory configurations (2025) — got official support in ROCm 6.4.0 (2025-04). For the 9070 pair that is about one month, the fastest turnaround of any consumer card on this page.

The exception is the RX 7600 XT. It launched 2024-01 on Navi 33 (gfx1102), and gfx1102 appears in no ROCm release before ROCm 7.14.0 in 2026-07 — roughly a two-and-a-half-year wait, the longest of any card here, and it arrived after the RDNA 4 cards that launched a year later. Newer architecture generations are being onboarded faster, but a lower-tier die within an older generation can be left waiting far longer than the trend suggests.

Practical takeaway: a brand-new Radeon card is not a safe bet for ROCm on day one, and neither is an older budget one. Check this table (or the card's own GPU page, which lists every compatible ROCm version) before assuming a given GPU works.

Support can also be taken away

Everything above is about support arriving. It can also be withdrawn, and this table has a case of it:

• Radeon VII (gfx906) — supported from ROCm 4.5.0, but listed by no currently-supported release.

For gfx906 (Vega 20) the window was ROCm 4.5.0 through 6.0.2 (2024-01-31); 6.1.0 (2024-04-16) dropped it. It is the only gfx target this site tracks that has ever lost support — every other one either gained support and kept it, or never had it. The practical consequence is that the Radeon VII reads as supported in any guide, blog post or Stack Overflow answer written before April 2024, and is a dead end on every current release.

Retiring old targets is not an AMD peculiarity, and the scope of that sentence matters: it is a claim about ROCm's gfx targets, not about this site as a whole. Asked of theCUDA data, the same question returns 4 NVIDIA architectures — Kepler, Maxwell, Pascal, and Volta — that earlier toolkits supported andCUDA 13.3 does not, since it lists compute capability 7.5 and up. That covers 7 cards in this collection against 1 on the AMD side. Both vendors retire hardware; ROCm's single case is notable here only because it landed on a card people still buy for its bandwidth.

That card is worth the paragraph because its specs still tempt people: 16 GB of HBM2 at1024 GB/s is more memory bandwidth than any consumer Radeon released since, the RX 7900 XTX (960 GB/s) included, and it sells cheaply second-hand. The bandwidth is real. The support is gone. Your options are pinning to ROCm 6.0.x — which is end-of-life, so no fixes and no new framework builds — or sidestepping ROCm altogether via Vulkan, below.

The general lesson for this whole page: "supported" is not a permanent property of a card. Check the release you are actually installing, not a claim from two years ago.

Using a card ROCm doesn't officially list

A gfx target missing from the table above doesn't always mean the card is unusable today — it means AMD hasn't validated it. The community workaround is the HSA_OVERRIDE_GFX_VERSION environment variable, which tells ROCm's runtime to treat the installed GPU as a different, officially-supported gfx target from the same architecture family. For the two unsupported RDNA 2 cards above that means HSA_OVERRIDE_GFX_VERSION=10.3.0, borrowing gfx1030's ABI — the version string is the target number written as major.minor.step, so gfx1030 becomes10.3.0 and gfx1100 becomes 11.0.0.

It works because chips in the same family usually share an instruction set even when only one of them is in AMD's support matrix — but it's an unofficial, self-managed workaround, not something this site's compatibility data reflects: it can break between ROCm releases, kernels tuned for the impersonated target can be slower or numerically different, and results vary by workload. Treat it as a way to try a card, not as equivalent to official support.

ROCm isn't the only path

If your card isn't in the table and the override route doesn't appeal, the other option is to stop needing ROCm. llama.cpp ships a Vulkan backend alongside its HIP/ROCm one — it has its own build instructions in the project'sdocs/build.md and two dedicated CI workflows (build-vulkan.yml and a self-hosted one running on real hardware), so it's a maintained build path rather than an experiment.

What makes that relevant here: Vulkan doesn't care about gfx targets. It needs a conformant Vulkan driver, not an entry in AMD's compatibility matrix — so it covers thegfx1031 and gfx1032 cards above that ROCm has never supported, with no HSA_OVERRIDE_GFX_VERSION involved and nothing to break on the next ROCm release.

On performance, this site has no numbers and won't invent any. It's commonly reported in the local-LLM community that Vulkan matches or beats ROCm for llama.cpp inference on consumer Radeon cards. We haven't measured it, this site doesn't publish benchmarks, and results depend heavily on card, driver, model and quantisation. Treat it as a path worth testing on your own hardware, not as a settled result.

What Vulkan does not replace: it's an inference path for llama.cpp-class engines. If you need PyTorch, custom HIP kernels, vLLM, or anything doing training or finetuning, you need the ROCm stack — and therefore a card whose gfx target is actually in the table above. The choice only exists for inference.

Picking a card for local LLMs today

VRAM capacity binds before compute does for inference, so the ordering here is mostly a memory-capacity ordering. See the VRAM calculator for whether a specific model fits a given card, and Compare GPUs to set any two side by side. Among the 14 officially-supported consumer Radeon cards tracked here:

• The RX 7900 XTX (24 GB) pairs the most VRAM of any consumer Radeon with the longest official ROCm track record — still the safest pick. The RX 7900 XT (20 GB) shares its gfx1100 target and support history, so it carries the same software story with 4 GB less headroom.
• The RX 9070 XT and RX 9070 (16 GB) are RDNA 4, the first Radeon generation with native FP8 matrix support and the fastest ROCm onboarding so far. They have less real-world track record than the 7900 series simply by being newer.
• For 16 GB on a budget, the RX 7600 XT and RX 9060 XT (16GB) fit the same models as the 9070 at much lower cost — but at 288 and 320 GB/s respectively, versus 640 GB/s on the 9070, they generate tokens considerably slower. The 7600 XT additionally needs ROCm 7.14.0 or newer, so it is not an option on an older pinned toolchain.
• The RX 6950 XT / 6900 XT / 6800 XT / 6800 (16 GB, gfx1030) are the cheapest supported 16 GB route and have the longest support history of all, but RDNA 2 has no matrix/AI accelerator cores at all — their FP16 numbers are packed-math vector rates, not matrix throughput, which shows up in prompt-processing speed.
• Avoid the 8 GB cards for this workload — the RX 9060 XT (8GB) is supported but capacity-bound almost immediately; run anything you plan to load through the VRAM calculator first.

If 16 GB is the wall you're hitting, the way out isn't a consumer card. The Radeon AI PRO R9700 is a workstation part, so it isn't in the table above, but it carries 32 GB on the same gfx1201 target as the RX 9070 XT — same ROCm support from 6.4.0 onward, same 640 GB/s bandwidth, double the capacity, plus ECC (Linux only). Nothing about your ROCm version or toolchain changes; only how much fits.

← All ROCm versions · All GPUs →