Are Stateblocks useable?

You''re going to wish you never asked...

The quick answer is "I don''t know for sure, but stateblocks should be okay... but it really depends on your app. In most apps it should be okay".

The long answer is that both Microsoft and nVidia don''t recommend using state blocks, but you can work around their reasoning somewhat.

Their reasoning is this. Suppose you have drawn an object, and now you want to load a state block to draw another object differently. Lets say your state block sets 10 states. Lets assume that 9 of these states are already what you wanted from before the earlier draw. You''re now requesting that DX and the hardware do 10 times as much work as needed to setup your next draw call.

In addition to that extra overhead, the real problem lies in requesting a state block that exactly matches the current state. State changes on the GPU take time. Changing 1 value or 50 doesn''t really matter, just the fact that you''re changing *something*, *anything*, causes a hit to GPU performance. If you record all your changes as you make them, and later notice that you don''t need to change anything to do your next draw, you''ll get a boost from not changing any states at all. If you change even 1 state, you''ll get a performance hit.

My reasoning is this. The overhead to remember, and check each state setting exists, however small. When you need to set, say 5 new states, you''re incurring 5 stack frame create/destroys, 5 context switches to the DLL code, etc, in addition to the checks and recording of the values you''re changing.

Unless you know the exact ordering of your drawing each frame, which you won''t if you depth sort, you''ll need to record each state change you make, and check for each state setting to see if it needs changing before asking it to change.

Now, if you can guarantee that all your state blocks are truly unique, and sort by effect over depth, then you won''t incur extra state change penalties even if there is a little redundancy in loading your new state block. Of course, you might now be drawing too much that will be overdrawn since you''re not truly depth sorting, but texture, state, shader changes all take time, and you''d have to make extra state changes to do proper depth sorting.

Welcome to the annoyances of 3D. You want to depth sort for performance, but you don''t want to change states, textures, or shaders, or even shader constants, for performance too. Unless all your objects are the same color with the same texture, with the same effect, you''ve got conflicting goals.

Sorting such that similar objects are drawn together will most likely, in most cases, win out over a proper depth sort. And if you''re sorting similar objects together you nullify the warning about making redundant state settings. (set state once, draw many objects, set new state once, draw many more objects, etc.)

Unlike GL display lists, only state can be stored in state blocks.

You might find this helpful:

http://tomsdxfaq.blogspot.com/2002_07_01_tomsdxfaq_archive.html#78505386

Wow thanks NTNET for the feedback. I guess they might be a little more trouble than their worth. I guess I''ll have to focus somewhere else within the scene management to optimize the thing..

Thanks Donavon..Tom contributes regularly to the DXDEV mailing list, and I totally forgot to check his site out..(thanks for the link tho!)