Use Direct3D 12 rendering driver by default on Windows

[Calinou]

Describe the project you are working on

The Godot editor 🙂

Describe the problem or limitation you are having in your project

Godot runs into many driver bugs when using Vulkan on Windows. All GPU vendors are affected, but Intel generally has the Vulkan driver that runs into the most issues in Godot (such as godotengine/godot#86833).

On top of that, Vulkan allows applications to install layers which affect the rendering of any Vulkan application on the system. While this is an useful tool, applications often install broken layers or don't clean up layer files after uninstalling, which leads to various issues. In the worst case scenario, Godot is completely unable to start with Vulkan if a broken layer makes it crash on startup. In comparison, Direct3D 12 doesn't have a layer system, so it's impossible for this to happen.¹

To summarize, the state of Vulkan drivers on Windows is less than ideal. It's overall better than OpenGL, but not quite at the level of Direct3D.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Godot has a Direct3D 12 rendering driver since 4.0, but it's not used by default.

Using Direct3D 12 by default would sidestep the Vulkan driver bugs that Godot runs into. Additionally, we gain a few upsides for using Direct3D 12:

• Godot is automatically presented using DXGI when using D3D12, which is not the case when using Vulkan.
• Special K injection works correctly when using D3D12, while it always crashes Godot on startup when using Vulkan (at least in my experience).
  • It's possible that this is a Godot bug, but I don't know what's causing this.

There are still a few roadblocks to using Direct3D 12 by default that we need to resolve first:

• There is currently no shader pipeline caching. This impacts loading times and can result in increased shader compilation stutter.
  • This was resolved by Add shader baker to project exporter. godot#102552, but only if you export the project with the shader baker enabled. This must be done from a Windows device, which is an issue for those who don't have a Windows setup or are exporting from a Linux CI setup (as it's typically more convenient than using a dedicated Windows instance).
• OpenXR lacks Direct3D 12 support with Godot.
  • This was implemented by Add support for Direct3D 12 OpenXR backend godot#104207.
• There are several bugs specific to the Direct3D 12 driver.
  • These are listed in the tracker issue.

Does this affect visuals in existing projects?

Visuals are expected to be 100% identical across rendering drivers (barring renderer or driver bugs). Therefore, this should not lead to visual changes in existing projects unless you run into a bug. Please report any such bugs when using Direct3D 12; make sure to include comparison screenshots between Direct3D 12 and Vulkan.

What about performance?

Unlike the Metal rendering driver that replaces MoltenVK by default on macOS, there isn't expected to be a significant performance difference between Vulkan and Direct3D 12 on most GPUs. This may differ on Intel GPUs which are known to have performance problems in Vulkan applications, so the D3D12 driver may perform better on those GPUs.

If you want to check this for yourself, try switching your project's rendering/rendering_device/driver.windows project setting to d3d12. If you run into large performance drops that don't occur in Vulkan, please open an issue with a minimal reproduction project attached.

What if my GPU doesn't support Direct3D 12?

Any GPU that supports Vulkan also supports Direct3D 12 on Windows. If this was not the case anyway (or if you use a binary compiled without Direct3D 12 support), Godot automatically falls back to Vulkan since 4.4. If Vulkan is not supported either, then Godot automatically falls back to OpenGL.

Note

Projects that use the Compatibility rendering method are not affected by this proposal. Compatibility uses OpenGL by default, with a fallback to ANGLE on specific graphics drivers (which translates OpenGL to Direct3D 11).

What about users compiling their own binaries?

You need to go through some extra steps to enable Direct3D 12 support in self-compiled binaries.

This proposal would also enable Direct3D 12 support by default in self-compiled binaries. Compilation will fail if the D3D12 dependencies aren't installed. Users can still pass d3d12=no if they wish to build Vulkan-only binaries without having to install Direct3D 12 dependencies.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Change this line in main/main.cpp:

-		GLOBAL_DEF_RST(PropertyInfo(Variant::STRING, "rendering/rendering_device/driver.windows", PROPERTY_HINT_ENUM, "vulkan,d3d12"), "vulkan");
+		GLOBAL_DEF_RST(PropertyInfo(Variant::STRING, "rendering/rendering_device/driver.windows", PROPERTY_HINT_ENUM, "d3d12,vulkan"), "d3d12");

Also change this line in SConstruct:

-opts.Add(BoolVariable("d3d12", "Enable the Direct3D 12 rendering driver on supported platforms", False))
+opts.Add(BoolVariable("d3d12", "Enable the Direct3D 12 rendering driver on supported platforms", True))

If this enhancement will not be used often, can it be worked around with a few lines of script?

No.

Is there a reason why this should be core and not an add-on in the asset library?

This is about changing a rendering default setting.

Footnotes

1. Vulkan layers are also supported on Linux, but are far less problematic overall due to apps being more behaved with layer usage there. ↩

[BastiaanOlij]

I'm on the fence with this one. It sounds like a "grass is greener on the other side" solution, once we switch over, we're going to find all the issues using DX12 that make life less than grand.

For XR, while we now have a working DX12 option with OpenXR, there are still limitations that may hamper those that are far along with their OpenXR projects or make it a bad default choice (lack of VRS support springs to mind).

But yeah, Vulkan has some strange issues on Windows for sure.

[Maran23]

I was wondering the same today. Since Metal is the default on MacOS, it might make sense to do the same for Windows and DirectX12 at one point.

[allenwp]

While testing HDR output on Windows with different configurations, I found that there are substantial issues with integrated GPU drivers and HDR output when using the Vulkan swap chain. Specifically, Intel drivers will report valid HDR buffer formats available to the Vulkan swap chain, but the buffer is actually treated as an SDR sRGB buffer. Using an integrated GPU hardware for HDR output with an NVIDIA driver for rendering also doesn’t work, which is how gaming laptops are often configured.

None of these issues reproduce when using the d3d12 driver (with its DXGI swap chain).

All that to say, it would be a better user experience for enabling HDR output to have the d3d12 driver as default on Windows. There is no way for HDR output to ever be supported on Windows when using a Vulkan swap chain due to these longstanding GPU driver issues.

[0xbeefd1ed]

@Calinou I'd like to highlight the fact that Vulkan will never reach the "critical mass" needed to force GPU vendors to improve their drivers if major engines like Godot steer developers away from it.

Vulkan has a repair channel for indie developers. D3D12 doesn't.

When a driver violates spec, anyone can land a test in the CTS and every GPU vendor must fix or waive it on their next submission. I've done this multiple times before, and I'm not a Khronos member. There is no D3D12 equivalent. Best you can do is file a support ticket.

Vulkan drivers are worse on Windows because engines keep routing around them

Drivers get tested where applications ship. Every engine individually deciding to avoid Vulkan on Windows is rational and collectively guarantees it never reaches critical mass. It's a chicken and egg problem. Godot represents a large share of new projects, so this decision will have broad ecosystem implications.

The downstream effect on ports

Windows dominates the gaming market so it's likely that developers will develop on Windows. As a result Vulkan-specific problems stop being caught in development and start being caught when the developer finish developing their Windows build and try to make one for Linux. And given the Linux market share today, if there's any behavioral divergence, the Linux build gets dropped, the Mac build gets dropped, and the ecosystem consolidates further onto Windows. As a result, everyone who isn't Microsoft has to implement DX on their platform: dxvk/VKD3D for Valve, GPTk for Apple. And that's why we end up with layers upon layers of API translation everywhere else, while Microsoft gets to take a screenshot of your desktop every few seconds to feed their AI.

What this also means is that the graphics ecosystem will always have fragmented APIs. The fact that every game engine have to maintain three graphics RHIs is largely a self-imposed burden due to decisions made like this.

It would be much better from an ecosystem perspective to:

• Default to Vulkan on Windows and DX12 on older Intel chips
• Recommend D3D12 as the documented escape hatch when you hit a driver bug
• Have your Claude writing a CTS reproducer so that it gets fixed by GPU vendors in their next driver update