Sign in to follow this  

if early-z is enable, does late-z make any sense??

This topic is 2587 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Early Z is a very coarse representation of the scene depth. It works on groups of fragments (8 pixels or so) so that they can be discarded before they are pixel-shaded. As such, you cannot solely rely on early z alone.

Having said that I'm not sure if you can enable early Z without having regular/late Z. I think that that is not possible.

Share this post


Link to post
Share on other sites
thanks for answer me!

Quote:
Original post by 2square
Early Z is a very coarse representation of the scene depth. It works on groups of fragments (8 pixels or so) so that they can be discarded before they are pixel-shaded. As such, you cannot solely rely on early z alone.

Having said that I'm not sure if you can enable early Z without having regular/late Z. I think that that is not possible.


i'm sorry , my opinion is a little different with urs.
In AMD hardware, there are two level z-comparasion before pixel shader: HiZ(short for Hierarchical Z) and early-Z.
HiZ is a coarse comparasion, while early-Z is for per pixel.
Check the article "depth in depth". (google it , u'll find it)

But it doesn't mention that whether late-z is useful when early-z is enable.

Share this post


Link to post
Share on other sites
It does not matter whether what you call "late Z" is useful or not, because the Z test by definition is always "late", i.e. after the pixel shader has been executed. The pipeline is defined this way, both in OpenGL and Direct3D.

Hi-Z, early-Z and whatever they're called (ATI and nVidia have different marketing words for the same thing) are conservative optimizations. They skip the pixel shader and everything that comes after it if it can be determined with absolute certainity that the fragment will not be visible anyway. This frees shader units for other computations and saves energy.

As such, they strictly do not implement the pipeline correctly (if you're pedantic), but since the optimizations are conservative, it does not matter for the outcome.

Share this post


Link to post
Share on other sites
Quote:
Original post by CodeBoyCjy
But it doesn't mention that whether late-z is useful when early-z is enable
On DX/GL it doesn't matter, because you can't (directly) turn early-z/late-z on or off!! The API only lets you turn the z-test on/off -- the driver will choose whether the test is early or late.

The driver will try to use the early-z test whenever it can, because it's an optimisation.


However, on some other (non DX/GL) platforms, you can actually set a render-state to enable/disable early-z yourself... but, you'd only want to enable it when it's safe to do so (when the pixel shader doesn't modify depth or have other side effects -- e.g. no custom depth writes, no alpha-test, etc...)

Share this post


Link to post
Share on other sites
Quote:
Original post by Hodgman
Quote:
Original post by CodeBoyCjy
But it doesn't mention that whether late-z is useful when early-z is enable
On DX/GL it doesn't matter, because you can't (directly) turn early-z/late-z on or off!! The API only lets you turn the z-test on/off -- the driver will choose whether the test is early or late.

The driver will try to use the early-z test whenever it can, because it's an optimisation.


However, on some other (non DX/GL) platforms, you can actually set a render-state to enable/disable early-z yourself... but, you'd only want to enable it when it's safe to do so (when the pixel shader doesn't modify depth or have other side effects -- e.g. no custom depth writes, no alpha-test, etc...)


Ok, I don't want to control early z in DX or OGL, I think I can control it indirectly.
I think my point is that late z means nothing if early z is enable.
The first question we need to solve is whether early z is correct without other z tests, such as hiz late z, my answer is yes.
And urs?

Share this post


Link to post
Share on other sites
Quote:
Original post by Hodgman
Quote:
Original post by CodeBoyCjy
But it doesn't mention that whether late-z is useful when early-z is enable
On DX/GL it doesn't matter, because you can't (directly) turn early-z/late-z on or off!! The API only lets you turn the z-test on/off -- the driver will choose whether the test is early or late.

The driver will try to use the early-z test whenever it can, because it's an optimisation.


However, on some other (non DX/GL) platforms, you can actually set a render-state to enable/disable early-z yourself... but, you'd only want to enable it when it's safe to do so (when the pixel shader doesn't modify depth or have other side effects -- e.g. no custom depth writes, no alpha-test, etc...)


Actually D3D11 has the earlydepthstencil attribute for pixel shaders that's supposed to force early-z testing, although I've never tried it myself...

Share this post


Link to post
Share on other sites
earlyZ is an ambiguous word. It basically just means that there is an "early out" for depth testing in the pipeline, before the actual testing would be done in the backend.
Hiz,Zcull etc. are earlyZ versions as well, before G80 hardware was executing shaders once they have been triggered from start to the end, even if you used things like clip(d3d)/kill(ogl). G80 can exit "early out" when you call this "clip", it would also stop fragment program execution if you'd do the z-test yourself, so there would be no reason to not always have this feature which is the per-pixel earlyZ.

Quote:

The first question we need to solve is whether early z is correct without other z tests, such as hiZ late z, my answer is yes.

no, it's not always correct, for various reasons.
1. you can have shader that modify the depth
2. you can have shader that don't set a pixel (this means that the earlyZ representation might not have the final zbuffer information and pass through a pixel although the backend will reject it).
3. there can be several rasterization units (e.g. 4 on fermi) and they might not know the coverage information of vice versa. both could send the same triangle through the pipeline and if 'LessEqual' is enabled, the 2nd one will fill the color and zbuffer, if 'Less' is set, the first one will do.
4. if you write out to buffers other than frame buffers, earlyZ __could__ help, but as the driver programmer don't know if you rely on the execution of the fragment program or not( no matter if the pixel will be visible, because you spoil out data to other buffers), they have to disable this optimization. In that case you can hint to keep it enabled by the earlydepthstencil flag that MJP mentioned, then YOU have to guarantee that the result will be looking properly (if you e.g. want to count the overdraw while still properly drawing objects, or you want to make some x-ray vision while rendering other stuff properly, you can't enable earlydepthstencil).
...

cheers

Share this post


Link to post
Share on other sites

This topic is 2587 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this