NV: Early Z-Reject vs Depth-Modify-Shader

NV encourages ISVs to sort geometry front-to-back to handle early Z-reject. I assume ATI’s HyperZ benefits from this (as must the Kyro series which sorts everything anyways).

However, does anyone know how the NV Depth-Modify Texture-Shader affects this?

Will early Z-reject clip pixels who may not be rejected post-Depth-modify?

This is not as much of an API question as it is general HW, since in DX8, there is also a Depth-Modify option for PS1.4, (however, it isn’t exposed for GeForce3 which sadly only supports PS1.1…[thus NV-OGL enables more GF3 features than DX8 :] )

Anyways, its interesting to notice how we’ve gone from
-:-Software-Rasterized
()Back-to-Front Painter’s Algorithm
to
()Front-to-Back Scan-line

and
-:-Hardware
()Texture/State sorted
to
()Front-to-Back “Early Z-Reject”
to hopefully
()“HP-Occlusion-Tests” or “Hiearchical Z-Culling”

its simple: if you choose some shader settings wich manipulate z later than the z-test it will not be done till this shader is finished… you loose all the early-z-test-features but you get what you want… normally you only use this for particles or something and its not that big problem then but you’re right, it doesn’t work together

Early Z rejection specifically refers to killing pixels before the shader (and before texturing). Therefore, it is explicitly incompatible with depth replace shaders.

  • Matt