I too find some interesting issues with this thread. :)
Robert,
This proposal you mention for 2.6 will it help balance the cpu workload
against the gpu I/O bottleneck?
I've been doing some osg performance benchmark research on thread
synchronization using the Intel Threaded compiler, and so far the results
are looking really good except for a 26% over-utilization due to
sleeping. I do want to say awesome job to those responsible for
threading, the amount of critical section use looked very good! All the
worker threads also had good profiling results. The ultimate test I want
to try today deals with an intentional GPU bottleneck... where I have a
quadcore that pipes graphics out a PCI graphics card. If anyone is
interested I'll post these test results. I know now that using a quad
core there is lack of parallelization (e.g. 25% 85% 15% 15%), but that is
a different battle for a different time.
I do want to get to the bottom of the profiling and determine how well
the workload is balanced against the gpu i/o, and see if there is some
opportunity for optimization here.
----- Original Message -----
*From:* Robert Osfield <mailto:[EMAIL PROTECTED]>
*To:* OpenSceneGraph Users
<mailto:[email protected]>
*Sent:* Thursday, June 26, 2008 7:06 AM
*Subject:* Re: [osg-users] multi threaded with slave camera and fbo
Hi Guys,
I've just skimmed through this thread. Interesting issues :-)
Wojtek explanations of the double buffered SceneView is spot on, in
this case leading to two FBO's, Creation of two FBO's for RTT is
something I've been aware of since the inception of the
DrawThreadPerContext/CullThreadPerCameraDrawThreadPerContext, but as
yet haven't had the opportunity to refactor the code to avoid it.
The problem actually stems from the reuse of SceneView to do
something
that it was never intended to handle, and in terms of osgViewer
implementation SceneView was used simply because it was the line of
least resistance i.e. it worked and code be adapted to help speed up
the implementation of osgViewer, and mostly it's actually worked out
ok, the stop gap has worked out pretty well.
However, it has always been my plan to rewrite the
osgViewer::Renderer
so that it doesn't use SceneView at all, let alone double buffering
them, instead it's my plan to use a single CullVisitor which
alternately populates double buffered RenderStage. This approach
would be far leaner and less obfusticated, and we should be able to
clean up some of the artefacts as well. The downside is by not
using
SceneView we'll loose all the stereo rendering support, so instead
we'll need to refactor osgViewer so that stereo rendering is done at
the viewer level i.e. using slave cameras - this means more coding
work, but the actually end result would be far better both design
wise
as well as in flexibility and performance.
I just need to time to go off and do this work, I might be able to
get
it done for 2.6, but spare time certainly isn't something that I'm
blessed with right now.
Robert.
_______________________________________________
osg-users mailing list
[email protected]
<mailto:[email protected]>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
------------------------------------------------------------------------
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
