Inconstant time with occlusion query inside FBO

Hello, yet already another issue…

Occlusion queries, when done inside an FBO, are done very inconstantly, whereas, when done inside the onscreen framebuffer, happen quite constantly.

I noticed it some months ago, but had no time to check this more deeply. And several drivers later (but with the same graphic card and OS), the problem remains.

The location where things hurt are the place where I wait for the results to be finished. If I don’t ask for the wait, then the problem is relocated into the rendering process of the occlusion pass (which looks logical).

So, for a given scene, if I render on-screen, and do the occlusion queries on-screen too, the latter happen quickly, and spend almost the same time from a frame to another one (between 0 and 4 ms for the wait). But if I render the same scene, but rendered inside an FBO, then the time to wait for the results has a large amplitude (between 0 and 45 ms for the wait) and changes very quickly. The average framerate is slower too (haven’t measured it yet).

The fbo is built with a depth24 depth texture attached (results are the same with a renderbuffer instead of the texture).

This looks a redundant problem with ATI, in this old thread the poster had a similar issue: link

The main difference was that the topic poster noticed he had the problem with and without FBO whereas now the issue happens only when used with FBO.

In case where requested, here is info about the system on which it happens:

ATI Mobility Radeon HD 4570
OpenGL version: 3.3.11251 Compatibility Profile Context
Drivers: 11.11 (it was the same with 11.9 and 11.4).
On a linux OS (can’t test it under Windows for now, for some reasons).

Has anyone encountered the same issues, is it a known issue/bug, maybe someone knows a trick to improve things a bit ?

Does using glFlush() helps in any way to get more consistent timings ?

I just tried it (I placed it at the end of the occlusion render pass) and the results are unfortunately the same.