So, this option is now available, but what does it do?
What are some good examples and practices for using Deferred Plus?
I can’t find any documentation or mentions of this.
1 Like
Google’s AI:
A “deferred plus” rendering pipeline refers to a hybrid approach in computer graphics that combines the core principles of traditional deferred rendering (where geometry information is stored in a G-buffer first, then lighting is calculated in a separate pass) with additional techniques to address some of its limitations, often allowing for better performance when dealing with a large number of lights or complex lighting scenarios, while still maintaining the benefits of deferred rendering like efficient per-pixel lighting calculations
I have heard of forward plus, but this is the first I have heard of deferred plus. It may simply be an extension to handle high numbers of lights in a manner similar to forward plus where each light source is applied only over a small fraction of the total rendered image.
I cannot say exactly, but the response from AI seems to suggest that.
Thanks for the question. This is a fresh feature, and we need to do a better job at documenting it. Until then, here’s an explanation:
Forward
Render both, transparent and opaque objects, one at a time. For each object, we bind a list of lights that affect that it. On the GPU, we iterate over this list and accumulate lighting.
The upside of this approach is that this is dead-simple, and has a low CPU cost. For very simple scenes, this is a win.
Downsides are (a) overdraw, i.e. you pay for lighting pixels that will be later occluded by other geometry, (b) a smaller light limit, (c) incompatibility with GPU-driven rendering and GPU occlusion culling.
Forward+
On the CPU using Burst, sort all visible lights and reflection probes into screen-space clusters. Now that we have a light list for each screen-space cluster, upload this to the GPU. Transparent and opaque objects can now be instanced, which is great for performance. While shading, we calculate which cluster the shaded pixel lies in, and then loop over the light list for it.
Upsides of this approach are (a) Compatibility with GPU-driven rendering and GPU occlusion culling, (b) higher light limit.
The downsides are that (a) the clustering has a CPU cost, which might hurt on low-end devices, (b) you still end up paying for overdraw, similar to Forward.
Deferred
Opaque objects first render their material properties to intermediate textures, called GBuffers. After all opaque objects are rendered, there is a pass for each local light. This light will render a volume to the stencil buffer. This volume looks like a cone for spotlights and a sphere for point lights. Pixels that pass this stencil are lit by the light, and the lighting result is additively written to the final color. After we draw a pass for each light, we’ll end up with a fully lit opaque final frame. Then we use Forward mode for drawing transparent objects.
Upsides of this approach are (a) you don’t pay for overdraw for opaque objects, (b) you don’t pay a CPU cost for light clustering.
Downsides are (a) you’re writing to the final frame memory once per light, so the texture bandwidth usage is higher, which can be a problem on mobile devices (b) this isn’t compatible with GPU-driven rendering or GPU occlusion culling.
Deferred+
Similar to Forward+, perform light and reflection probe clustering on the CPU. Then, similar to deferred, render all opaque objects to GBuffers. Now, unlike Deferred, do a single full-screen lighting pass. In this pass, loop over the lights and reflection probes, accumulate writing, and write it to the final texture and the end. Then use Forward+ for drawing transparent objects.
Upsides of this approach are (a) you don’t pay for overdraw for opaque objects (b) you write to the final frame once, using less texture bandwidth (c) you can use GPU-driven rendering and GPU occlusion culling, (d) higher light limit.
The downsides of this approach is that, like Forward+, it has a CPU cost, which might hurt on low-end devices.
I would recommend that you use Deferred+, and then switch to something else if you get performance issues. Also give us feedback if it doesn’t work for you. 
Hope this helps.
17 Likes
That sounds very promising!
Does that mean that the GPU bandwidth issues from Deferred are mostly gone in Deferred+?
If so, definitely going to test it soon!
I would not say that Deferred+ fundamentally solves GPU bandwidth issues, because even though there’s less writing going on, there are still GBuffers at play. It will also depend on which passes get merged by the render graph (merging is very good for reducing texture bandwidth).
The real promise of Deferred+ (in my opinion) is that it allows for GPU-driven rendering and GPU occlusion culling, which, depending on your scene, can get you a lot of performance.
1 Like
This is interesting!
Is there any plan to have Deferred+ supported by Entities Graphics? See: Support for URP deferred rendering path?
how is this corelated to the GPU resident drawer?
Does the resident drawer depend on deferred+?
or the deferred+ is a foundation for other gpu driven things in the future?
This should actually be supported already, please do check it out and let us know if you run into any problems.
It’s correlated in the sense that Deferred+ is GPU Resident Drawer compatible. Previously, Forward+ was the only GPU Resident Drawer compatible rendering path for URP.
1 Like
I tested the last version (entities graphics 1.4.5) with Unity 6000.1.0b1. It still gives this warning when I’m using Deferred+
Entities.Graphics should be used with URP Forward+. Change Rendering Path on Ultra_PipelineAsset_ForwardRenderer for best compatibility.
Can you pass the message to the entities team? Maybe they just have to hide this warning when using Deferred+. (and update the message to “should be used with URP Forward+ or Deferred+.”)
So conceptually, Deferred+ in URP of Unity 6.1 is similar to what HDRP has had since forever? (as in: BiRP did deferred by drawing some simple mesh for each light; whereas HDRP was doing tiled/clustered/fptl deferred from day 1 , back in 2018 or so – I forget when exactly HDRP had the initial release)
1 Like