How we test DXVK

Linux/Wine: all 6 base-dxvk311-* cases ok, log banner info: DXVK: v3.1.1. Windows Server 2025 and 2022: all 6 ok with lavapipe. (run1 base-dxvk311-*; ci-4 base-dxvk311-*)

No registry change, no install step: the game loaded …\game\d3d11.dll / dxgi.dll / d3d9.dll from its own folder (column loadedD3D11 etc.). (ci-4 base-dxvk311-*)

Same files, no WINEDLLOVERRIDES: the game silently used Wine's built-in C:\windows\system32\d3d11.dll (wined3d, fake "NVIDIA GeForce GTX 470" adapter), no DXVK log. With d3d8,d3d9,d3d10core,d3d11,dxgi=n,b: DXVK active. (run1 method-noovr-dxvk311-d3d11-64 vs base-dxvk311-d3d11-64)

x64 DLLs into system32, x32 DLLs into syswow64, overrides set to native in the registry → DXVK active for 32-bit and 64-bit games. (run1 method-prefix-dxvk311-d3d9-32, method-prefix-dxvk311-d3d11-64)

x64 DLLs next to a 32-bit game (or x32 next to a 64-bit game): no error, no log, the game simply keeps using the system Direct3D (Windows: WARP / your normal driver; Wine: wined3d). (ci-4 fail-wrongarch-* both machines; run1 fail-wrongarch-*)

Only d3d11.dll copied: device creation fails, DXVK logs err: D3D11CreateDevice: Failed to create swap chain, the app gets 0x887A0004 (DXGI_ERROR_UNSUPPORTED). Same on Windows Server 2025/2022 and Wine. (ci-4 fail-d3d11only-64; run1 fail-d3d11only-dxvk311-64)

The D3D8 run loaded DXVK's d3d9.dll as well and wrote both *_d3d8.log and *_d3d9.log. (ci-4 base-dxvk311-d3d8-64 logFiles)

Native D3D8 x64 failed with "LoadLibrary d3d8.dll failed" on both Windows Server machines; 32-bit D3D8 worked. Real D3D8 games are 32-bit, so use the x32 folder. (ci-4 base-native-d3d8-64, base-native-d3d8-32)

and still ships d3d10.dll, d3d10_1.dll and setup_dxvk.sh; a D3D8 game with 1.10.3 keeps using the system D3D8. D3D8 support arrived in 2.4 (upstream). (tarball listing in run1-…/logs/; run1 compat-dxvk1103-d3d8-64 dxvkActive = False)

(D3D9 and D3D11, x64). (ci-4 compat-*)

dxvk-3.1.1.tar.gz 18,041,512 bytes (SHA-256 40565b4a724aadc4433fa4e010b4b23916d9b1f1baeee64e17186db94f54e608), unpacks to 45.7 MB; dxvk-2.7.1.tar.gz 10,310,666 bytes (d85ce7c79f57ecd765aaa1b9e7007cb875e6fde9f6d331df799bce73d513ce87); dxvk-1.10.3.tar.gz 8,509,003 bytes (8d1a3c912761b450c879f98478ae64f6f6639e40ce6848170a0f6b8596fd53c6). Each holds x64/ and x32/. 3.1.1 DLL sizes (x64 / x32, bytes): d3d11 7,483,406 / 8,192,014; d3d9 7,286,798 / 7,856,142; dxgi 5,414,926 / 5,877,774; d3d8 1,564,686 / 1,687,566; d3d10core 122,894 / 180,238. 3.x DLLs are about 1.7× the size of 2.7.1's. (downloads.json in ci-4 logs; run1 tarball listing)

After deleting them from the game folder the same game loaded C:\Windows\SYSTEM32\d3d11.dll again and ran on the normal driver. Nothing else was changed by DXVK. (ci-4 uninstall-before-d3d11-64 → uninstall-d3d11-64/stdout.txt)

With just d3d9.dll (plus the Vulkan loader) next to the .exe, DXVK ran (banner DXVK: v3.1.1), 32-bit and 64-bit, and the system dxgi.dll stayed in use. Copying dxgi.dll is not required for D3D9. (ci-6 dll-d3d9only-d3d9-32/64, both Windows machines; loadedDXGI = C:\Windows\system32\dxgi.dll)

With only d3d8.dll: no DXVK banner, Direct3DCreate8 returned NULL, and the system d3d9.dll was loaded. The log line is err: D3D8Interface: ERROR! Failed to get D3D9 Bridge. d3d9.dll might not be DXVK!. With d3d8.dll + d3d9.dll it ran. Extends F07. (ci-6 dll-d3d8only-d3d8-32 vs dll-d3d8d3d9-d3d8-32)

