Members - Reputation: 392
Posted 22 May 2012 - 08:05 AM
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.
Members - Reputation: 4606
Posted 23 May 2012 - 06:30 AM
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.
Edited by Ashaman73, 23 May 2012 - 06:31 AM.
My game: Gnoblins
Developer journal about Gnoblins
Small goodies: Simple alpha transparency in deferred shader