Hi, all
I made a simple test with first drawing one mesh of sphere(515 verts and 768 primitives) and second drawing a skybox(5040 verts and 1680 primitives).
The sphere mesh is ZWrite on and ZTest on, and the skybox is ZWrite Off and ZTest on.
Wth the streamline report, the first sphere is expected to enable the ZSUpdate, and the SkyBox is expected with EarlyZSKilled with the Sphere quads size.
Those two values are expected to be exact, as a result, the EarlyZSKilledQuads is far more different from ZSUpdateQuads.The MaliCoreQuadsEarlyZSUpdatedQuads is almost close to the expectation, but the EarlyZSKilledQuads with 20,949.
I wonder how the EarlyZSKilledQuads is calculated.
Thanks
There are various optimizations in the hardware than can coarsely remove occluded work early in the pipeline. Only quads that pass those early checks and hit (and are killed by) the quad-based ZS testing will actually increment EarlyZSKilledQuads counter.
Thank you, Peter.
I understand what you mean and the early Z mechanism and that's why I am confused with the streamline report.
In my case, during the first sphere drawing, it updates the depth buffer,so the ZSUpdateQuads increase the counter,the size should be the depth buffer size/16(mine is MaliG76 MP 16)/4(QuadSize) and the result is in my expectation, however during drawing the skybox which didn't update the depth buffer,but what is occluded pixes by the first sphere which here is earlyZTest conter is expected to added.In my expectation the EarlyZSKilledQuads(earlyztest) size here should be as same as the previous ZSUpdateQuads size,but the report is only (20,949) which is far less than the ZSUpdateQuads(443,310)
In my expectation the EarlyZSKilledQuads(earlyztest) size here should be as same as the previous ZSUpdateQuads size
It should be no higher than the update value, but can be lower because of other optimizations in the hardware that can remove redundant workloads before early-zs.