DXVK: Running Direct3D 8, 9, 10 and 11 Games on Linux Through Vulkan

What DXVK Replaces, and Who It Is For

DXVK is a Vulkan-based translation layer for Direct3D 8, 9, 10 and 11, and its stated purpose is running 3D applications on Linux using Wine. That sentence defines both the audience and the boundary. The audience is people who already run Windows games or 3D applications inside a Wine prefix and want the graphics calls translated to Vulkan instead of whatever Wine would otherwise use. The boundary is API version: the README lists d3d8, d3d9, d3d10 and d3d11, and says nothing about Direct3D 12, so a D3D12 title is not this project's problem.

The README is explicit that launchers usually handle this for you. Steam Play, Lutris, Bottles and Heroic Launcher will automatically set up DXVK when enabled. Manual installation exists for the cases those tools do not cover: a bare prefix, a game launched outside a launcher, or a prefix where you want a specific DXVK build rather than whatever the launcher ships.

One warning in the README deserves to be read before anything else. Manipulation of Direct3D libraries in multi-player games may be considered cheating and can get an account banned. The README adds that this may also apply to single-player games with an embedded or dedicated multiplayer portion, and closes with use at your own risk. That is not boilerplate. If you are installing DXVK into a prefix that runs an online game, the decision is not purely technical, and no amount of HUD output changes it.

How the DLL Swap and the Overrides Fit Together

DXVK ships as DLLs that take the place of the system ones inside a Wine prefix, plus DLL overrides that tell Wine to prefer the native copies. The README's install instructions are exactly that: copy or symlink the DLLs into the prefix directories, then open winecfg and manually add native DLL overrides for d3d8, d3d9, d3d10core, d3d11 and dxgi under the Libraries tab.

The dependency list in the README is worth reading carefully because the DLLs are not one-to-one with APIs. d3d8 needs d3d8.dll and d3d9.dll. d3d9 needs only d3d9.dll. d3d10 needs d3d10core.dll, d3d11.dll and dxgi.dll. d3d11 needs d3d11.dll and dxgi.dll. So a d3d10 application pulls in the d3d11 and dxgi DLLs even though it never calls D3D11 directly, and a d3d8 application carries d3d9.dll along with it. If you copy a partial set, you get a broken prefix rather than a graceful fallback.

Removal is symmetric and documented. Remove the DLLs and the DLL overrides, then run wineboot -u to restore the original DLL files. The README does not describe a rollback path for a prefix where the original DLLs were overwritten rather than symlinked, which is the practical reason to prefer symlinks when you are experimenting.

Configuration is split between a file and the environment. dxvk.conf sits at the repository top level, and the README documents DXVK_CONFIG_FILE=/xxx/dxvk.conf to point at a specific one. Alternatively DXVK_CONFIG="dxgi.hideAmdGpu = True; dxgi.syncInterval = 0" sets variables through the environment using the same syntax, with a semicolon as the separator. The environment route is convenient for a single test run; the file route is what you want for a prefix you intend to keep. Note that the two documented examples, hideAmdGpu and syncInterval, sit under the dxgi section, which is a reminder that some knobs belong to the DXGI layer rather than to a specific Direct3D version.

Installing DXVK Into a Wine Prefix

Get a package from the releases page first. The README points at the release page for release builds and at the artifacts workflow for the most recent development builds, so there is a choice between a tagged release and a build straight off master. For a prefix you actually play in, the tagged release is the safer starting point.

In a default Wine prefix, the README gives this sequence. It sets the prefix, copies the 64-bit DLLs into system32 and the 32-bit DLLs into syswow64, then opens winecfg so you can add the overrides.

