Does DXVK make games faster? What the evidence shows

The short answer by game type

The pattern in public reports is consistent, even though no single report proves it. This table is our reading of those reports, not a measured verdict.

Our results

We have none for games. The lab has produced one thing that looks like performance data, and it is deliberately not used here: a software renderer test (F36). On a CPU renderer, frame rates measure the test program’s CPU cost, not what a game would do on a graphics card, so it would mislead. The method is shown on How we test.

Planned test, for when real GPUs are available: at least eight games, two GPU vendors, native Direct3D against DXVK 3.1.1 and 2.7.1, three runs each, average FPS and 1% lows from a frame-time capture, with first-run and second-run stutter counted separately. Every chart will show machine, driver, DXVK version and date, with the raw CSV beside it. Until that exists, treat any FPS table for DXVK on Windows, including ones on other sites, as one machine and one game.

Why DXVK can be faster

These are mechanisms, not guarantees.

• Less CPU per draw call in some paths. A game that makes many draw calls can be limited by how much CPU the Direct3D implementation spends on each. DXVK has its own implementation and a separate command stream thread (step 3 on How DXVK works), so it can spend less in some games.
• Better use of several CPU cores. That command stream thread, and shader compilation on worker threads, move work off the thread that runs the game.
• A different driver path. Vulkan drivers are a separate code path from the Direct3D 9 to 11 ones. Where the Direct3D path is poor for a given GPU, the Vulkan route can be better. Reports of this mostly concern older games and GPUs; we cannot confirm any particular pairing.

Why DXVK can be slower

• Translation costs CPU time. DXVK validates state, translates shaders and records commands. In a game that is GPU-limited this cost is mostly hidden; in a game where the CPU is already the limit and Direct3D was cheap, it can show.
• Shader compilation. Each new shader combination must be compiled by your driver. The first time a scene is drawn this can cost frames; see shader stutter. The 3.0 release notes say the new compiler is not expected to raise overall performance.
• Driver and version differences. Reports disagree between DXVK versions (GitHub issue 5216 calls 2.7.1 the slowest for one game). The 3.0 release notes tell AMD RDNA1 and RDNA2 owners on Windows to stay on 2.x because of severe performance issues; see DXVK 3.x and the Version Picker on the requirements page.
• Overlays and post-processing. One report describes a nearly 60% drop in The Sims 3 when ReShade was added (GitHub issue 3995). The cost belongs to the overlay layer, not necessarily to DXVK, but the combination can be the one that hurts.

Stutter is not FPS

Average FPS can look fine while the game hitches. What matters for feel is the frame time graph and the lowest 1% of frames. DXVK can raise or lower either. It compiles shaders at run time, so the first run of a scene is the worst case; DXVK 3.x writes a shader cache to disk, and we saw its files appear on Windows (F19), but we have not counted hitches in a game. The shader stutter page shows how to tell a shader hitch from other causes.

Try it in 5 minutes and measure yourself

You need the HUD, which we confirmed shows FPS and a frame time graph on Windows and Linux (F18). This works for any game you have already set up with DXVK; the Windows guide covers installing it.

What about Linux and Proton?

On Linux and Steam Deck, the question is different: Wine’s built-in Direct3D (wined3d) against DXVK, not native Windows Direct3D against DXVK. See DXVK vs WineD3D.