Sign in to follow this  
CodeBoyCjy

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

Recommended Posts

CodeBoyCjy    163
hi all:

i'm wondering that if there is no alpha test or something that disable early-z in the pipe, does late-z make any sense??

or maybe i should say, if early-z is enable, do we need late-z???

thanks for ur help.

Share this post


Link to post
Share on other sites
2square    129
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
CodeBoyCjy    163
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
Hodgman    51223
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
2square    129
Quote:
Original post by CodeBoyCjy
HiZ is a coarse comparasion, while early-Z is for per pixel.


Thanks for pointing it out. You're right. I mixed up Early-Z and Hi-Z.

Share this post


Link to post
Share on other sites
CodeBoyCjy    163
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
MJP    19754
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
Krypt0n    4721
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

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