How Proton Translates DirectX to Vulkan on Linux

Valve’s Proton compatibility layer enables Windows-exclusive games to run seamlessly on Linux systems by translating Microsoft DirectX calls into native Vulkan commands in real time. Rather than emulating an entire operating system, Proton integrates specialized sub-projects—primarily DXVK and VKD3D-Proton—into a customized Wine environment. This pipeline intercepts draw calls, translates compiled shader bytecode into Vulkan-compatible representations, and manages system resources with minimal CPU overhead, often delivering performance comparable to native Windows execution.

The Architectural Framework

Proton builds upon Wine, an open-source compatibility layer that reimplements the Windows Win32 API for Unix-like platforms. When a game issues commands to render a frame, it communicates with dynamic link libraries (DLLs) such as d3d9.dll, d3d11.dll, or d3d12.dll.

Proton replaces these proprietary Microsoft DLLs with custom, drop-in replacement libraries. Instead of executing Direct3D instructions natively, these replacement libraries intercept the API calls and redirect them to translation layers dedicated to specific DirectX versions.

Translating DirectX 9, 10, and 11 via DXVK

For older to modern high-level APIs (DirectX 9 through 11), Proton uses DXVK.

DirectX 11 relies on an abstract, driver-managed state model where the graphics driver handles memory allocation, state validation, and synchronization behind the scenes. Because Vulkan is an explicit, low-level API, DXVK must bridge this architectural gap:

  1. State Tracking: DXVK maintains an internal state tracker to emulate the state machine behavior of DirectX 11. It records rendering states (such as blend modes, depth testing, and rasterizer states) and bundles them into immutable Vulkan Pipeline State Objects (PSOs).
  2. Command Recording: Drawing commands (such as DrawIndexed) are translated into Vulkan command buffers (vkCmdDrawIndexed).
  3. Resource Binding: DXVK maps DirectX resource views, constant buffers, and samplers into Vulkan descriptor sets and uniform buffers.

Translating DirectX 12 via VKD3D-Proton

For DirectX 12, Proton relies on VKD3D-Proton.

Unlike DirectX 11, DirectX 12 and Vulkan share a similar lineage and philosophy. Both APIs were heavily influenced by AMD’s Mantle and expose explicit hardware control to the application developer. Because their low-level mental models align, VKD3D-Proton functions more like an efficient translation layer rather than an emulation engine:

  • Command Lists to Command Buffers: D3D12 command lists map closely to Vulkan command buffers, allowing near one-to-one translation with very low CPU overhead.
  • Root Signatures to Pipeline Layouts: D3D12 root signatures, which define how data binds to the shader pipeline, are translated into Vulkan pipeline layouts and descriptor set layouts.
  • Resource Barriers: D3D12 resource barriers (used for memory synchronization) are translated into Vulkan pipeline barriers (vkCmdPipelineBarrier) to maintain proper execution order across GPU tasks.

Shader Translation and Intermediate Representations

Graphics APIs send compiled bytecode to the driver rather than human-readable source code. A critical task of both DXVK and VKD3D-Proton is translating this compiled shader format into a format that Vulkan hardware drivers can consume.

  • DirectX 9 through 11 compile High-Level Shader Language (HLSL) into DirectX Bytecode (DXBC).
  • DirectX 12 compiles HLSL into DirectX Intermediate Language (DXIL), an LLVM-based format.
  • Vulkan drivers accept shaders compiled into SPIR-V (Standard Portable Intermediate Representation).

Both translation layers parse incoming DXBC or DXIL bytecode at runtime and reconstruct the control flow and math operations into equivalent SPIR-V instructions. The host Linux Vulkan driver (such as Mesa's RADV for AMD or the proprietary NVIDIA driver) then compiles this SPIR-V code into machine code optimized for the specific GPU architecture.

Eliminating Shader Compilation Stutter

Runtime translation of shaders can cause micro-stutters during gameplay because compiling complex shaders introduces latency. Proton handles this through multiple mechanisms:

  • Pipeline Caching: Once a shader is translated into SPIR-V and compiled by the driver, Proton caches the binary pipeline using the graphics driver's on-disk cache.
  • Fossilize: Valve integrates Fossilize, an API capture and playback tool, which records Vulkan pipeline creation calls.
  • Pre-Caching via Steam: Valve aggregates shader caches generated across thousands of players and distributes pre-compiled pipeline states and shader binaries through Steam before a game is even launched, avoiding the translation bottleneck entirely during play.

Memory and Execution Synchronization

DirectX and Vulkan manage memory visibility and concurrency differently. Proton bridges this gap by mapping Direct3D buffer and image allocations directly to Vulkan memory types via device memory bindings (VkDeviceMemory).

DirectX 12’s explicit asynchronous compute queues and copy engines are translated to distinct Vulkan queue families (vkQueueSubmit), preserving multi-threaded CPU submissions without triggering race conditions or GPU serialization bottlenecks. Through this precise, low-overhead mapping, Proton achieves near-native graphics execution on Linux.