synthesis · RDNA3 · ROCm · vLLM

Eight ROCm kernel findings narrow to three on RDNA3,
and measuring another vendor removed two

Eight findings on RDNA3 classified across five hardware axes; checked against another vendor, kernel sources, and host topology

This repository's own summary describes RDNA3 as a second-class citizen in ROCm's kernel ecosystem, with eight write-ups grouped under that heading. Sorted by what the evidence actually supports, three of the eight are that. The rest are AMD-wide, vendor-neutral, or unrelated to the GPU — and separating them is the difference between a diagnosis and a grievance.

2× RX 7900 XT · gfx1100 8 findings · 16 upstream threads statuses checked 2026-08-29

Abstract

The claim is real, but narrower than it appears. What survives as architecture-specific is a short list: a fast attention path this hardware falls off, a native quantised-linear kernel whose type gate excludes a common checkpoint class, and a performance heuristic written into one architecture's branch of a function while omitted from the other.

The purest instance is one line. use_rocm_custom_paged_attention requires gqa_ratio >= 3 on gfx11 and >= 1 on CDNA, for the same kernel. In the excluded range that kernel is 1.84× to 7.28× faster than the fallback it is passed over for, and the two bands overlap. The bound does not separate anything.

Four of the eight are not RDNA3 problems. Two are vendor-neutral on distinct evidence. The same attention gate was measured on an A100, where it loses 61 % at 50K. In addition, the single-threaded compile setting was traced to a file that runs on every platform. One is AMD-wide, at a kernel line AMD named. One is a PCIe capability that hits bare metal too.

Half of the sixteen upstream threads belong to other people. The most useful role for this hardware was simply being the machine that upstream developers lacked.

1Sorting eight findings by what they are actually about

Each row below represents a separate article. Every number beside it is recomputed directly from the underlying data file. Only the classification represents an interpretive judgement, and each row carries the evidence that places it on its axis.

Figure 1 · what each finding is an instance of recomputable from repo

Figure 1. Sorted by axis, not by size. The magnitudes are not comparable to each other — they are ratios of different things, each meaningful only against its own article's baseline — and they are here to say which findings are worth an afternoon rather than to rank them. The three marked as architecture-specific are the ones where the same software makes a different decision on this hardware than on another AMD part.

2The purest instance is one line

If "second-class" has a precise meaning, it means identical software choosing differently for one architecture than another, for a reason that fails empirical checking. A single function in vllm/platforms/rocm.py does exactly that:

Figure 2 · the same kernel, two branches, one condition apart recomputable from repo

Figure 2. The bound is a performance heuristic — the pull request that added it says so — and measured on this hardware it is inverted: the excluded range is where the gated-out kernel helps most. Below, the four ecosystem gaps this repository's architecture notes list, extracted from that document. They are the structural version of the same thing: the fast path exists, and the supported-hardware list does not include this part.

Two of those four gaps require distinction. AITER and FP8 are Instinct-only by design, reflecting an intentional product boundary rather than a software defect. The absent tuned MoE configurations exist for no AMD GPU at all, making them an AMD-wide omission rather than an RDNA3 limitation. Only Composable Kernel's forward-only fused attention on RDNA3 sits squarely on the architecture axis, alongside the gate above.

3The four that are not this

The measurements that mattered most were the ones that took a finding off this list.

Two were settled by measuring another vendor Speculative decoding collapse at long context appeared to be an RDNA3 issue. When tested on a rented A100, however, the same model lost 61 % at 50K through the identical Triton kernel, and recovered on a backend without that guard. Similarly, a 128-expert MoE recorded at 15 tok/s initially suggested missing ROCm tuned kernels. The actual cause was an assignment in env_override.py that executes on every platform. See one report and the other.

One is AMD-wide, at a line AMD named Weight loading ran slower than disk reads because kfd_svm.c inspected the access mode directly from the VMA. A read-only copy requested write permissions, breaking copy-on-write across every resident page. That kernel file is not architecture-specific. AMD confirmed the underlying mechanism, and an independent user reproduced the failure on a different card. See the full write-up.

One is not about the GPU at all Every RCCL collective failed at dispatch because the PCIe root port above the card lacked the AtomicOps capability. This failure reproduces on bare metal and has no dependence on the installed GPU. For a virtual machine, the fix requires a single line of host configuration. See the RCCL write-up.

A fifth case warrants separate distinction because it reflects host topology rather than the silicon. The 2D attention path launches one workgroup per KV head. Splitting a model across two cards halves the available KV heads, causing compute starvation to double. That penalty is an inherent cost of tensor parallelism. The single-card control measured here — an A100 running the identical kernel — does not pay it. See the dual-card comparison.

4What the hardware turned out to be for

