Sign in to follow this  

Overdraw sucks [deferred renderer]

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

Deferred renderer. I first perform a z-pre pass (turned out to be very fast). Then the usual GBuffer pass, which performs some computations for each pixel. Ih this pass, however, Z buffer in ON with func=LESSEQUAL.
So I expect the GBuffer pass to be fast regardless of the scene complexity, because rasterization IS fast, and invisble pixel are discarded because the zbuffer is already filled.
But this doesn't happen.
A scene with 100.000 tris is WAY WAY slower than a scene with 5.000 tris. Vertex processing and rasterization is supposed to be fast, and with zbuffer already filled, the pixels should be computed exactly one time.

I even tried rendering a stupid fullscreen plane with a very low depth, causing all the geometry to be discarded. But this doesn't change anything. GBuffer pass keeps being slow, depending of tris number. Doesn't have sense for me.

I really can't understand WHY !
Could you help ??

THANKS

Share this post


Link to post
Share on other sites
Some things you can do will disable the early z rejection optimization because of hardware limitations. This is somewhat driver and graphics card dependant, so check their documentation for a list of things that will disable it. In general you should avoid:

- Explicitly writing depth from the shader.
- Alpha testing.
- Calling clip() in the pixel shader.

Share this post


Link to post
Share on other sites
Somehow you missed the disadvantage of Early Z pre pass is that you render all your geometry twice. Twice the batch count, twice the draw calls.
Google "draw call CPU bottleneck". This is the original reason why instancing was invented.

Early Z pre pass only works great when you're GPU bottlenecked, and you're obviously CPU bottlenecked.

Even then, there are, as Adam_42 pointed out, some limitations that prevent Early Z from working correctly.

Cheers
Dark Sylinc

Share this post


Link to post
Share on other sites
I have a deferred engine setup and i tried and early z pass. The early z made things slower, not faster. Even when I am doing 40 draw calls per frame, the early z doubled that to 80, but i experienced a 30% decrease in frame rate. I am not cpu bound in any way: I only utilize a 7% usage of a single core.

I believe that early z is special case where you have EXTREMELY heavy duty shaders.

Share this post


Link to post
Share on other sites
I've never noticed a win doing z pre-pass either. Your shaders have got to be pretty damn serious ime before doing /some/ early z rejection outweighs the extra draw call overhead.

You can probably use instancing to render to z with only a couple of simple shaders (with or without alphatest for example), but that's how my engine worked until I removed it for a second time and swore there wouldn't be a third.

Share this post


Link to post
Share on other sites
Early-Z does very much depend on the scene you are rendering and the shader work load you are doing.

If your shader work is low, or you have low over draw anyway, then an early z-pass isn't going to help matters as you are just pushing more verts for no reason.

If, on the other hand, you have heavy scene, with lots of over draw of objects you can't occulusion cull away, well then early z can be a win, more so when coupled with a sane drawing order so that close objects lay down their z values nice and early.

Share this post


Link to post
Share on other sites
That's just it though isn't it. Lots of books and sources say things like draw front to back in one chapter and then back to front in another and then sorted by shader changes in a third.

My experience says just sort for shader change reduction and be happy - its the only thing that consistently makes a positive outcome vs the others.

I'm sure that you can frig a system somewhere that pushes a renderer to a card's theoretical maximums, but in the real world you have to work with what your scene demands. And that's alpha, lots of overdraw, state change minimisation and etc.

I'm still of the opinion that a deferred renderer is the emperors new clothes tbh. I went this route mainly to see how it felt and I was never happy. Deferred has a lot of advantages but the few drawbacks are just deal-breakers for me. Like the problems with alpha, especially lighting it.

Unlimited shader lenghts on DX10+ make ubershaders look very attractive. I guess you can put 20 lights in a one-pass shader and then early z might give a win too. But my engine only supports a few lights at once as it tries to maintain feature compatibility with crapper platforms, but it runs like shit off a shovel and alpha has no special casing attached at any point, which is great.

Share this post


Link to post
Share on other sites
So, basically you just agreed with what I said; it depends on your scene.

I'd also be very surprised if you found a text saying to draw back to front, apart from in the case of correct alpha blending in certain alpha modes.

As for front to back rendering, and indeed a Z pass in general;



This scene contains many objects with the same shader/material combinations, and quite heavy shaders at that, so a failure to take advantage of early-z (or occulsion culling) would murder the frame rate.
(We also support alot of lights, thus a win for deferred rendering).

