Wine, Proton, DXVK, VKD3D-Proton: The Four Layers That Decide Whether a Windows Game Runs on Linux

By Indie Kings | October 19, 2026

A Windows game on Linux is not one translator but four layers: Wine, Proton, DXVK and VKD3D-Proton. Each layer does a different job, and knowing which one failed explains almost every "this game does not run" complaint.

GitHub repository card for the ValveSoftware Proton project

Image credit: ValveSoftware/GitHub.

The four layers in one pass

The stack answers four separate questions. Wine answers what Windows environment the executable expects. Proton answers which Wine build, which graphics translators and which per-title settings Steam hands the game. DXVK answers how Direct3D 8, 9, 10 and 11 calls become Vulkan commands. VKD3D-Proton answers the same question for Direct3D 12.

Proton's repository documentation states the first relationship plainly: Proton is a tool for use with the Steam client which allows games exclusive to Windows to run on Linux, and it uses Wine to facilitate this. The DXVK README defines itself as a Vulkan-based translation layer for Direct3D 8, 9, 10 and 11 which allows running 3D applications on Linux using Wine. The vkd3d-proton README describes a fork of VKD3D that aims to implement the full Direct3D 12 API on top of Vulkan, and says the project serves as the development effort for Direct3D 12 support in Proton.

Put together, the four layers look like this. The symptom column is the practical read on the same table: it follows from the scope each project claims for itself in its own README, so it points at a layer rather than at a specific bug.

Layer	Job	Project	Failure symptom
Wine	Runs the Windows executable and answers its API calls	Wine, vendored inside Proton's source tree	The game never reaches a rendered frame: launcher, installer, input or file path breaks
Proton	Packages Wine, DXVK and VKD3D-Proton, then applies per-title settings from Steam	ValveSoftware/Proton	The same title behaves differently on different Proton builds
DXVK	Translates Direct3D 8, 9, 10 and 11 calls to Vulkan	doitsujin/dxvk	No or broken 3D output on a Direct3D 9, 10 or 11 title, or the HUD shows wined3d instead
VKD3D-Proton	Translates Direct3D 12 calls to Vulkan	HansKristian-Work/vkd3d-proton	A Direct3D 12 title fails on a driver below the README's hard requirements
Shader compilation	Converts the game's shader bytecode into Vulkan shaders and caches the result	Both translators, each with its own cache	Stutter in the opening minutes that fades as the cache fills

Layer one: Wine and the Windows API surface

Wine is the base of the stack, not an optional add-on. Proton's README says Proton uses Wine to facilitate running Windows-exclusive games on Linux, and Proton's source carries its own Wine tree rather than calling out to a system install. The README's build instructions tell anyone changing Wine to apply those changes to the wine/ directory.

That placement matters. Wine is the layer that sees the executable first: the installer runs, the registry writes, the save path resolves, the input and audio devices appear. None of that work is Direct3D work, which is why a game can fail before it ever asks the GPU for anything. A launcher that never appears and a game that renders at the wrong resolution are often failures in different layers.

Proton also ships a debugging path aimed at this layer. The README documents PROTON_LOG, which dumps a log to a directory of your choosing, plus a debug beta branch and a GDB helper script for loading symbols. Proton builds strip symbols by default, so the README points debugging users at the unstripped build or at the accompanying debug files.

One consequence follows from that packaging. Proton's Wine tree, its translators and its config presets form one specific combination, so a result under a different Wine build is not a promise about Proton, and the reverse holds too.

Layer two: Proton packages Wine and applies the fixes

Proton is the delivery layer. Its README describes a tool for the Steam client, and its build targets list both make dxvk and make vkd3d-proton, which rebuild those two subprojects. The graphics translators are built into the tool, not installed beside it by the player.

The README is explicit that most users should use Proton provided by the Steam client itself, and that Steam ships with several versions of Proton which games use by default or that users can select in the Steam Play settings page. Local builds installed into compatibilitytools.d are the advanced path the README documents, including the option of a different Wine version for a particular title.

The fixes side lives in the runtime config section. Per Proton's README, the Steam client sets options for known games using the STEAM_COMPAT_CONFIG variable, and users can override those options with environment variables per game, usually by appending the variable before %command% in the launch options. The README notes these are runtime options only: removing one reverts the previous behavior rather than permanently altering the Wine prefix.

Two documented options show how deep the layer reaches. PROTON_USE_WINED3D=1 swaps the OpenGL-based wined3d renderer in for the Vulkan-based DXVK renderer for Direct3D 11, 10 and 9. PROTON_NO_D3D11 disables d3d11.dll outright, for Direct3D 11 games that the README says can fall back to and run better with Direct3D 9. Both change which layer the game ends up using, which is why "it worked on another Proton version" is diagnostic information rather than superstition.

