Change the naming of rendering methods and drivers

[reduz]

Describe the project you are working on

Godot

Describe the problem or limitation you are having in your project

In Godot 3, choosing the rendering driver is relatively easy because only GLES2 and GLES3 are present.
In Godot 4, this problem is far harder due to the addition of the new RenderingDevice rendering layer. The following combinations are (and will be) possible:

RenderingDevice renderers:

• ForwardClustered
• DeferredClustered
• ForwardMobile

RenderingDevice drivers:

• Vulkan
• D3D12
• Metal
• WebGPU

GLES3 drivers:

• Native (OpenGL/GLES)
• Angle D3D12/Metal

This is far too many combinations, we can't put 3 combos for selecting everything.

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

The general idea is that we simplify this by having a main rendering method, then drivers configurable in the project settings.

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

As suggested by @clayjohn we should instead focus on rendering method, driver second. This way, the combobox showing the graphic driver instead the following methods:

• RD_Forward (Renderer for desktop, focused on flexibility, using RenderingDevice)
• RD_Deferred (Renderer for desktop, focused on performance, using RenderingDevice)
• RD_Mobile (Renderer for mobile, focused on performance on mobile devices, using RenderingDevice)
• GL_Compat (Renderer for compatibility with old desktop and mobile, using GLES3)

Then, in the project settings, we need to have a setting with the rendering driver.

rendering/rendering_device/driver - this one not really editable

Then the following platform overrides:

rendering/rendering_device/driver.windows [ Vulkan | Direct3D]
rendering/rendering_device/driver.linuxbsd [ Vulkan ]
rendering/rendering_device/driver.javascript [ WebGPU ]
rendering/rendering_device/driver.android [ Vulkan ]
rendering/rendering_device/driver.ios [ Metal | Vulkan ]
rendering/rendering_device/driver.osx [ Metal | Vulkan ]

also

rendering/gl_compatibility/driver - not really editable

Then the following platform overrides:

rendering/gl_compatibility/driver.windows [ OpenGL | AngleDirect3D ]
rendering/gl_compatibility/driver.linuxbsd [ OpenGL | AngleVulkan ]
rendering/gl_compatibility/driver.javascript [ WebGL ]
rendering/gl_compatibility/driver.android [ GLES3 | AngleVulkan ]
rendering/gl_compatibility/driver.ios [ AngleMetal | OpenGL (Deprecated) ]
rendering/gl_compatibility/driver.osx [ AngleMetal | OpenGL (Deprecated) ]

Remember also that overrides can be set by export setting, so different export settings can also change the driver.

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

N/A

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

N/A

[Zireael07]

How does the part with drivers selectable in project setting interact with the fact some people have frankly broken setups and HAVE to use a specific driver? We already have shades of this with GLES 3 not running or Vulkan not running and people opening issues complaining Godot doesn't work (on their machine)

(TODO: find the issue number for the GPU blacklist idea)

[reduz]

@Zireael07 I guess those are bugs that will need to be fixed at some point.

[Zireael07]

Those bugs are often on the GPU driver side, not Godot side, though.

[Calinou]

Related to #4188.

(TODO: find the issue number for the GPU blacklist idea)

This is #1609, but I think it no longer applies to Godot 4 now that we know that GLES2 support won't be officially added to Godot 4.x.

We can't fall back from Vulkan to OpenGL by default, as there are too many rendering differences for this to be viable in most projects. There could be an opt-in project setting for this (like the GLES3 -> GLES2 fallback), but it's not something most people will be able to enable without manually ensuring they can minimize the visual difference at a script level.

[Ansraer]

Sounds good to me. Letting users pick rendering method is definetly an improvement over picking drivers.
Though a small footnote at the bottom of each option listing the supported drivers would be nice.

Not sure if this is already possible, but automatic driver fallback would be nice too, if the configured driver is not fully supported on the platform. And also a way for players to override the driver with commandline arguments.

[RandomShaper]

It'd also be good to rename the CLI switch --vk-layers to --gpu-validation, that would partner nicely with --gpu-abort. The renamed switch would be relevant to any driver having any sort of runtime validation.

And maybe also SPIRV-Reflect could be downgraded from core dependency to a Vulkan driver dependency in the build scripts.