Jump to content
  • Advertisement
Sign in to follow this  
spek

OpenGL OpenGL state change performance question

This topic is 2527 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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 :D Hard to measure such things.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!