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 To: OpenSceneGraph Users 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 osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
