GPU optimisation: laydown z
Author
hihi,
i was reading the GPU gems book, and came across the part called
"render depth only (no color)" or they called "laydown z" first.
which i am quite bit cluelessss here, i mean how do we actually render the depth? jus a depth test without clearing the backbuffer? or the other way around?
or is there alot more to it actually??
also, the book recommended to disable alpha testing during the render depth only process.
thx!
Edwinz
This refers to rendering the scene with color writes disabled. This translates into only writing the z-value of all polygons in the scene into the z-buffer.
Once the z-buffer is filled with all visible polygons, you re-render your scene with full detail, and if the polygon is invisible in the final result, it will fail the z-test and no more work will be put into it.
This is only really helpful if you are fill-bound in your engine, but this method really sucks if you''re transform-bound (because you have to transform all your polygons twice)
Chris Pergrossi
My Realm | "Good Morning, Dave"
Once the z-buffer is filled with all visible polygons, you re-render your scene with full detail, and if the polygon is invisible in the final result, it will fail the z-test and no more work will be put into it.
This is only really helpful if you are fill-bound in your engine, but this method really sucks if you''re transform-bound (because you have to transform all your polygons twice)
Chris Pergrossi
My Realm | "Good Morning, Dave"
quote:Original post by c t o a n
This is only really helpful if you are fill-bound in your engine, but this method really sucks if you''re transform-bound (because you have to transform all your polygons twice)
while seeing how current cards push hundreds of millions of triangles through transformation you''ll always be fill bound unless your texturing/shading is extremely simple or the scene is extremely complex.
sorting objects by "shading complexity" and maybe use that method only for the complex objects after the simple stuff was drawn might be a good compromise.
Well, there are other potential bottlenecks when doing graphics programming, so you might not be fill-bound OR transform-bound, so you might not see a big change, positive or negative, if your engine has other limiting factors.
On the whole though, this is a good technique for improving performance if you''re using complex pixel/vertex shaders, multitexturing, or have alot of overdraw in your scenes.
Chris Pergrossi
My Realm | "Good Morning, Dave"
On the whole though, this is a good technique for improving performance if you''re using complex pixel/vertex shaders, multitexturing, or have alot of overdraw in your scenes.
Chris Pergrossi
My Realm | "Good Morning, Dave"
Doesn't rendering your geometry in rough front-to-back order acheive about the same result without the extra transformation work?
EDIT: If you have a lot of different setups (different textures, different shaders, etc) render front-to-back for each setup separately, starting with the simler ones and progressing to the more complex ones. This way, by the time you reach the expensive shading, your z buffer is already almost filled, and the front-to-back rendering order takes care of most of the remaining overdraw.
Michael K.,
Co-designer and Graphics Programmer of "The Keepers"
We come in peace... surrender or die!
[edited by - technobot on May 29, 2004 5:04:11 AM]
EDIT: If you have a lot of different setups (different textures, different shaders, etc) render front-to-back for each setup separately, starting with the simler ones and progressing to the more complex ones. This way, by the time you reach the expensive shading, your z buffer is already almost filled, and the front-to-back rendering order takes care of most of the remaining overdraw.
Michael K.,
Co-designer and Graphics Programmer of "The Keepers"
We come in peace... surrender or die!
[edited by - technobot on May 29, 2004 5:04:11 AM]
quote:Original post by technobot
Doesn''t rendering your geometry in rough front-to-back order acheive about the same result without the extra transformation work?
This is probably for places where you don''t have the good front-to-back ordering info. From one of the slides @ GDC I think the suggested order was.. sort by rendertarget, shader, texture (roughly in that order)
quote:Original post by edwinnie
also, the book recommended to disable alpha testing during the render depth only process.
This is because alpha-testing enables/disables the depth write on a per-pixel basis and, because alpha is available later in the pipeline than the early z-write, the early z-write has to be omitted (you can't write to the depth buffer and then have the alpha-test, which happens further down the pipeline, say that the pixel is transparent and shouldn't have written z in the first place). The z-write still goes to the late zbuffer though. This means any batch of triangles rendered with alpha-testing enabled cannot early z-reject subsequent batches rendered in the z-only pass. On modern h/w there's two types of zbuffer - a late one that tests a single pixel and an early one that tests a group of pixels (sometimes rejecting a single triangle with one test).
[edited by - soiled on May 29, 2004 12:09:22 AM]
That works well if you don''t have textures with holes in them (alpha keys). Otherwise you''ll have to render those textures twice, and even with color writting disabled you still waste a lot of bandwidth/fillrate, because the texture is needed for the alpha key.
Since most of our plants need alpha testing, it''s not going to be very usefull.
Eternal Lands (free, Open Source MMORPG)
Since most of our plants need alpha testing, it''s not going to be very usefull.
Eternal Lands (free, Open Source MMORPG)
Re: "laydown z"
You'll double the batch count, and engines these days (i.e. shader driven) are so easy to become batch-limited.
You should try this *after* you got the engine running and fed with real-world dataset (i.e. during optimization phase).
[edited by - yogiwp on May 31, 2004 11:22:59 AM]
You'll double the batch count, and engines these days (i.e. shader driven) are so easy to become batch-limited.
You should try this *after* you got the engine running and fed with real-world dataset (i.e. during optimization phase).
[edited by - yogiwp on May 31, 2004 11:22:59 AM]
You could use a lowpoly approximated mesh instead of rendering the scene geometry twice. Prefilling the zbuffer with an occlusion skin (as in occlusion culling) would probably work pretty well - early z rejection is a kind of degenerated (perpixel) occlusion culling method after all.
If you're not fillrate limited, that is.
[edited by - Yann L on May 31, 2004 11:46:13 AM]
If you're not fillrate limited, that is.
[edited by - Yann L on May 31, 2004 11:46:13 AM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
