YixunLiu

Can adjust rendering order improve performance much?

Recommended Posts

Hi,

I would like to know if rendering opaque surfaces in front-to-back order (closer ones first, more distant ones last) can improve performance  much.

By 'opaque' I mean surfaces for which the DepthWriteMask is set to one in the depth-stencil state.

I think no matte we adjust order or not, the pixel shader needs to be performed. The difference is the output merge stage.  Does this improve performance much?

 

Thanks.

YL

 

Share this post


Link to post
Share on other sites

As long as your pixel shader doesn't write to the depth buffer, it doesn't need to be run at all if the fragment fails the depth test (that's one reason why writing to the depth buffer comes with big performance warnings).

So assuming that you don't screw with the depth buffer, sorting from front-to-back can save a whole lot of overdraw,

Share this post


Link to post
Share on other sites

I am confused about "it doesn't need to be run at all if the fragment fails the depth test".

The output merge stage gets color and depth from pixel shader output and then do depth and stencil test.

I think this means the pixel shader will run no matter if the fragment pass the depth and stencil test or not, right?

Thank.

Share this post


Link to post
Share on other sites

The logical order of the API and the physical order of the hardware doesn't have to match up exactly, as long as it behaves the same way.

If a clever GPU decides to do the depth-test before the pixel shader instead of after, there's no way for you to know -- the behaviour is the same... except that performance will improve... so GPU's will do this.

Share this post


Link to post
Share on other sites

Got it. Thanks. I got similar answer from other places.

https://gamedev.stackexchange.com/questions/26719/when-does-depth-testing-happen

"This is the idea behind the Early-Z optimization, where if you're rendering a pixel whose pixel shader doesn't change the depth, the hardware may never actually run the pixel shader (or, more likely, if a full 2x2 quad of pixels is occluded, then none of them will be run through the pixel shader). This is why you want to render a fully-opaque scene from front to back."

Share this post


Link to post
Share on other sites

AMD had a paper on the subject called "depth in depth" which I will attach.  I also found this with a pretty good explanation of depth related issues: 

 

It also depends what API you're using since in DX11/10/9 and opengl you will get more bang for your buck sorting by state first.  DX12 and Vulkan with the great amount of draw calls possible makes it more practical to sort front to back.

 

Depth_in-depth.pdf

Edited by Infinisearch

Share this post


Link to post
Share on other sites

You're welcome.  Just remember it is very important what API you're using.  Sorting by depth first on dx11 can actually cause worst performance because all the state changes.  DX12 is different not just in more draw calls but some state changes are cheaper.

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