DX12 rendering backend having slow startup time comparing to Vulkan

[Delsin-Yu]

Tested versions

v4.4.stable.official [4c311cb]

System information

Godot v4.4.stable - Windows 10 (build 19044) - Multi-window, 2 monitors - Direct3D 12 (Forward+) - dedicated NVIDIA GeForce RTX 3060 Laptop GPU (NVIDIA; 32.0.15.7247) - AMD Ryzen 9 5900HS with Radeon Graphics (16 threads)

Issue description

When using the DX12 rendering backend, the game & editor startup becomes very slow comparing to vulkan.

QQ202539-10029.mp4

Steps to reproduce

1. Create an empty project.
2. Observe the startup time using Vulkan
3. Observe the startup time using DX12

Minimal reproduction project (MRP)

workspace_2025-03-09_10-13-55.zip

[youer0219]

I feel that my editor is fine, but the game starts much slower.

[clayjohn]

There is a good chance this is caused by shader transpilation (converting the shaders to the format needed by D3D).

See the videos here that show the load time improvements from using baked shaders in D3D12 specifically #102552 (also note that Vulkan doesn't have the same issue)

[Delsin-Yu]

also note that Vulkan doesn't have the same issue

I thought Vulkan, Dx12, and Metals are alike (as they all took the inspiration from the AMD Mantle API). Is there anything specific to DX12 that requires this extra step? Don't we also compile the shaders to SPIR-V on Vulkan?

[clayjohn]

also note that Vulkan doesn't have the same issue

I thought Vulkan, Dx12, and Metals are alike (as they all took the inspiration from the AMD Mantle API). Is there anything specific to DX12 that requires this extra step? Don't we also compile the shaders to SPIR-V on Vulkan?

They all use different intermediate formats, Vulkan uses SPIRV, D3D12 uses DXIL, and Metal uses Metal IR.

Since D3D12 and metal can't use SPIRV directly, we need the transpilation step I mentioned above.

[Delsin-Yu]

we need the transpilation step I mentioned above.

Ah, so we are not emitting DXIL and Metal IR directly; instead, we are always emitting SPIRV and then transpiling it to another format. I see, that's sad. Thanks for the explanation.

[maidopi-usagi]

Tested on my machine.
(Godot v4.4.stable.mono - Windows 11 (build 26100) - Multi-window, 1 monitor - Direct3D 12 (Forward+) - dedicated NVIDIA GeForce RTX 3090 (NVIDIA; 32.0.15.6094) - 13th Gen Intel(R) Core(TM) i7-13700F (24 threads))

I can't reproduce the same problem, both rendering backend starts without much stuck. Here's a comparison between vulkan(L) and dx12(R) with --benchmark argument.

I'm wondering if this is caused by some kinds failure of shadercache?

[Calinou]

--benchmark might not track this, so I suggest measuring wall clock time for editor startup + shutdown. hyperfine can be used for this.

[Delsin-Yu]

The startup time for pure editor and pure player don't show a difference, so it's specific to the performance degradation of the Run Project of the editor.

// Editor

Benchmark 1: .\Godot_v4.4-stable_mono_win64.exe --editor --path D:\GodotProject\PayloadProject --display-driver windows --rendering-driver vulkan --quit --quiet
  Time (mean ± σ):      5.473 s ±  0.131 s    [User: 4.541 s, System: 0.710 s]
  Range (min … max):    5.331 s …  5.625 s    10 runs

Benchmark 1: .\Godot_v4.4-stable_mono_win64.exe --editor --path D:\GodotProject\PayloadProject --display-driver windows --rendering-driver d3d12 --quit --quiet
  Time (mean ± σ):      5.517 s ±  0.156 s    [User: 4.828 s, System: 0.617 s]
  Range (min … max):    5.346 s …  5.757 s    10 runs

// Player

Benchmark 1: .\Godot_v4.4-stable_mono_win64.exe --path D:\GodotProject\PayloadProject --display-driver windows --rendering-driver vulkan --quit --quiet
  Time (mean ± σ):      1.053 s ±  0.006 s    [User: 0.398 s, System: 0.482 s]
  Range (min … max):    1.044 s …  1.060 s    10 runs

Benchmark 1: .\Godot_v4.4-stable_mono_win64.exe --path D:\GodotProject\PayloadProject --display-driver windows --rendering-driver d3d12 --quit --quiet
  Time (mean ± σ):      1.029 s ±  0.007 s    [User: 0.557 s, System: 0.368 s]
  Range (min … max):    1.021 s …  1.041 s    10 runs

[maidopi-usagi]

After I updated my nvidia graphics driver to the same 572.47 version, and can reproduce the issue. I believe it's related to specific drivers.

[blueskythlikesclouds]

Should be improved with #111762.