Render Parity and the D3D12 Default on Windows in Godot

Why this change happened

The PR is rooted in a very practical problem: Windows Vulkan drivers have caused repeated regressions that break Godot projects in the field. The argument in the discussion is not that Vulkan as an API is weak. It is that the Windows driver reality has been costly enough that a more stable default is worth pursuing when feature coverage is close enough.

The maintainers point out that Direct3D 12 support has matured since landing in Godot 4.3 and has been refined through later releases. By the 4.6 cycle, the idea was no longer just experimental support. It was mature enough to become the default starting point for new Windows projects.

What the PR actually does

The important detail is that the engine does not simply flip a global default and call it a day. Instead, newly created projects in 4.6 automatically get the Windows rendering-device setting configured to `d3d12`. Older projects are intentionally handled more carefully so that users are not silently pushed into a backend change during upgrade.

That compatibility logic matters. It means the team is treating the rendering backend as a production-facing choice with real migration risk, not as a cosmetic preference.

Why parity matters more than slogans

A default backend only makes sense if it can serve the common case without forcing users into missing features on day one. The PR discussion repeatedly frames D3D12 as close enough in parity to Vulkan for this new-project default to make sense, while still acknowledging gaps and platform-specific exceptions. PCVR is explicitly mentioned as an area where Vulkan may still be the better choice for some users.

The startup-performance discussion

One of the more interesting parts of the thread is that the conversation does not stop at default selection. Users and contributors dig into startup behavior, D3D shader cache interactions, and what happens when multiple Godot instances share the same executable name. That turns the PR from a simple default toggle into a wider discussion about runtime behavior, cache reuse, and where D3D12 still feels rough around the edges.

The takeaway is useful: a backend can be the right default and still have real implementation details worth scrutinizing. Those are not contradictory positions.

What this means for developers

If you create a new Windows project in 4.6, D3D12 becomes the default path to test first. If you upgrade an older project, you should evaluate the change intentionally instead of assuming the engine will migrate you automatically. The discussion around the PR makes it clear that the team wants to protect running projects while nudging new work toward a better default for Windows driver conditions.