Alpha test vs early z

[Rolf N]

A tangent from this thread.

Early Z effectively does the Z testing before the far more expensive texturing operation thus can save some otherwise redundant work.

It can't be used with alpha testing as that requires you to texture before deciding if you need to do the Z test.

With alpha testing, visibility is a function of (amongst other things) the texturing operation. You can only update the Z buffer if the pixel is visible.

That much I knew

AHHH! I think I know why you're confused. Consider what would happen with the next object, i.e the following an alpha tested object, if you didn't do all the operations on the alpha tested object first.

That was the direction I was going in with my theory ...

So the problem is that you can't get the final visibility information back (from after alpha testing) into the "z block" without stalling the whole pipeline. Correct?
And you can't do the z updates inside the "z block" the usual way because you'd produce false positives (culled even though visible).

But ... what about just not updating the "z block" internal data while alpha testing is active? No updates would mean no false positives. You'd still be able to vis cull alpha tested fragments against "old" fragments that have been rendered without alpha test AFAICS. And there are circumstances that do not require you to update regardless: depth test=EQUAL; and anything with depth writes masked off. That should be pretty common during multipass rendering (all passes except for the first one).

All of this would, of course, require that a proper z test and (external) z buffer update happen after the alpha test. Isn't such a "fallback" z test facility at the end of the pipe already, exactly for such cases as alpha testing? Or is this the same "z block" that -- by some magic I do not understand -- changes its position in the pipeline?

 

[ERP]

I have no idea about ATI's solution, but NVidia's will happilly kill unseen alpha tested pixels.

I've never timed it to see if there is a significant stall on large amounts of visible Alpha writes, but from what I know I doubt it.

Fiddling with Z in the shader however causes allsorts of performance issues.

 

[JohnH]

The trick is that when you apply alpha test it introduces a latency between the submission of the object and the validity of the depth values it produces. Due to pipelining this is normally OK while you're supplying alpha tested objects, but if you switch alpha test on and off a lot this latency can result in a stall (as an early Z object needs valid depth before it can proceed). You could just take the hit of false positives as these would be rejected at the backend anyway, but still not good for early Z performance, particularily given the reliance newer HW has on this and Hierarch Z to reduce depth buffer BW. The obvious statement is, as usual, group objects with like state together to avoid performance hit, that said I've never taken the time to measure the impact of this wrt to alpha test.

As for updating depth from the shader, this completly screws IMR's as it prevents them from applying any kind of BW saving techniques (such as hierarchical Z) to the depth buffer.

John