AMD have announced the end of AMDVLK, their official open-source Vulkan driver and will instead now be focusing on the much more popular RADV.
Most people gaming on Linux will likely be using RADV anyway, since Mesa comes as pretty much the standard on Linux distributions and has Valve's backing too with it being the graphics driver used on SteamOS.
On the official AMDVLK GitHub, an announcement was posted by AMD's JianRong JIN:
In a move to streamline development and strengthen our commitment to the open-source community, AMD is unifying its Linux Vulkan driver strategy and has decided to discontinue the AMDVLK open-source project, throwing our full support behind the RADV driver as the officially supported open-source Vulkan driver for Radeon™ graphics adapters.
This consolidation allows us to focus our resources on a single, high-performance codebase that benefits from the incredible work of the entire open-source community. We invite developers and users alike to utilize the RADV driver and contribute to its future.
- Learn more about RADV: Mesa RADV Documentation
- Contribute to the code: Mesa GitLab Repository
We are excited about this focused path forward and are committed to the continued success of open-source Vulkan on Radeon.
As a result they've also archived the GitHub page for PAL (Platform Abstraction Library), the GitHub for their GPU Ray Tracing Library and others related.
I'm quite excited by their mention of throwing their "full support" at RADV, which will hopefully mean actually providing some resources for the Mesa driver to improve.
What do you make of this news?
Then I read the news. Now I am relieved. ^^
Playing Doom The Dark Ages on mesa 25.0 was a slideshow on the 3rd level and required me to install amdvlk, but when mesa 25.1 showed up in Fedora repositories, performance was on par with amdvlk - and that's using an RX 6600. I wonder if mesa 25.2 improves this even further, but I guess we'll get the answer when Fedora 43 hits our SSDs

Last edited by omer666 on 15 Sep 2025 at 8:59 pm UTC
Great news in my opinion. I haven't noticed any ray tracing performance gap, but I'm also using a 7900XTX and avoid using raytracing on principle when I'm not checking "max settings" performance with a game.
I wonder if mesa 25.2 improves this even furtherIf you need it, why don't you install it? It was released more than a month ago.
Last edited by Beta Version on 16 Sep 2025 at 12:06 am UTC
Also using Arch I learned the hard way that the first couple of releases of a new version aren't stable enough for daily use, despite being deemed "stable" in their own development process.
what AMD plan to do with amdvlk for Windows
Wondering the same, but the open source Linux drivers have been much better than the Windows drivers (on the OpenGL side as well) for quite some time. ATI's hardware has always been better than their drivers, going back decades, so having Valve, Google, Red Hat, and the rest solving that for them has been great for everybody.
From DexterMorgan on "Tainted Grail: The Fall of Avalon" entry for ProtonDB:
during Steam installation on Arch system it defaults to the amdvlk driver when asking you to select a driver, as opposed to the vulkan-radeon driver. (...) Most other distros default to the vulkan-radeon driver for their Steam packages but if you see horribly broken environment textures and everything else is fine, odds are it's amdvlk.
So one error less here!
ray tracing is watching your average frame rate take a dive when you use the latter with little in the way of significant visual improvement
im not sure what im doing wrong but raytracing on most titles i have tested is glitchy & noisy to the point of being ugly and distracting. There has been raytracing prior to rtx for decades via software, it wasn't as noisy ? inefficient yes. I almost always turn it off , sometimes just running the shadows if the option allows.
Last edited by Lofty on 16 Sep 2025 at 11:04 am UTC
Few shiny features at launch are not worth getting a half abandoned device couple of years later
all of which are on AMD, or are able to be done (close enough) in opensource software with enough effort.