Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Hardware Occlusion Queries


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 ill   Members   -  Reputation: 320

Like
0Likes
Like

Posted 28 May 2012 - 03:39 PM

So I've been reading up on occlusion queries and I'm seeing a lot of warnings about making best use of them and avoiding a stall. So what exactly is a good number of queries to use simultaneosly? Does it depend on the hardware?

Is there a bad performance penalty for constantly calling glGenQueries pretty much every frame? Is it good to try to keep a constant or maybe even a growing pool instead?

Here's kindof a short description of what I'm doing in case it helps.

I'm working on trying out an algorithm for my masters that does a first pass of rendering simplified geometry for big occluders and the 3D grid scene cells in the same frame before rendering the actual scene.

I will then do the normally recommended frame late rendering of actual objects since the first frame will only render the bounding boxes of objects like in this article http://http.develope...ugems_ch29.html, and then in the next frame I would truly render the objects if they passed the bounding box test in the last frame.

Edited by ill, 28 May 2012 - 03:47 PM.


Sponsor:

#2 Ashaman73   Crossbones+   -  Reputation: 7837

Like
0Likes
Like

Posted 28 May 2012 - 11:59 PM

The problems with queries is, that whenever you want to check the result, the command queue must be already processed up to the query command. When this has not been occurred yet, the API will wait until this occurrs (=stall). The number of queries doesn't really matter, the problem is when will you access the result.

#3 ill   Members   -  Reputation: 320

Like
0Likes
Like

Posted 29 May 2012 - 12:17 AM

Is there a way to force the command queue to flush? Is there some number of commands that it needs before it flushes?

Once nice thing about my engine is it's multicore, so if there's a stall, my engine might still be doing other useful things.

#4 Ashaman73   Crossbones+   -  Reputation: 7837

Like
1Likes
Like

Posted 29 May 2012 - 12:27 AM

Is there a way to force the command queue to flush?

Yes, glFlush/glFinish. But this is the best way to kill your performance. When you want to do queries to improve performance, you must be extremely cautious, else you ruine it.

Once nice thing about my engine is it's multicore, so if there's a stall, my engine might still be doing other useful things.

My engine supports multiple cores too, but the GPU is always the bottleneck for me.

Edited by Ashaman73, 29 May 2012 - 12:29 AM.


#5 mhagain   Crossbones+   -  Reputation: 8141

Like
0Likes
Like

Posted 29 May 2012 - 12:27 AM

glFinish will force the buffer to flush, but you're not really going to be getting much benefit from a multithreaded engine here as this will ultimately happen on your GPU - CPU-side stuff is not really relevant.

The common trick is to exploit a little temporal coherence (i.e. assume that things don't really change too much from frame-to-frame) and read back each frame's results in the frame after. That generally works well enough and avoids the stall.

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS