Skip to content

Frequently Asked Questions (FAQ)

Jump to bottom
Digger1955 edited this page Mar 16, 2026 · 18 revisions

Frequently Asked Questions (FAQ)

Q: I am a Wine/Proton fork developer, how can I properly integrate and provide DXVK-GPLALL as a part of Wine/Proton fork distribution?

A: Solution:

  1. You should not change DXVK-GPLALL default settings. Its default settings are aimed at the widest possible compatibility.

  2. For users that want to change DXVK-GPLALL settings, you should recommend to use DXVK_CONFIG environment variable or usage of dxvk.conf configuration file. They both are using the same syntax and provide access to the same settings. DXVK-GPLALL fully implements upstream DXVK, DXVK-GPLAsync and DXVK Low Latency and their respective settings, which can be configured using DXVK_CONFIG environment variable or dxvk.conf configuration file.

  3. You should always provide link to the dxvk.conf Options Guide, so the user can fine-tune DXVK-GPLALL for specific needs.

Q: How to run applications with DXVK on Windows 10/11 with NVIDIA GPUs?

A: Solution:

In order to get DXVK working on WIndows 10/11 user have to change a specific setting within the Nvidia Control Panel. There is a specific setting named Vulkan/OpenGL present method that by default is set to AUTO, but instead needs to be set to Prefer layered on DXGI Swapchain for DXVK to load. It appears that without this setting set, the Nvidia driver tries to use a direct native GDI copy present method.

DXVK_NVIDIA_Prefer layered on DXGI Swapchain

Solution discovered by Britt Yazel in upstream DXVK Issues section.

Additional Info on the subject:

Q: Is there any way to apply Anti-Aliasing to D3D8/D3D9 applications?

A: Solution:

This question was asked by upstream DXVK users to upstream DXVK developers - Link to DXVK GitHub Issue.

Short answer is - there is no way to make AA solution that will always work proprely from quality, performance and compatibility standpoint and such solution is out of scope for DXVK.

DXVK-GPLALL is a fork of DXVK, so it is bound by what DXVK developers do in many aspects, in order to not break compatibility and provide GPLALL features.

But there is a solution you can try in order to force MSAA in some games - combine dgVoodoo2 with DXVK. Example for D3D9 x32 application:

  1. Copy dgVoodoo2 d3d9.dll (x32) to the game folder.
  2. Copy dgVoodoo2 dgVoodoo.conf to the game folder with the OutputAPI parameter set to d3d11_fl11_0 and Antialiasing parameter set to your desired value in DirectX section.
  3. Copy DXVK d3d11.dll (x32) and dxgi.dll (x32) to the game folder.
  4. Copy dxvk.conf with the line dxvk.hud = full to the game folder.
  5. Run Game. You will see DXVK HUD, which clearly states that DXVK performs translation from D3D11 to Vulkan. But before that translation occurs, dgVoodoo2 performs translation from D3D9 to D3D11. So it looks like:

Game (D3D9) -> dgVoodoo2 (D3D11) -> DXVK (Vulkan)

I checked that such translation is working properly in different games - Need for Speed Carbon (D3D9), WarCraft 3 1.26a (D3D8), C&C Generals (D3D8).

If you have more than 1 GPU in your PC, make sure that Game, dgVoodoo2 and DXVK use the same GPU. Which GPU is used can be configured in dgVoodoo.conf (Adapters parameter) and dxvk.conf (dxvk.deviceFilter config option).

You should configure other dgVoodoo2 settings using dgVoodoo.conf - dgVoodoo2 Options Guide, dgVoodoo2 FAQ, dgVoodoo2 PCGamingWiki Guide

Important: Wine/Proton users must use older than latest dgVoodoo2 version - dgVoodoo2 Forum Issue Link - Lutris developer recommends:

Latest dgVoodoo2 version that fully works with Wine is 2.79.3

Here are other examples of such solutions:

Note: Some of my messages in these solutions were deleted by DXVK developers, don't know why, but I added them to this issue (Instruction example above and answer to the user's question below):

Passing a wrapper (dgvodoo) through another wrapper (dxvk)? Won't that waste a lot of performance?

