vkd3d-proton: Running Direct3D 12 on Vulkan

What vkd3d-proton is for, and who it is not for

Direct3D 12 is a Windows API. Vulkan is a cross-platform one. vkd3d-proton sits between them: it is a fork of VKD3D that, in the project's words, "aims to implement the full Direct3D 12 API on top of Vulkan", and it exists as the development effort behind Direct3D 12 support in Proton. The upstream project lives at WineHQ; this fork is where Proton's D3D12 work happens.

The audience is narrow and technical. If you are packaging a game runtime for Linux, or debugging why a Direct3D 12 title fails under Wine, this is the component you are looking at. If you want a stable, portable D3D12 layer that runs on a five-year-old GPU, it is not. The README states the priorities plainly: performance and game compatibility come first, "at the expense of compatibility with older drivers and systems", and backwards compatibility with the vkd3d standalone API "is not a goal of this project". That sentence should decide the question for anyone maintaining an application against the standalone vkd3d interface.

The driver requirements that actually gate adoption

The README lists hard requirements rather than suggestions, and they are stricter than "supports Vulkan". Vulkan 1.3 is the floor. Descriptor indexing must support at least 1000000 UpdateAfterBind descriptors for all types except UniformBuffer, and the README says essentially all features in VkPhysicalDeviceDescriptorIndexingFeatures must be present. Two device features are required by name: samplerMirrorClampToEdge and shaderDrawParameters. Two extensions are required: VK_EXT_robustness2 and VK_KHR_push_descriptor.

A second tier is described as needed for optimal or correct behavior and likely to become mandatory: VK_EXT_image_view_min_lod. VK_EXT_mutable_descriptor_type (or the vendor VALVE alias) and VK_EXT_descriptor_buffer are "highly recommended, but not mandatory". The practical consequence is that a driver can support Vulkan and still fail here. The README's advice is to use the very latest drivers available.

Per vendor: on AMD, RADV is the recommended driver and the one that sees most testing, with Mesa 22.0 as the minimum; for older Mesa, the README points to the v2.6 release. On NVIDIA, the Vulkan beta drivers carry the latest fixes, and 535 series drivers are the stated minimum. On Intel, the README says no testing has been done against Intel GPUs. That last line is the most useful one in the document.

What you get after a build, and how it plugs into Wine

The intended artifact is native Win32 DLLs, d3d12.dll and d3d12core.dll, which the README describes as a drop-in replacement for D3D12 usable in Wine (Proton or vanilla) or on Windows. One dependency is explicit: vkd3d-proton does not supply DXGI components on its own, and instead shares a DXGI implementation with DXVK 2.1 or newer. If you are assembling a runtime, the two go together.

The repository layout reflects that split. Top-level entries include include/, libs/, programs/, tests/, demos/, profiles/ and setup_vkd3d_proton.sh, alongside Meson build files and cross files for win32, win64, arm64x and widl. There is also VP_D3D12_VKD3D_PROTON_profile.json, a profile file sitting next to the build scripts. The CHANGELOG.md and docs/ directories are where release-level behavior is recorded, and the tags v3.0a, v3.0b and v3.0.1 show the project ships bugfix releases between larger versions.

Building vkd3d-proton from source

Clone with submodules, since the build depends on them:

git clone --recursive https://github.com/HansKristian-Work/vkd3d-proton

Requirements are wine (for widl) on native builds, Meson at least version 0.49, glslang, and Mingw-w64 at least version 7.0 for the default cross-builds for d3d12.dll. On Windows, Strawberry Perl can substitute for wine because it ships widl.

The simple path is the packaging script. With --no-package it produces a vkd3d-master folder in the target directory containing 32-bit and 64-bit builds:

./package-release.sh master /your/target/directory --no-package

Pass --native to build against your system compilers instead, or --dev-build to keep the build directories. With --dev-build, after editing source you rebuild with ninja against the build directory, using build.86 for 32-bit:

ninja -C /your/target/directory/build.64 install

Doing it manually for the default cross-build is two Meson invocations, one per architecture, each followed by ninja install:

meson --cross-file build-win64.txt --buildtype release --prefix /your/vkd3d-proton/directory build.64
ninja -C build.64 install