Both copied, nothing else (no d3d10core.dll): DXVK active, device created. (ci-6 dll-d3d11dxgi-d3d11-64) Extends F06.

DXVK's dxgi.dll loaded and printed its banner, then the process died within 0.3 s with exit code 0xC0000005 (access violation) and no output. Mixing DXVK's DXGI with the native D3D11 is not a valid install. (ci-6 dll-dxgionly-d3d11-64, both machines; log dxprobe64_dxgi.log)

Copying 3.1.1 over a folder that held 1.10.3 left 1.10.3's d3d10.dll and d3d10_1.dll (1,093,646 bytes each, not part of 3.1.1) next to the new files; D3D9 and D3D11 still loaded 3.1.1's d3d9.dll / d3d11.dll / dxgi.dll and reported DXVK: v3.1.1. 2.7.1 to 3.1.1 left nothing extra. The stale files were not exercised (dxprobe has no D3D10 path), so "harmless" is untested: advise deleting the old DLLs first. (ci-6 swap-1103to311-*, swap-271to311-d3d11-64; gameDlls field in each result)

Our Windows matrix extracted dxvk-3.1.1, 2.7.1 and 1.10.3 with the tar that ships with Windows (Server 2022 and 2025) before every run. This is the command-line tool, not File Explorer; we did not test File Explorer or 7-Zip. (ci-4 / ci-6 windows_matrix.ps1 download step; downloads.json)

All 95 tagged releases (v0.20 to v3.1.1) have a dxvk-<ver>.tar.gz asset; each was downloaded from the official GitHub release asset URL and hashed together with every DLL inside (4 to 12 DLLs per release; 3.1.1, 3.0 and 2.7.1 have 10: d3d8, d3d9, d3d10core, d3d11, dxgi in x32/ and x64/; 1.10.3 has 12, adding d3d10 and d3d10_1). Data: data/upstream/hashes-raw.json (scripts/build_hashes.py). The 3.1.1, 2.7.1 and 1.10.3 archive hashes equal F11.

In 3.1.1, 2.7.1, 1.10.3 (and spot checks of 1.9.4, 2.0, 2.6.2, 3.0): every d3d9, d3d11, dxgi DLL contains DXVK_LOG_PATH and DXVK_LOG_LEVEL; DXVK_SHADER_CACHE appears only from 3.0; DXVK_STATE_CACHE only up to 2.6.2; DXVK_PERF_EVENTS only in 1.x; DXVK_FRAME_RATE in 1.9 to 2.7.1 and not in 3.x (matches F21); the async markers enableAsync / DXVK_ASYNC are in none of them. The wrapper DLLs (d3d8, d3d10, d3d10_1) hold only the two log names; d3d10core.dll holds none, so only a hash identifies it. Every DXVK DLL carries the Windows-style version text 10.0.17763.1 (WinBuild...), so File Properties cannot tell you the DXVK version. (scripts/test_t5.mjs, scan of the extracted archives)

, named <exe>_d3d11.log, <exe>_dxgi.log, <exe>_d3d9.log, <exe>_d3d8.log. (ci-4 every DXVK case logFiles)

(run1: files exist only because the harness set DXVK_LOG_PATH; the stderr capture has the same lines.)

Game:, DXVK: v3.1.1, Build: x86_64 …, the Vulkan loader line, Found device: llvmpipe … (llvmpipe 25.2.8), and, if a config file was read, Found config file: dxvk.conf followed by Effective configuration:. (run1 conf-maxfps60-file-d3d11-64.stderr.txt)

(it is an info: line), so a log analyser must not treat a missing banner as "DXVK not active". (ci-4 log-path-d3d11-64: log files exist, banner absent)

readMonitorEdidFromKey: Failed to get EDID reg key size and DXGI: Failed to parse display metadata + colorimetry info, using blank. The game ran normally each time. (run1 every *-d3d11-* DXVK case)

: 1 shows device + FPS; full shows version, feature level, device, driver, FPS, queue submissions, draw calls, render passes, barriers, pipelines, shaders, descriptor heaps, memory, CS chunks, GPU load and a cache line (Cache: 256 kB (100% hit)); scale=2.0 doubles it. (screenshots lab-lnx-hud-*, lab-w25-hud-*)

files <hash>.dxvk.bin + <hash>.dxvk.lut in %LOCALAPPDATA%\dxvk (Windows: C:\Users\<you>\AppData\Local\dxvk; Wine: inside the prefix), log line Created cache file: …. DXVK_SHADER_CACHE_PATH moves it (verified). (ci-4 shader-cache-listing.json; run1 cache-run1-d3d11-64.stderr.txt, cache-listing.txt)

