[osg-users] Retrieving occlusion query results prior to swap (was: RE: Need a post-swap traversal)

Robert Osfield robert.osfield at gmail.com
Mon Oct 22 10:57:33 PDT 2007


Hi Paul,

The approach Dirk suggest sounds a bit like differed rendering
occlusion extension (I'm afraid I can't recall the name of this recent
extension off hand), but done at the rendering dispatch level rather
than lower level OpenGL.

The high level approach does suffer from a round trip to the graphics
card - you still have to wait till all the queries are returned before
you can dispatch the last bit of data into the OpenGL fifo.  Claiming
this eliminates the latency is rather stretching things, it hides it a
bit, bit only a bit, you are still stalling the CPU till the GPU is
done so parallelism between the CPU and the GPU is heavily
compromised.

Personally I'd rather taking the hit and doing everything in one frame
rather than having a frame overlap and then having to come up with
clever frame coherency tricks to ensure that you don't get false
negatives in the next frame.  There are certain models types that are
already breaking frame by a long way - i.e. hitting 10fps, so for
these a round trip to the GPU is relatively low compared to the
potential gain of culling geometry and state from the draw dispatch,
for these occlusion culling in frame will be a godsend.

As for mods the rendering backend, I'd suggest some sort RenderLeaf
extension that allows leaves to be switched off, and during draw
traversal the switched off leaves are ignored.  The toggling code be
done be the pre RenderStage you set up to do the occlusion query.

Robert.

On 10/22/07, Paul Martz <pmartz at skew-matrix.com> wrote:
> 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.
>
> Thanks,
>
> Paul Martz
> Skew Matrix Software LLC
> http://www.skew-matrix.com
> 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.
> >
> > Robert.
> >
> >
> > 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
> > RenderGraph
> > > 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
> > http://openscenegraph.net/mailman/listinfo/osg-users
> > http://www.openscenegraph.org/
>
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



More information about the osg-users mailing list