You are strongly advised to minimise state changes as far as you comfortably can. DirectX 10's pipeline can handle this trigger-happy system, but anything earlier will suffer, perhaps badly.

For a small project, it's easiest to set states only when necessary, and live with the difficulties this causes when the rendering order needs to be changed. For larger-scale programs, you're encouraged to keep track of states manually as you describe. Depending on the level and nature of the state-switching, this can give overall performance a considerable boost.

Driver and batch overhead is usually associated with CPU performance, since you're making more driver calls for the same amount of GPU work.

Quote:Original post by patrrr
Thanks, that was what I wanted to hear!
Will this affect only CPU performance, or GPU? Or maybe both?

Well, both, but that's probably not the best way to think of it.

By manually keeping track of state and avoiding an unnecessary change, a few important situations arise:

1. The need to call the API is removed. While redundant state-changes are often caught by the API (and so very little work is done), there are certain situations where this isn't possible. The result is a transition to kernel-mode (as the driver comes into play), which costs CPU-time.

2. The GPU need not flush its buffers. Considering that geometry tends to come in large batches of the same type, GPUs utilise heavy parallelism, with long pipelines that work on different parts of the data simultaneously. Although the cores are largely independent, they share render-states, and so they cannot work on data of differing type at the same time. The crux here is that a state-change requires the video card to wait for all of its pipelines to finish work before the state can be changed and the next batch can start being processed. Regular state-changes make for many such GPU 'pipeline bubbles' and amount to more waiting and less doing.

3. Parallelism is benefited. Most current games are either CPU- or fillrate-limited, and most render states pertain to the vertex pipeline, so excessive state-changing generally serves to tip this unbalance even further. It's a very general claim, but state changes hence tend to cost CPU-GPU parallelism.

The relative importance of these three factors is debatable, but it's probably not a worthwhile conversation as any one of these facts is enough to convince a sensible programmer to manage states carefully.

State management is such a common drain on processor resources that DirectX 10 (I can't speak for OpenGL 2, but I assume the situation is the same) has made huge efforts to take the strain off the programmer. Batching and state-management are tedious details that the programmer would ideally not have to concern himself with, and considering how it looks a lot more like manual-labour than insightful problem-solving, it's quite right that the effort is moving out of the domain of the programmer and into that of the silicon. Alas, until we can disregard platforms that aren't currently top-of-the-range, we'll just have to grin and bear it.