Sign in to follow this  
IYP

Deferred shading: advanteges and disadvanteges and is it really faster

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

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

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.

#1:

Typically you render opaque objects via matching shaders, then by matching textures, then by depth (nearest-to-farthest).
In other words, for sorting via < and == (not shown for brevity):

// If objects have the same shader and texture, render the closer one first.
bool CRenderable::operator < ( const CRenderable &_rOther ) const {
    if ( ui32Shader < _rOther.ui32Shader ) { return true; }
    if ( ui32Texture0 < _rOther.ui32Texture0 ) { return true; }
    return fDist < _rOther.fDist;
}

Where is the clash? If 2 objects have the same shader and primary texture (which is a good basis for the assumption that all other textures are the same), then draw the closest one first (front-to-back).

Of course this does not necessarily fully minimize overdraw, but instead it fully minimizes state-changes while “decently” minimizing overdraw.

#2: If you ignore my suggestion to use a sort that considers shaders and textures, you should still draw front-to-back.
Even as just the most basic optimization in the universe, you could just sort by depth.  At Square Enix our framework prevents the best-possible state-reducing sort, but by sorting just by depth I was at least able to gain some performance.
 
 
So there is no clash.  You can mix them (probably best) or just sort by depth.  It’s always faster except on hardware with deferred tile rendering (in which case the depth sort only wastes CPU cycles).
 
 

im actually already using the depth pass to calculate the radiosity

At least this is a valid excuse for having a pass devoted only to depth, but it does not excuse the lack of sorting. Even the depth pass will be faster if you draw front-to-back.

 

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.

You seem not to understand a lot of terms.
#1:
Submitting Geometry: A draw call used to draw a 3D object (2D objects are not considered “geometry” simply for the sake of clarity).
During the rendering of a 3D scene, every draw call is a geometry submit.
You can’t render the depth or the 3D scene without submitting geometry.
 

coz my scene is dynamic and user can add objects I cant sort the objects.

if I sort ill have to sort objects every time user adds an other object .

#2:
Sort: The use of a render-queue to sort draw calls by material and depth every frame.
 
I’m not going to explain the details of a render-queue again as the link I posted not only contains a very detailed explanation but the first post links to yet another post with plenty of information.  It is all there waiting for you to read.
 
 
You need to understand the very basics in order to ask meaningful questions or to propose meaningful excuses as to why you can’t do this or that.
I suggest you read up and get a better understanding before you post again saying something like, “I can’t sort because my scene is dynamic.”  99% of all games are dynamic and sort every frame.  This problem does not exist.  Especially if you are only sorting once when a new object is added.
 
 

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.)

Sigh.
Have you done even the most basic research at all?

The depth, normal, albedo, shininess, etc. buffers are all created in a single pass.

Multiple Render Targets.
 
 
L. Spiro

Edited by L. Spiro

Share this post


Link to post
Share on other sites

If you want to know why front to back rendering is still faster even with a depth only pass download and read "depth in-depth" from this page:

 

http://developer.amd.com/tools-and-sdks/graphics-development/amd-radeon-sdk/#downloadsamples

 

The same page has a demo that demo's both tile deferred and forward+ (as L.Spiro pointed out), its called TiledLighting11_v1.2.zip.  You can check that out if you want to, source is included IIRC.

 

im actually already using the depth pass to calculate the radiosity (1366*768*24 sampled secondary lights)

 

Do you have a paper or webpage on this?  I'll be looking into this soon.

Share this post


Link to post
Share on other sites

yes I guess im gonna use sorting.but still not sure about using deferred rendering.

 

and about radiosuty, I actually implemented my radiosity using mostly this(reflective shadow maps):

 

http://www.vis.uni-stuttgart.de/~dachsbcn/download/rsm.pdf

 

there are other suggestions in:

 

http://www.gamedev.net/topic/667456-a-practical-real-time-radiosity-for-dynamic-scene/

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this