There are plenty of reasons in 2021 why you would still have a gbuffer in your rendering pipeline. However, here's a thread with reasons why you might not 👇
The gbuffer pass is usually heavy on memory loads/stores and texture sampling, and light on ALU resulting in unused silicon due to the uneven workload
Gbuffers are getting fatter (gotta have TAA, cavity, ids for decals, ray cones, etc) to the point where gbuffer overdraw is a thing and z-prepasses are almost ubiquitous in deferred rendering anyways (remember, overdraw reduction was one of the original points of the gbuffer)
... to wit, gbuffer memory is already heavy, but we need to look forward to 8k rendering and beyond. Gbuffers add a strict multiplicative factor to memory cost each time consumer resolutions increase (unless you already have a good temporal upscaling solution)
Even then though, TAA still isn't perfect and there are still cases where you might wish you had more resolution to work with (DLSS still isn't ubiquitous yet, and while it's great on the platforms it supports, you can't put all your eggs in this basket just yet)
Deferred shading pipelines never translate as well to mobile hardware or iGPUs that rely on HSR optimizations and triangle binning *before* your vertex shader runs.
You probably need to support transparency anyways, so if you have a strategy for reducing overdraw and solving the light permutation already, this could extend to opaque geometry also, as opposed to maintaining two code paths
Rasterizing via the fixed function pipeline is still pretty fast, but not so much if you have lots of idle threads (due to small triangles and still needing gradients for texture sampling). Also, you're only rasterizing one view at a time. What about shadows and reflection maps?
Less and less silicon is being used proportionally for fixed function units, with hardware vendors trending toward both unified caches and more general execution pipelines, implying that rasterizing via compute or mesh shaders is more viable
Note: I'm not saying that gbuffers are bad. Just noting the hardware and artistic trends that may make them less attractive relative to the past. There are still plenty of reasons why the gbuffer is useful (multi-pass techniques and decals come to mind)
You can follow @m_ninepoints.
Tip: mention @twtextapp on a Twitter thread with the keyword “unroll” to get a link to it.

Latest Threads Unrolled:

By continuing to use the site, you are consenting to the use of cookies as explained in our Cookie Policy to improve your experience.