Triton brings full DirectX 11 support to Windows guests in QEMU

The developers behind Neptune, a Direct3D protocol forwarding layer for VirtIO that let Wine games run on a Linux guest faster than DXVK running directly in the guest, have now built Triton, a new Windows driver. Combined with Neptune, Triton brings full DirectX 11 support to Windows guests running in QEMU virtual machines.

Previous approaches to graphics acceleration in QEMU worked by replacing a Windows application's d3d11.dll and dxgi.dll with custom versions that implement the DirectX API set, the same approach used by DXVK to Vulkan to Venus. The team lists three problems with this. First, because the desktop compositor (DWM) sees the rendered frame as a plain image, it has to use CPU blitting to place it in the window, so performance never matches a native desktop experience. Second, since d3d11.dll and dxgi.dll are core Windows system files, they cannot be replaced outright, and even where a per-application DLL swap works, many games refuse to run because their anti-cheat systems detect the modification. Third, because the swap only works on a per-application basis, getting acceleration means copying the replacement files into every application, which is not a user friendly experience. The team concluded that the correct approach is not to implement the DirectX APIs but to implement the DirectX DDIs, the Device Driver Interface that a Windows graphics vendor's user-mode driver (UMD) and kernel-mode driver (KMD) normally expose to the system's own Direct3D and DXGI libraries.

On the kernel side, the work was already partly done: developers anonymix007 and arehnman had independently been building a KMD for Venus (Vulkan), and because Neptune is modelled after Venus, its guest kernel interfaces and its UMD-to-KMD interface are effectively identical. The team adopted anonymix007's branch as the base for Triton's KMD because it had more working features. For the harder UMD side, they studied two existing open source references: Mesa's DirectX 10 UMD, which the upstream project only backs with software rasterization (VirGL support exists but is not viable on macOS hosts because virglrenderer there lacks required features), and VirtualBox's DirectX 11 UMD, the only other working open source implementation of its kind. The team chose not to reuse VirtualBox's method, which translates DDI calls into an intermediate bytecode on the guest and interprets that bytecode back into DirectX API calls on the host. They judged that this extra translation step is a likely source of the game compatibility bugs they say are visible in online forum reports about VirtualBox, and it also carries a licence conflict: VirtualBox is GPLv3, while virglrenderer is MIT licensed and QEMU is LGPLv2. They did borrow two things from VirtualBox's implementation: its list of which DDI prototypes are actually required for games to work, information not documented by Microsoft, and its algorithm for computing DXBC shader signatures, which Microsoft also does not publish.

Instead of VirtualBox's bytecode-transport design, Triton performs what the team calls an inverse transform: rather than converting DirectX API calls down into DDI calls the way d3d11.dll does, Triton's UMD converts DDI calls it receives back up into DirectX API calls. That lets Triton reuse the existing, already-tested Neptune serialization protocol without inventing a new transport, and it means the host side needs no separate interpreter, because the deserialized Neptune commands already are DirectX 11 API calls that can be dispatched directly. Most DDI calls have a direct DirectX API equivalent, so the conversion is largely a matter of mapping handles and looking up enum differences between the two interfaces.

The hardest part of the project turned out to be DXBC, the DirectX Byte Code shader intermediate format that Microsoft's older FXC compiler emits from HLSL. Because Triton reverse-transforms DDI calls into API calls, it does not need to disassemble or convert the shader bytecode itself, unlike VirtualBox's approach, which the team calls a major win for complexity and compatibility. The complication is that the compiler also emits metadata alongside the bytecode, which d3d11.dll normally consumes, but which is not passed down through the DDI call. To make a valid DirectX API call, Triton has to reconstruct that missing metadata by interpreting the raw bytecode and synthesizing the fields the host DirectX renderer expects. The team says this reconstruction took a lot of trial and error, was largely handled with the help of an AI assistant, and remains the weakest and most error-prone part of the implementation.

The full rendering path runs as follows: an application calls the system DirectX and DXGI libraries, which invoke Triton through DDI calls; Triton converts the raw DXBC bytecode back into a full DXContainer and issues DirectX and DXGI API calls to Neptune; the Neptune UMD serializes those calls through a ring buffer managed by the KMD; the KMD sends them to the host over VirtIO; QEMU passes the Neptune calls to virglrenderer; virglrenderer's Neptune host module deserializes them and forwards them to the host's own DirectX implementation, which renders the frame.

