[osg-users] Retrieving occlusion query results prior to swap (was: RE: Need a post-swap traversal)
pmartz at skew-matrix.com
Mon Oct 22 10:25:32 PDT 2007
Hi Robert -- Digging up this post from way back - last May. Funding to
complete the occlusion query work is back online, and I wanted to revisit
this issue with you to discuss other possible solutions.
In summary, the current implementation of occlusion query has a single-frame
latency, in which the occlusion test is performed in the draw traversal, and
the results are retrieved and acted upon during the next frame's cull
traversal. The discussion below, between you and I, was exploring ways to
make this a bit cleaner, such as retrieving the results immediately
following the swap.
Before I start coding such a solution based on your advice below, I'd like
to explore a different approach that eliminates the 1-frame latency. I met
with OpenSG's Dirk Reiners at SIGGRAPH this year and discussed their
occlusion query implementation with him. He says they issue the queries
during the draw, but then before they swap, they iterate over all the
queries and ask OpenGL if the results are ready yet. If ready, they retrieve
the results, and if visible, draw the geometry. They repeat this until all
queries have been retrieved and acted upon, then finally issue the swap.
This eliminates any latency.
I'd like your thoughts on how to implement such a scheme in OSG. If I
understand correctly, a custom RenderStage, configured as the final
RenderStage to execute in the draw traversal, should be able to accomplish
this? If possible, I'd like to avoid creating a custom CullVisitor.
Any direction from you would be appreciated. I hope to get this work done
ASAP and submitted to you for inclusion in the OSG distribution.
Skew Matrix Software LLC
303 859 9466
> -----Original Message-----
> From: osg-users-bounces at openscenegraph.net
> [mailto:osg-users-bounces at openscenegraph.net] On Behalf Of
> Robert Osfield
> Sent: Sunday, May 20, 2007 4:01 AM
> To: osg users
> Subject: Re: [osg-users] Need a post-swap traversal
> Hi Paul,
> Adding a callback to Drawables to support post swap callback
> in the way you describe would be crappy for performance -
> we'd need to add an extra fine grained check to all
> Drawables, and Drawable ends up bloated by another pointer,
> all for something which is very very specialist.
> A post swap callback is a high level feature, just like a
> Camera post draw callback, this would be the level and
> granularity that it should be at. Checking for something
> once per frame is a low cost, and also just adding one extra
> pointer to one to objects is a again a low bloat option. One
> could possibly add hooks for such a callback into the
> rendering back end, so that a custom node could place a post
> swap callback in, this would allow you to avoid specifically
> adding callbacks into the viewer's cameras for a particular
> effect - perhaps something like a RenderStage post swap
> callback would fit the bill.
> In terms of implementation, the viewer codes will need to
> know about this feature, and need to call it. Its high
> levler than SceneView or any of the rendering backend as they
> all just deal with part of the whole frames rendering, they
> never manage the frames themselves let
> alone the swap. In osgViewer the actual swap callback would be an
> Operation added to the GraphicsContext's list of rendering operations.
> I'd like to see a bit finer grained control of this, but in
> the end in might we'd still want to hide this complexity for
> most users - what they want is to just add a node above their
> scene and have occlusion culling magically work.
> On 5/19/07, Paul Martz <pmartz at skew-matrix.com> wrote:
> > Hi Robert -- My occlusion query work is nearly complete, at
> least this
> > phase of it. In the course of development, I've discovered I need a
> > post-swap traversal in which the traversal thread still has
> the same
> > context current as was current in the draw traversal and swap.
> > Here's the background behind that need.
> > The naive way to use occlusion query is to issue a test,
> then retrieve
> > the results, then make a decision on whether to draw the
> geometry or
> > not based on those results, all in a single frame.
> Unfortunately, such
> > an implementation destroys any occlusion query performance gains by
> > causing a pipe flush to read back the query results.
> > The better approach, as recommended in GPU Gems and most OpenGL
> > vendors, is to issue occlusion query tests in one frame,
> swap buffers,
> > retrieve the results, then decide whether to draw the
> actual geometry
> > or not in the next frame (based on the previous frame's results). I
> > currently have this implemented in OSG by reading the
> results back in
> > the next frame's cull traversal. However, as I'm sure you're aware,
> > this fails in DrawThreadPerContext because the thread that executes
> > the cull traversal doesn't have a current rendering
> context. It works
> > in the other threading models, though, and it works for
> Producer and
> > SceneView based apps, so it's a good first step.
> > To really solve the problem, however, I'd like to read the results
> > immediately after the swap, in the same thread that just
> executed the
> > draw traversal and the swap. One way for me to do this is to attach
> > postSwap callbacks to the ancestor Camera node, but this
> seems kind of
> > clumsy and inefficient.
> > Instead, I'd prefer a post swap traversal executed by the
> draw/swap thread.
> > Drawables would need to support a setPostSwapCallback method. The
> > traversal wouldn't need to execute if the Drawables in the
> > all lacked callbacks, so this traversal would have zero
> cost in most
> > cases. But in the case of occlusion query, it'd allow my occlusion
> > query Drawables to retrieve their results and use them in the next
> > frame, even for the DrawThreadPerContext threading model. osgViewer
> > would need to be modified to execute the traversal.
> > I'd be glad to do this work but wanted to have an open discussion
> > about it on this list. This would be a post-2.0 feature.
> > Paul Martz
> > Skew Matrix Software LLC
> > http://www.skew-matrix.com
> > 303 859 9466
> > _______________________________________________
> > osg-users mailing list
> > osg-users at openscenegraph.net
> > http://openscenegraph.net/mailman/listinfo/osg-users
> > http://www.openscenegraph.org/
> osg-users mailing list
> osg-users at openscenegraph.net
More information about the osg-users