Opengl Device not cheap to set new values

Started by
0 comments, last by Ashaman73 11 years, 11 months ago
Hello,

I have analysed my engines performance using gDebugger and it shows me a number of warnings about changes to the underlying opengl state not being cheap. From my understanding the engine should store local copies of opengl states and check against these before calling the opengl state setter functions, we currently just call the setters even if the value is the same. Does anyone have any numbers on how much an opengl renderer can be improved by doing this; obviously a lot will depend on the types of calls the engine makes over several frames.

I'd be interested to know if this is an area I should look to implement to improve engine performance before other things.
"I have more fingers in more pies than a leper at a bakery!"
Advertisement
Some thoughts.
Most state changes are only enqueued into the command queue at the time you call the API. The state, once your command will be executed, is not known yet. Therefore it will most probably results in a larger command queue than necessary.

The assumption how a API works, is always risky. The same argument could be turned around: the developer knows what to call and the driver don't need to double check it (better performance). But this depends on the driver implementation as long as it has not been explicitly defined in the API.

This topic is closed to new replies.

Advertisement