Hi Brian, The current stereo support in the OSG is provided by the osgUtil::SceneView class, this is an old class that have survived through todo because it's still be useful for managing low level rendering, it is set for eventually replacement though. SceneView being old and quite primitive doesn't know about threading or multiple contexts so in itself it can't do stereo multi-thread or with multiple contexts.
The osgViewer library which is a much higher level of abstraction is much more modern and is capable of multi-threading and multi-context rendering, but right now at the low level it still defers to SceneView to do the rendering and stereo if you use the OSG standard stereo support. However, if manage stereo yourself you aren't limited to restrictions of SceneView w.r.t threading for stereo if you do your own stereo setup at the high level - using two slave Camera in a osgViewer::Viewer is the prefect way to do this, it's slightly more setup but it still should be quite straight forward. There is a gotcha though... most stereo is done with a single graphics context, and you can only efficiently drive a single graphics context from a single thread, so OpenGL/hardware limitations themselves may well limit you to use a single thread for rendering. Potentially you can use CullThreadPerCamerDrawThreadPerContext threading model which would run the cull threads in parallel, but the draw will still be single threaded. The OSG's default threading model of DrawThreadPerContext also enables multi-threading by allow the draw threading to dispatch static objects whilst the next frame gets under way. The fact that OSG already will likely be doing DrawThreadPerContext rather diminishes the potential of CullThreadPerCameraDrawThreadPerContext to make much difference. If you are able to do stereo with two graphics cards, two contexts and two screens then threading does a better possibility as the OSG can naturally run this configuration multi-threaded and it should scale very well. This is a very specific stereo setup though - so as driver two passive stereo projectors. You haven't said anything about the type of stereo you intend so I can't really say whether this is possible at your end. So... all in all it's likely that you won't have much opportunity to make things more parallel that then probably already are, unless you have a specific hardware setup. However, multi-threading isn't the only area of optimization you can do, so I'd suggest you look very strongly at why your app is currently so CPU limited. Robert. On Sat, Sep 11, 2010 at 3:36 PM, Brian Tomko <brianto...@gmail.com> wrote: > Hi, > I have a 1 camera 1 viewport OSG app that uses close to 50% of the CPU. > When I enable stereo (anaglyph/quad buffered), CPU utilization nearly > doubles. Is there a way to split the left and right eye frame rendering into > separate threads so that I can take advantage of mulitcore? I am using osg > 2.8.3 on windows. > > ... > > Thank you > > Brian > > ------------------ > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=31539#31539 > > > > > > _______________________________________________ > 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
