occlusion queries and framebuffer object


I would like to know if it’s possible to do occlusion queries per fbo. I would like, for example, do a ‘set’ of queries in the global framebuffer and do other ‘sets’ of queries in some fbo, and later check the results of all of them.

However, tests I made shew that the first made tests on the first framebuffer (or fbo) impact the next tests.

The solutions I have found are to create as much contexts as ‘sets’ of queries (1 per framebuffer) since occlusion queries are context-dependent. However I would like to avoid this solution since context switching is said heavy-weight and this will also complicate my code (and I don’t really like this way to achive this).
Other solutions would be to use occlusion queries 1 and 2 (so use 2 different targets) since I never saw any performance issue between both versions of occlusion query, but this will be limited to 2 ‘sets’ of queries per frame, limited to 3 ‘sets’ if I use the HP version too.

Note that I do ‘frame-late’ queries, so this is why I’m facing this problem. I could do simple queries in a single frame, but this would lead to several clears of the depth-buffer, and several waitings of the query results, which I would like to avoid, for performance issues.

Any clue ? Thanks in advance.

Spec says: “Occlusion queries use query objects to track the number of fragments or samples that pass the depth test.” Depth test operates on the depth buffer for the currently bound FBO. So yes, should be able to do occlusion tests per FBO, assuming the right one is bound before you do each set of queries.

However, tests I made shew that the first made tests on the first framebuffer (or fbo) impact the next tests.

Are you doing any conditional rendering, or rendering dependent on the results of the occlusion queries?

If not, pray tell: what GPU/driver?

I do simple things like this (single pass per frame here for conveniencies):




(with no fbo bound:)


I don’t do any conditional rendering at all.
I, of course, render depending on the results of the occlusion queries: I render what the results said visible as major occluders. This works very nice until I try to do the same for what I render into fbo too.

However the first made tests impact on the second test (ie, the major occluders from the global framebuffer impact the results on the bound framebuffer). If I disable the tests on global framebuffer, results are OK on the framebuffer tests.

Work is done under Linux with:

OpenGL renderer: ATI Mobility Radeon HD 4500 Series
OpenGL vendor: ATI Technologies Inc.
OpenGL version: 3.3.10666 Compatibility Profile Context
OpenGL Shading Language version: 3.30

Graphic card is an ATI Radeon HD 4570.

Note: My fbo had only a depth texture attached. I tried to attach to it a depth rbo but results are identical.

Note2: All occlusion queries are generated from the global framebuffer. From what I know this should not be a problem.

EDIT: driver is 11.4. I don’t want to try to update my drivers for now (Linux AMD fear !).

That’s really strange.

Quick sanity check: are you using the same occlusion query objects in the two renderings?

I don’t use the same objects.

From what you said, I now know it should work. I’ll try to make deeper look at my code during this week-end: maybe there’s a bug somewhere in it. If not, I’ll try to make a simple test case and post it here.


So, some little news.

I upgrated my drivers to the latest pre-compiled versions providen by my distribution (11.8) and I have exactly the same results but the fact that the rendering is twice faster (??..) (out of topic but can’t understand why for the same application I had about 200 fps and now over 400 just with new driver and new kernel…)

So I will make a simple test example, try it, and if it doesn’t work, I’ll post it here.

So, it was a bug in my program. Strangely, if I have few objects, how I manage occlusion queries does not work well. I added few more objects in the scene and everything works well. Now I’ll try to find out why it gives such results with few objects…

Thanks for the time spent with this topic and sorry for the (again) mistake.