GoKawiilRADV is the open source Mesa Vulkan driver for AMD GPUs. Over the years, it has become a cornerstone of the Linux graphics stack. It has now effectively become the de facto Vulkan driver for AMD hardware on Linux. AMD even discontinued their PAL-based (Platform Abstraction Library) alternative in its favor, consolidating their open-source efforts around Mesa.
On Windows however, AMD users are still served only by the proprietary driver. But don't panic, we have a solution: porting RADV to Windows, bringing the same open source Vulkan implementation that has proven itself on Linux to them. It's such an improbable proposition that we might actually get there faster than light (spoiler alert: that's going to be a little slower).
An open source Vulkan driver on Windows opens up a number of possibilities: a shared codebase across platforms, easier debugging and experimentation, faster turnaround on fixes, and a path for the community (e.g., game developers) to report problems or contribute improvements that benefit everyone regardless of operating system.
From first triangle...
This effort builds directly on the groundwork laid by Faith Ekstrand, who first explored the feasibility of running RADV on Windows and presented her findings at XDC 2024. We strongly suggest you go watch the talk, but here is a quick summary.
A central theme of her talk is that since Windows 10, the WDDM2 interface provides a much better foundation for a third-party driver than what came before. It defines a clear model for how a user-mode driver (UMD) interacts with the operating system and the kernel-mode driver (KMD).
However, there is of course a significant catch: many D3DKMT calls can carry private driver data - opaque, vendor-specific blobs whose contents are entirely up to the driver. This means the UMD and KMD remain tightly coupled and that this interface is totally undocumented.
To work around this, Faith created the wddm2-pdd-re tool to log the WDDM2 calls and the private data content for some D3D12 applications. Using this approach, she was able to reverse engineer enough of the private interface — querying adapter info, allocating buffers, creating queues, and submitting commands — to get RADV to submit work to the proprietary kernel driver. And ultimately she was even able to get a rotating 3D model displayed on her screen in all its glory.
...to first game
Where Faith's work established that this could be done, this project picked up the thread. The goal was to improve upon it to make it more flexible (support for different hardware by reducing hard-coded values), more portable (breaking free of WSL with native Windows support), and far more stable (no longer crashing after two minutes of deqp-vk testing).
... continue reading