Collabora has the Mesa RADV driver, the open source Vulkan implementation for AMD GPUs that Linux gamers and the Steam Deck depend on, rendering on Windows and running Counter-Strike 2. Valve is paying for the work, which is described as early phase and exploratory rather than a product. The hard part is not the driver, it is everything under it: RADV on Windows has to talk to AMD's proprietary kernel driver through WDDM2, and the team is currently doing that by reverse engineering private data structures that can change with any driver release. That is the difference between a demo and something shippable.
The short answer
Collabora published its progress on porting Mesa's RADV Vulkan driver to Win32 on July 28, 2026, in work sponsored by Valve. The driver has gone from rendering rotating 3D models to running Counter-Strike 2 with its Vulkan renderer, gaining sparse bindings, tessellation, task shaders and dynamic GPU property queries. It reaches the GPU through reverse engineered WDDM2 structures, presentation is CPU based only, and Collabora says production use needs either a documented AMD kernel interface or a stable shim library.
Graphics drivers usually travel the other way. Someone takes a Windows stack and coaxes it into working on Linux, generally through a translation layer and a good deal of patience. Collabora is doing the reverse, and the reason it is worth reading about is not novelty. It is what the port has run into.
What has been built
RADV is the Mesa project's open source Vulkan driver for AMD hardware. On Linux it sits underneath most Vulkan gaming, including everything Proton translates from Direct3D, and it is a significant part of why the Steam Deck performs the way it does. On Windows, that role belongs to AMD's own proprietary Vulkan driver.
Louis-Francis Ratte-Boulianne's writeup traces the progression. First came basic rendering, the traditional rotating 3D model. Then came the features a real application expects: sparse bindings, tessellation, task shaders, dynamic queries of GPU properties, along with more capable command stream handling and synchronisation. Then Counter-Strike 2, launched with its Vulkan renderer, ran on it.
That last step is the meaningful one. A shipped game touches far more of the API than any conformance demo, and it does so in the messy order real engines use.
The blocker is beneath the driver
A Vulkan driver is a user space component. It still has to get commands to the hardware, and on Windows that path runs through WDDM2, the Windows Display Driver Model, and into AMD's proprietary kernel driver.
Nothing about that interface is documented for third parties. So the team is reverse engineering the private data structures the kernel driver expects, which works right up until AMD ships a driver update that changes them. A user space driver built on undocumented structures is not a driver anyone can support, however well it runs today.
Collabora names the two ways out. Either AMD provides a stable and documented interface to its Windows kernel graphics driver, or somebody builds a shim library that sits between RADV and the kernel driver and absorbs the private structure handling. Both require AMD to participate.
Presentation is the other gap
The second limitation is narrower but has a direct performance cost. Only CPU based presentation is implemented so far. GPU accelerated DXGI swapchains and zero copy swaps are not.
Presentation is the final step of every frame, the handoff from the rendered image to what the display controller scans out. Doing it on the CPU means copying data that should never have moved. Any benchmark taken today is measuring that copy as much as it is measuring the driver, which is a useful thing to remember before anyone compares numbers.
Below those two sit the ordinary irritations of porting a codebase that has only ever been built by GCC and Clang. MSVC handles enums differently, and that difference had to be worked around.
Why Valve would pay for this
Valve's interest is not mysterious. It ships Linux hardware in the Steam Deck and Steam Machine, its customers overwhelmingly also run Windows PCs, and its Proton stack already funnels Direct3D into Vulkan on both. Today the Vulkan implementation underneath differs by platform, which means a bug can exist on one and not the other, and the fix for one of them belongs to a vendor rather than to Valve.
One driver on both platforms collapses that. It also means the work Valve already funds on RADV, which is considerable, benefits Windows users of its software rather than stopping at the platform boundary. We noted a similar pattern of vendor funded upstream work in AMD P-State patches lift 1% low frame rates by 31.8%, where the measurable gain arrived through the kernel rather than through a product.
How to read it
This is exploratory work, sponsored, published openly, and honest about its limits. Running Counter-Strike 2 is a real milestone and not a shipping date. The question that decides whether it goes anywhere is not in Collabora's hands: it is whether AMD documents its Windows kernel interface or helps build the shim. Until then, the interesting output is the engineering write up, not a driver you can install.
Sources and further reading
- Collabora: Cracking Windows open, porting RADV to WIN32
- Phoronix: Valve sponsors work bringing open source RADV driver to Windows
- Mesa documentation: the RADV driver
- Hacker News discussion of the announcement
Frequently asked questions
What is RADV, and why does porting it to Windows matter?
RADV is Mesa's open source Vulkan driver for AMD graphics hardware. It is what runs underneath Vulkan titles on most Linux gaming setups, and a large part of why the Steam Deck and Steam Machine work as well as they do, since Proton translates Direct3D calls into Vulkan and RADV executes them. On Windows, AMD ships its own proprietary Vulkan driver instead. Bringing RADV to Windows means the same driver code, the same bug fixes and the same behaviour on both platforms, which removes an entire class of works on Linux but not on Windows problems and gives Valve a driver stack it can actually patch itself.
How far along is the port?
Further than a proof of concept and well short of a product. Collabora reports going from first rendering of rotating 3D models to running Counter-Strike 2 with its Vulkan renderer, having implemented sparse bindings, tessellation, task shaders and dynamic queries of GPU properties along the way, plus work on command stream handling and synchronisation. Phoronix describes the effort as early phase, exploratory work, and Collabora's own writeup is candid about what is missing. Running a shipped game is a genuine milestone for a graphics driver, because a game exercises far more of the API surface than any test suite demo, but it is not the same as being ready to use.
What is actually blocking it?
Three things, in descending order of severity. First, the kernel interface: on Windows the driver has to reach the GPU through WDDM2 and AMD's proprietary kernel driver, and the private data structures involved are not documented, so the team is reverse engineering them and there is no guarantee they stay stable across driver updates. Second, presentation: only CPU based presentation works today, with GPU accelerated DXGI swapchains and zero copy swaps still unimplemented, which matters enormously for performance since presentation is the last step of every frame. Third, the ordinary porting friction, including MSVC handling enums differently from GCC and Clang.
What would make this production ready?
Collabora is explicit about the requirement: either a stable and documented interface to AMD's Windows kernel graphics driver, or a shim library sitting between RADV and that kernel driver to mediate the private data structures. Both routes need cooperation from AMD, because neither can be sustained by reverse engineering alone. A driver that depends on undocumented structures is a driver that breaks the next time the vendor ships an update, and no distributor wants to own that. Until one of those two exists, this stays exploratory work no matter how many games it runs.
Should I expect to use this on my Windows machine?
Not soon, and possibly not directly. This is exploratory work funded by a company with a specific interest in a unified driver stack across its Linux hardware and the Windows PCs its customers still use. Even in the best case, the path from running Counter-Strike 2 in a lab to a driver that any Windows user installs runs through GPU accelerated presentation, a supported kernel interface, and a long tail of games and applications. The realistic near term reading is that this makes RADV development easier and gives Valve leverage, and any consumer facing outcome comes later, if at all.