Oops!!!

In the below, "It simply uses Performer." should have read "It simply uses
Producer."

Performer is not involved with this problem in any way. 8^)

John


On Fri, 17 Dec 2010, John Kelso wrote:

Hi Robert,

Based on your question I went back and did some grepping through the DGL
codebase and I see that DGL does NOT use SceneView or any other OSG code.
It simply uses Performer.  I was mistaken when I said earlier than DGL uses
SceneView.

There is an OSG layer that can be used with DGL to allow OSG programs to work
with DGL, and it is this layer that uses SceneView.  It does not use the
OSG Viewer or Camera classes.

This might be helpful: While a non-OSG DGL program does not show the
slowdown when using multiple displays, an OSG program using DGL DOES show a
slowdown similar to what we see with the pure OSG program.

To summarize:

1) DGL, all OpenGL no OSG used, uses only Producer, no slowdown

2) DGL with OSG, uses SceneView and Producer (no Viewers or Cameras),
   slowdown observed

3) pure OSG, uses Viewers, Cameras (and eventually SceneView if I read the
   OSG code correctly), slowdown observed

I apologize that my original posting was incorrect, and I hope it didn't
cause anyone to go down the wrong rabbit hole.

Thanks,

John


On Fri, 17 Dec 2010, Robert Osfield wrote:

Hi John, Steve, et. al,

On Tue, Dec 14, 2010 at 7:32 PM, John Kelso <ke...@nist.gov> wrote:
DGL has its own threading and draw code.  It uses OpenThreads
for threading. The OpenGL calls generated by draw() are sent to the
defined windows using OSG's SceneView class and Producer.  So, it's
not completely OSG-free, but as its threading works, perhaps this
indicates that the OSG problem is not in SceneView.

I'm I reading this correctly.  You are using Producer and SceneView,
and only a custom OpenGL call to the rendering?

I wouldn't expect any performance issues due to straight OpenGL
dispatch or SceneView, the scene graphs job is make sure there aren't
issues, and will typically far out perform a naive OpenGL program.

Most likely culprit would be at the high level - creating graphics
windows and synchronization of the threads and swap buffers.  This
would lead me to ask question could the difference be Producer vs
osgViewer?

Both are pretty similar in window setup and threading when running
CullDrawThreadPerContext is very similar to that of Producer's
multi-thread approach.  Events are handled a little differently, but
this won't be a factor for performance.  The only real difference I
can recall is that the osgViewer uses a barrier at the end of dispatch
and before the call swap buffers, while Producer just dispatches swap
buffers independently and then joins a barrier afterwards.  Is there
any chance that this is the issue? I'd be easy to move the barrier.

Unfortunately I've got my head down looking at paging issues right now
so can't head off to start testing multi-card setup.

Robert.
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Reply via email to