AMD preps its open-source Linux driver for GDDR7 memory ahead of RDNA5

September 21, 2026. AMD posts a batch of patches to the AMDGPU kernel driver. A single string. The patch adds “GDDR7” to the list of video memory types the driver recognizes. 2027. The year the first RDNA5 cards with GDDR7 could launch. Why it matters: one line of code in the Linux kernel announces AMD’s next GPU generation months before any official launch.

The patch, spotted by Michael Larabel at Phoronix, looks trivial on its surface. It adds the “GDDR7” identifier to an enumeration of memory types — a change of a few lines. But in the way AMD develops its graphics drivers, that small string is a strong signal: it ties the IP blocks recently added to the driver to a next-generation GPU architecture.

Reading a roadmap in kernel patches

The GDDR7 patch does not arrive alone. The same day, AMD posted patches enabling two new IP blocks: IH 8.0, the interrupt handler, and NBIF 7.10, the latest version of the New Bus InterFace that links the GPU to the rest of the die. Other small patches make more mundane preparation changes for the new hardware.

These blocks add to work already underway. AMD recently introduced Display Core Next 6 (DCN6), the sixth generation of its display engine, plus several GFX 13.0.x patches — the graphics-core generation that succeeds RDNA4’s GFX 12. Put together, these pieces outline the skeleton of a future RDNA5 architecture.

That is how you read an AMD roadmap on Linux: the company makes no announcement, it pushes patches. Each IP block and each memory identifier is a piece of a puzzle the community reassembles into a picture of the coming hardware, often months before marketing says a word.

Decoding the IP blocks

To understand what these patches announce, you have to read the names. AMD structures its hardware into IP blocks — reusable functional subsystems carried from one generation to the next. GFX is the graphics core itself; DCN (Display Core Next) handles display; IH (Interrupt Handler) processes hardware interrupts; NBIF (New Bus InterFace) links the GPU to the rest of the die over the bus.

The September 21 patches add IH 8.0 and NBIF 7.10, two blocks carrying version numbers never seen before. Combined with DCN6 and the GFX 13.0.x work already in flight, they describe a generation that is not a simple evolution of RDNA4: it is a new foundation, with new controllers, a new bus, and a renumbered graphics core.

For observers, each numbered block is a marker. When AMD moves from one block version to the next, it usually signals an architectural change, not a refresh. The simultaneity of these moves — DCN6, GFX 13, IH 8.0, NBIF 7.10 — is what makes the case for an RDNA5 in preparation so strong, even with no official announcement on the table.

Why GDDR7 is a milestone

GDDR7 is the video-memory generation that follows GDDR6. It delivers substantially higher bandwidth, which is needed to feed wider GPUs and local AI workloads. NVIDIA already uses it on its GeForce RTX 50 desktop cards, while AMD’s current RDNA4 generation stays on GDDR6.

Moving to GDDR7 is therefore not trivial. It is one of the markers that separates one GPU generation from the next, alongside a new graphics core or a new display engine. By adding the memory type to the driver, AMD confirms that GDDR7 is part of the next generation — without having to say so explicitly.

The rest is informed rumor. Reports suggest first RDNA5 cards in 2027 at limited volume, then a widening in 2028 given the supply constraints across the industry. Nothing official, but consistent with the pace at which AMD is preparing its driver.

The structural advantage of open source

What separates AMD from its rival NVIDIA is the timing of software enablement. AMD develops its AMDGPU driver directly in the Linux kernel, ahead of card launches. The result: when an RDNA5 card ships, its driver will already have matured for months in the mainline tree, tested by the community and integrated into distributions.

The contrast with the NVIDIA ecosystem is instructive. NVIDIA’s proprietary driver arrives at launch, and the open-source Nouveau driver has historically lagged the hardware. On Linux, a recent AMD GPU generally works from day one with a free driver and no proprietary blob to install by hand.

For a workstation, a compute server, or a rendering box running Linux, that difference translates into hours of administration saved and greater stability. It is one reason AMD has become the default choice for many Linux users on recent graphics.

A history of upstream enablement

This way of working is nothing new for AMD. Since 2015 and the introduction of the amdgpu driver in the Linux kernel, the company has enabled its graphics hardware upstream, often six to twelve months before cards launch. The Polaris, Vega, RDNA, RDNA2, RDNA3, and RDNA4 generations all followed this path: patches land first on the amd-gfx list, then in successive kernels, then in distributions.

The userspace ecosystem follows the same principle. Mesa, with the RADV (Vulkan) and RadeonSI (OpenGL) drivers, develops support for the same IP blocks in parallel. The result: a recent Linux user gets, for an AMD card, a fully free graphics stack from the kernel up to the graphics API, with no proprietary blob to install.

The contrast with NVIDIA remains the clearest illustration of the benefit. NVIDIA did open its kernel modules in 2022, but its proprietary userspace driver still holds most of the logic, and the open-source Nouveau/NVK driver had to claw back years of gap. For compute, rendering, and gaming on Linux, that strategic difference has made AMD the smoothest choice — and these GDDR7 patches show the strategy is still running.

What this changes for users

For the user, today’s news changes nothing immediate. No card is on sale, and these patches target the in-development Linux 7.4 kernel, not a stable release already deployed. What they provide is visibility.

They confirm the next RDNA5 generation is under active preparation and that its Linux support will follow the same path as prior generations: early enablement, a free driver, and distribution integration before launch. For anyone planning a graphics purchase in 2027, that is a data point worth folding in.

They also remind us of the value of watching the kernel mailing lists. The amd-gfx list at freedesktop.org, where these patches were posted, is an earlier and more reliable source than most marketing leaks. Architecture decisions are visible there months before they become products.

Verdict

If you run Linux on AMD hardware, there is nothing to do today: these patches target a future generation and will reach your distribution when the time comes, as they did for RDNA4. If you are planning a GPU purchase in 2027, note that RDNA5 will most likely carry GDDR7 and that its Linux support will be ready at launch, with no proprietary driver needed. If you follow Linux hardware, add the amd-gfx list to your reading: that is where AMD’s roadmap shows up first, well before any press release.

References

• Phoronix — AMD Begins Preparing Open-Source Linux Driver For Graphics Cards With GDDR7 (September 21, 2026)
• freedesktop.org — amd-gfx, patch adding the GDDR7 identifier
• VideoCardz — AMD adds GDDR7 support to Linux driver ahead of next-gen Radeon GPUs
• Phoronix — AMD-DCN6-Linux-Start (Display Core Next 6)