Cracking Windows Open: Porting RADV to WIN32
-->
-->
-->
About
Who we are
Our expertise
Our work
Open Source
Our ecosystem
Services
Guide
Train
Build
Integrate
Optimize
Maintain
Industries
Automotive
Digital TV
Silicon
OEM
VR/AR
News & Blog
Careers
Contact
About
Services
Industries
News & Blog
Careers
Contact
-->
+44 (0)1223 362967
+1 514 667 2499
contact@collabora.com
-->
Home "
News & Blog "<br>News & Events "
-->
Home<br>News & Blog<br>News
Cracking Windows Open: Porting RADV to WIN32
-->
28/07/2026<br>-->
Posted on 28/07/2026 by Louis-Francis Ratté-Boulianne
-->
Cracking Windows Open: Porting RADV to WIN32
Posted on 28/07/2026 by Louis-Francis Ratté-Boulianne<br>--><br>Louis-Francis Ratté-Boulianne<br>July 28, 2026
Share this post:
-->
Reading time:
RADV 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).
We improved command stream handling and synchronization and added support for, among others, sparse bindings, tessellation and task shaders, and dynamic querying of GPU properties. It is still not conformant (even though the success rate has dramatically increased), but the real highlight is being able to run our first game with RADV: Counter-Strike 2 . Anyone can try it by switching the renderer with the -vulkan argument.
...through darkness
Like any port and/or reverse-engineering project, it brought some challenges:
New generation is so oversensitive: We were experimenting on Gen 11 hardware (RX 7900 XT) while Faith was working with a 10th Gen GPU (RX 7800 XT). We weren't able to replicate Faith's results for quite a while, due to architecture changes between these two generations. The main problem was that it would hang as soon as we tried to do anything more complicated than clearing a surface to a hard-coded color. Unfortunately, with no tools to debug such hangs on Windows, this forced us to improve the tooling to reduce discrepancies with the proprietary driver as much as possible. We upgraded the reverse-engineering utility into a full WDDM2 logging layer, able to analyze any application run with the official Vulkan driver, and added support to dump the command streams, registers, and shader code.
Compilers are not playing nice: Mesa is developed primarily against GCC and Clang, and its code base relies on a number...