Early z and stencil buffer

I’m working on a GeForce5200. Ok, until now I thought that early z-culling was disabled when stencil test was enabled, but apparently I was wrong. Even if I perform a stencil operation just once, early z is disabled for the rest of the program. My game renders usually at 90fps, and I take use of early z.

If, just before the rendering loop start,I just write:


This is called just once during the whole program,but the fps drop to 40, just if early z was disabled.That happens even if I write:


That also causes early z to be disabled,even if it is called just once before the main loop.

What is going on? Early z is present only if the stencil buffer is never even mentioned in the program?

i think there is a thread somewhere on this forum concerning the early z test on nv3x hardware. as far as i have understood these chips do only support the early z test (not talking about any hierarchical approach… just that the z test happens before fragment program evaluation) if absolute nothing more than simple polygons are rendered (so no alpha test and no stencil test…).
even though on r3xx hardware and the new nv4x this should work

Yes, the thing is early z gets disabled if I call this:


one instruction immediately after the other.
And I call those before the main loop, so they get executed only once during the whole program lifetime.
So,during the rendering stencil test is always disabled. But it seems that if stencil test is enabled even for just a moment, early z gets disabled for the rest of the program’s lifetime. That’s what I find weird.

If you clear Z and stencil in the same call to glClear(), after SwapBuffers(), that should re-enable early Z cull.

We’re told that, once Z cull is turned off, it won’t get turnen on until the next frame, and then only if you don’t re-use the Z/stencil buffer.

How do you proceed to get the early z test ? It would save a lot of gpu computing if nvidia was able to discard some fragment computation before they are actually computed.

its on automagically if the current pipeline configuration allows for it