DXVK async and gplasync: what they are and whether you still need them

Which async is which

Where to get them: only from the project pages above (the GitLab repository and its releases). Do not download re-uploads. We host no fork files.

How async works (and what it costs)

Normally a frame waits when the game uses a shader that is not compiled yet: that wait is the hitch. Async draws the frame anyway and leaves out the object whose shader is not ready, then shows it a few frames later. You trade a pause for a brief visual gap, which players describe as pop-in or missing objects (community reports; we did not reproduce it). The fork’s README says it lets frames be drawn before shaders finish compiling and can run together with the Graphics Pipeline Library.

Where official DXVK fits: GPL compiles shaders at load time when the game loads its shaders early, and 3.x’s shader cache helps repeat runs (see the stutter page). Async only matters for what is left: shaders created at draw time.

Do you still need it in 2026?

• Official 3.x, a GPL-capable driver, and the game loads shaders early: probably not.
• Games that create shaders at draw time (most Unreal Engine games), or drivers without GPL: maybe; the README says GPL leaves some stutter there.
• Any online game: no.

We measured it: not yet

We planned a same-route comparison of official 3.1.1 against gplasync, with frames over 50 ms and a screenshot pair for pop-in. That needs a real GPU, real games and the fork’s DLLs on a Linux desktop, which our lab does not have. So this page gives you no numbers and does not claim async helps or hurts any game.

How to turn it on

Windows

Download the gplasync release that matches your DXVK line from its GitLab releases page, and place the DLLs exactly like normal DXVK (see the Windows guide). Then enable it in dxvk.conf or the environment, per the fork’s README:

          
          dxvk.enableAsync = True
          
          
          
        

Official DXVK ignores that line. Our Config Builder flags it as fork-only if you choose “gplasync” as the DXVK line. We have not run the fork, so we cannot show you its log banner; check the log for the version the fork reports, and use the DLL Verifier on the download page: an async build is “DXVK-based, not an official release file” and the verifier marks async builds when it finds the async markers (F45).

Linux and Proton

Replace the DLLs in a Wine prefix, or use a launcher that offers gplasync builds. The environment variable form is DXVK_ASYNC=1. Details for launchers are on the launchers page.

Winlator and Android

People use packaged builds in Winlator. We host none and link none; see the Android page.

Risks

• Anti-cheat. The fork’s README says to use it at your own risk in games with anti-cheat. The official README warns that replacing Direct3D DLLs can be treated as cheating.
• Visual glitches. The fork’s README mentions graphical glitching with its memory-defrag feature in some versions and offers dxvk.enableMemoryDefrag=false as a workaround.
• Extra VRAM. The fork’s README says the Graphics Pipeline Library can increase VRAM use, and dxvk.enableGraphicsPipelineLibrary=false turns it off.
• Lag behind upstream, and bug reports. Forks follow official releases after a delay. Do not report fork problems to official DXVK; report them to the fork.

Old async versions people still search for

“1.10.3 async” means Sporif’s patch on 1.10.x, for older GPUs, now archived: see the 1.10.3 page. Fork releases are numbered after the upstream version they are built on, so an old number carries that old version’s bugs. Use the current fork release and read the release history for what changed upstream.

Settings that only work with the fork