Trying to optimize my program a bit, and used gDEBugger for that. One of the (many) warnings is about state changes. Changing the
status in OpenGL can be a costly operation. However, it does not explain exactly which state changes can hurt the performance.

Anyway, my program surely does a lot of unnessecary state changes when it comes to, for example, setting Culling or Blending modus.
Each group of objects (sorted on material) enables or disabled face culling, a certain blend modus, and eventually an alpha function for transparency purposes.


In practice, the culling is the same(enabled) for 9 out of 10 objects, and the same for setting the (alpha)blending modus. So, glEnable / glAlphaFunc are getting called quite a lot of times while nothing will change effectively. I could prevent this by keeping track of the last modus:

if lastCullMode = cullDisabled then
glEnable( GL_CULL_FACE ); // only call this when it was disabled previously


But... Maybe OpenGL does such a check itself already. Plus, does it really makes a difference? The "if then" statement in my own code
takes CPU power as well, so...

Rick

That type of state is typically not that expensive, and it's not worth the effort to reduce calls. IIRC, expensive state changes primarily include binding textures and binding shaders, with a VBO and FBO binds a distant third and fourth.

I'm careful with textures, shaders, calling VBO's and changing textures already (by grouping and stuff). The simple stuff like changing POINTSIZE or DepthTest is done many times, careless.

I would say toggling CULL_FACE and the likes would be cheap too. But reading the discussion Kloffy mentioned, I'm still not sure what is best. One time, the glEnable/glDisable (or querying if something is enabled) is cheap, then a few seconds later they say it's faster to use your own custom checks to prevent going through a large switch state... Not sure what is best now.

I guess the best way to find out, is doing a little test. Then again, I guess the speed gain or loss is about nanoseconds Hard to measure such things.

I guess the best way to find out, is doing a little test. Then again, I guess the speed gain or loss is about nanoseconds Hard to measure such things.

Ja, the switch statements are basically meaningless from a performance standpoint. It's state changes that trigger actual changes to GPU-side data that cause issues.