Your mails are black so i need to select the test to read it. Anyway i
am interested by all result you have. If you can post them
Cedric
James Killian wrote:
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
--
+33 (0) 6 63 20 03 56 Cedric Pinson mailto:[EMAIL PROTECTED]
http://www.plopbyte.net
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
