RADV Already Ate Linux. Now Valve Points It at Windows

RADV has a habit of showing up where it wasn't invited and outstaying the incumbent. The open-source Vulkan driver for AMD GPUs started life in 2016 as a reverse-engineering project by Dave Airlie and Bas Nieuwenhuizen, with no help from AMD. Nine years later, AMD discontinued its own open-source Vulkan driver, AMDVLK, and declared RADV the officially supported open driver for Radeon on Linux — a rare case of a vendor conceding its own hardware's driver to a community project because the community project was simply faster.

Now Valve is paying Collabora to point the same driver at Windows. In a July engineering write-up, Collabora's Louis-Francis Ratté-Boulianne detailed a Win32 port of RADV — building on earlier exploratory work by Faith Ekstrand — that already runs Counter-Strike 2 with the -vulkan flag on real AMD hardware. It's experimental, non-conformant, and held together in places by reverse-engineered guesswork. It's also one of the more strategically interesting things happening in graphics drivers right now.

A native driver, not another translation layer

Mesa on Windows isn't new. Microsoft itself contributed Dozen (Vulkan-on-D3D12) and a GL-on-D3D12 driver to the tree, and lavapipe has built on Windows for years. But all of those are layered or software drivers. This port is different in kind: RADV running as a native user-mode driver, programming AMD silicon directly, on an operating system Mesa has never really treated as a first-class hardware target.

The trick — and the central fragility — is what sits underneath. Porting the Linux amdgpu kernel driver was never on the table, so Windows RADV talks to AMD's proprietary kernel-mode driver through WDDM2's D3DKMT interfaces. That's the same UMD/KMD split AMD's own Windows Vulkan driver uses, with one enormous difference: many D3DKMT calls carry "private driver data" — opaque, vendor-specific blobs that encode command submission details, memory layout, and everything else the kernel driver actually needs. AMD's user-mode drivers know the format because AMD wrote both sides. Collabora had to reverse-engineer it, and AMD guarantees nothing about those structures staying stable between Adrenalin releases.

There's a pleasing symmetry here. RADV was born by reverse-engineering AMD's hardware interfaces on Linux; the Windows port begins by reverse-engineering AMD's software interfaces on Windows. The difference is that GPU command streams are constrained by silicon, while a private data blob can change whenever AMD's driver team feels like it. Collabora is explicit that a real product needs one of two things from AMD: a stable, documented kernel interface, or a shim library that mediates the private channel. Everything else in the port is engineering; that part is diplomacy.

The rest of the log is the grinding reality of cross-platform driver work. RDNA3 hardware (an RX 7900 XT) hung on complex workloads in ways older generations didn't, forcing new command-stream debugging tooling. MSVC's enum semantics — signed, 32-bit-capped, unlike GCC and Clang's — quietly broke assumptions baked into Mesa's codebase. That last category of fix is worth noting because it flows upstream: portability cleanups for MSVC harden Mesa for everyone, the way Microsoft's D3D12 work already forced the tree to stop assuming Linux.

What actually works today

The honest status: Counter-Strike 2 runs. Sparse bindings, tessellation, and task shaders work. Vulkan CTS pass rates climbed substantially during the project, but the driver is not conformant, and presentation — the part users would actually notice — is the weakest link. Frames currently reach the screen via CPU copies; proper DXGI swapchain integration and D3D12 image import are still to be built. Nobody should install this expecting frames. Most people can't sensibly install it at all: it lives in a Mesa development branch, you build it with MSVC, register it as a Vulkan ICD, and accept that any AMD driver update might silently break the private-data handshake.

So who is this for? In the near term, driver and game developers. An open user-mode driver on Windows means you can read the source of the thing generating your GPU commands, instrument it, and — critically — reproduce behavior across platforms. Valve's ACO shader compiler is the heart of RADV, and it's the compiler behind every game running on Steam Deck. A Windows RADV gives Valve, and eventually game developers, one compiler stack whose bugs, workarounds, and performance characteristics are identical on both operating systems. Today, a shader that misbehaves on Deck and behaves on Windows involves two vendors' compilers and two bug trackers. Collapse that to one and a whole class of "works on Windows, breaks on Proton" tickets becomes tractable.

Valve hasn't spelled out its endgame, and it's worth being careful about inferring one. But the company's pattern is consistent: fund the open stack until it's the best stack, then build products on it. That playbook produced ACO, DXVK, Proton, and the Steam Deck. A Vulkan driver it controls on Windows fits the pattern uncomfortably well for AMD's Windows driver organization — because the Linux precedent shows what happens when RADV competes head-to-head with a PAL-based AMD driver. AMDVLK lost on performance, stability, and game compatibility, and AMD eventually stopped fighting.

Hinge point: AMD

My read: this is a genuine strategic move, not a tech demo, but its ceiling is set entirely by AMD's response. Without a stable kernel interface, Windows RADV is permanently one Adrenalin update away from breakage — fine for Valve's internal testing and compiler validation, unshippable to users. With one, the Linux story becomes repeatable: an open driver that starts as a curiosity, reaches parity, then becomes the thing enthusiasts install first.

Would AMD actually provide it? A year ago I'd have said no — no Windows GPU vendor has ever stabilized its UMD/KMD private interface for outsiders. But AMD already did the harder thing when it killed AMDVLK and embraced RADV on Linux, trading control for a better driver it doesn't have to fully staff. Offering a documented interface or a sanctioned shim on Windows is a smaller concession with the same shape. The rational move is to engage early rather than wait for benchmark charts on their own OS.

For now, watch two signals: whether the presentation path lands (DXGI integration is the difference between demo and driver), and whether AMD says anything at all. Silence from AMD keeps this a research project. A stable interface makes it the most interesting thing to happen to Windows graphics drivers in a decade.