Jump to content
  • Advertisement
Sign in to follow this  
Alundra

Stop using Deferred Shading with Clustered Shading ?

This topic is 517 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi,

I recently read this post from MJP : https://mynameismjp.wordpress.com/2016/03/25/bindless-texturing-for-deferred-rendering-and-decals/

We can see the clustered forward shading is faster using a Z pre-pass.

We can also notice clustered shading implementation in unreal engine is only forward shading and DOOM also only use forward shading.

Clustered Forward Shading is really more efficient in all situations or Deferred Shading has again his value ?

Thanks

Edited by Alundra

Share this post


Link to post
Share on other sites
Advertisement

I would expect deferred techniques to scale better with geometry complexity for the reasons that Hodgman mentioned. Having to rely on a Z prepass can also be undesirable, since it automatically doubles your draws and your vertex/geometry processing. However a Z prepass may not be necessary if you're able to ensure that your triangles are rasterized in roughly front-to-back order.

Share this post


Link to post
Share on other sites

We can see the clustered forward shading is faster using a Z pre-pass.
We can also notice clustered shading implementation in unreal engine is only forward shading and DOOM also only use forward shading.
Clustered Forward Shading is really more efficient in all situations or Deferred Shading has again his value ?

It's not as much a matter of speed, but rather solutions to technical issues.
Deferred shading is a solution to the problem of figuring out which lights should be processed by a surface's fragment program. Before that, lights were assigned on a per-object basis. this works ok'ish when the lights cover whole objects, but what if you have a big objects and tons of tiny lights? (e.g. an airfield).
Backing all your fragment-registers into a gbuffer is by now way fast, nor complete, yet it's fast enough if you bake the bare minimum. In fact, this is quite expensive and some games used a z prepass to speed it up.

Having a gbuffer in place gave you the clear benefit of lighting just the really affected pixel with your lights, people developed tons of depth/stencil carving techniques to improve this situation, as every light was grabbing the whole gbuffer.
The trade off was to give up lighting on transparent objects mostly (you had still the n-lights/objects fallback in some games) and stuff like MSAA, varying shading models,...

With compute, you can tackle the biggest performance issue, as you save a lot of data fetches, although you drop fine grain light culling.
But wait, if we can handle all lights in the shader now, we don't have to assign them per-objects in a forward renderer. We can render custom shading models (hair, metal, cloths), we could use MSAA, we can render transparent objects just the same way, without the need of deferred. Hence most benefits are back and trade offs are gone.

Therefore it was not strictly a performance question, deferred and forward+ were reducing problems.
To make it a performance question, you rather need to compare two implementations that cover your required feature set, and also know your hardware target. e.g. on PowerVR, with some extensions, the classical deferred (not compute) might be the best way to go if you need modern rendering techniques.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!