On the swapchain, the team says its earlier design for Neptune on Linux was a mistake for Windows. For Wine, they had forked DXVK to export swapchain images as DMAbuf resources and implemented swapchain handling on the host side, in virglrenderer, to avoid dealing with shared textures in the guest. But on Windows, DXGI is a system component that talks to the UMD and itself handles backbuffer creation, frame pacing, and mode switching, largely without special treatment from the UMD, so Triton's DDI-to-API inverse transform does not naturally cover DXGI, and the host-side swapchain logic built for Neptune ends up mostly bypassed. Because the Windows desktop compositor (DWM) works by sharing one process's rendered backbuffer with the DWM process, which then composites the final desktop frame, the team says it also has to add DMAbuf import support to DXVK, in addition to the export support it already had, so that separate guest and host graphics contexts can share those textures directly. With both import and export in place, the team says host-side swapchain logic is no longer needed.

Key facts

Triton is a new Windows driver that implements the DirectX 11 DDI (Device Driver Interface) rather than the DirectX API itself, unlike prior approaches that replace a game's d3d11.dll and dxgi.dll files.
Combined with the team's earlier Neptune protocol forwarding layer, Triton gives Windows guests in QEMU virtual machines full DirectX 11 support.
For the kernel-mode driver, the team adopted developer anonymix007's existing Venus (Vulkan) KMD branch as the base over arehnman's, because it had more working features.
The team rejected VirtualBox's approach of translating DDI calls into an intermediate bytecode, citing likely compatibility bugs and a GPLv3/MIT/LGPLv2 licence conflict, but reused VirtualBox's list of required DDI prototypes and its DXBC signature algorithm.
Reconstructing the metadata that DXBC shader bytecode normally carries, since it is not passed through the DDI call, was done with a lot of trial and error assisted by an AI tool, and the team says it remains the weakest, most error-prone part of Triton.

Why it matters

Working open source DirectX 11 drivers for Windows are rare: the article states VirtualBox has the only other one that works, and Windows graphics-driver internals are documented poorly enough that the team says this scarcity is one reason QEMU has never gotten far with Windows GPU acceleration. Triton targets the DDI layer directly rather than intercepting API calls with replacement DLLs, the same class of workaround used by DXVK-based approaches, which the team says caps performance because the desktop compositor has to CPU-blit the output and which many games' anti-cheat systems detect and block.

Who it affects

The direct audience is people running Windows guests in QEMU, including through UTM's virtualization stack, who want DirectX 11 games to run with proper graphics acceleration rather than software rendering or a per-application DLL swap. It also matters to other developers of open source Windows graphics drivers, since the article documents a DDI-to-API reverse transform approach, plus reused implementation details from VirtualBox, that were not previously written up.

How to use it

The article describes Triton as newly built and working, achieved by combining it with the existing Neptune layer, but the captured text does not state a release date, a version number, or how to obtain or install it. It does not name which specific games have been tested or confirmed working.

How solid is it

This is a first-person engineering account from the people who built Triton, describing their own design choices and trade-offs in detail, including problems they ran into and what they changed their minds about. No performance benchmarks, such as frame rate or latency comparisons against native Windows, DXVK, or VirtualBox, are given. The captured article text ends mid-sentence while describing the DMAbuf import and export work for the host renderer, so its final description of the swapchain implementation and any closing summary are not available here.

Risks and caveats

The team itself flags the DXBC metadata reconstruction as the weakest and most error-prone part of Triton, since it has to synthesize fields the host DirectX renderer expects from bytecode alone rather than the original DXContainer file. The claim that many games fail in VirtualBox is explicitly hedged as an impression from reading online forum threads, not the team's own measurement. No information is given on anti-cheat compatibility with Triton itself, or on which real people are behind the anonymix007 and arehnman handles credited with the KMD work.

“The correct approach is not to implement the DirectX APIs but to implement the DirectX DDIs (Device Driver Interface).”

— the Triton/Neptune development team, in the project blog post