I’ve beeen benchmarking parts of my program and noticed that “deactivation” part is taking a good deal of time relative to other parts. For example “activation” and “render” part took under 1 ms, but deactivation took in average more than 24 ms.
Now you might think this is nothing to deal whit but imagine running it in cycle 1000 times. 1 second and 24 second are quite a difference now. So I benchmarked every openGL call and traced that to
glGetQueryObjectiv
In fact this single call is the source of whole slowdown as other calls performed again under 1 ms. I’m using this query for transform feedback whit parameter “GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN” in begin and end.
My question is why this call is so time expensive? I don’t really need it so I will probably exclude it or make optional if it would be needed in future but I find it quite strange.
Most OpenGL calls are nothing more than putting an instruction at the end of an instruction queue on the graphics card (quite simplified of course). This means that e.g. a drawArrays() call will retun quickly even if the rendering itself takes a lot of time. This way the CPU does not have to wait for the GPU.
But some calls will have to wait because you query information from the GPU so it ‘has to catch up’. That’s readPixels for example and of course reading back your query results.
If you do very CPU intensive tasks before your glGetQueryObjectiv call to give the GPU time to catch up (without wasting that time) you might get better results.
You can also ask GL if the result is available with GL_QUERY_RESULT_AVAILABLE.
Wow, I totally forgot to add “glFinish” call when benchmarking! Also I wasn’t aware of “GL_QUERY_RESULT_AVAILABLE” and indeed I might be able to do some CPU stuff while waiting for results.
