vkd3d-proton 3.1: Descriptor Heaps and Shader Model 6.9

By Indie Kings | October 29, 2026

Updated October 29, 2026: vkd3d-proton released version 3.1 on October 28, the last stable tag before the project moves to 3.2 and enables its descriptor heap path by default. The Direct3D 12 to Vulkan layer has 3,030 stars, 353 forks and 98 contributors, is LGPL-2.1 licensed, and has been the D3D12 backend for Valve's Proton since 2019.

Image: an ATI Radeon HD 5870 graphics card, via Wikimedia Commons.

A release that is mostly a marker

The release notes open by saying the tag exists mainly to bump the build version before 3.2, and that 3.2 will bring a lot of important changes. That is an unusual thing to publish, and it is accurate: version 3.1 is a checkpoint rather than a feature drop. The reason for the checkpoint is the descriptor heap work, which has been available as an opt in feature for months, has been tested heavily on NVIDIA hardware, and is not enabled by default in 3.1 because of concerns about driver quality. The notes say that will change imminently on master, which is why the stable tag had to happen first.

For readers outside the Wine and Proton communities, vkd3d-proton is the component that lets Windows games built on Direct3D 12 run on Linux. It is a fork of VKD3D, the WineHQ project that implements D3D12 on top of Vulkan, but it is not the same codebase and does not try to be compatible with it. The fork exists because Proton needs to chase game compatibility and performance aggressively, using modern Vulkan extensions and accepting that older drivers and systems will be left behind. The README says that plainly: performance and game compatibility are the targets, at the expense of compatibility with older drivers.

That posture explains the release cadence. A layer like this is judged by whether specific games launch and hold frame rate, so the changelog is a list of game specific workarounds, driver bugs and shader compiler fixes rather than a tidy feature roadmap. The 3.1 notes end with a line about a ton of random game workarounds too numerous to list, which is the honest summary of what maintaining a translation layer at this scale looks like.

Descriptor heaps and Shader Model 6.9

The headline feature is support for VK_EXT_descriptor_heap, a Vulkan extension that maps D3D12's descriptor heap model more directly onto the hardware. Descriptors are how shaders find textures, buffers and samplers, and D3D12 lets applications manage them in large heaps. Emulating that on older Vulkan required indirection and copies, which costs performance and creates edge cases. A direct mapping removes a layer, and the fact that it has been battle tested on NVIDIA but is held back for driver quality tells you where the remaining risk sits.

The second feature is Shader Model 6.9, which includes Shader Execution Reordering and long vectors. Shader Execution Reordering lets a shader reorganize work to improve coherence, which matters for ray tracing and other divergent workloads, and long vectors widen the data types shaders can use. The notes say it currently only lights up on NVIDIA because SM 6.9 is a ray tracing and machine learning oriented update, which is a polite way of saying the other vendors' compilers are not there yet. DXR 1.2 is exposed when the driver supports it, along with KHR_opacity_micromap and the removal of the older and broken EXT path.

The rest of the feature list is plumbing with real consequences. NVAPI intrinsics in dxil-spirv let more games use vendor specific shader functions without falling back. AgilitySDK 619 features are exposed, view instancing is on by default because more games rely on it, and there is an opt out for titles that push the feature past what the implementation supports. The notes are candid that the view instancing implementation is not fully conformant, and then point out that no implementation on Windows is either, which is the kind of context that makes a caveat useful rather than alarming.

Performance changes follow the same pattern of removing overhead. ClearUAV now goes through vkCmdClearColorImage or vkCmdFillBuffer when possible, letting the driver optimize a clear instead of treating it as a shader operation. Pathological COPY to RESOURCE to COPY barrier sequences are optimized, because applications cannot be trusted to write competent code. Compositor round trips in Present related to occlusion checks are avoided, which helps when the main render thread is CPU bound. Ray tracing acceleration structure builds are batched before barriers, which the notes say massively increases RT performance in some cases.

Steam Frame, ARM and the driver contract

