PDA

View Full Version : Early Z-Reject and Depth-Modes



Mahjii
12-18-2002, 08:03 PM
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).

V-man
12-19-2002, 06:09 AM
Do you have a link to the specific paper.

DEPTH_EQUAL

is DEPTH_LESS OR DEPTH_GREATER

davepermen
12-19-2002, 06:10 AM
Originally posted by V-man:
Do you have a link to the specific paper.

DEPTH_EQUAL

is DEPTH_LESS OR DEPTH_GREATER



actually its NOT DEPTH_LESS OR DEPTH_GREATER.. or am i somehow brain****ed? http://www.opengl.org/discussion_boards/ubb/biggrin.gif

Mahjii
12-19-2002, 08:15 AM
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.

Mahjii
12-19-2002, 08:17 AM
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.

davepermen
12-19-2002, 09:58 AM
how about storing min and max? http://www.opengl.org/discussion_boards/ubb/biggrin.gif

V-man
12-19-2002, 12:20 PM
What the **** did I say there???

yes, that's NOT(LESS OR GREATER)

Mahjii
12-20-2002, 05:28 AM
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?

mcraighead
12-20-2002, 03:07 PM
Using DepthFunc(EQUAL) is fine and even expected behavior. Also, make sure to turn off DepthMask when you're doing that...

- Matt

jwatte
12-20-2002, 08:11 PM
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).

mcraighead
12-20-2002, 10:19 PM
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.

- Matt

ehart
12-21-2002, 08:56 AM
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

mcraighead
12-21-2002, 10:05 AM
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

ehart
12-21-2002, 12:49 PM
Originally posted by mcraighead:
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

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

mcraighead
12-21-2002, 03:30 PM
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.

- Matt