Gaming in virtual machines just got a real graphics driver
Triton v0.4, the GPU-accelerated DirectX 11 in QEMU driver, has been updated.
Unlike DXVK, which intercepts the API, Triton implements the actual DirectX Device Driver Interface. Windows' own d3d11.dll stays put and talks to a legitimate WDDM driver instead of a trick. Osy demonstrated Crash Bandicoot: The Trilogy and a full 3DMark Fire Strike benchmark inside a Windows 11 ARM64 guest, with the desktop compositor working, something no prior QEMU effort pulled off.
What's new in v0.4
The v0.4 tag landed on October 15, 2026, off the neptune branch at commit a3422e7. It's the first one that isn't marked a prerelease, though osy is clear the drivers remain very unstable and shouldn't be installed on any VM you care about. The changes are tightly scoped kernel-mode fixes to viogpu3d, all AI-assisted.
First, a reference-counting fix across RES_INFO and RES_RELEASE escapes. Both resolved a handle to a bare pointer and dropped their lock before use, leaving a classic use-after-free: a destroy-allocation call in another process could free the allocation between the lookup and the resource-info call. The fix resolves the reference under the lock, the way the kernel driver already does elsewhere, and Claude:claude-opus-5 assisted on it.
Second, synchronous host mapping for blob windows. A placed-and-mapped window was previously handed back before the host backed it, forcing a roughly 12 ms scheduler drain behind every DMA packet. A new CtrlQueue::ResourceMapBlobSync call now returns a window that's placed, mapped, and host-backed at once, and its FIFO acknowledgement also proves the blob was processed. Assisted by Claude:claude-fable-5.
Third, EDID-derived refresh rates. The guest used to run at a fixed 60 Hz regardless of the host display, and a compositor that saw its primary at a rate it didn't have would black-screen and rebuild its swapchain every frame. Triton now parses the preferred timing out of the host EDID, reports it on all modes, and drives the vsync tick from a high-resolution EX_TIMER so 120 Hz modes don't get quantized to 8 ms. Assisted by Claude:claude-fable-5-1 and Claude:claude-opus-5.
Signed prebuilt packages are on GitHub as release assets. An ARM64X build covers native ARM64 and x64-emulated apps, and there's also a plain x64 build. Head here to grab them. The tag sequence runs v0.1 v0.2 v0.2.1 v0.3 v0.4, sitting on the neptune branch, which carries roughly 3,458 commits of accumulated VirtIO-guest-driver history. The whole repo is a BSD-3-Clause fork of virtio-win/kvm-guest-drivers-windows, and upstreaming into mainline QEMU, virglrenderer, and Mesa is reportedly in progress.
The numbers behind the build
It's worth pausing, because this is as much a case study as software. osy published an unusually detailed accounting of the human-to-machine division of labor. The build took roughly nine weeks across 40 active days, spread across four bursts separated by multi-week gaps. There were 208 sessions and 51,900 API turns, costing about $14,760 in Claude API fees at June 2026 pricing. The models produced roughly 1.84 million words while osy typed just 59,443. That's a 31-to-1 ratio on words, and it buys about 480 hours of machine work against roughly 65 hours of human effort.
The "armies of AI agents" worry gets answered head-on by the data. The hardest bugs were the visual kind. Black screens. Missing UI elements. Frame flashes. There were 139 messages devoted purely to carrying a perception across the gap the AI couldn't cross. As osy put it, the bottleneck didn't disappear. It migrated, from typing to seeing. Notably, osy sent zero messages asking the model how to use its tools, no "grep for this" or "open that file." The models made their own ~29,000 Bash calls and ~6,300 edits, while the human stayed one level up on commits, DDI entry points, and architectural trade-offs.
Why DirectX 11 and not 12?
The question keeps coming up, so osy's answer is worth repeating. DX11 is by far the most used 3D API on Windows, with thousands of D3D11 games versus only hundreds of D3D12. It's also higher-level and more approachable to implement. DX12 is "shockingly similar" to Vulkan and hands you low-level, explicit control over the GPU, which makes it far harder to emulate through a driver abstraction. Pragmatically, DX11 wins on bang-for-the-buck.
Triton's core idea is an "inverse transform." Instead of inventing a new serialization format for DDI commands, it converts the calls back into standard DirectX 11 API calls inside the guest and hands them to Neptune's existing transport. Most D3D11 DDI functions have direct API equivalents, so the mapping is mostly handle lookups and enum translations. A VirtIO pipe then carries those calls to the host, where virglrenderer and a host renderer do the actual drawing. The single hardest piece is DXBC shader bytecode, Microsoft's compiler emits intermediate code, and d3d11.dll normally strips away the metadata before the driver ever sees it. Triton has to synthesize that metadata back out of raw bytecode it never actually looked at, which is why osy calls it "the weakest and most error-prone part of our implementation."
If you want to try it out, the constraints are real. Hosts are limited to Linux with KVM or macOS with Apple Silicon. You'll pull a handful of forks: osy's qemu and virglrenderer changes, the Mesa neptune branch, and either the DXMT or D3DMetal Metal backends. Prebuilt signed drivers save you from compiling the Windows side yourself.
Head here to download the release from GitHub.
