Vulkan vs DX12 Stutter: 2026 PSO, RT & Cache Benchmark Results

A Vulkan vs DX12 stutter benchmark rarely identifies a universal API winner. The frame-time difference usually comes from pipeline-state compilation, shader caches, descriptor lifetime, driver behavior, and the way the engine schedules work. Vulkan can deliver better first-run behavior—or worse. The same is true of D3D12, including a renderer using the DirectX 12 Agility SDK.

Key Takeaways

• Vulkan is not automatically smoother: In 3DMark Steel Nomad, Vulkan led D3D12 by 11.9% on an RTX 4090, but DX12 led by 10.8% on Intel Arc A770.
• PSO strategy matters more than API branding: Vulkan graphics pipeline libraries and D3D12 pipeline libraries reduce compilation work, but neither removes the need for offline preparation and cache management.
• Ray-tracing overhead is usually elsewhere: BLAS/TLAS updates, shader divergence, payload size, denoising, and memory traffic often matter more than the API call that launches rays.
• Benchmark cache states separately: First run, warmed cache, deleted cache, driver update, and shader update are different tests—not noise to average away.

Vulkan, D3D12, and the Agility SDK Are Not Three APIs

The comparison needs one correction before any charts appear: the DirectX 12 Agility SDK is not a competing graphics API.

D3D12 is the rendering API. DXR is Microsoft’s ray-tracing interface integrated with D3D12. The Agility SDK lets a game ship and select a newer D3D12 runtime instead of depending entirely on the version installed with Windows.

So the technically accurate comparison is:

Vulkan versus D3D12, with D3D12 using a specified Agility SDK version.

That distinction matters because feature availability, shader delivery, debugging support, and runtime behavior can change with the selected SDK. A 2026 test should record the exact Agility SDK build, Windows version, GPU driver, shader compiler, and validation settings. Calling the result “Vulkan versus Agility SDK” obscures the variables that actually affect frame time.

D3D12 graphics pipeline state objects package shaders and fixed-function state into a prevalidated object. A typical PSO can include the vertex and pixel shaders, input layout, blend state, rasterizer state, depth/stencil state, primitive topology, render-target formats, multisampling configuration, and root signature.

Vulkan uses VkPipeline objects for graphics, compute, and ray tracing. It also exposes more explicit ways to split and reuse compilation work:

• VkPipelineCache
• VK_EXT_graphics_pipeline_library
• VK_KHR_pipeline_library
• Pipeline binaries where supported
• Application-managed asynchronous compilation

The practical difference isn't that Vulkan pipelines are magically cheaper. Vulkan gives the engine more control over how much state gets compiled together and when.

A material system with thousands of shader permutations can benefit from separating vertex input, pre-rasterization, fragment shader, and fragment-output pieces. That may prevent a new render-target format from forcing a completely fresh monolithic pipeline. D3D12 traditionally pushes engines toward complete PSOs, although pipeline libraries and newer state-object delivery workflows narrow that gap.

Why PSOs Cause Stutter on Both Backends

The familiar “shader compilation stutter” is often a PSO problem wearing a shader-shaped disguise.

A game may compile a shader early, then still create a new pipeline when that shader is combined with a previously unseen blend mode, vertex layout, root signature, render-target format, or feature flag. If the render thread waits for that pipeline, one ordinary-looking effect can produce a 100 ms hitch in an otherwise stable 8 ms frame.

That explains why a game may stutter the first time you:

• Enter a new area
• Fire a weapon effect
• See a material with a different permutation
• Change resolution or HDR mode
• Trigger a reflection or shadow variant
• Enable ray tracing for the first time

D3D12 PSO creation moves validation and driver work out of the draw call, but it can still block if the application creates the PSO during gameplay. Vulkan has the same basic risk. A pipeline cache helps reuse compiled data; it does not make a cache miss free.

Graphics pipeline libraries reduce the size of each compilation step, not the need for pipeline planning. They work best when the engine has a sensible content pipeline that can enumerate likely combinations, compile them offline, serialize them, and load them without blocking the render thread.

D3D12 engines can use pipeline libraries, state-object collections, and newer Agility SDK shader-delivery workflows. The exact feature set depends on the SDK and runtime selected by the application. That makes version reporting essential: “DX12” without an Agility SDK version is incomplete benchmark metadata.

A useful telemetry record for every runtime pipeline creation looks like this:

frame=18420
backend=Vulkan
material=metal_panel_07
vertex_layout=skinned_tangent
rt_formats=RGBA16F,D32
shader_variant=clearcoat+ray_query
cache_hit=false
compile_ms=47.3
blocked_render_thread=true

Without that information, a developer sees only a bad 1% low and may blame the API.

Pipeline benchmark results

The clearest supplied cross-API result comes from ComputerBase’s 3DMark Steel Nomad testing, published in May 2024. This is a rasterization benchmark, not a ray-tracing test, and it should be treated as vendor-specific evidence rather than a universal API verdict.

The pattern is the important result. Vulkan led substantially on the tested high-end GeForce cards, while AMD showed a small difference and Intel favored DX12. Driver architecture and compiler quality are part of the outcome. The table says nothing about how a particular game handles runtime PSOs, descriptor allocation, or ray tracing.