on lavapipe 25.2 DXVK 3.1.1 reported Binding model: Descriptor buffer and Graphics pipeline libraries supported. On drivers with descriptor-heap support the line reads Descriptor heap (upstream). (run1 base-dxvk311-d3d11-64.stderr.txt)

DXVK_FRAME_RATE=60 → 184 FPS (uncapped). The same cap in dxvk.conf (dxvk.maxFrameRate = 60) → 60.5 FPS (Wine) / 58.0 FPS (Windows Server 2025) / 57.8 (2022). Upstream removed the variable in 3.0. (run1 conf-maxfps60-env-d3d9-64 vs conf-maxfps60-file-d3d11-64; ci-4 conf-maxfps60-d3d11-64)

DXVK_CONFIG=d3d9.maxFrameRate=30 → 28.3 FPS. (run1 conf-maxfps30-dxvkconfig-d3d9-32)

(the folder the game runs in). (all conf-* cases put it next to the .exe and the log shows Found config file: dxvk.conf)

[dxprobe64.exe] + d3d11.maxFeatureLevel = 10_1 → the game got feature level 10_1; the same option under [otherGame.exe] was ignored (11_0). (run1 conf-perapp-*)

of texture memory (default seen: 3,062 MB for 32-bit, 4,086 MB for 64-bit). Same on Windows. (run1 conf-vram2048-d3d9-32; ci-4 conf-vram2048-d3d9-32)

dedicated video memory. (run1 conf-vram4096-d3d11-64)

dxgi.customVendorId = 1002 / d3d9.customVendorId = 10de change the vendor ID the game sees. (run1 conf-spoofamd-d3d11-64, conf-spoofnv-d3d9-64)

On a GPU whose vendor is not AMD, NVIDIA or Intel (lavapipe, vendor 0x10005), DXVK's D3D9 reported AMD Radeon RX 6700 XT (0x1002:0x73DF) and logged D3D9: Hiding actual GPU, reporting: …; D3D11 reported the real name. (run1 and ci-4 base-dxvk311-d3d9-*)

err: D3D11CreateDevice: Failed to create a DXGI factory, 0x80004005. A matching substring (llvmpipe) works. (run1 fail-filter-*)

(the game runs with defaults). (run1 conf-configfile-env-d3d11-64)

DXVK logs err: Vulkan: vkGetInstanceProcAddr not found and both D3D9 and D3D11 apps crash at start. (ci-4 windows-2022 fail-novulkan-*)

err: DxvkInstance::createInstance: Failed to create Vulkan instance then err: Failed to initialize DXVK.; D3D11 apps get 0x80004005 with D3D11CreateDevice: Failed to create a DXGI factory; D3D9 apps crash; D3D8 gets a NULL device. (ci-4 windows-2025 fail-novulkan-*; run1 fail-novulkan-*; ci-3 first attempt)

on lavapipe (Wine and Windows) when the extensions 3.x needs were present. Consistent with upstream: 3.x checks required features/extensions rather than the version number. Real old GPUs lack those extensions, so they still fail: test T-ERR-05 on pc-old gives the real message. (run1 fail-vk13-*; ci-4 fail-vk13-dxvk311-d3d11-64)

(mesa-vulkan-drivers:i386 and the 32-bit GL libraries on Ubuntu). Before installing them, every 32-bit D3D9/D3D11 app failed at device creation, with wined3d and DXVK alike. (run1 setup notes, apt log in the test repo README)

in our container, while 3.1.1 and 1.10.3 ran; the same 2.7.1 D3D11 case ran on Windows + Mesa 26.2.6 lavapipe. Treat as an environment-specific issue, not a general 2.7.1 problem; do not publish it as a game finding. (run1 compat-dxvk271-d3d11-64; ci-4 compat-dxvk271-d3d11-64)

D3D9 wined3d 340.8 / 261.6 / 137.1 vs DXVK 211.1 / 162.2 / 94.3 at 100 / 1,000 / 4,000 draws; D3D11 wined3d 351.6 / 225.9 / 94.5 vs DXVK 330.7 / 234.3 / 121.7. On a CPU renderer this says nothing about games; it is published only on /tested/ as an example of the method, and as the reason we benchmark games on real GPUs. (run1 scale-*)

DXVK device creation in our app took 45–79 ms vs 117–195 ms for wined3d under Wine (initMs). Relative only. (run1)