D3D12 vs Vulkan on Steam Deck: Stutter & Frame-Time Benchmark

D3D12 games on Steam Deck don’t stutter for one single reason. The useful comparison is not “DirectX 12 versus Vulkan” in the abstract; it’s native Vulkan versus D3D12 translated through VKD3D-Proton, tested with shader caches, physics load, ray tracing, drivers, and anti-cheat held in view.

Key Takeaways

• Translation is only one suspect: VKD3D-Proton can add CPU work, synchronization, shader conversion, and feature-mapping overhead, but a stutter may still originate in physics or pipeline compilation.
• Average FPS hides the problem: A translated game can match native Vulkan in average frame rate while losing badly in 1% lows, 0.1% lows, and frame-time consistency.
• Use a diagnostic benchmark: Warm and cold shader-cache runs, low-preset CPU tests, ray-tracing toggles, and physics-heavy scenes reveal far more than a single FPS average.

What the Steam Deck is actually running

The two paths look like this:

Native Vulkan
Game engine → Vulkan → Linux Vulkan driver → GPU

D3D12 through Proton
Game engine → D3D12 → VKD3D-Proton → Vulkan → Linux Vulkan driver → GPU

That second route is not a crude emulator. VKD3D-Proton maps D3D12 concepts onto Vulkan and can perform extremely well in the right game. It still has more translation decisions to make, though:

• D3D12 resource states must be represented through Vulkan synchronization.
• Descriptor heaps and pipeline state need equivalent Vulkan handling.
• HLSL shaders may pass through conversion and compilation steps.
• Windows-specific assumptions can collide with Linux driver behavior.
• Presentation, frame pacing, and memory management may differ from a native port.

This is why “Vulkan is faster” is too blunt to be useful. A native Vulkan build may have a cleaner steady-state path, but a poorly optimized Linux port can lose to a well-tuned Windows build running through VKD3D-Proton.

The available comparative Linux and Windows testing points in the same direction: one 2026 test set reported an average Linux performance reduction of 11.1% at 1080p and 16.3% at 4K. Those figures are not a universal Proton penalty. They vary by game engine, driver, GPU vendor, resolution, API, and whether the Linux version is native or translated.

On AMD hardware, including the Steam Deck’s custom AMD APU, several games can approach parity. The exceptions are where the details matter: D3D12 translation, native-port quality, ray tracing, shader preparation, and CPU-heavy game logic.

A benchmark that can separate the causes

A credible Steam Deck comparison needs more than two API labels and an FPS counter. Keep the game build, scene, camera path, resolution, upscaler, frame limiter, and graphics settings identical.

Run these conditions:

On Steam Deck, use the same Proton version, Mesa version, kernel, and SteamOS build for each run. Log them. A result captured on one Proton release can change after a VKD3D-Proton or Mesa update.

For frame-time capture, MangoHud is a practical starting point:

mangohud --dlsym %command%

Useful MangoHud fields include average FPS, frame-time graphs, CPU and GPU utilization, temperatures, clocks, and power. For deeper work, combine it with PresentMon-compatible capture or a frame-time logger that records percentile data.

At minimum, publish:

• Average FPS
• Median frame time
• 1% low
• 0.1% low
• 99th-percentile frame time
• Maximum frame-time spike
• Game-thread time
• Render-thread time
• Physics time
• GPU frame time
• Shader compilation events
• GPU utilization and clocks

The distinction between 1% and 0.1% lows matters on a handheld. A game averaging 40 FPS may feel excellent at a stable 25-millisecond frame time. The same game can feel broken if traversal repeatedly produces 100- or 200-millisecond spikes.

A useful interpretation rule is straightforward:

Why shader compilation often gets blamed on the API

Native Vulkan may feel smoother on Steam Deck even when its steady-state renderer is not dramatically faster. The difference can come from how the game distributes and warms shader caches.

A native build may ship a better-prepared pipeline cache or use fewer shader permutations. A D3D12 game running through VKD3D-Proton may need to convert and compile more shader variants as effects appear. The player experiences this as traversal stutter, a hitch when entering combat, or a pause when a new material first appears.

That is not the same as permanent API overhead.

Run each test twice: once with a cold cache and once after the game has visited the same areas. If native Vulkan wins only during the first pass, the advantage is probably pipeline preparation. If VKD3D-Proton remains worse after the cache is warm, investigate CPU submission, synchronization, resource-state tracking, or game-specific behavior.

The reverse can happen too. Steam’s shader pre-caching may not cover every runtime path, and a game’s native Linux build may have weaker cache management than its Windows release. “Native” does not guarantee smooth frame pacing.

