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
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,
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.
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.
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."
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.
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.
