Repeated State changes in Opengl

   Its a fact that state changes in Opengl leads to performance degradation. 

//Say If i'm calling glEnable(GL_DEPTH_TEST) / glBlendFunc repeatedly in every frame.

EDIT: >Here I just mean to say 'some state changes like this which state changes cause perf开发者_Go百科ormance problems'

Can any one please explain the reason for this in detailed?

To my knowledge, The states can be maintained with in a register and can be used in traditional rendering GPU(Immediate mode kind) or can maintain a state vector for each draw call in Tile based deferred Rendering. Is this really costly to maintain? (wonder why GPU's are having still this problem :( )

---

Indeed state changes may be a performance killer. However the important question to ask is: "Which state". Some state changes are so cheap, that is simply doesn't make sense to keep track of them to minimize their use.

On today's OpenGL implementations glEnable/glDisable have virtually no performance penality (of course some states en-/disabled have large influence on the rendering performance in general).

So what are expensive state changes? About everything that kills the caches' contents, and the data in the cache is to be accessed at high bandwidth or requires high throughput.

Textures are about the most expensive source of data to switch. So as a basic rule you sort your scene by use of textures, to switch textures as few as possible.

Another expensive state change is switching shaders. Switching a shader affects the GPU in a negatively in two ways: First it forces the processing units into a full stop, flushing their execution pipeline. Refilling the pipeline until the thing works "like clockwork" takes a few hundred cycles. The other problem is, that different shaders have different execution and data access patterns. Execution patterns are determined by codepath prediction units to estimate which operations are about to be executed most likely. This also means knowing, which data to prefetch. Switching the shader trashes this vital information.

States that are very cheap, but not for free is anything that can be described by a small set of numbers: Uniforms. Switching uniforms is extremely cheap, since it requires only very little overhead in the communication with the GPU and since Uniforms live in registers, changing them will effect neither cachelines nor execution prediction. And if you're wondering about traditional, fixed function OpenGL: Transformation matrices, lighting parameters, clip planes are uniforms (just look into the OpenGL-2.1 GLSL spec, which built-in uniforms there are).

---

I believe that glEnable(GL_DEPTH_TEST) would not incur significant performance degradation.

The expensive state changes I believe are shader program binds, buffer binds, texture binds and buffer offset/stride changes. Because these require validation to ensure that the buffer is large enough etc.

If you think this could be affecting performance you can order elements to be rendered by material (textures, shaders, depth testing) before rendering, and perform the state changes only once.

---

You should enable some opengl state only if you disabled it first. So there is no reason to call glEnable(GL_DEPTH_TEST) or glBlendFunc every frame if you don't need such changes