Ansraer
commented
1 year ago Ok, I just finished reading this for the first time and have some initial feedback. So far, this looks like a fairly typical deferred renderer implementation. While I personally would have been more interested in a VisBuffer variant, reduz has pointed out (on RC and the GPU renderer gist) that it would not support all possible use cases (without some complex workarounds). I personally still believe that, despite those shortcomings, the superior performance makes it an attractive option for many projects, but can also understand the decision to go with something more traditional instead.
Something I have to wonder while reading this proposal is why we want to keep the forward option alive. Right now, the Forward+ renderer is only really used on platforms that could easily support the higher bandwidth requirements of a deferred renderer, so I can't really think of any reason to use the forward option once this has been implemented. I suppose small scenes with simple geometry could be a bit faster with a forward renderer, but given the numbers I saw the last time I profiled Godot, I doubt that it would be significant enough to justify maintaining another rendering path.
Also, what happens when people want to render something without using the deferred light logic? I would imagine that this is a valid use case once you start writing advanced shaders, so I kind of expected to see a mask bit somewhere to deactivate the compute shader for certain fragments. Alternatively, maybe the proposed compositor could be used to run a forward pass after the deferred renderer?
Finally, what happened to the depth prepass? I would imagine that it still happens before the deferred passes, but didn't see it mentioned above. What I would really like to know is if we plan to continue writing normal + roughness there if GI is enabled.
EDIT: I just realized that I accidentally mentioned VisBuffer while writing this comment. Everyone else, please do NOT start arguing for/against it here. We had a lot of that discussion already over the last few weeks, and the team has valid reasons for the proposed architecture. Please try to keep this proposal focused on the deferred renderer in question, if you wish to discuss VisBuffer rendering feel free to open a second proposal.
clayjohn
Koalamana9
Calinou
jams3223
hayahane
AresDevult
Ikaroon
and-rad
Mautar55
Describe the project you are working on
Performance improvements for Godot
Describe the problem or limitation you are having in your project
We are finding two places where we are losing a significant amount of performance:
Both of these performance problems are inherent to using a Forward renderer and are typically solved by very aggressively hand optimizing your shaders to reduce VGPR usage. This typically means cutting out features to just the bare essentials and pre-baking as much as possible.
Unfortunately, since Godot aims to be flexible (and allows users to write shaders), we can't reduce VGPR count / features much more than we already have (although we will continue looking for ways to reduce VGPR count and improve performance).
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Add a project setting to use deferred shading instead of forward shading in cases where users are willing to sacrifice flexibility for performance.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
The following is copy-pasted from a technical document prepared by @reduz We have already discussed it among a few rendering contributors and are now posting it here more publicly to get wider feedback before going ahead:
Implementation
Given so much would be shared between deferred and forward, the most likely use case scenario is that the rastering shader code is renamed to just clustered and contains both the deferred and the forward pass.
Deferred pass would be just adding a few more variants to the shader, mostly to simply not do any lighting, decal, or fog computation and write down the material values to the GBuffer.
The C++ side (for clustered rendering) may not be entirely reused. It should probably be designed so a base class (RenderClustered) is created, and then Forward and Deferred are derived, so it reuses as much as possible (specially for shadow, GI passes and other stuff that are shared between both).
G Buffer format
We want to find a compact G-Buffer format that is flexible enough for what we need. Remember we can take advantage of bit-packing to pack as much as we can. The following is proposed and used for opaque rendering. Existing shaders used in the clustered render are used for transparency.
Required Buffers
The base shader always writes to those.
Optional Buffers
These require more buffers to render to which are not always needed, so should be done on a different render pass combination.
Ultimately, this means there are 17 shader permutations for deferred (base + 16 permutations of special versions).
Rendering logic
Remember that this is still a clustered renderer. The fog effects and the transparent pass require access to light clustering, so this is not going away. The rendering code is almost the same as forward clustered, the main difference is the opaque pass being deferred.
Step 1: Opaque rendering
As described above, the opaque rendering happens to the G buffers in one or multiple passes (depending what needs to be written) the pass with the least buffers often happening first (because it will be the most common), then the specialized passes.
Step 2: Post opaque effects
Here is when effects such as SSAO and SSGI can be computed. SSGI probably depends on a reprojection of the previous frame diffuse+ambient buffer.
Step 3: Shading
Shading will be performed by a compute shader, which will do the following:
This code is pretty much the same as the one found in the clustered renderer, not much change is needed. Shader includes will need to be reorganized for better reuse. Attention has to be paid to subgroup operations like in the forward render when reading the cluster to maximize SGPR usage, but this should be simpler in Compute.
There is one exception, though, which is that some code relies on geometric normals (specially the shadow biasing). As such, geometric normals will need to be computed from depth in the compute shader. Here is an article on how to do this:
https://wickedengine.net/2019/09/22/improved-normal-reconstruction-from-depth/ (also https://atyuwen.github.io/posts/normal-reconstruction/) If SSS or SSR are used, the ambient+diffuse and specular buffers need to be written separate for post processing, then merged. The reason for this is that reflections can mess both the subsurface scattering and screen space GI information. Otherwise, writing to a single buffer can be done.
Step 4: Post shading effects
Here is where subsurface scattering is processed (of course check that any material is using this, otherwise skip this step like we do on forward rendering).
Step 5: Transparency pass
From now on this is the same as the forward clustered renderer.
If this enhancement will not be used often, can it be worked around with a few lines of script?
It can't be worked around
Is there a reason why this should be core and not an add-on in the asset library?
It is a care enhancement