Shader stutter in DXVK: why it happens and what actually helps in 3.x

Which stutter do you have?

What DXVK already does for you

Graphics Pipeline Library (2.0 and later)

On drivers that support the VK_EXT_graphics_pipeline_library extension, DXVK compiles Vulkan shaders when the game loads its Direct3D shaders, not when it first draws with them, which reduces or removes shader compile stutter in many games (README at 3.1.1). Our 3.1.1 runs logged Graphics pipeline libraries supported on both Windows and Wine (F20; software driver). You can watch the work with the HUD’s compiler item; see the HUD guide.

The cost: in games that load shaders in a menu or loading screen, you can see a long stretch of very high CPU use, worse on weaker CPUs. The README advises waiting for compilation to finish before playing.

The shader cache (3.0 and later)

3.0 added a cache of DXVK’s translated shader work (an intermediate form, not finished Vulkan pipelines), which offsets the higher cost of its new shader compiler. We saw it created: the log line Created cache file: …\d457b6a386c27677.dxvk.bin, with a .dxvk.bin and a .dxvk.lut file per game (F19).

Your driver’s own cache

NVIDIA and Mesa drivers keep their own compiled pipelines, and Steam’s shader pre-caching is a separate system. Clearing a driver cache makes DXVK’s pipelines compile again.

First run vs second run: not measured yet

We planned a chart of the same route played twice, first with an empty cache and then with a full one. That needs a real GPU and real games, which this project’s lab does not have, so there is no chart and no number here.

Where the cache is, and how to clear it

To open it on Windows press Win+R, type %LOCALAPPDATA%\dxvk and press Enter. This is what the folder held after our Windows run with two small test programs:

The files are tiny because our test programs use trivial shaders; real games will grow them, and we have no real sizes. Delete the folder’s files to clear it; set DXVK_SHADER_CACHE_PATH to move it (verified, F19), or DXVK_SHADER_CACHE=0 to switch it off, which is for troubleshooting only.

“DXVK not creating a cache” and other cache questions

No cache folder usually means one of: DXVK is not loaded, the version is older than 3.0, DXVK_SHADER_CACHE=0 is set, or the folder is not writable. DXVK 1.10.3 and 2.x use the old state cache instead, and 1.10.3 logs it:

          1
          warn:  DXVK: No state cache file found
          
          
          The old state cache, normal for 1.10.3.
        
          2
          warn:  DXVK: Creating new state cache file
          
          
          
        

Can you share caches? Pipelines are compiled per driver, so there is little reason to; we did not test whether the 3.x cache is invalidated by version changes.

Things that no longer exist

What you can do

1. Let loading screens finish and watch the compiler HUD item: heavy compile activity after the menu is normal on GPL drivers (README).
2. Play the same area twice: the cache should help the second run. We have not measured how much.
3. Keep your GPU driver current: GPL depends on the driver.
4. Cap FPS or set a frame latency to smooth pacing; see the FPS limit page.
5. On Linux and Steam Deck, keep Steam’s shader pre-caching on.
6. Close overlays.
7. If you accept the risks, an async fork: see the async page.

More compiler threads rarely help. dxvk.numCompilerThreads defaults to 0, which uses all CPU cores, and our runs logged DXVK: Using 4 compiler threads.

Unreal Engine and other draw-time shader games

GPL cannot help games that only load their Direct3D shaders at draw time, such as most Unreal Engine games. The README says they will still stutter somewhat, though less than without GPL. Many of these games stutter on native DirectX too; we have not compared.