If you scene does only consist of 250 batches/drawcalls, you're definitily not cpu bound. To my knowledge the average scene in a modern game is much larger than this. My personal experience is that a present single core system can handle 2000 batches with shader/texture switches at 30 fps and you still have spare CPU cycles. So to repeat previous advice: profile.

Some more hints, just to refresh some memories of my baddest mistakes:

* Pay attention to accesses on dynamic resources. You most propably have some of this, for example dynamic vertex buffers for particle systems or simple font/HUD rendering. Be sure to actually allocate with the USAGE_DYNAMIC flag and lock into that buffer with LOCK_DISCARD. If you don't do this, you loose all CPU/GPU parallelism. Even if one of these both is heavily under-utilized you can still gain some frames per second.

* Filter all state changes. If you set a render state to a value even if it actually has that value from a previous call, you waste a lot of CPU cycles. To my knowledge, DirectX does no filtering of useless state changes, it just warns on them at a high debug output level. It's very simple to put a thin layer between DX and your engine that caches all state changes and compares them to the previous values before issuing a DX call. A simple change that doubled our framerate a long time ago.

* Same can be applied to textures, shaders and about everything else, but you are most propably already doing that.

* Batch shader constant updates. This won't gain you as much, but it helps as well. Instead of multiple calls to SetShaderValue() or what it's called, fetch the registers indices for all textures / parameters you need in advance and store them with the shader. When drawing you are then able to construct the whole shader parameter set in an offline float buffer and commit it all in one call. It helped us a bit, but it provides not as much gain as the other tips.

* As already said before: group batches by shader.

Good luck. If you succeed in improving your performance, please let us know what exactly helped you and to what amount. Future discussions might profit from such real-world data.

Bye, Thomas

[edit] fixed some typos.

I'm doing all that redundant state stuff, but your suggestion about dynamic data is a good one - I'm going to look again at that stuff.

I'll certainly post back later if I find anything dramatic worth passing on.