If the custom depth is always less that the default depth, it should be possible to use the standard depthbuffer and a depth texture. The depthbuffer contains the depth computed by the fixed pipeline and the depth texture contains the displaced depth. The fragment has to pass the normal fast depth test and a custom depth test with the depth texture in the shader. Most of the fragments will be occluded by the default depth test and the expensive pixel shader with the kill instruction is only executed for pixels, that were visible without z replacement. I haven’t tried it yet, but perhabs this works. But Stencil Shadows could be a problem.
Originally posted by LarsMiddendorf:
The fragment has to pass the normal fast depth test and a custom depth test with the depth texture in the shader.
Yes,but if the fragment shader replaces depth,the early depth test is disabled.That’s the whole problem.
Originally posted by mikeman:
I have a GFX5200.The only things that disable early z-test is running depth-replacing fragment programs and,of course,glDisable(GL_DEPTH_TEST).Alpha test and zwrites have no impact.
Weird, I should try on mine. If the drivers follow the spec alpha testing should disable early-z testing since the alpha value generated by the fragment program must be tested before the depth component. Though there is a quirk, this does make a difference if z-writes are enabled since fragments rejected by the alpha test must not write to the depth buffer; but with z-writes disabled you can rearrange the tests w/o altering the results so early-z testing should be fine.
I think that following tests are performed in this order:
- Scissor test.
- Early Z-Test
- Alpha test.
- Stencil test.
- Depth test.
- Blending.
- Dithering.
yooyo
Originally posted by crystall:
Weird, I should try on mine. If the drivers follow the spec alpha testing should disable early-z testing since the alpha value generated by the fragment program must be tested before the depth component. Though there is a quirk, this does make a difference if z-writes are enabled since fragments rejected by the alpha test must not write to the depth buffer; but with z-writes disabled you can rearrange the tests w/o altering the results so early-z testing should be fine.[/QB]
Ok,I found a .ppt in the web that describes the rasterization pipeline.
It goes like this:
1)Rasterization(yielding a fragment)
2)a)Fixed:Texture Mapping Engine,Color Sum,Fog
b)Programmable:Fragment program
3)Pixel ownership test
4)Scissor test
5)Alpha test
6)Stencil test
7)Depth buffer test
8)Blending
9)Dithering
10)Logical Operations
11)Write to FrameBuffer
Early z-test should take place after rasterization and before fragment programs.There is no reason why alpha test should disable it.At least on NVidia,it doesn’t.
You can find the document in “http://www.plunk.org/Performance.OpenGL/”.
It contains a lot of material of how to boost performance in OpenGL.
Originally posted by mikeman:
[b]Ok,I found a .ppt in the web that describes the rasterization pipeline.
It goes like this:
1)Rasterization(yielding a fragment)
2)a)Fixed:Texture Mapping Engine,Color Sum,Fog
b)Programmable:Fragment program
3)Pixel ownership test
4)Scissor test
5)Alpha test
6)Stencil test
7)Depth buffer test
8)Blending
9)Dithering
10)Logical Operations
11)Write to FrameBuffer
Early z-test should take place after rasterization and before fragment programs.There is no reason why alpha test should disable it.At least on NVidia,it doesn’t.
You can find the document in “http://www.plunk.org/Performance.OpenGL/”.
It contains a lot of material of how to boost performance in OpenGL.[/b]
I’ll chech that document. As I said there is a reason for disabling early-z test when alpha testing is used with depth-writes enabled unless during the early-z test no z values are actually written out (they are kept in a buffer and written out after the depth test). If a fragment fails the alpha-test then its depth value is not written out, early-z usually requires that the depth test (and thus the write to the depth buffer) is done before the alpha test (that is before running the fragment program). So fragments discarded by the alpha test could end up writing in the depth buffer which is contrary to what is in the spec. If the hardware is smart enough to posticipate the depth-write to after the alpha test or if depth-writes are disabled then its fine to execute the early-z test before the alpha test.
Originally posted by crystall:
If a fragment fails the alpha-test then its depth value is not written out, early-z usually requires that the depth test (and thus the write to the depth buffer) is done before the alpha test (that is before running the fragment program)
The writes to the buffer(color,depth,anything) happen in the final stage of the rasterization pipeline.I don’t understand where you got the idea that zwrite must be done immediately after ztest.
I don’t think you understood what early ztest is:
The raster pipeline works as I described.Early ztest is just a trick the hardware uses to discard fragments at an early stage.It doesn’t mean that,if a fragment passes the z-test,the depth value is immediately written to the buffer.That would mean z-test would disable any other test(scissor,stencil,alpha).
I said I already did a test on my NVidia.A wrote a program that does specular bumpmapping and parallax mapping,running in 25FPS.Then i clear the depth value with 0.0 so nothing passes,and I have 500FPS(early z boost).I enable ALPHA_TEST,I still have 500FPS.I disable DEPTH_TEST,and I’m back to 25FPS.