Layer three: DXVK turns Direct3D 8, 9, 10 and 11 into Vulkan

DXVK sits under the game's Direct3D calls and above the Vulkan driver. Its README defines it as a Vulkan-based translation layer for Direct3D 8, 9, 10 and 11 which allows running 3D applications on Linux using Wine. Proton's README names the alternative it replaces: wined3d, the OpenGL-based renderer that Proton can use instead of the Vulkan-based DXVK renderer for Direct3D 11, 10 and 9.

The layer boundary is made of DLLs, and the README lists exactly which ones each API needs. That list is the clearest evidence that this is a layer and not a wrapper around the whole game.

Direct3D API	DLLs DXVK supplies, per its README
Direct3D 8	`d3d8.dll` and `d3d9.dll`
Direct3D 9	`d3d9.dll`
Direct3D 10	`d3d10core.dll`, `d3d11.dll` and `dxgi.dll`
Direct3D 11	`d3d11.dll` and `dxgi.dll`

A manual install is deliberately low level: copy the DLLs into the prefix's system32 and syswow64 directories, open winecfg, and add native DLL overrides for d3d8, d3d9, d3d10core, d3d11 and dxgi. Tools such as Steam Play, Lutris, Bottles and Heroic Launcher handle that setup on their own when enabled, per the same README.

DXGI is the shared piece. vkd3d-proton's README states that it does not supply the necessary DXGI components on its own, and that DXVK and vkd3d-proton share a DXGI implementation. That is why the two translator layers are siblings rather than a sequence: a Direct3D 12 title uses VKD3D-Proton for the 3D API and DXVK's DXGI for the swapchain side.

The README gives players a way to confirm which path is live. Enabling the HUD verifies that an application uses DXVK instead of wined3d, and DXVK_LOG_PATH writes per-application log files such as app_d3d11.log and app_dxgi.log. The same README carries a blunt warning that manipulating Direct3D libraries in multiplayer games may be considered cheating and can get an account banned, including in single-player games with a multiplayer portion. That risk belongs to the layer, not to Proton alone.

DXVK also exists in a form that removes Wine from the picture. DXVK Native lets the same translation layer be used without Wine, primarily for game and application ports and for port bringup during development, with a window system backend selected through DXVK_WSI_DRIVER. The option is a reminder that Wine and DXVK are separate components that can be paired or unpicked.

Layer four: VKD3D-Proton turns Direct3D 12 into Vulkan

VKD3D-Proton is the Direct3D 12 sibling. Per its README it is a fork of VKD3D that aims to implement the full Direct3D 12 API on top of Vulkan, and it serves as the development effort for Direct3D 12 support in Proton. Its intended delivery is a pair of native Win32 DLLs, d3d12.dll and d3d12core.dll, used as a drop-in replacement for Direct3D 12 in Wine, in Proton or on Windows.

This layer is where driver requirements bite hardest. The README sets hard requirements of Vulkan 1.3, descriptor indexing with at least one million UpdateAfterBind descriptors for all types except UniformBuffer, the samplerMirrorClampToEdge and shaderDrawParameters device features, VK_EXT_robustness2 and VK_KHR_push_descriptor. It also lists extensions that should be supported for correct behavior, including VK_EXT_image_view_min_lod.

The project states its priorities without apology: performance and game compatibility are important targets, at the expense of compatibility with older drivers and systems, and modern Vulkan features are aggressively used. The README recommends the very latest drivers available. It names RADV as the recommended AMD driver and puts the minimum NVIDIA requirement at the 535 series, while noting that Intel GPUs had not been tested.

Those requirements are the first thing to check when a Direct3D 12 title refuses to start while Direct3D 11 titles in the same library run. A driver that satisfies Proton's older Direct3D 11 path can still fall short of the Direct3D 12 path, and no Proton setting fixes a missing Vulkan feature.

Where shader compilation fits

Shader compilation is not a fifth translator. It is a stage both translators perform, and it is the stage players notice because its failure mode is stutter rather than a crash.

Per the DXVK README, on drivers that support VK_EXT_graphics_pipeline_library, Vulkan shaders are compiled when the game loads its Direct3D shaders rather than at draw time, which reduces or eliminates shader compile stutter in many games. The cost moves rather than disappears: games that load shaders during loading screens or menus can show prolonged periods of very high CPU utilization, especially on weaker CPUs, and the README recommends waiting for compilation to finish before starting play. Compiler activity can be watched with DXVK_HUD=compiler.

