pouët.net

I would like some input from coders who use either OpenGL or D3D.
Is it worth it to encapsulate the whole array of states with a state manager just to cache them. Is there a real performance gain?
Why not just use PushAttrib/PopAttrib(OpenGl).

thanks

We have a state manager in our demoengine, and we've been thinking of getting rid of it. It's caused some problems, and no real performance gain.

I use a "minimal" state manager that only keeps track of the most important states (lighting, blending, depth test, texturing, stuff like that). It definitely doesn't save performance compared to doing all the glEnable/glDisable "by hand", but the overhead is almost negligible. The real benefit is the massive savings in development and debugging time: "Well, is lighting enabled right now? Ah, it is. 'k, so I won't enable it again here." -- [two weeks later after some code has been moved around] "Aww, why is that object so dark?" ... no thanks. I'l gladly waste the 100 CPU cycles at run-time to save me these efforts :)

http://www.opengl.org/discussion_boards/ubb/ultimatebb.php?ubb=get_topic;f=3;t=014858

for d3d, if you arent using a puredevice the states are cached by the driver anyway. if you are using a pure device, they aren't cached. either way they get set when you do a drawxxx call, when all the state changes since the last drawxxx call get flushed. they do it using state blocks these days i believe, so setting one is almost as bad as setting a load.
so the question becomes, can you do it faster than the driver? the main cost on a non-pure device is that of the d3d->SetRenderState function call.

the worst things to change are pixel shaders and pixelshader constants. you wouldnt want to know how nvidia cards handle pixelshader constants. :)

In general, a state manager is not worth the hassle. The driver usually masks away redundant state changes, and you can't really get rid of non-redundant state changes as they will affect rendering. The only real work that can be done, is changing the draw-order (if possible). In that case, try to logically group rendering-batches by costy "state changes" like constant registers, shaders, textures etc. However, keep in mind that there are other things to worry about. For opaque objects, depth-sorting the meshes for optimal early-z effectiveness is usually gaining you more than sorting on state-changes (this depends of course on how many pixels was rasterized and culled as a result of the draw-call). My personal opinion on this is that it doesn't make much sense in trying to automate these decisions on a low level. Implement something that makes sense (like depth-sorting), and - IF PROVEN TO BE A PROBLEM - tweak this on a case-by-case basis.

we do the management mostly on a material basis. in our case, material=states+textures+shaders (shader constants aren't explicitly declared beforehand because they tend to change regularly). this is just fixed states, everything that's different on a per-object basis gets set by the material anyway.

then sort all drawing ops on a material basis (ofcourse you should make sure you don't create the same material twice). everything that's bound to be different per instance, you set every time.

as for states, we basically have custom state blocks (that code dates back to around 2000; probably wouldn't bother anymore nowadays :). the reason is that we have tons of redundant state sets in our lists - set everything to be sure there are no issues due to "hanging" state from previous calls, then let the system cut that down.

this is the main reason for the whole stateblock thingy in the first place - once you have a data structure for them, you can just say "ok, i take the defaults, but with alpha blending enabled and zwrites disabled" and you know exactly what's going to happen. our pre-FVS32-code had everyone fiddling with states all the time and it was a mess.