The README also documents a native 32-bit build that sets CC and CXX to gcc -m32 and g++ -m32 with PKG_CONFIG_PATH pointing at the 32-bit pkgconfig directories, an aarch64 cross-build that starts by creating a distrobox from Steam's runtime SDK image, and Windows builds using either MSVC (meson --backend vs2022, then msbuild.exe vkd3d-proton.sln) or mingw UCRT in msys2. The README is careful about the Windows case: it says building directly on Windows is only expected for testing and development, to run tests against native drivers rather than real applications, and that these builds are not stress tested.

Where vkd3d-proton is the wrong tool

The README names several boundaries itself. Native Windows use is described as mostly relevant for developer testing, with an explicit warning not to expect games running on Windows 7. Intel GPUs are untested. Older GPUs and older drivers are deprioritized by design, so a machine that runs Vulkan fine may still be unable to run this.

The second limitation is architectural rather than a bug: the project aggressively uses modern Vulkan extensions to gain performance and compatibility, which means the set of supported configurations shrinks over time rather than grows. The README anticipates this, noting that some currently-optional extensions "will likely become mandatory later". If you ship a runtime to users with heterogeneous hardware, that trajectory is the thing to plan around, not the current feature list.

There is also a documented version floor for the driver stack: Mesa 22.0 on AMD, 535 series on NVIDIA. Users below those need either a driver update or, in the AMD case, the v2.6 release. The README does not document rollback procedures for the DLLs themselves, so replacing a working d3d12.dll with a newer build is a change you should be prepared to reverse by hand.

vkd3d-proton versus DXVK, and versus upstream vkd3d

The comparison people search for is DXVK versus VKD3D, and the two cover different APIs. DXVK translates Direct3D 9, 10 and 11 to Vulkan; vkd3d-proton handles Direct3D 12. They are not substitutes, and in practice they coexist: the README states that DXVK 2.1 or newer supplies the DXGI components that vkd3d-proton deliberately does not provide. A Proton prefix typically contains both.

The more consequential comparison is against upstream VKD3D at WineHQ. The fork exists because the two projects optimized for different things. Upstream maintains a standalone API and broader compatibility; this fork states that backwards compatibility with that standalone API is not a goal, and that it will trade driver and system compatibility for game performance. If you are writing an application against libvkd3d's API, upstream is the project you want. If you are trying to make a shipped Direct3D 12 game run under Proton, this is the one that is tested against that workload.

Maintenance, licensing and upgrade cost

The repository is not archived, and its last push was on 2026-09-22. Recent tags are v3.0a (2025-11-18), v3.0b (2025-12-10) and v3.0.1 (2026-05-06). The a and b tags are labeled bugfix releases, which suggests the project's habit is to cut small corrective releases rather than hold fixes for a major version. That matters for upgrade cost: staying current is a series of small moves, but each one can raise the driver floor, as the note about extensions becoming mandatory indicates.

The licence is LGPL-2.1, and the repository carries both COPYING and LICENSE files at the top level. The README does not discuss linking or distribution questions beyond that, and nothing here should be read as legal advice; if you redistribute the DLLs, the LGPL-2.1 terms and the separate licences of the bundled subprojects are what you need to review.

The build itself is the recurring cost. Cross-compilation needs Mingw-w64 and glslang, native builds need wine for widl, and the aarch64 path needs a distrobox based on Steam's runtime SDK image. None of that is unusual for a C project of this kind, but it is not a one-command install either.

Editorial conclusion

Adopt vkd3d-proton if you run Direct3D 12 titles through Proton or Wine on a GPU whose driver meets the Vulkan 1.3 and descriptor indexing requirements, and you are willing to update drivers. Do not adopt it for the standalone vkd3d API, for Intel GPUs, or for Windows 7. Verify first that your driver reports the required features, check the latest release tag and its changelog, and confirm you have a DXGI implementation such as DXVK 2.1 or newer alongside it.

Frequently asked questions

Official sources

1. HansKristian-Work/vkd3d-proton on GitHub
2. Issues
3. License: LGPL-2.1
4. README
5. Releases