Share this post


Link to post
Share on other sites
Quote:
Original post by Rubicon
That's just it though isn't it. Lots of books and sources say things like draw front to back in one chapter and then back to front in another and then sorted by shader changes in a third.

My experience says just sort for shader change reduction and be happy - its the only thing that consistently makes a positive outcome vs the others.

I'm sure that you can frig a system somewhere that pushes a renderer to a card's theoretical maximums, but in the real world you have to work with what your scene demands. And that's alpha, lots of overdraw, state change minimisation and etc.

I'm still of the opinion that a deferred renderer is the emperors new clothes tbh. I went this route mainly to see how it felt and I was never happy. Deferred has a lot of advantages but the few drawbacks are just deal-breakers for me. Like the problems with alpha, especially lighting it.

Unlimited shader lenghts on DX10+ make ubershaders look very attractive. I guess you can put 20 lights in a one-pass shader and then early z might give a win too. But my engine only supports a few lights at once as it tries to maintain feature compatibility with crapper platforms, but it runs like shit off a shovel and alpha has no special casing attached at any point, which is great.


There was a thread in Graphics Programming & Theory about deferred rendering, and I made this great big list of pro's and con's. When my coworker read it he said to me "you forgot the most important one: it's sexy!" Even though a lot of people go deferred for the wrong reasons (it's trendy), it doesn't mean that all of its benefits are suddenly moot. You might think right now that in DX10 you can just scale up to 20 lights per object and everything will be hunky dory, but it won't be. You either end up with stupidly expensive shaders, or a shader permutation nightmare, and/or abysmal efficiency regarding wasted shaded fragments per light. You already mentioned how important reducing state changes and maximizing batching can be on the PC...try throwing 20 lights into the mix and see what that does for your batching.

As for alpha, it's true that deferred rendering can't handle it without extending the technique in the some way. But at the same time it also doesn't prevent you from doing it the old-fashioned way, so I don't think it's a deal breaker. It's not like MSAA, where if you want it you *have* to specifically handle it throughout the pipeline, and suffer worse performance. Besides it's not like alpha-blended materials are all roses in forward renderers, since you can't multipass the lighting.



Share this post


Link to post
Share on other sites
Quote:
Original post by phantom
So, basically you just agreed with what I said; it depends on your scene.

I'd also be very surprised if you found a text saying to draw back to front, apart from in the case of correct alpha blending in certain alpha modes.

As for front to back rendering, and indeed a Z pass in general;



This scene contains many objects with the same shader/material combinations, and quite heavy shaders at that, so a failure to take advantage of early-z (or occulsion culling) would murder the frame rate.
(We also support alot of lights, thus a win for deferred rendering).


What game is that? Looks nice!

Share this post


Link to post
Share on other sites
But it's a lose when you come to put it on the xbox. Don't get me wrong, I'm not saying deferred is shit, it's just not for everyone and its definitely not for hobbiests/amateur game devs - they'd be better off with a simpler system and just get some games out imo.

Share this post


Link to post
Share on other sites
Deferred rendering works just fine on the 360; the PS3 struggles with traditional deferred rendering because the GPU is utter garbage when compared to the 360's in that regard and requires a rethink thus SPU assisted light index deferred rendering is popular there.
(I see to recall out engine being CPU limited on the 360 and GPU on the PS3).

I also don't think deferred rendering is any harder to get up and running on the PC than a forward renderer; not if you want any decent performance out of either anyway so I wouldn't go as far as to say its "definitely not for hobbiests/amateur game devs".

What it comes down to is pick the tech which suits you best and then run with it, making senible choices because it very easy to get it very wrong with both a forward renderer and a deferred renderer.

Share this post


Link to post
Share on other sites
Quote:
Original post by phantom
Operation Flashpoint : Red River
(aka my day job [grin])

Showing off eh? That looks superb!
Congrats to the whole team

Quote:
Lots of books and sources say things like draw front to back in one chapter and then back to front in another and then sorted by shader changes in a third.

Slightly outdated, but still very true (go to the right section, click on "Scene Graphs - just say no").
I'm pro scene graphs (and the author seems to be too), however his discussion about the inconsistencies with different, incompatible performance optimizations is very interesting.

Cheers
Dark Sylinc

Share this post


Link to post
Share on other sites

This topic is 2563 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.

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