Valve Funds RADV Vulkan Driver Port to Windows, and It Already Runs Counter-Strike 2

Valve is bankrolling an experimental effort to move RADV — the open-source Vulkan driver that has anchored AMD graphics on Linux for years — onto Microsoft Windows. The work is being carried out by engineers at Collabora, and it has already reached a milestone that gives the project real credibility: Counter-Strike 2 running through the ported driver on a Radeon RX 7900 XT.

That single detail reframes what could easily have been dismissed as a curiosity. A driver stack built, tested, and hardened for one operating system is now pushing frames on another, and the company funding it has spent the better part of a decade betting that open graphics infrastructure pays off.

What RADV Is

RADV lives inside Mesa, the open-source graphics library that underpins most of the Linux desktop graphics experience. Over time it became the default Vulkan implementation for AMD GPUs on Linux — not by mandate, but by being the option developers and distributions kept reaching for. It is also a core piece of the Steam Deck's graphics stack, which is precisely why Valve has a direct stake in its health.

AMD's own position reinforced RADV's status. The company retired AMDVLK, its separate open-source Vulkan project, last year and consolidated around RADV instead. One open-source driver, not two competing ones.

Windows never got that consolidation. AMD users on Windows have exactly one Vulkan implementation available to them: AMD's proprietary one. There is no open-source alternative, no second path, and no shared codebase with the Linux side.

The Technical Approach: RADV on Top of AMD's Kernel Driver

The Collabora team is not attempting to replace AMD's Windows driver wholesale. The plan is narrower and considerably more pragmatic — run RADV as the user-mode driver while keeping AMD's existing Windows kernel-mode driver underneath, with the two communicating through the WDDM2 interface.

That structure means RADV handles the Vulkan API surface, shader compilation, and command submission, while the proprietary kernel component continues doing what it already does. It is the smallest viable wedge into a closed platform.

The idea did not appear from nowhere. Faith Ekstrand did the initial feasibility work and presented findings at XDC 2024, demonstrating that an open-source user-mode driver could successfully submit work to AMD's proprietary Windows kernel driver. That proof of concept is the foundation everything since has been built on.

Progress So Far

Since picking up the project, the team has worked through a substantial list of subsystems:

• Command stream handling
• Synchronization
• Sparse bindings
• Tessellation
• Task shaders
• GPU property detection

Those are not cosmetic fixes. They are the plumbing a Vulkan driver needs before any non-trivial game will run at all, and getting them functional on a new platform interface is the bulk of the engineering effort.

The result is a driver that is not yet conformant with the full Vulkan specification but is capable of running Counter-Strike 2 through the game's Vulkan renderer on a Radeon RX 7900 XT. Conformance and playability are different bars, and the project has cleared the second one first — which is the normal order for work like this.

Why a Shared Codebase Changes the Economics

The strategic argument here is about maintenance, not benchmarks. If RADV serves both Linux and Windows, bugs get fixed once instead of twice. Debugging becomes easier because behavior can be compared directly across platforms rather than inferred through a proprietary black box. Fixes ship faster because there is a single tree to land them in.

It also opens a door that has been closed on Windows: game developers who hit a driver bug could contribute a fix themselves, and that fix would benefit players on both operating systems. In the current arrangement, a Windows-side Vulkan driver problem can only be reported and waited on.

The Obstacles Standing in the Way

The hardest problem is not performance. It is the interface between AMD's Windows kernel driver and whatever user-mode driver talks to it — undocumented, fragile, and never designed to be a public contract.

AMD ships its user-mode and kernel-mode components as a matched pair. There is no backward-compatibility guarantee between them, because none was ever needed; the two halves always shipped together. That means private data structures can shift between driver releases with no warning and no changelog entry, and an outside user-mode driver depending on those structures can break overnight.

Collabora's assessment is that production viability requires one of two things:

Neither is trivial. The first depends entirely on AMD's willingness. The second means committing to ongoing maintenance against a moving target.

Presentation Performance Is Still a Bottleneck

There is a second limitation that will be visible to anyone who tries the driver in its current state. RADV on Windows currently displays frames using only a slower CPU path. That works, but it leaves performance on the table in a way that matters for a driver whose entire purpose is running games.

Reaching zero-copy swaps — getting rendered frames to the display without the extra copy — would likely require direct involvement from both AMD and Microsoft. That is a different kind of problem from the ones engineers can solve by writing more code, and it puts a ceiling on how far the project can go on its own momentum.

What This Signals

Valve funding this work fits a recognizable pattern: invest in graphics infrastructure that the company does not control outright but depends on. RADV's status on Linux is the result of years of that kind of investment, and the Steam Deck runs on the outcome.

Whether the Windows port becomes production software depends less on the code and more on the interface question. The engineering is demonstrably tractable — Counter-Strike 2 is running. What is not yet settled is whether AMD provides the stable ground the driver would need to stand on long-term, or whether the project has to build that ground itself.