Jump to content
  • Advertisement
Sign in to follow this  

Keeping state changes to a minimum...

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

As I'm sure we all know, state changes are evil and supposed to be kept to a minimum, but what I want to know is HOW minimal should they be kept? I was looking at writing an engine where during the visibility determination phase, all the vis tris where added into some sort of list class, where they where grouped by ps/tex/material, with each ps/tex/material group having its own tri list. This would keep the state changes as small as they possibly could be ( and as an added bonus would allow me to keep all the transparent ones for last easily ), and drawprim calls to 1 per ps/tex/material used, but is it overkill? All the other stuff i've seen seems to only sort state changes within an individual mesh, is the above method going to kill my speed what with rebuilding all those vb's every time I build my vis set? Thoughts and comments much appreciated :)

Share this post


Link to post
Share on other sites
Advertisement
Quote:
is the above method going to kill my speed what with rebuilding all those vb's every time I build my vis set?

As with any form of optimization - you need to benchmark it before you'll know if it is any good. It is quite possible that your approach to sort/rearrange geometry will offset any performance gain from a more optimal renderer.

When I've looked into state/material sorting I've tried two approaches:

1. Graph traversal Start at the most basic state, and then work out your order-of-rendering by a pattern of which steps require the least changes before they can be completed. It's not ideal, but its quite simple.

2. Bucket sorting references Rather than copying/moving resources around, I maintained a list (with simple integer ID's) of what objects were in what bucket - and whenever the bucket sorting was complete I'd despatch those resources off to be rendered (with associated state changing).

Also, remember theres going to be quite a lot of temporal coherancy with the grouping of geometry/objects; so you might not need to re-calculate everything on every frame.

hth
Jack

Share this post


Link to post
Share on other sites
I wouldn't rebuild VBs every frame if I could help it. You can build dynamic VBs, and this is sometimes expected behavior, but if you can place things in static VBs and leave them be you'll do better. You can dynamically create an IB though, since in general they're not stored on the video card. But that only works if all your vertices are in one VB (for one DrawPrim call).

Large VBs are desireable, as are few DrawPrimitive calls. Sort batches by FVF/shader, then by texture.

Share this post


Link to post
Share on other sites
We've tried to help reply to similar questions as how expensive are state changes with some content.

First, we've added some content to the DX SDK documentation about this, "Accurately Profiling Direct3D API Calls". This article has an appendix with estimates. Available on MSDN:
http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_c_Summer_04/directx/graphics/programmingguide/advancedtopics/ProfilingDirect3D.asp

Second, we've present some Meltdown 2004 content addressing similar issues, complete with pretty graphs, titled "The CPU Aspect of the D3D Pipeline":
http://www.microsoft.com/downloads/details.aspx?FamilyID=00600351-4c8f-43cd-b3e3-a9975ecda0ce&displaylang=en

Share this post


Link to post
Share on other sites
Thanks for the comments folks. Given that even ms admit profiling that sorta thing is hard, I guess i might just hack out a few quick and dirty variations and see what kinda throughput I get.

Using pointers or indexes to the data to be rendered sounds like the go, especially if i break the meshes up into shader/mat index lists or something as I load them. Will have a play around and let you all know how it turns out.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!