Does anyone know if using the DEPTH_EQUAL comparion disables the early Z-Reject on NV2x or R300+ hardware? (as using Depth-Modify in a pixel shader does).
From what i’ve read about the hierarchical Z-compression methods, i’d think that these Z-reject tests can only function with the comparision operators ( >, >=, <,<=) but not an exact equality (since they apparently cull on a min or max depth per block of depths).
Do you have a link to the specific paper.
DEPTH_EQUAL
is DEPTH_LESS OR DEPTH_GREATER
Originally posted by V-man:
[b]Do you have a link to the specific paper.
DEPTH_EQUAL
is DEPTH_LESS OR DEPTH_GREATER
[/b]
actually its NOT DEPTH_LESS OR DEPTH_GREATER… or am i somehow brain****ed?
I don’t have any papers in front of me, just what i’ve read on Ati’s site about HyperZ, what i’ve read on Tom’s Hardware/Anand Tech sites reviewing Nvidia’s/Ati’s early Z-Rejection. I’ve searched the GL/DX forums for some mention and i haven’t found it, but i hope some of the IHVs or in-depth developers see this post.
And yes, equality DEPTH_EQUAL can be expressed logically as (NOT( DEPTH_LESS ) AND NOT (DEPTH_GREATER) ), but that would follow the same logic that there wouldn’t be an early-z-reject if the hw was storing a min (or max) depth value for a NxN (say 4x4) tile of the depth buffer for fast z-rejections.
how about storing min and max? 
What the **** did I say there???
yes, that’s NOT(LESS OR GREATER)
Thx for both of your replies.
I’m not seeking to store min/max or do multiple Less/Greater passes.
I have a scene with massive transparency overdraw and i have implemented a depth-peeling approach. I want to use just the ‘depth-equals’ compare after the first pass (per depth-peel layer) instead of the 2 compares required to fill the depth-peel-layer the first pass.
The only question i have is does using the Z-Compare ‘EQUAL’ disable any of today’s IHV’s Early-Z-Rejection?
Using DepthFunc(EQUAL) is fine and even expected behavior. Also, make sure to turn off DepthMask when you’re doing that…
Yes, it’s fine and expected behavior. It probably also will turn off some specific depth buffer optimization schemes; especially when you’re “close”.
However, if you can look at the hierarchical Z information and see that the current block is entirely larger, or entirely smaller, than the range you’re interested in, you could still throw away an entire block. This is assuming that a Z RANGE is stored per block (which it pretty much has to be).
No, I don’t see why it would turn off optimizations. What’s the alternative, anyhow? Either you could use LEQUAL, in which case clearly the hardware can kill even fewer pixels, or PolygonOffset and LESS, which would probably be worse also.
So I am rather confused by claims that EQUAL would somehow defeat optimizations. It doesn’t.
Tests that perform culling on a hierarchical depth buffer may lose some efficiency in cases like equal. This is because the hierarchical test is going to be based on conservative tests that may rely on the test having a direction. Equal and always lack direction.
Most cases I have seen that use EQUAL can be done with either LEQUAL or GEQUAL without any penalty. If this is the case, you should use the directional version. The most frequent example where it can’t be used is in multipassing alpha tested geometry.
One other thing to keep in mind to get the most out of hierarchical depth buffers is to avoid changing the direction (less/greater) of the test between clears.
-Evan
Well, I’d disagree on EQUAL. Assuming that you turn DepthMask off, it’s better than all the alternatives, and you should use it.
Originally posted by mcraighead:
[b]Well, I’d disagree on EQUAL. Assuming that you turn DepthMask off, it’s better than all the alternatives, and you should use it.
- Matt[/b]
You are free to disagree all you want. It doesn’t change the fact that EQUAL can cause sub-optimal use of hierarchical depth buffering in some HW. If you are using EQUAL in the typical multipass scenario, I can’t think of any scenario where EQUAL kills more pixels than GE or LE depending on how you set up your depth test. (Assuming you pay attention to my previous caveats)
-Evan
I’m completely at a loss as to how EQUAL could possibly be less efficient. Reversing directions being a problem makes sense, but EQUAL is not a direction reverse.