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.
if early-z is enable, does late-z make any sense??
Are you asking about a particular API where you can control whether early-z/late-z is used?
i.e. are you asking when you should use late-z?
i.e. are you asking when you should use late-z?
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.
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.
Author
thanks for answer me!
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.
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.
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.
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.
Quote:Original post by CodeBoyCjyOn 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.
But it doesn't mention that whether late-z is useful when early-z is enable
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...)
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.
Author
Quote:Original post by HodgmanQuote:Original post by CodeBoyCjyOn 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.
But it doesn't mention that whether late-z is useful when early-z is enable
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?
Quote:Original post by HodgmanQuote:Original post by CodeBoyCjyOn 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.
But it doesn't mention that whether late-z is useful when early-z is enable
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...
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.
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
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
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
