Graphics state management

re: Graphics state management

ajmiles — Fri, 26 Oct 2007 08:36:20 GMT

What I've never understood is why somewhere in between $3D_Application and the GPU there isn't someone else taking responsibility for ensuring redundant state changes are caught and can also be read back quickly. This could (conceivably) be either the graphics card driver or DirectX itself. Although I've not given this plan much thought, the renderstates that easily map to enums (like FillMode, the Alpha ones etc) could be stored in RAM and just get updated every time the GPU gets updated. Meaning that changing from FillMode.Line to FillMode.Line never gets passed on to the GPU, and querying any of those states doesn't require talking to the GPU.

I've thought about trying something similar just in my XNA apps, a "RenderStateManager" of sorts, but using things like SpriteBatch mean that I can't run *all* state changes through my manager, and it just ends up being a pain to keep track of.

re: Graphics state management

Ultrahead — Fri, 26 Oct 2007 16:18:41 GMT

This can also be combined with a sorting helper so as to minimize switching states. You just define when to call each object's draw method based on, say, material, texture, type of object/entity (good occluder, transparent one), or categories (3D models first then 2D sprites) and so on.

re: Graphics state management

ShawnHargreaves — Fri, 26 Oct 2007 19:42:18 GMT

> What I've never understood is why somewhere in between $3D_Application and the GPU there isn't someone else taking responsibility for ensuring redundant state changes are caught and can also be read back quickly.

There is! At least for setting, and on Windows for reading back as well: reading back is especially slow on Xbox due to the user/supervisor memory split.

The trouble is not that everybody isn't doing their best to optimize state setting, but that there are simply so many states. A DX9 GPU has kilobytes worth of state data, and it takes hundreds of function calls to set all this state. Even if every one of those function calls could just trivially compare the state it is being asked to set against the current value and return in just a couple of clock cycles, that is still hundreds of calls, comparing hundreds of values, for no good reason.

Even if T is quick, it is still faster to not call it in the first place, and in this case we are talking about a large number of T's!

The key thing here is that games are able to use higher level architectural decisions to reduce work, where the driver is only able to apply dumb "this state is the same value I have already" checks. The game knows more, so it can make assumptions like "I don't even need to bother thinking about setting states X, Y, or Z, because I know the previous guy already set them for me".

re: Graphics state management

Ultrahead — Sat, 27 Oct 2007 01:39:03 GMT

There was an interesting reading on ShaderX4 book about this. In the article, it was even considered setting some states back and forth within each shader it-self.

re: Graphics state management

digini — Sat, 08 Dec 2007 10:18:09 GMT

Cool post...

For our material system we've tried a few different approaches EMFH and Consistency.

Right now we are using kind of a hybrid. When we change materials we set the shader params to the base "known" state and then apply a set of deltas that are specific to the particular material In our testing this seemed to do better than the Consistency approach.

But I have a question about shader state optimization... Right now we are making heavy use of Effect Parameter Blocks (for static state) since individual calls to set each parameter seems like a really bad idea.

I'm curious though how fast EPB's are in XNA. What is the underlying mechanism for commiting the parameter block to the GPU. Since I assume the XNA EPB's are simply handles to the underlying native effect blocks in DX9 I guess they are pretty efficient.

Can it be almost as quick as a native mode block copy? If they are really this quick maybe Approach 1 (EMFH) might actually be the quickest.

thoughts?

Christian