For a proper stutter test, report more than average FPS:

• Median frame time
• 1% and 0.1% lows
• Worst-frame duration
• CPU submission time
• GPU frame time
• PSO count and creation duration
• Pipeline-cache hit and miss rate
• First-run and warmed-cache results

A benchmark that averages away a single 200 ms hitch is measuring throughput, not player experience.

Descriptors and Ray Tracing: Where the Time Really Goes

A D3D12 descriptor heap is not the direct equivalent of a Vulkan descriptor set. The fair comparison is between the renderer’s binding policy.

D3D12 commonly uses large shader-visible resource heaps, persistent allocations for long-lived resources, ring-buffer space for transient descriptors, and descriptor tables for bindless indexing. Vulkan engines may use persistent descriptor sets, per-frame pools, dynamic offsets, descriptor indexing, or push descriptors.

Either design can perform well. Either can stall.

Count descriptor updates and binds separately. A renderer that updates 50,000 descriptors but binds only a few tables has a different cost profile from one that binds a new material set for every draw. Comparing those two implementations and declaring one API faster is not a valid experiment.

Ray tracing needs the same discipline. DXR and Vulkan Ray Tracing both expose bottom-level and top-level acceleration structures, ray-generation and miss shaders, hit groups, shader binding data, and explicit synchronization. The API launch call is rarely the dominant cost.

Measure these independently:

1. BLAS build and refit time
2. TLAS build or update time
3. Ray dispatch time
4. Shader-table or shader-binding setup
5. Barriers and synchronization
6. Denoising
7. GPU occupancy and divergence

A ray-traced frame can regress because of a large payload, excessive recursion, poor ray coherence, expensive any-hit shaders, or a TLAS rebuilt every frame. Calling that “DXR overhead” or “Vulkan RT overhead” hides the actual problem.

D3D12’s Shader Execution Reordering can improve workloads where divergent rays create inefficient wave execution. It requires suitable hardware and shader support, and the gain depends on the workload. A reported Alan Wake 2 demonstration showed roughly one-third lower ray-tracing cost using a combination of Opacity Micromaps and SER. That is a feature demonstration, not proof that D3D12 has lower baseline RT overhead than Vulkan.

A Fair Cross-Platform Profiling Workflow

Use the same scene, camera path, resolution, quality settings, shader behavior, descriptor model, and acceleration-structure policy. Then run at least four cache conditions:

• Cold launch after deleting application caches
• Second launch with a warmed cache
• Cache after a shader or content change
• Cache after a driver update

Keep shader compilation out of the GPU timing window, but record it separately. If the engine blocks on compilation, record the blocked duration as a stutter event rather than hiding it.

For NVIDIA comparisons, Nsight Graphics is the most useful common capture environment because it supports both D3D12/DXR and Vulkan/Vulkan Ray Tracing. PIX remains excellent for D3D12 and Xbox analysis, but it is not a neutral cross-API capture tool. Vulkan validation layers, GPU-assisted validation, vendor profilers, PresentMon, Tracy, ETW, and native timestamp queries fill out the rest of the workflow.

The instrumentation should answer a simple question for every bad frame:

Was the CPU waiting for a pipeline, the GPU waiting for a barrier, the ray tracer building an acceleration structure, or the shader doing too much work?

Choose D3D12 when Windows and Xbox are the center of the product, PIX is central to the team, or D3D12-specific capabilities such as SER fit the renderer. Choose Vulkan when Linux, Steam Deck, Android, or explicit pipeline composition matters. Support both when platform reach pays for the extra backend—and only if the team can keep binding and PSO behavior comparable enough to diagnose.

Do not choose Vulkan because a benchmark produced a larger number. Do not choose D3D12 because “DirectX is optimized.” Precompile known pipelines, move creation off the render thread, serialize compatible caches, and monitor cache misses in production. For ray tracing, optimize the BVH, shader divergence, payload, and denoiser before blaming the API.

Frequently Asked Questions

Q: Is Vulkan pipeline cache better than DX12 PSO caching?

Not universally. Vulkan exposes VkPipelineCache and graphics pipeline libraries, which can give engines finer control over compilation granularity. D3D12 also supports pipeline libraries and newer state-object delivery mechanisms, so the result depends on cache invalidation, offline coverage, driver behavior, and whether either backend creates pipelines during gameplay.

Q: Why does DX12 stutter when shaders compile?

D3D12 can stutter when the application creates a new PSO or state object on the render thread. The trigger may be a new shader permutation, root signature, vertex layout, render-target format, or material combination—not just raw shader compilation. Offline PSO preparation and asynchronous loading are the durable fixes.

Q: Is DXR faster than Vulkan Ray Tracing?

There is no universal winner. Ray-tracing performance is usually dominated by acceleration-structure updates, traversal, shader divergence, payload size, memory traffic, and denoising. Compare equivalent BLAS/TLAS policies, shader tables, recursion limits, and driver versions before assigning a difference to DXR or Vulkan RT.

Q: How should I compare Vulkan and DX12 stutter?

Use identical content and renderer policies, then report cold-cache, warmed-cache, and post-update runs separately. Track 1% lows, worst-frame time, PSO creation, cache misses, descriptor activity, BLAS/TLAS time, and GPU timestamps—not average FPS alone.