Archived

This topic is now archived and is closed to further replies.

GPU optimisation: laydown z

This topic is 4937 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

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

Share this post


Link to post
Share on other sites
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"

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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"

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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)

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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)

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
quote:
Original post by c t o a n
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"


Also if you cannot afford sending all that data through the rendering pipe twice, you can achieve roughly the same effect by sorting your batches front to back. Depending on how big your batches are it can either help or be pointless.

Don''t forget about occlusion queries either. If a surface has multiple passes, do an occlusion query on it on the first pass then a bit later in the rendering pipe, test the occlusion query, if no pixels were rendered don''t render the second pass.

There are tons of ways to improve fillrate performance.

Share this post


Link to post
Share on other sites
Btw, not all fillrate-limited scenes can benefit from this optimization. It has to be fillrate-limited *and* having a lot of overdraw. It doesn''t help on, for example, strategy games (view from above without any good occluder).

Share this post


Link to post
Share on other sites
quote:
Original post by Yann L
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.



Idea is nice, but practically you need to ensure that low res mesh has a "smaller" projection that the high res one. Else you might reject some pixels at the edges of objects that should have been rendered.

Share this post


Link to post
Share on other sites
quote:
Original post by vprat
Idea is nice, but practically you need to ensure that low res mesh has a "smaller" projection that the high res one. Else you might reject some pixels at the edges of objects that should have been rendered.

That''s what he meant by "occlusion skin".



Michael K.,
Co-designer and Graphics Programmer of "The Keepers"



We come in peace... surrender or die!

Share this post


Link to post
Share on other sites
quote:
That''s what he meant by "occlusion skin".


Yes, I had understood. However, practically, I don''t see how this would help. calculating an exact outline seems too expensive to be profitable (this outline has to be computed each time the point of view is changing on the original mesh).

Maybe you can fake and render the low res version for a point of view that is a bit further that the actual one. This could be what Yann meant.

Regards,

Vincent

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Actually fill rate limited is a strong word that covers multiple cases.

Doing a Z only pass doesn''t necessary help your fill rate either. Think that not only you pay the cost in transform (which can be limited with the occlusion skinning) and you also pay the price of the extra Z pass in fill rate (which can be accelerated on some modern hardware).

What you gain is :
- if you''ve got a hardware that is able to early reject pixels based on their depth (which they could or could not depending of what you''ve drawn before or how you did draw it) then any heavy pixel shaders (think sufficiently heavy so that those 10% extra pixels rendered does cost you 5/10% extra time between two frames.) will have to be cut off early.

Generally you arrange your rendering by opaque/transparent-materials-rendertargets such that little liberty on the spatial ordering is left. The early pass does allow you to not think about spatial ordering at the cost of extra vertex transform and a little extra fillrate (Z-Only, sometimes ambiant color). All those costs needs to be compared against the cost of having textured/rendered heavy pixel shaders that won''t be present on the screen.

For eg: FarCry wouldn''t necessarily benefit in their outdoor scene. Most of the pixels on the screen in some jungle scene are alpha/tested/blended plants billboards that do not benefit on some hardware of the early rejection. If a structure is entirely occluded by alpha blended objects, then the cost of drawing/transforming/texturing/shading this structure is lost). Alpha testing instead of alpha blending doesn''t necessarily helps because alpha tested polygons are bad occluders (don''t include them in your Z only pass).

Stencil rendering adds yet another dimension to the problem.

Everything has to be pondered and of course tested cause all hardwares do not react the same.

Share this post


Link to post
Share on other sites