AMD Quietly Working On New Linux GPU Driver Support Block By Block

AMD's Linux graphics driver engineers have been working on the driver support for new graphics processors and now the patches are at the earliest stages of publishing. However, due to driver handling changes, it's sharply different this time around where in the past they volleyed a big set of patches under some colorful fishy codename in an effort to conceal their hardware enablement work.

With the Radeon RX 6000 series support in good shape (as well as many more PCI IDs for the possible Navi 2 refresh / rumored RX 6x50 GPUs) various Navi 2 refresh IDs), VanGogh driver support in good shape for the Steam Deck, and the Yellow Carp / Rembrandt support settling down for the forthcoming Ryzen 6000 series mobile APUs, to no real surprise they internally would already be working on what's coming next... Plus the fact that the actual hardware enablement effort normally begins long before the product launch or even the initial open-source driver patches, due to the changes abound with each new generation plus needing to undergo various legal and internal review processes before new enablement code is published.

This time around with new hardware support it's coming out more subtly, but still enough to come up on my radar with the relentless monitoring of mailing lists and Git repositories during the hundred hour work weeks. In recent years of AMD providing pre-launch Linux driver support, for new GPU/ASIC enablement they've generally sent out the initial support as some long patch series and coming up with some colorful fishy codename like Sienna Cichlid, Yellow Carp, Dimgrey Cavefish, and others. Those Linux-specific codenames have been to help conceal the underlying product's codename but also used in the case of the GPU firmware filenames and other areas in the code. This approach though appears to be largely a matter of the past.

You may recall last year my article on the AMDGPU driver overhauling its approach to device enumeration. That fundamental driver change is about initializing the graphics card based on the IP/hardware blocks discovered rather than segmenting the driver code paths taken solely based on the graphics card PCI ID. Recent AMD GPUs support an "IP discovery table" that note the different hardware blocks comprising the GPU from the graphics engine to video encode/decode, system management / power management, security, and other IP blocks.

The AMDGPU driver is taking a new approach with their IP-based discovery.

That rework to the AMDGPU driver has already been mainlined to the Linux kernel so where for the latest GPUs it's already taking this "IP-based discovery" approach when lighting up the GPU to parse that table and take the respective code paths rather than being explicitly done based on the PCI ID. The IP-based discovery route is a win for less hard-coded information within the driver and effectively makes the driver more modularized and cleaner. This can also help with AMD on the custom SoC side by potentially needing less driver changes if it's just a matter of building a new combination of existing supported blocks. But as noted last year this would also benefit AMD in bringing up new hardware support as it can be done in a more modular manner rather than some big sequential patch series. That appears to indeed be the case with recently noticing various AMD graphics IP block versions being introduced to the driver.

The AMDGPU Linux driver is moving away from pre-defined/static configurations for the driver and more onto the "discovery" tables for discovering the different hardware/IP blocks found on the GPU being loaded.

There have been a number of different patch series to surface in recent days for bringing up new AMD Radeon graphics IP blocks such as SMU 13.0.5 for its system management unit, VCN 3.1.2 video coding, PSP 13.0.5 for security, and GC 10.3.6, among others.

This is the path moving forward it seems for their new GPUs and some mentions to "onwards ASIC" and future hardware coming up across small, unique patch series rather than the initial big patch series normally seen as part of their new hardware enablement.

The fun colorful and fishy "Linux codenames" look like they may be over...

The firmware file names also take on the block name/version rather than the fishy codenames in these new IP blocks being brought up.

Long story short, it appears AMD is moving forward on baking their new hardware support now along this IP-based discovery approach for their open-source Linux driver. Of the several different patch series posted so far, no hardware surprises found so far but still not enough code yet for a major GPU update. As for what these different blocks being enabled is for, it's possible early work towards RDNA3-based hardware. With the AMDGPU driver already having the launched GPU hardware supported plus having added in various RDNA2 "refresh" PCI IDs as well as having VanGogh and Yellow Carp (Rembrandt) already, it's quite possible early patches are beginning to flow for RDNA3 that AMD has reaffirmed will launch in H2'2022. These new patches are likely too late to be related for RDNA2 refresh graphics cards given it will be until May at the earliest before these patches would be found in a stable kernel, far off their good enablement regiment of recent launches.

Regardless of the recent patch series for new IP blocks, if AMD wants good RDNA3 GPU support at launch on the Linux desktop with the upstream driver code, they will need to get their next-gen GPU driver code out and ready for this summer. Due to the cadence of Linux kernel releases (and that of Mesa for OpenGL/Vulkan) as well as the release cycles of the prominent Linux distributions, this summer we should be seeing more patch activity clearly pointing to RDNA3 if they are aiming for good out-of-the-box support at launch with the upstream code as opposed to just their enterprise-focused packaged driver set.

In any event, great seeing more open-source Linux code from AMD and stay tuned to Phoronix for learning more.