Is early z rejection a good gain performance for mobile?

Reading about GPU bottlenecks in mobile platform seems like fillrate is one of the most causes of fps drop. Minimizing overdraw could be a great boost performance.

My doubts are about the effectiveness of sorting opaque objects from front to back. In my game particular case there is always a terrain rendered filling all the screen (camera is looking from top to down) and no objects can be seen behind the terrain.

Is a good idea queueing the terrain material to just after all the opaque materials for ensure the maximum early z rejection?

 

you can test it in 1 minute

 

Most likely not because mobile GPUs do not suffer from overdraw on opaque geometry.

 

AFAIK it doesn’t suffer from overdraw on color buffer, but depth buffer needs to render at least the vertex program for all objects and rendering a very big and far object the first one could be a waste of cycles because all other objects will be drawn in front of it.

 

On GPUs that use tile based rendering, which is most mobile GPUs (and recent desktop GPUs!), opaque objects w/o alpha testing suffer no significant penalties from overdraw. After all vertices are computed, the plane equations for visible triangles are used to determine the closest triangle per pixel before the fragment shader stage is run. There's not really a per pixel depth buffer, just the plane equations for visible triangles.

In short, drawing the terrain first, or last, or any other time within the opaque queue range will have zero impact on the performance.

Alpha testing messes all of this up. Since you need to run the shader prior to knowing which pixels are visible or not, and the coverage is no longer accurately represented with a plane, and the depth buffer gets decompressed into per pixel depth values. This means the render order of alpha tested objects matters. All opaque objects drawn after an alpha tested object will be slower to render, and I believe may overshade if not drawn in the correct order.


Note: all vertices for all objects submitted to the GPU are always processed. This is true for mobile and desktop GPUs. The GPU isn't going to cull any vertices it can't see since not being able to "see" a vertex has no bearing on if it's needed or not. For example: a triangle that competely covers the screen will likely have all of its vertices not be "visible".

 

Thanks bgolus, it’s all now crisp like water

 

Does this mean that opaque sorting has no impact on mobile rendering performance?

 

No impact on the GPU side, but some on the CPU: if you are sorting your opaque geometry manually you are basically wasting CPU power (the sorting itself + worst batching).

 

I wonder if Unity changes this per platform right now. Because the default is to sort on the CPU by depth if I understand correctly. This also tends to break instancing as a negative side effect. I did some more research over the last few hours and most people are saying that manually sorting meshes by depth does nothing on TBDRs due to hidden surface removal.

 

Also does OpaqueSortMode sort alpha tested, or does that fall in the TransparencySortMode?

 

In the general case, tile based deferred rendering removes most of the need for properly sorted opaque surfaces, since most of the cost of incorrectly sorted opaque surfaces is in over shading (computing the color for surfaces that won't be seen in the final rendering). But it's plausible there are cases where certain orders are still faster, since there's still a cost for generating the pixel visibility. Unity defaults to not applying any distance based sorting on mobile GPUs that make use of tile based deferred rendering to reduce CPU usage, but there are people who manually sort their meshes as they find it still has benefits for their project.

Alpha tested geometry, assuming it's using the

AlphaTest

queue of 2450, are part of the opaque queue range, which is from 0 to 2500. And thus use the

OpaqueSortMode

. 2501 and above are in the transparency queue range, and thus use the

TransparencySortMode

.

Just be mindful that the sorting mode only applies to objects with the exact same queue, and only in certain rendering passes. The depth only passes, like shadow maps and the camera depth texture, ignore both the material queue order and the sorting mode and always sort front to back.