Sixteen upstream threads originated from this work. The split tells the story: eight are ours, while eight belong to external contributors where this test bench provided measurements they could not gather themselves.

Figure 3 · every thread, and where it stood on 2026-09-09 check with gh api

Figure 3. Status as read from the API on the date shown, not from memory — these move, and a page that says "open" forever is wrong within weeks. Two are merged. One, by its own author, closed the larger half of a problem this repository had spent a month characterising through a different kernel; the other, the V-cache padding fix, merged on 2026-09-08 with this repository's gfx11 evidence in its thread. Two more had gfx11 as their explicit gap: their authors had validated on Instinct and said so in their test plans.

That is the realistic value of consumer cards to this software ecosystem. The goal was never raw benchmark throughput: running on a VFIO guest without peer-to-peer over a cross-die PCIe 3.0 link establishes only a lower bound. Their genuine utility lies in bridging an empirical gap: providing the physical hardware that developers lack, allowing compile-only validation plans to be verified against live execution.

5What is not established

The classification is a judgement

While each magnitude recomputes and each note cites evidence, assigning findings to axes remains an argument. Two of the eight could occupy different columns: the W4A16 type gate is a bug located in an architecture-specific kernel, while the absent tuned MoE configurations are AMD-wide within an RDNA3 evaluation.

One machine, one software generation

Measurements reflect gfx1100 on a VFIO guest across two vLLM generations and two ROCm versions. Whether these findings apply to RDNA4 was not measured. The repository notes expect the gap to extend there, but that statement reflects documentation audits rather than benchmark runs.

Whether the gaps are closing

One upstream pull request merged during this study, resolving half of one finding; a second, the V-cache padding fix, merged on 2026-09-08, after this page's first reading. Those resolutions indicate progress, but do not prove an ongoing trend. The data records where gfx11 support stood at the time of testing, not the velocity of upstream development.

6What has changed since

2026-07-14 · one of the three narrowed by itself Upstream pull request vllm#40977 merged, adding a second native kernel that accepts the checkpoint type the first one refuses. The finding survives — eight of twelve asymmetric configurations still have no kernel on gfx1100 — but its headline example does not: the model that decoded at 11.41 tok/s reaches 37.32 on current main.

2026-08-20 · one was fixed by a distro, not by a report Canonical shipped the missing kernel commit in 7.0.0-30. The Launchpad bug asking for exactly that backport is still untriaged, so it arrived through the standard stable release track. Reporting an issue and having it resolved remain separate events; this repository records one of each.

Statuses expire Figure 3 represents a point-in-time snapshot. Everything in it except the two merges was open on 2026-09-09, and the proper use of the page is to inspect the direct links rather than rely on the table status.

2026-08-29 · the Chinese axis label claimed exclusivity Figure 1's Chinese label for the architecture axis previously read RDNA3 特有, and 架构特有 appeared in four additional places. While 特有 translates as "unique to", the English text specifies "specifically". This article's argument is that findings are narrower than claimed, not that they are exclusive to this part. Both now read 特定. The masthead date chip originally read 状态核对于, which is not idiomatic; it now reads 状态核查于.

2026-08-29 · a campaign that sorted into two of these bins, and one case first filed between them Twenty configurations across the two Radeons and a rented A100 produced one finding in each category, putting this taxonomy into practice. Vendor-neutral: vllm#45450 has effect only when the patched Triton kernel is actively executing. Because Qwen3.8-27B bypasses that kernel on both platforms — selecting ROCM_ATTN here and FLASH_ATTN on CUDA — the patch remains installed but idle on each. AMD-wide: ROCm's selector opts for ROCM_ATTN because TURBOQUANT cannot run with the decoder. That choice concedes 15.0 % at 32K context that TRITON_ATTN — listed in the candidate options it displayed — would have preserved. And a case this article first filed between the bins, which turned out to be vendor-neutral too: gemma-4 fails to start on the 0.27 ROCm image. vLLM 0.27's Gemma4 converter reads a global head_dim through a getattr fallback that expects AttributeError, and transformers 5.x's per-layer accessor raises its own exception instead; the AMD Quark frame in the traceback only forwards the call. Upstream vLLM fixed the read in vllm#49797, which 0.28.0 carries and 0.27.1 does not, and the same checkpoint serves on 0.28.0 on CUDA. It is a version pairing the ROCm image shipped, not a fault in either vendor's code alone; whether a newer image serves it is unmeasured.

The eight articles. the hybrid-SSM collapse · two problems in one model · the gqa gate · weight loading · the MoE and eager mode · speculative decoding · two Radeons against an A100 · the RCCL crash. Methodology is detailed in its own article, and the negative result protocol is in another.

The full ecosystem survey is in docs/architecture-notes.md. All figures on this page recompute directly from repository data via verify_doc_figures.py.