The most consequential line for the next year may be the one about Steam Frame, Valve's standalone headset, becoming a supported platform. That brought fixes for Qualcomm hardware and support for aarch64 builds, which means vkd3d-proton now has a reason to care about ARM devices beyond the occasional experiment. The notes also mention workarounds for AMD GCN and Qualcomm hardware running games that assume Wave32 support, and more detailed Unreal Engine 5 and RE Engine detection so Mesa drivers can apply workarounds that cannot be keyed off vkd3d-proton alone.

Some fixes are pure correctness. D24 to buffer copies are handled correctly on AMD GPUs where the format is emulated as D32, which fixed jank in the Metal Gear Solid 4 remaster. The low latency2 path was updated to match spec version 3 for NVIDIA. Undefined behavior around integer division and modulo was fixed because NVIDIA's compilers take advantage of the allowed undefined behavior in ways that broke things. The AMD anti lag implementation was simplified and its frame attribution bugs fixed. A root SRV and UAV workaround addresses games that get away with out of spec behavior on Windows, and the use after free workarounds were rewritten for the FSR4 Unreal plugin.

None of that runs without a compliant driver. The requirements are steep: Vulkan 1.3, descriptor indexing with at least one million UpdateAfterBind descriptors for every type except uniform buffers, essentially all of the descriptor indexing features, samplerMirrorClampToEdge, shaderDrawParameters, VK_EXT_robustness2 and VK_KHR_push_descriptor. Image view min lod, mutable descriptor type and descriptor buffer are strongly recommended, with the first likely to become mandatory. On AMD the recommendation is RADV with Mesa 22.0 or newer, on NVIDIA the 535 series is the floor and the Vulkan beta drivers are preferred, and Intel is listed as untested. The build itself needs wine for widl, Meson, glslang and Mingw-w64, and the repository has to be cloned recursively for its submodules.

That contract is why the project can move fast. By declaring old drivers out of scope, it can use extensions that make the translation cheap instead of emulating missing features in software. The cost is that users on older distributions or vendor drivers get a worse experience, and the project's answer is to tell them to update. It is a defensible trade for a component shipped inside Proton, where Valve controls the runtime, and a harder one for anyone building it standalone.

Project card

FAQ

What is vkd3d-proton?
A fork of VKD3D that implements Direct3D 12 on Vulkan and serves as the D3D12 backend for Valve's Proton compatibility layer.

What is new in 3.1?
Optional VK_EXT_descriptor_heap support, DXR 1.2 with opacity micromaps, Shader Model 6.9 on NVIDIA, several performance paths and many game fixes.

Why is descriptor heap not enabled by default?
The release notes cite driver quality concerns. It has been tested heavily on NVIDIA and will be enabled by default on master shortly after 3.1.

Which GPU drivers are required?
Vulkan 1.3 with full descriptor indexing support, Mesa 22.0 or newer on AMD, NVIDIA 535 or newer, and the Vulkan beta drivers are recommended for NVIDIA.

Does it work on ARM?
Yes. Version 3.1 adds aarch64 builds and Steam Frame support, with fixes aimed at Qualcomm hardware.

Is it the same as VKD3D?
No. It is a fork with different priorities and no goal of compatibility with the standalone VKD3D API.

Bottom Line

Version 3.1 is a waypoint, and the most useful thing about it is what it says about 3.2: descriptor heaps are about to become the default path, which should remove a layer of indirection from every D3D12 game Proton runs. The rest of the release is the usual mix of shader compiler work, barrier tuning and game specific fixes, and the Steam Frame and aarch64 support quietly expands the addressable hardware. The driver requirements are strict enough to leave some users behind, and that is the price of the performance strategy. For anyone tracking Linux gaming, this is the component to watch, not the one to benchmark in isolation.

Sources

• GitHub HansKristian-Work/vkd3d-proton README, driver requirements, build instructions and project scope, accessed October 29, 2026
• vkd3d-proton v3.1 release notes, published October 28, 2026, features, performance, fixes and workarounds
• GitHub API metadata for vkd3d-proton, stars, forks, contributors, open issues and LGPL-2.1 license, accessed October 29, 2026

Related: Steam Deck: HelixSR Injects DLSS Onto AMD Handhelds | SteamOS 3.9: Valve Ships Plasma 6.7 and Linux 7.2 to Everyone