Introducing Neptune: Direct3D virtualization for QEMU | UTM Blog

Skip to content

For many years, I had wanted to bring Direct3D virtualization to QEMU. I have tried and given up multiple times because the problem felt intractable. A proper solution required expertise in many niche areas of system design including: virtualization, GPU, Windows kernel, graphics APIs, etc. Each of these topics is deep enough on its own to build an entire career. Now with AI agents getting better each week, I decided to give it another shot. I know using AI is seen as an albatross in some circles. There are loud rich AI CEOs who say that programmers will completely be replaced by AI. Meanwhile, concerned open source maintainers talk about low quality slop being spammed in projects that create extra work for maintainers already stretched thin. In fact, we have experienced this increased stream of low quality submissions to UTM with one egregious example of a “security researcher” submitting a “bug report” as a publicity stunt for their new company without taking any time to understand the project’s threat model or trying to communicate with the maintainers before publishing. However, my belief is that AI tools should not replace human thought but instead be used to amplify creativity. AI can complement the gaps in my knowledge and I can direct it with my systems experience. I want this post to both be a technical document describing the history that led up to Neptune as well as a case study on how AI was used to bring that idea to life.

Reader's note —<br>posts on this blog are jointly authored. The blue gutter line marks<br>paragraphs written by a human contributor; the orange line marks<br>paragraphs drafted by an AI collaborator.

Introducing Neptune<br>Results

Alternatives

Implementation<br>The numbers

The timeline

Where Claude excels

Shortcomings — the recurring failure modes

The human’s role

Patterns for complex problem solving

Takeaways for future projects

Appendix<br>Code

Building

Running

Introducing Neptune

Neptune is an extension of virglrenderer for transporting Direct3D APIs over Virtio GPU, the device used by QEMU to provide para-virtualized graphics. It joins vrend (OpenGL), vDRM (Linux DRM), and Venus (Vulkan) as a protocol which virglrenderer can speak. Currently, Neptune only works on Linux host (DirectX 11 through DXVK) and Linux guest. This was a choice made to simplify the bring-up process and to get early feedback from the community. The next phase is to add macOS host support and Windows guest support. After that, Neptune will be extended to support DirectX 12.

Results

I want to start with the results to highlight what is already working. The following benchmarks were selected:

3DMark Fire Strike : a classic D3D11 benchmark which does optimised rendering

Unigine Heaven : an older benchmark that is one of the few games that feature heavy tessellation

Final Fantasy XIV Dawntrail : features submit bound workload

Civilization VI : one of the few games that features multi-threaded rendering

The main reason these games were selected though is because they are all free (and I already own Civ 6) and each has a clear score which can be compared to native DXVK (running on Venus). This is important to make sure the performance is within expectation. While correctness can be checked visually, it is more difficult to check performance. Thanks to Venus though we have a lower bound on what is “acceptable” performance. When DXVK is used as the Wine D3D back-end, DXVK does state tracking and creates a combined Vulkan command buffer. The Venus driver sends the command buffer to the host to execute on the GPU. Neptune does not do D3D11 state tracking and passes the API calls directly to the host. This means that there is a lot more traffic over the ring buffer shared by the guest and host. Therefore, I had expected a small but non-negligible drop in performance when running Neptune vs DXVK+Venus.

However, I was surprised to see in each case, the performance increased . Here is Claude’s theory as to why:

Neptune moves DXVK from competing for 4 guest vCPUs (next to the game) to the host’s many cores running against native radv with zero Vulkan-side virtualization, and that win dwarfs the extra ring chatter whenever GPU work or DXVK CPU work — not app-thread work — is the actual ceiling. DXVK is CPU-heavy. Hazard tracking, render-pass building, descriptor-set diffing — all hot. Moving that work out of the guest VM is a big deal even before you count the Venus saving.

3DMark Fire Strike

DXVK + Venus

Neptune

Unigine Heaven

DXVK + Venus

Neptune

Final Fantasy XIV

DXVK + Venus

Neptune

Civilization VI

DXVK + Venus

Neptune

The test machine used with a 2018 Intel NUC Hades Canyon running AMD Polaris graphics. QEMU is run on Ubuntu 24.04 with -accel kvm -cpu host -smp 4 -m 16G. For reasons explained above, the performance differences should not be extrapolated to mean the Neptune will outperform Venus in general....