The README is careful about the exception. Games that only load their Direct3D shaders at draw time, a group it says includes most Unreal Engine games, will still exhibit some stutter, though it should be less severe than without the feature. That single caveat explains a large share of "this game stutters on Linux" reports that are not layer failures at all.

Both translators keep caches for exactly this reason. DXVK maintains an internal shader cache, disabled with DXVK_SHADER_CACHE=0 and relocated with DXVK_SHADER_CACHE_PATH, defaulting to %LOCALAPPDATA%/dxvk in a Wine environment. VKD3D-Proton caches Direct3D bytecode to SPIR-V conversion in vkd3d-proton.cache, generally in the game install folder when running in Steam, and documents VKD3D_SHADER_CACHE_PATH to move or disable it. Its README says the cache reduces stutter when pipelines are created last minute and shortens load times when applications load pipelines up front.

The practical result is that the first run and the tenth run of the same game are different workloads. A cache that has filled makes the tenth run smooth, and deleting that cache brings the first-run behavior back.

Reading a failure by layer

Start with whether the game process runs at all. If the launcher, installer or save system breaks, the problem sits in the Wine layer, and Proton's README points at PROTON_LOG for evidence before any graphics question is worth asking.

Next, test whether the same title behaves differently on another Proton build. The README's own example of altering Proton is running a different Wine version for a particular title, and its runtime config presets exist precisely because some titles need different settings. A title that works on one build and fails on another implicates the Proton layer, including its per-game presets, not the driver.

Then confirm which graphics path the game reached. The DXVK HUD verifies whether an application uses DXVK or wined3d, and DXVK_LOG_PATH writes per-application logs. On the Direct3D 12 side, VKD3D_DEBUG controls the log level and VKD3D_SHADER_DEBUG controls logging from the shader compilers, both documented in the vkd3d-proton README.

Finally, decide whether anything failed at all. Stutter that fades after the first minutes is a filling shader cache, not a broken layer, and the DXVK README's note about draw-time shader loading covers the games where it will not fully fade.

Our take

I think the layer model is worth memorizing because it turns a vague complaint into a question with an address. I would rather see a launcher report which DXVK and VKD3D-Proton build it loaded than a compatibility badge with no detail, and I would rather read the README of the layer that broke than a forum thread guessing at all four at once. None of that makes a broken title work, but it stops people from reinstalling a game that was never the problem.

FAQ

What is the difference between Wine and Proton?
Per Proton's README, Proton is a tool for the Steam client that runs Windows-exclusive games on Linux and uses Wine to facilitate this. Proton packages Wine with the graphics translators and the Steam-side per-title settings; Wine is the Windows API layer underneath.

Do I need to install Wine separately to use Proton?
No. The README says most users should use the Proton provided by the Steam client itself, and that Steam ships with several Proton versions selectable in the Steam Play settings page. Separate installs are the advanced path for people building or modifying Proton.

Which Direct3D versions does DXVK handle?
Direct3D 8, 9, 10 and 11, per the DXVK README. Direct3D 12 is handled by a different project, VKD3D-Proton.

What translates Direct3D 12 on Linux?
VKD3D-Proton, a fork of VKD3D that aims to implement the full Direct3D 12 API on top of Vulkan, delivered as d3d12.dll and d3d12core.dll. Its README says it serves as the development effort for Direct3D 12 support in Proton.

Why does a game stutter for the first few minutes?
Shader compilation. DXVK compiles Vulkan shaders when a game loads its Direct3D shaders on drivers with graphics pipeline library support, and both translators cache the results so later runs are smoother. The DXVK README notes that games loading shaders only at draw time, including most Unreal Engine titles, can still stutter.

Why does a Direct3D 12 game refuse to start on an older driver?
VKD3D-Proton's README sets hard requirements including Vulkan 1.3, descriptor indexing with at least one million UpdateAfterBind descriptors, VK_EXT_robustness2 and VK_KHR_push_descriptor, and states that compatibility with older drivers is deliberately sacrificed. A Direct3D 11 title can run on a driver that the Direct3D 12 path cannot use.

Bottom Line

A Windows game on Linux passes through four layers, and each one publishes its own scope: Wine for the Windows API surface, Proton for packaging and per-title fixes, DXVK for Direct3D 8 through 11, and VKD3D-Proton for Direct3D 12. Shader compilation crosses the two translator layers and explains the stutter that is not a failure. When a title does not run, the layer that broke tells you which README to open and which log to read.

Sources: ValveSoftware/Proton repository README, doitsujin/dxvk repository README and HansKristian-Work/vkd3d-proton repository README, all fetched October 19, 2026: Proton, DXVK, VKD3D-Proton.