It will waste only CPU-performance (additional translation of graphics API calls). For most games where such translation is possible the CPU-performance hit is insignificant. Common rule is: the older the game - the less is the CPU-performance hit, because of older and simpler graphics API calls and lesser amount of them. But, I recommend to use such translation only, if this is the only way to make the game work properly.

Q: Is there any way to use DxWrapper alongside DXVK to run D3D1(DDraw)-D3D9 applications?

A: Solution:

DxWrapper developer elishacloud has answered this question. Quote:

Yes, for most games you can use DXVK alongside dxwrapper.

DX1-DX7:

For DX7 and older games you can use the ddraw.dll stub and dxwrapper.dll/ini files from dxwrapper. Make sure you enable dd7to9 in dxwrapper.ini. Then you can use the d3d9.dll (32bit version) from DXVK.

DX8:

For DX8 games you can use the d3d8.dll stub and dxwrapper.dll/ini files from dxwrapper. Make sure you enable d3d8to9 in dxwrapper.ini. Then you can use the d3d9.dll (32bit version) from DXVK.

DX9:

For DX9 games you can use the d3d9.dll stub and ``dxwrapper.dll/inifiles from dxwrapper. Make sure you enableEnableD3d9Wrapper` in `dxwrapper.ini`.

However, for DX9 games there is an extra step. You still need to use the d3d9.dll (32bit version) from DXVK, however if you just copy that over it will overwrite the d3d9.dll stub from dxwrapper. So you have to use a d3d9.ini stub configuration from dxwrapper to get this to work.

Here is what you can do for DX9 games:

  1. Copy d3d9.dll stub and dxwrapper.dll/ini files from dxwrapper into the game folder.
  2. Enable EnableD3d9Wrapper in dxwrapper.ini.
  3. Download the stub.ini file from here and copy it into the game folder.
  4. Rename stub.ini to d3d9.ini.
  5. Set the RealDllPath in d3d9.ini stub config to d3d9_dxvk.dll.
  6. Rename the d3d9.dll file from DXVK to d3d9_dxvk.dll.
  7. Copy d3d9_dxvk.dll into the game folder.

Here are the files you should see in the game folder when using DX9 games:

  • d3d9.dll - (stub file from dxwrapper)
  • d3d9.ini - (stub config file from dxwrapper)
  • dxwrapper.dll - (from dxwrapper)
  • dxwrapper.ini - (from dxwrapper)
  • d3d9_dxvk.dll - (from DXVK)

Q: Why is GPL disabled by default?

A: Reasons:

  1. This feature is replaced by Async, which does not require any specific driver/extension support and provides better performance than using DXVK with GPL or using DXVK only with state cache.

  2. Use of GPL leads to prolonged periods of very high CPU utilization and decreases GPU-bound performance in some cases.

  3. Use of GPL significantly increases VRAM/RAM usage and since many Vulkan Drivers on Linux do not have effective memory management mechanisims and do not implement VK_EXT_pageable_device_local_memory, using GPL decreases GPU-bound performance in VRAM-limited and VRAM/PCIe bandwidth-limited situations.

  4. Use of GPL requires proper implementation of VK_EXT_graphics_pipeline_library extension which is not available on all devices/drivers. - "GPL broke on all RDNA GPUs sometimes during 2025, can't remember which drivers, could've been between May to August." - Message Link at Guru3D forums. Additional Info: https://forums.guru3d.com/threads/dx9-dxvks-shader-compilation-seems-broken-in-rdna-4-gpus.459451/

Note: GPL is disabled by default since 2.6.1-4. GPL still can be enabled by setting dxvk.enableGraphicsPipelineLibrary = Auto in dxvk.conf.

Q: Why is there no AVX512 (x86-64-v4) build?

A: Reasons:

  1. DXVK code is hard to vectorize for any C/C++ compiler. DXVK-GPLALL-AVX2-AMD64 branch, ver. 2.6.1-5, MSVC build log:
src\util\util_string.h(113) : info C5002: loop not vectorized due to reason '500'
src\util\util_string.h(113) : info C5012: loop not parallelized due to reason '500'

src\d3d8\d3d8_state_block.cpp : info C5002: loop not vectorized due to reason '1301'
src\d3d8\d3d8_state_block.cpp : info C5012: loop not parallelized due to reason '1007'

src\dxvk\dxvk_context.cpp(6982) : info C5002: loop not vectorized due to reason '504'
src\dxvk\dxvk_context.cpp(6982) : info C5012: loop not parallelized due to reason '504'

src\d3d11\d3d11_context.cpp(4880) : info C5002: loop not vectorized due to reason '502'
src\d3d11\d3d11_context.cpp(4880) : info C5012: loop not parallelized due to reason '502'

and etc... Log size is 22 MB.

  1. AVX512 instruction set works best only on CPUs with 512 bit datapath. The only such consumer CPUs are AMD Zen 5. And even on them any use of AVX512 instructions leads to severe downclocking, which will lead to lower in-game performance, especially in stock.

  2. DXVK-GPLALL developers do not have CPUs with AVX512 support, so they cannot test such builds. Untested builds will not be provided.

  3. GCC-MinGW toolchain has a known bug, which leads to crashes in applications, when DXVK is compiled with AVX2 with more than 128 bit datapath and optimizations. It is acknowledged by upstream DXVK developers.

Q: Why is there no -mtune=AMD GCC build?

A: Reasons:

There is no GCC -mtune=AMD build, because there is no such option in GCC compiler. The closest equivalent is -mtune=generic, which is used for GCC-WinMacLinux-SSE4.2-O3-LTO-GENERIC builds.

Q: Why is there no GCC -march=x86-64-v3 equivalent to MSVC /arch:AVX2?

A: Reasons:

There is no GCC -march=x86-64-v3 build, because GCC-MinGW toolchain has a known bug, which leads to crashes in applications, when DXVK is compiled with AVX2 with more than 128 bit datapath and optimizations. It is acknowledged by upstream DXVK developers.

If this bug will be fixed, GCC AVX2 -march=x86-64-v3 build will be added.

Q: Would you consider adding Clang compiler and LLD linker build?

A: Reasons:

In order to provide DXVK-GPLALL builds GitHub Actions infrastructure of upstream DXVK is used. Upstream DXVK only provides GCC and MSVC builds and DXVK-GPLALL limited by upstream DXVK. If upstream DXVK starts to provide LLVM/Clang builds, they will be provided too.

Q: Why is there no /arch:SSE4.2 /favor:AMD64 MSVC build?

A: Reasons:

There is no /arch:SSE4.2 /favor:AMD64 build, because there are no AMD CPUs which will benefit from using such builds. All AMD Zen CPUs support AVX2 and get benefits from using AVX2. All older AMD CPUs either do not support SSE4.2 (AMD Phenom II series and older) or will not benefit from using SSE4.2 (AMD FX series) due to specifics of architecture implementation.

Q: Why is there no /arch:AVX2 /favor:INTEL64 MSVC build?

A: Reasons:

There is no /arch:AVX2 /favor:INTEL64 build, because Intel CPUs are affected by downclocking when they encounter any AVX instructions. Downclocking will lead to significanlty lower overall performance of application that is using /arch:AVX2 /favor:INTEL64 build on Intel CPU.

Intel workarounded AVX throttling problem (high power draw, which leads to high temperatures, when AVX instructions are used) using AVX downclocking solution, but Intel did not solve the AVX throttling problem. The full answer on this question will take too long, so here are links with information reletated to your question:

https://skatterbencher.com/intel-avx-ratio-offset/ - Intel AVX Ratio Offset - AVX downclocking workaround information.

https://www.numberworld.org/blogs/2024_8_7_zen5_avx512_teardown/#throttling - Zen5 Article, Intel's Approach section - information about why workaround is needed and is still used in some form.

In short, there are Intel CPUs that fully affected by AVX downclocking (up to Rocket Lake) and that are partially affected by AVX downclocking (Alder Lake and newer). And any Intel CPU still will throttle enough to lower its clock rate, which will lead in lower performance for user that is using DXVK-GPLALL /arch:AVX2 /favor:INTEL64 build on Intel CPU, espescially, if the application for which DXVK-GPLALL is used, does not use AVX at all (D3D8, D3D9, D3D10 games do not use AVX at all, and the number of D3D11 games which use AVX is rather small).

Clone this wiki locally