Physics can be the hidden Steam Deck bottleneck

The Deck’s GPU often gets blamed because the game is running through Proton. A low GPU utilization reading tells a different story: the CPU may be spending the frame on physics, animation, visibility, gameplay scripting, or draw submission.

Physics is particularly easy to misdiagnose. A destruction scene can increase collision detection, rigid-body constraints, ragdolls, animation coupling, and scripting at once. If the renderer is lightly loaded, those costs show up as poor 1% lows even though changing texture quality does almost nothing.

The 2026 Geekbench 7 Game Physics workload illustrates how wide CPU simulation capacity can vary. A submitted Apple M5 MacBook Air result recorded 146.2 FPS in the single-core Game Physics test, with a 3,614 physics score. A MediaTek MT8189 result recorded 27.9 FPS, with a 689 physics score. These are not Steam Deck predictions and they do not compare Vulkan with D3D12. They demonstrate why CPU simulation must be measured independently from rendering.

A practical Steam Deck test uses the lowest graphics preset at a fixed resolution, then compares a quiet scene with a physics-heavy one. If GPU utilization falls but frame time worsens during combat or destruction, the likely problem is simulation or game-thread saturation—not necessarily VKD3D-Proton.

Physics middleware also complicates API comparisons. One build might use CPU PhysX, another Jolt, another Havok, and another a custom solver. Different collision meshes, solver iteration counts, thread scheduling, and ragdoll settings can outweigh the graphics API difference.

GPU physics is not a universal solution. CUDA-based PhysX can be useful on supported NVIDIA hardware, but it is a poor portability baseline for Steam Deck, AMD, Intel, Apple, consoles, and mobile devices. GPU dispatch and CPU/GPU synchronization can also cost more than they save in smaller scenes.

Ray tracing and anti-cheat change the platform question

Ray tracing creates another bad comparison when reviewers treat “RT on” as a single setting. D3D12 commonly uses DXR; Vulkan uses extensions for acceleration structures, ray-tracing pipelines, and ray queries. Similar hardware features do not mean identical workloads.

A valid test records the ray count, BVH build or update behavior, denoiser cost, shader-cache state, and GPU memory pressure. Disable ray tracing first when diagnosing ordinary stutter. If the game becomes smooth with RT off, the API is not yet proven guilty.

Anti-cheat belongs in the report for a different reason. It can affect:

1. Launch compatibility — the game may not run under SteamOS.
2. Runtime compatibility — services or process-monitoring assumptions may fail.
3. Competitive eligibility — a technically fast Linux configuration may still be unsuitable for ranked play.

An anti-cheat failure is a platform limitation, not evidence that Vulkan or VKD3D-Proton renders more slowly. Report whether the title is fully supported, limited, disabled, or incompatible.

For players, the troubleshooting order is simple: verify the API path, warm the shader cache, disable ray tracing, test low settings, and watch CPU/GPU frame times. If GPU frame time is low and CPU time spikes, investigate physics, scripting, or Proton overhead. If new areas trigger repeatable hitches, suspect shaders. If only one Proton version behaves badly, try another after recording the change.

For developers, choose D3D12 first when Windows and Xbox tooling, PIX, DXR, and Xbox GDK are central. Choose Vulkan first when SteamOS, Linux, Android, or a broad cross-platform renderer matters enough to justify explicit synchronization and resource management. Use Metal directly for serious Apple targets rather than assuming a translation layer will preserve every performance characteristic.

The best Steam Deck result is not always the highest average FPS. It is the configuration that holds frame time steady at a realistic cap—often 30 or 40 FPS—without turning traversal, physics, or shader discovery into visible interruptions.

Frequently Asked Questions

Q: Why does D3D12 stutter on Steam Deck?

D3D12 games running through VKD3D-Proton can stutter during shader conversion, pipeline creation, synchronization, or resource-state translation. The same symptom can also come from CPU physics or game-thread saturation, so compare GPU and CPU frame times before blaming the API.

Q: Is native Vulkan faster than VKD3D-Proton?

Not automatically. Native Vulkan removes the D3D12-to-Vulkan translation step, but a mature VKD3D-Proton path can approach native performance while an under-optimized Linux port can be slower. Warm-cache 1% and 0.1% lows are more informative than API labels.

Q: How can I tell if my Steam Deck is CPU-bound or GPU-bound?

Lower the graphics preset while keeping resolution and frame rate limits fixed. Large gains indicate a GPU bottleneck; little change, combined with low GPU utilization and high game-thread or physics time, points to a CPU-side limit. Frame-time graphs are more reliable than the Steam overlay’s average FPS alone.