export WINEPREFIX=/path/to/wineprefix
cp x64/*.dll $WINEPREFIX/drive_c/windows/system32
cp x32/*.dll $WINEPREFIX/drive_c/windows/syswow64
winecfg

For a pure 32-bit prefix, which the README describes as non default, the 32-bit DLLs go to system32 instead, and only one copy step is needed.

export WINEPREFIX=/path/to/wineprefix
cp x32/*.dll $WINEPREFIX/drive_c/windows/system32
winecfg

Inside winecfg, the Libraries tab is where the native overrides for d3d8, d3d9, d3d10core, d3d11 and dxgi go. The README is clear that this step is manual. Skipping it leaves the DLLs in place but unused, and the game will keep using whatever Wine would have used.

The first real check is the HUD, because the README says to verify that your application uses DXVK instead of wined3d by enabling it. DXVK_HUD=1 is equivalent to DXVK_HUD=devinfo,fps, so a single variable gives you the GPU name and driver version plus a frame rate. DXVK_HUD=full enables every element. For a first run, devinfo,fps is the useful minimum: if you see the device name and a frame counter, the swap took effect.

When something goes wrong, logs are the next stop. DXVK prints to stderr under Wine, and DXVK_LOG_PATH=/some/directory writes standalone files named app_d3d11.log, app_dxgi.log and so on, where app is the game executable's name. DXVK_LOG_LEVEL=none|error|warn|info|debug controls verbosity, and DXVK_LOG_PATH=none disables log file creation without disabling logging itself. That last distinction matters when you want output on stderr but do not want files accumulating next to the game executable.

The Device Filter Is a Sharp Edge

Some applications offer no way to pick a GPU, and DXVK answers that with two environment variables. DXVK_FILTER_DEVICE_NAME="Device Name" matches on the Vulkan device name, which you can read with a tool such as vulkaninfo. Matching is on substrings, so VEGA or AMD RADV VEGA10 works when the full name is AMD RADV VEGA10 (LLVM 9.0.0). If the substring matches more than one device, the first match wins. DXVK_FILTER_DEVICE_UUID="00000000000000000000000000000001" matches the Vulkan device UUID instead, a 32-character hexadecimal string with no dashes, which the README describes as more precise, especially with multiple identical GPUs.

The README's own note on this is the important part: if the device filter is configured incorrectly, it may filter out all devices and applications will be unable to create a D3D device. There is no fallback to the default device. A typo in a substring, or a UUID copied with dashes still in it, produces a failure that looks nothing like a configuration mistake. If a game suddenly cannot create a D3D device and you have a device filter set, unset it before investigating anything else.

Debugging has its own set of variables. VK_INSTANCE_LAYERS=VK_LAYER_KHRONOS_validation enables the Vulkan validation layers and requires the Vulkan SDK on the host. DXVK_DEBUG takes several modes: capture, hang, markers and validation. The hang mode detects GPU hangs or driver crashes that produce VK_ERROR_DEVICE_LOST and logs the failing commands, which is the mode to reach for when a game freezes rather than errors. The validation mode needs VK_INSTANCE_LAYERS set alongside it on Linux. The capture mode is described as the default when used with certain tools and enables DXVK-internal debug names and debug markers for render passes and shaders, while markers forwards application-provided resource names and debug markers to Vulkan through VK_EXT_debug_utils.

Driver support is deliberately not covered by the README. It points at a wiki page on driver status and asks that you run a recent enough driver version for your hardware before reporting an issue. That is the right place to start with a rendering problem, and it is also a reminder that DXVK's behaviour is partly a function of the Vulkan driver underneath it, not only of DXVK itself.

Where DXVK Is the Wrong Choice

The clearest case is an API the README does not list. Direct3D 12 is absent from the supported set, so a D3D12 title is outside this project's scope, and installing the DLLs will not change that. The same applies to any application that does not go through Direct3D 8, 9, 10 or 11 at all.

The second case is multi-player. The README's warning is not hedged: manipulation of Direct3D libraries in multi-player games may be considered cheating and can get your account banned, and the warning extends to single-player games with an embedded or dedicated multiplayer portion. If the prefix runs an online game, DXVK is the wrong layer regardless of how well it performs.

The third case is operational rather than technical. DXVK's manual install is a copy step plus a manual winecfg change. If you use Steam Play, Lutris, Bottles or Heroic Launcher, the README states these handle setup automatically when enabled, and doing it by hand only adds a way to get it wrong. Manual installation makes sense when a launcher's bundled build is not the one you want, or when no launcher is involved.

The fourth is a partial copy. Because d3d8 needs d3d9.dll and d3d10 needs d3d11.dll and dxgi.dll, installing only the DLL that matches the API name gives you an incomplete set. The dependency list in the README is the checklist.

Finally, there is the shader cache. DXVK_SHADER_CACHE=0 disables the internal shader cache, and DXVK_SHADER_CACHE_PATH sets its location, defaulting to %LOCALAPPDATA%/dxvk in a Windows or Wine environment and to $HOME/.cache or $XDG_CACHE_HOME in a native Linux environment. Disabling the cache is a diagnostic move, not a tuning one. Leaving it off means shader compilation work is repeated instead of being reused across runs.

DXVK Against WineD3D, and Against Doing Nothing

The real alternative is Wine's own wined3d, which translates Direct3D to OpenGL rather than Vulkan. The README frames the two as a choice you verify with the HUD: you enable the HUD specifically to confirm that your application uses DXVK instead of wined3d. The difference in approach is the graphics API underneath. wined3d targets OpenGL, which is what Wine has historically used; DXVK targets Vulkan. Which one is better for a given title is not something the README answers, and it does not claim to. It sends you to the wiki for project status and driver status.

The second alternative is not installing DXVK at all, and for launcher-managed setups that is a legitimate position. Steam Play, Lutris, Bottles and Heroic Launcher set up DXVK themselves when enabled, so the manual path is a fallback for prefixes those tools do not manage. If your launcher already handles it, the only reason to intervene is to pin a specific build or to debug with the environment variables.

A third comparison is between DXVK builds rather than between layers. The README distinguishes release builds from the most recent development builds, which come from an artifacts workflow on master. A development build is how you test a fix that has not been tagged. It is also how you end up running code that has not been through a release, which is a trade you should make deliberately rather than by default.

On the graphics pipeline library front, the README's text is truncated at a mention of VK_EXT_grap, so the mechanism it describes cannot be summarized here. What can be said is that the feature is driver-dependent, which fits the pattern: much of what DXVK can do is bounded by what the Vulkan driver exposes.

Licence, Maintenance and Upgrade Cost

DXVK is licensed under the Zlib licence. That is a permissive licence, and it is worth noting what the project does not do: it does not ship a licence file that imposes conditions on the games you run through it, and the DLL swap does not modify the application. None of this is legal advice, and if you redistribute DXVK inside a product, read the licence text in the repository rather than a summary.

The repository is not archived, and the last push was on 2026-09-19. Recent releases are v3.1.1 on 2026-09-15, v3.1 on 2026-08-28 and v3.0.2 on 2026-07-17. That is a steady cadence across the last few months, and the version numbers show that the project does make breaking changes across major versions rather than holding an API stable forever.

Upgrade cost depends on how you installed it. If a launcher manages DXVK, the launcher decides when you move, and your work is verifying that a game still renders correctly afterward. If you installed by hand, an upgrade means replacing the DLLs in system32 and syswow64 and confirming the overrides are still in place. The README's removal procedure, deleting the DLLs and overrides and running wineboot -u, is the clean way to reset a prefix that an upgrade has broken. Keep the old DLLs before overwriting them; the README does not document a downgrade path, and the release page is where an older package would come from.

Reading the HUD Without Guessing

The HUD is the closest thing DXVK has to a status page, and its options are worth knowing beyond devinfo and fps. drawcalls shows the number of draw calls and render passes per frame. submissions shows command buffers submitted per frame. pipelines shows the total number of graphics and compute pipelines. descriptors shows descriptor pools and descriptor sets. memory shows device memory allocated and used, while allocations gives detailed chunk suballocation info. gpuload shows estimated GPU load, and the README notes it may be inaccurate, which is a useful admission rather than a caveat to ignore.

Two options are API-specific and only meaningful in one context. samplers shows the current number of sampler pairs used and is marked D3D9 only. swvp shows the vertex processing mode and the current number of software vertex processing shaders, also D3D9 only. If you are not running a D3D9 title, these will not tell you anything.

The remaining options are about the machinery rather than the frame. compiler shows shader compiler activity, cs shows worker thread statistics, api shows the D3D feature level the application is using, and version shows the DXVK version. The api readout is the one to check when a game behaves as though it is on an older feature level than you expect, since it reports what the application asked for rather than what you assumed.

Presentation is adjustable. scale=x scales the HUD by a factor, for example 1.5, and opacity=y adjusts opacity, with 1.0 fully opaque and 0.5 given as an example. On a small display or at high resolution, the default size can be unreadable, and scale is the fix rather than a different HUD mode. Combining several elements in one comma-separated value is how the README expects you to use it, so a diagnostic run can carry drawcalls, pipelines and api together.

Editorial conclusion

DXVK is the right layer when you run Direct3D 8 to 11 titles under Wine and want Vulkan rather than OpenGL underneath. It is the wrong tool for Direct3D 12, which the README does not list among the supported APIs, and for anyone unwilling to set native DLL overrides by hand. Before adopting it, verify two things in your own prefix: that your Vulkan driver is recent enough per the wiki's driver support page, and that the HUD reports the expected API and device, since a misconfigured device filter can leave an application unable to create a D3D device at all.

Frequently asked questions

Official sources

1. doitsujin/dxvk on GitHub
2. Issues
3. License: Zlib
4. README
5. Releases