Add a page documenting Godot's internal rendering architecture

[Calinou]

This is intended for new and returning engine contributors.

There are some clarifications I'd like to add – see my review comments and the question below. Also, I may have forgotten talking about certain features of the renderer entirely, so please comment if that's the case.

@BastiaanOlij Could you write up a paragraph or two about subpass usage in the Forward Mobile backend, and how it differs from approach in the Clustered Forward backend (and why subpasses are used)? This would be useful to list on this page 🙂
Edit: Added

[paddy-exe]

Absolutely amazing work on this! Thank you for creating this

1. Not sure if this should get its own category but it would be great to have the Visual Shader system and its place in the rendering code as well here.
2. I am not sure if I understand the Rendering Device part correctly but if I want to add a new feature (e.g. like ray tracing or something else) which is technically supported by a Vulkan extension, would I first take a look at the Rendering Device API and see if I can implement this with its API and if not add the necessary stuff to the underlying code?

[clayjohn]

We should also include the image from godotengine/godot#44094 somewhere in the document and explain its meaning in more detail. IMO the structure of the RenderingServer is something a lot of new contributors have trouble with

[clayjohn]

Before we release 4.0 we are going to reorganize the renderer selection and place more emphasis on selecting the rendering method and less emphasis on the driver (see here. I think the organization of the document should emphasis that organization. I.e. it should start with the renderer, clustered forward then explain that there are two options for using that Vulkan or DirectX (in the future hopefully will support WebGPU and Metal), When using MacOS, you have to use Vulkan, but it is translated to metal through MoltenVK and in the future we may have a metal backend. If using the compatibility renderer, you have to use OpenGL3 now, but we will support choosing between opengl and Angle

[BastiaanOlij]

@Calinou first draft of what could be a replacement Forward Mobile section. Let me know if its usable:

Forward Mobile
^^^^^^^^^^^^^^

This is a forward renderer that uses a traditional single-pass approach to lighting.

Intended for mobile platforms, but can also run on desktop platforms. This
backend is optimized to perform well on mobile GPUs. Mobile GPUs have a very
different architecture compared to desktop GPUs due to their unique constraints
around battery usage, heat and overal bandwidth limitations of reading and writing
data. Compute shaders also have very limited support or aren't supported at all, the
mobile renderer as a result purely uses raster based shaders.

Instead of rendering the whole image as a single unit, the image is divided in
smaller tiles that fit within the faster internal memory of the mobile GPU. Each
tile is rendered and then written out to the destination texture. This all happens
automatically on the graphics driver.

The problem this introduces is that our traditional approach for desktop rendering,
where we render all opaque geometry, then handle the background, then transparent
geometry, then post processing, introduces bottlenecks as each pass will need to
read the current result into tile memory, perform its operations and then write it 
out again. We then wait for all tiles to be completed before moving on to the next
pass.

The first important change in the mobile renderer is that the mobile renderer does
not use the RGBA16F texture formats that the desktop renderer does. Instead it is
using a R10B10G10A2 texture format. This halves the bandwidth required and has
further improvements as mobile hardware often further optimises 32bit formats.
The tradeoff is that the mobile renderer has limited HDR capabilities due to the 
reduced precision in the color data.

The second important change is the use of sub-passes whenever possible. Sub-passes
allows us to perform the rendering steps end-to-end per tile saving on the overhead
introduced by reading from and writing to the tiles inbetween each rendering pass.
The ability to use sub-passes is limited by the inability to read neighboring pixels
as we're constraint to working within a single tile.
This results in not being able to implement features such as glow and dof.
Similarly if there is a requirement to read from the screen texture or depth texture
we must fully write out the rendering result limiting our ability to use sub-passes.
When such features are enabled a mix of sub-passes and normal passes are used, and
these features thus have a notable performance penalty.

On desktop platforms the use of sub-passes won't have any impact on performance 
however this backend can still perform better than Clustered Forward in 
simple scenes thanks to its lower complexity and lower bandwidth usage.
This is especially noticeable on low-end GPUs, integrated graphics or in VR applications.

Given its low-end focus, this backend does not provide high-end rendering
features such as SDFGI and Volumetric fog. Most post-processing effects are also not
available.

[Calinou]

@Calinou first draft of what could be a replacement Forward Mobile section. Let me know if its usable:

Thanks, I incorporated it 🙂

[Calinou]

I've added a small section on recommended OpenGL/Vulkan learning resources, as it may help with understanding concepts on this page (see https://twitter.com/reduzio/status/1649707259281260550).

[clayjohn]

Excellent work! This is a fantastic start to a deep documentation of the rendering architecture. I have left a few comments, and I have tried to make suggestions wherever I had a comment. Please let me know if you have any questions about my suggestions

[mhilbrunner]

Fantastic addition to these contributor-facing docs. I have nothing to add besides Clay's feedback.

[mhilbrunner]

Thanks for this contribution (and for addressing all the feedback :))! Merged. 🎉 Really good addition.