Sent out on Wednesday was the latest AMDGPU/AMDKFD driver pull request of new feature code ready for DRM-Next as the staging area ahead of the upcoming Linux 7.2 kernel. This doesn't yet land the HDMI 2.1 enablement work that's finally been taking place but it is preparing for that with the FRL register headers now in place as part of this merge.
Timur Kristóf of Valve's Linux open-source graphics driver team isn't done driving new improvements to aging AMD GCN 1.0/1.1 era graphics cards on Linux. Beyond enhancing display support for older APUs, transitioning GCN 1.0/1 GPUs from the legacy Radeon driver to modern AMDGPU driver, and a host of other fixes and optimizations for these old GPUs going back to the Radeon HD 7000 series, he has another notable addition that was announced today. These original GCN graphics cards with pending patches to the AMDGPU kernel driver and Mesa user-space can now allow for DRM format modifiers.
The open-source Radeon "R300g" driver living within the Mesa codebase for supporting the aging ATI (AMD) Radeon 9500 "R300" through Radeon X1000 "R500" series graphics processors is going through a big code restructuring as part of a big undertaking in 2026... Yes, 24 years after the ATI R300 GPUs first released, thanks to a devoted open-source developer fan, there is a significant improvement in the works.
At the beginning of the month was the surprise milestone of AMD posting AMDGPU kernel driver patches for HDMI 2.1 Fixed Rate Link (FRL) support. The HDMI FRL patches have since been updated to also enable HDMI 2.1's Display Stream Compression (DSC) functionality for higher resolutions and higher refresh rates with the open-source AMDGPU driver.
Merged today to Mesa 26.2-devel was a reorganization of the AMD RadeonSI Gallium3D driver code to better separate the graphics and multimedia acceleration code from the rest of the driver.
Sent out today was a batch of "new stuff" for the AMDGPU graphics and AMDKFD compute kernel drivers that are ready for DRM-Next to queue until the Linux 7.2 merge window happens in June. Most notable is the introduction of the AMDGPU DC power module to better align with the Radeon power management behavior under Microsoft Windows.
Since last November we've begun seeing new open-source driver activity for their next-gen GPU IP with their GFX12.1 graphics engine. GFX12 (12.0) was for the Radeon RX 9000 series RDNA4 hardware while GFX 12.1 is some new revision for yet-to-be-known products while there is also GFX13 bring-up and GFX12.5 too.
It's not complete HDMI 2.1 support but to much surprise hitting the mailing list today were official patches from AMD for implementing HDMI Fixed Rate Link "FRL" support for their kernel graphics driver. HDMI FRL as part of HDMI 2.1+ allows for higher bandwidth to support higher refresh rates and resolutions.
The newest Mesa Radeon Vulkan driver "RADV" feature enabled by AMD engineers is protected memory support using the Trusted Memory Zone (TMZ) support on newer GPUs.
Merged overnight to the latest Mesa graphics driver development code is enabling the VPE 2.0 engine to be found with future AMD Radeon GPUs.
Canonical announced last year that in collaboration with AMD they would be bringing the ROCm software libraries into the Ubuntu archive for Ubuntu 26.04 LTS. The plan has been to ship AMD ROCm AI/ML and HPC libraries in the Ubuntu archive so it would be as easy as sudo apt install rocm for getting started with AMD's open-source GPU compute stack. With today being the Ubuntu 26.04 LTS release day, I decided to revisit the topic.
Introduced back in 2023 with Vulkan 1.3.258 was VK_EXT_host_image_copy to copy data between host memory and images on the host processor without needing to stage the data through a CPU-accessible buffer. This direct CPU-to-GPU image data transfer path can reduce memory usage during asset loads and all around more efficiency and performance. Finally now the RADV open-source Radeon driver is enabling support by default.
Timur Kristóf of Valve's Linux graphics driver team is the one that worked on improving the old AMD Radeon GCN 1.0/1.1 graphics card support by making AMDGPU driver improvements so it could become the default for these Southern Islands and Sea Islands GPUs rather than the legacy Radeon kernel driver. That meant better performance, RADV Vulkan support out-of-the-box, and other benefits. More recently he finished AMDGPU improvements for Kaveri and other GCN 1.1 era APUs. Now Timur's out with some more fixes for helping select GCN 1.0 hardware.
The open-source Linux graphics driver work continues around AMD's GFX11.7 GPU target for some yet-to-be-launched APUs/SoCs and to be branded as "RDNA 4m".
With the set of today's AMDGPU kernel graphics driver Display Core (DC) patches is a rather curious addition with wiring up the Linux code to a "power module" that looks like it will better match Microsoft Windows behavior with the AMD Radeon driver around display-related power savings features.
As a big helper for Valve's Steam Play with DXVK and VKD3D-Proton, the Mesa Radeon Vulkan driver "RADV" has merged its initial support for the VK_EXT_descriptor_heap Vulkan extension.
For those wishing to make use of modern OpenCL 3.0 capabilities on AMD APUs/SoCs with integrated Radeon graphics using Mesa's Rusticl driver, an improvement was merged this weekend to the RadeonSI driver ahead of this quarter's Mesa 26.1 release.
With Linux 6.19 AMD GCN 1.1 and GCN 1.1 dGPUs now default to the AMDGPU driver rather than the legacy Radeon Linux driver. For these Southern Islands and Sea Islands graphics cards it means much better performance, RADV Vulkan support out-of-the-box, and other improved functionality in using this modern AMDGPU kernel graphics driver on Linux. One of the exceptions has been the GCN 1.1 APUs like Kaveri still defaulting to the older Radeon driver but a patch has been volleyed to make that change.
With Linux 7.0-rc6 having released on Sunday, we are hitting the point of the cut-off of new feature material being allowed into the Direct Rendering Manager's DRM-Next tree of queuing new graphics/display/accelerator feature code ahead of the upcoming Linux 7.1 merge window. As presumably the last AMDGPU/AMDKFD feature pull ahead of Linux 7.1, today's pull request from AMD contains some noteworthy final enhancements.
For those wanting to make use of Linux GPU compute software under Windows 11 by way of Windows Subsystem for Linux (WSL2), AMD's ROCDXG "librocdxg" library is now deemed production-ready for delivering open-source ROCm compatibility with WSL.
The open-source RadeonSI Gallium3D driver with Rusticl for modern Rust-based OpenCL is nearing formal OpenCL 3.0 conformance with all necessary OpenCL test cases passing. Making this all the more interesting is that this is the first modern AMD graphics hardware in a decade likely to see formal recognition for OpenCL conformance with AMD having not submitted any of their own OpenCL conformance results since 2015.
The Mesa Radeon "RADV" Vulkan driver has added new low-latency Vulkan Video encode/decode options for those seeking better performance.
It's fairly rare for the RadeonSI Gallium3D driver to hit OpenGL rendering game bugs these days as besides more games going opting for Vulkan API use, RadeonSI is rather robust and very mature at this stage. Recently though a Linux gamer that upgraded to a Radeon RX 9070 XT RDNA4 graphics card noticed that the open-source EDuke32 Duke Nukem 3D build and its derivatives were failing to render properly with the RadeonSI driver.
Another round of AMDGPU/AMDKFD kernel driver improvements were sent out this week as feature development for DRM-Next ahead of Linux 7.1 begins to wind down.
Back in February AMD engineers introduced a new GFX1170 GPU target in LLVM for their AMDGPU shader compiler and was marked with new "RDNA 4m" branding. It's part of the GFX11 family associated with RDNA3 but carrying this new "4m" branding. In follow-up commits they made further ISA changes distinguishing it from existing RDNA 3 GPUs. Now there are two more RDNA 4m targets being added.
Merged overnight for Linux 7.0 and set to be back-ported to existing Linux stable kernel versions is a fix for aging AMD GCN 1.0 "Hainan" GPU models. This closes a 2021 bug report that was long neglected and ended up being just a small tweak to fix the issue reported of GPU hangs.
Last week yet more AMDGPU kernel graphics driver updates were submitted to DRM-Next ahead of the Linux 7.1 merge window happening in April.
A fix is on the way to the Linux 7.0 kernel today for addressing an idle power issue with AMD RDNA4 GPUs reporting high power consumption and full utilization even after being "idle" following compute workloads like Llama.cpp.
Introduced with Linux 6.19 was the long in development DRM Color Pipeline API while it's not the end of the road yet on enhancing the Linux desktop for modern high dynamic range (HDR) displays and color pipeline handling. AMD engineer Harry Wentland has more improvements pending for the AMDGPU driver as well as example compositor/desktop-side integration with KDE's KWin.
In Mesa 26.1 the Radeon Vulkan driver "RADV" has finally landed support for the VK_KHR_copy_memory_indirect extension that was introduced to the Vulkan API last year.
AMD has begun staging AMDGPU and AMDKFD kernel driver improvements for the upcoming Linux 7.1 cycle.
The Radeon R300 series turns 24 years old this year and thanks to the open-source ATI R300 Gallium3D driver that began via reverse engineering, it's still continuing to see the occasional random fixes from the open-source community.
AMD open-sourced the ROCprof Trace Decoder "rocprof-trace-decoder", a tool useful for developers targeting the AMD GPU compute stack.
It was less than four years ago that the modern AMDGPU/AMDKFD open-source driver stack was at four million lines of C code and header files. Now with the Linux 7.0 kernel it has surpassed six million lines. Or put another way, by the same calculations Linux 7.0-rc1 is at 39.2 million with the modern AMD kernel graphics driver now making up 15% of the kernel's entire codebase as the single largest driver.
Timur Kristóf of Valve's open-source Linux graphics driver team has been doing a fantastic job enhancing the older AMD Radeon GPU support under Linux. Last year he made enough improvements to the AMDGPU open-source driver that older Radeon GCN 1.0/1.1 dGPUs switched over to AMDGPU by default for nice performance gains, RADV Vulkan driver support out of the box, and all around better experience than using the legacy Radeon driver. He's also been fixing countless bugs affecting older AMD GPUs. There is another improvement on the way for benefiting some with aging AMD GPUs.
Earlier this month we spotted the addition of a new GFX1170 GPU target in the AMDGPU LLVM back-end. Making this GFX1170 target interesting is that its marked as an APU/SoC part with "RDNA 4m" while being part of the GFX11 series. The GFX11 series is for RDNA3, GFX115x is for RDNA 3.5, and GFX12 is RDNA4. More ISA changes have now been committed to the AMDGPU LLVM back-end that make a few more instruction differences better aligned with RDNA4.
One of the limitations of the AMDGPU Linux kernel graphics driver has been the lack of its support for HDMI 2.1 and later. AMD has wanted to support HDMI 2.1+ functionality under Linux but it's been legally blocked by the HDMI Forum. But anxious independent users have been working on open-source patches for wiring up HDMI 2.1 into the AMDGPU driver outside of the realm of AMD and the HDMI Forum's blessings.
In addition to their ongoing AMDGPU LLVM compiler back-end work for upcoming GFX1250 and recently the GFX13 target for their graphics IP, today AMD compiler engineers introduced a new "GFX1170" target to the LLVM codebase that is also called RDNA 4m.
Timur Kristóf of Valve's Linux graphics team last year addressed remaining issues in the open-source AMDGPU kernel graphics driver so old AMD GCN 1.0 and GCN 1.1 GPUs could transition to using AMDGPU by default rather than the former "Radeon" kernel driver that is largely in maintenance mode for pre-GCN/RDNA GPUs. One caveat though was the GCN 1.1 APU support still having some limitations leading to Kaveri and friends not being able to use the modern AMDGPU DC "Display Core" code. But new patches from Timur take care of those limitations.
A patch series posted last week for the open-source AMDGPU kernel driver implements HDMI Variable Rate Refresh "VRR" and other gaming features for HDMI displays. With the HDMI Forum blocking HDMI 2.1 open-source support, these HDMI gaming features for the AMDGPU driver were developed via trial-and-error and the limited public knowledge available. A second iteration of these patches are now available for testing.
This week's batch of AMDGPU and AMDKFD changes queued up ahead of the next kernel merge window is focused on delivering a variety of driver fixes.
Merged on Friday as part of this week's DRM kernel graphics driver fixes for the week is addressing a regression affecting many different users with the Linux 6.19 development kernel.
While slightly too late for making it into the Mesa 26.0 release that branched yesterday, merged now to Mesa Git for Q2's Mesa 26.1 release are some new RadeonSI Gallium3D (OpenGL) driver optimizations for the latest AMD Radeon RDNA4 graphics cards.
Mesa 26.0 was due to be branched last week and in turn start its feature freeze but ended up being pushed back to tomorrow (21 January) to allow some lingering features to land. It's been beneficial for the Radeon Vulkan driver "RADV" with several interesting merge requests having landed in time for Mesa 26.0.
Last year Valve contractor Timur Kristóf managed to improve the AMDGPU driver enough for old GCN 1.0 Southern Islands and GCN 1.1 Sea Islands GPUs that with Linux 6.19 AMDGPU is now the default for those GPUs with better performance, RADV Vulkan out-of-the-box, and other benefits. He isn't done though improving the old GCN 1.0/1.1 era GPU support on this modern AMDGPU kernel driver - a new patch series posted today brings some power management fixes.
Support for newer HDMI features in the open-source AMD Linux graphics driver have been limited due to being blocked by the HDMI Forum. There are though some new HDMI gaming features being enabled via new AMDGPU kernel driver patches that are coming outside of AMD and based on public knowledge and/or "trying things out until they work/break" for functionality like HDMI Variable Refresh Rate (VRR) and Auto Low Latency Mode.
There have been a number of nice RADV driver Vulkan ray-tracing performance optimizations for Mesa in recent times... Here is yet another merge request now merged for Mesa 26.0 and helping deliver some nice performance uplift for ray-traced games on Linux. And, yes, this is yet another Valve contribution to this open-source AMD Radeon Linux graphics driver.
On Friday AMD sent out another set of AMDGPU kernel graphics driver and AMDKFD kernel compute driver patches for queuing in DRM-Next ahead of the upcoming Linux 6.20~7.0 kernel cycle kicking off in February.
Separate from the Mesa merge request talked about earlier today for new RADV code that can deliver 10x faster ray-tracing pipeline compilation for this open-source Radeon Vulkan driver, another merge request landed today in Mesa 26.0 that was also carried out by Valve contractor Natalie Vock. That second merge request now in Mesa 26.0 delivers some additional gains for at least some ray-tracing games on RDNA3 and RDNA4 GPUs.
A new merge request opened today for Mesa's Radeon Vulkan driver "RADV" by Valve contractor Natalie Vock provides another significant boost for the Vulkan ray-tracing performance in multiple titles.
2113 Radeon news articles published on Phoronix.