Somebody might have done something like that already, but I would strongly suggest against them. Even if the binds/rebinds don't kill your performance, the glGets probably will.

kRogue

08-03-2013, 04:18 PM

...or you can track the state yourself; though, that solution just plain sucks too.

On the issue of the glGet, I am not 100% really sure that glGet's querying binding state would actually hurt performance so much; my thinking is that likely that state is available on the same thread as the GL calls and is tracked anyways [many GL implementations have that many commands are queued to another thread to execute the actions] But doing that for querying what is bound on a GL context does not smell right to me. Anyone have data or numbers saying which (if any) GL implementation are harmed by glGet querying what texture is active, what texture is bound or similar for buffer objects, FBO's or GLSL programs?

GClements

08-03-2013, 08:28 PM

On the issue of the glGet, I am not 100% really sure that glGet's querying binding state would actually hurt performance so much;
Try it with indirect rendering on X. Bonus points if you have >100ms ping between the client and the X server. In this situation (where OpenGL can be perfectly usable), glGet* can be 7 to 8 orders of magnitude (10 to 100 million-fold) slower than other OpenGL calls.

Osbios

08-08-2013, 01:56 PM

Is there no way excepet manualy subscribing to threads to get notifications on this forum? Most of my setting options just tell me I don't have access rights.

Back to topic:
I target Desktop PCs. AMD/Nvidia both support DSA in there drivers. So for now I will just ignore other drivers (I think intel still dosn't include the DAS Extension)
Possible syncing functions are out of the question.

Else there seems no other way except writing wrappers for almost every OpenGL function to track the states?

mhagain

08-08-2013, 07:07 PM

Well how many DSA functions are you using? Unless you're stuck in GL1.x land, I'd say not too many at all.