Jump to content
  • Advertisement
Sign in to follow this  
IYP

Deferred shading: advanteges and disadvanteges and is it really faster

This topic is 1187 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

Im now using forward rendering I was thinking if  deferred rendering may help my app's performance im already first processing the depth and then use forward shading (only nearest fragments get shaded so the number of fragments processed is equal or less than whole number of pixels) so in my method the calculation cost depends on n*p (p:number of pixels and n:number of lights), so is the calculation cost in deferred rendering exept you rasterize the scene several more times ,you calculate vertex shader several time too and etc. (especially when using transparent objects) and you also use a lot of memory so should I change my app (in which every thing is dynamic)  to use deferred rendering or im better off with the forward rendering.

Share this post


Link to post
Share on other sites
Advertisement

Depth–pre-pass actually increased my performance like 5.5 mili seconds. you see here is the point I don't get. (in my case all  objects in the scene are lit by all lights other wise ill run a light culling algorithim either on cpu or compute shader) 

 

 

Deferred is typically faster than forward because as you know each light is evaluated at most once per pixel,

 

my forward rendering does the same (due to Depth–pre-pass) so there is no advantage here and my forward rendering also does not shade the pixels in shadows while in deferred rendering, because in calculation of each G buffer we don't have access to other G buffers we don't do the same (well it can be done but still wouldn't give any advantage to deferred rendering) so there are actually no deference except several rastrizing in deferred rendering. so is there any other advantages for deferred rendering?

Share this post


Link to post
Share on other sites
Are you actually under your performance aim currently with forward rendering, with the quality you want to achieve? (For example >16ms per frame)

If not I wouldn't move to deferred, unless your existing approach holds you back on other/ new functionality you need/ want to have.

Share this post


Link to post
Share on other sites

Depth–pre-pass actually increased my performance like 5.5 mili seconds.

I already explained what that means in terms of how your current implementation is working. It means you just don’t have a very good forward-rendering pipeline.
By rendering opaque objects front-to-back (forcing certain things such as terrain to be drawn last also) you can basically (not perfectly) eliminate overdraw (the result of depth pre-pass), and use that same pass to also apply several lights (as many as you can fit in a single pass).  You’ll only have overdraw in perhaps 2% of the total pixels on the screen, but you will have saved an entire geometry pass.
 
So there is virtually no reason to do an entire pass just for depth.  I’ve tested it on many cards in many scenes and no matter the complexity, with a proper draw-sorting algorithm (render-queue), it is never faster to use depth pre-pass except in very extreme edge cases (none of which I have ever encountered).
 
 
 

Deferred is typically faster than forward because as you know each light is evaluated at most once per pixel,

 
my forward rendering does the same (due to Depth–pre-pass) so there is no advantage here and my forward rendering

You seem to have left out an important part of the quote…

Deferred is typically faster than forward because as you know each light is evaluated at most once per pixel, without the need to submit extra geometry

Just because there was a comma it doesn’t mean there was a fully contained idea there.


also does not shade the pixels in shadows while in deferred rendering, because in calculation of each G buffer we don't have access to other G buffers we don't do the same (well it can be done but still wouldn't give any advantage to deferred rendering) so there are actually no deference except several rastrizing in deferred rendering.

I don’t know what you are trying to say here.


L. Spiro

Share this post


Link to post
Share on other sites

im actually already using the depth pass to calculate the radiosity (1366*768*24 sampled secondary lights) and what do you mean by "without the need to submit extra geometry" im not submitting any extera geometry in my depth pass and coz my scene is dynamic and user can add objects I cant sort the objects.

Share this post


Link to post
Share on other sites
The fact that you're doing a depth pass at all means you are submitting extra geometry. You have to draw each object twice, right? Once for the depth pass, and once for the lighting.

And I don't understand why a dynamic scene means you can't sort your objects. Pretty much every 3d game in existence has "dynamic scenes", and sorts their objects.

Share this post


Link to post
Share on other sites

I should also redraw objects several times while using deferred rendering. so how is it a disadvantage for my forward rendering? and if I sort ill have to sort objects every time user adds an other object .

Share this post


Link to post
Share on other sites

 

Depth–pre-pass actually increased my performance like 5.5 mili seconds.

I already explained what that means in terms of how your current implementation is working. It means you just don’t have a very good forward-rendering pipeline.
By rendering opaque objects front-to-back (forcing certain things such as terrain to be drawn last also) you can basically (not perfectly) eliminate overdraw (the result of depth pre-pass), and use that same pass to also apply several lights (as many as you can fit in a single pass).  You’ll only have overdraw in perhaps 2% of the total pixels on the screen, but you will have saved an entire geometry pass.
 
So there is virtually no reason to do an entire pass just for depth.  I’ve tested it on many cards in many scenes and no matter the complexity, with a proper draw-sorting algorithm (render-queue), it is never faster to use depth pre-pass except in very extreme edge cases (none of which I have ever encountered).
 

 

L Spiro, in your first response you suggest sorting by shader then texture... in this response you're suggesting sorting front to back.  So what exactly are you suggesting since the two seem to clash with each other?  I'm not following.

 

 

I should also redraw objects several times while using deferred rendering. so how is it a disadvantage for my forward rendering? and if I sort ill have to sort objects every time user adds an other object .

 

Why are you redrawing objects for deferred?

Edited by Infinisearch

Share this post


Link to post
Share on other sites

well for deferred rendering I have to redraw the scene into several textures (G buffer) so I have to redraw scene for every pass (1 pass for normal 1 for material and etc.)

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!