Hi Tugkan, On 2/2/07, Tugkan Calapoglu <[EMAIL PROTECTED]> wrote:
> A small program that I wrote myself. I attached to the email.
Thanks, shame it came though inline. Are you using mozilla's mail tool by any chance? It automatically inlines text files, which makes it at best awkward for extracting the oringnal sources.
But why is there a performance difference between osgproducerviewer and osgviewer when other threading modes are used? Do you observe such a difference?
For your single window setup (I presume osgproducerviewer comes up on the single display) osgproducerviewer will be using SingleThreaded model. This will corresponds to osgViewer's SingleThreaded model. Producer's ThreadPerCamera will correspond to the way that osgViewer's ThreadPerContent works in that cull and draw will be both drawn in the same thread. In the case of Producer the Camera "is a" thread. In the osgViewer case the GraphicsContext "has a" thread. When there is one camera per graphics context then the two will effecitvely be one of the same. There will be little differences in the way the threads are set up but in principle its very similar. One thing to note is that if you have more than one Producer::Camera per RenderSurface (graphics window/context) it drops down to SingleThreaded for the whole app. osgViewer in the case of multiple cameras per graphics context will retain the ThreadPerContext, so if you have multiple windows then these will run multi-threaded, but the multiple cameras on a single window will run with a single graphics thread running all the cameras. osgViewer's ThreadPerCamera is quite different than Producer's ThreadPerCamera, as the camera threads are in addition to the graphics threads, and these camera threads just run the cull traversals. osgViewer's ThreadPerCamera also allows the cull of one frame to overlap the draw of the previous frame, which is where the potential peformance comes from. Its worth noting its most efficient to drive a single OpenGL graphics context from a single thread, which is why I've opted for the concept of osg::GraphicsContext having a single osg::GraphicsThread.
Monday I'll look into it again and make a more formal test using the paths to be sure that camera is in the same position. What threading model should I choose to make a fair comparison between osgproducerviewer and osgviewer?
SingleThreaded on your system as it stands, osgproducerviewer will default to this SingleThreaded so you might as well set osgviewer to it as well. If you have multiple graphics cards/windows open then osgproducerviewer should open a separate window on each screen, just as osgviewer should do, they should behave the same. If there are differences this something we need to look into. When opening up multiple windows osgproducerviewer will assume its default ThreadPerCamera, which will approximately match osgviewer's default ThreadPerContext. One thing to be careful about is that the averging done in osgProducer::Viewer's stats isn't collected and done in an identical way to that osgViewer, The later should be more slightly more accurate. The stats also have a different hit on performance between the two viewers - the osgViewer ones having a greater hit due to having more data displayed. The most accurate way to compare the viewers is with on screen stats off, and to use a animation path and let the app just loop round it. The time/no frames for loop is reported to the console. To do this simple record the path osgproducerviewer and then run: osgviewer mymodel.ive -p mypath.path Then once the app is running press space bar to reset the animation right to the start so that it has a clean loop to do the benchmarking with. Robert. _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
