Oh and btw for comparison sake - the numbers in the previous email were from after I got atomic reference counting working. Before I got it working I had these numbers:
Frame Rate/Update/Cull/Draw/GPU: 26/1/31/38/25 So it did make a difference to get atomic ref/unref working. Alex -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Pecoraro, Alexander N Sent: Wednesday, February 11, 2009 4:18 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Cull time doubled? Hi again, >> Might I suggest you examine the actual frame rates you get once again now that the atomic ref counts are in place. Here are some performance metrics that I get when running with atomic reference counting in OSG 2.6 (these don't correspond to the numbers in my previous email, which were from osgviewer, whereas these numbers come from my OSG based application, which is doing a little more work than osgviewer during the update stage - the scene graph is the same as before, but the viewpoint is different): OSG 2.6 Frame Rate/Update/Cull/Draw/GPU: 29/1/21/34/25 OSG 1.2 Frame Rate/Update/Cull/Draw/GPU: 27/1/ 9/27/25 I can get a faster frame rate in 2.6 because the frame rate is tied to the draw time only (due to DrawThreadPerContext functionality), whereas in 1.2 the cull and draw time are the biggest contributors to the frame rate. If I could somehow get my 2.6 draw time to be the same as the 1.2 draw time then I could get my frame rate up to 36 - 37. >> One does need to make sure that your scene graph is set up with STATIC + DYNAMIC DataVariance correctly to allow the frames to overlap the most without endangering thread safety. I was actually wondering about this. Is the fact that my cull and draw times improve to 16 and 31 when I run single threaded in 2.6 possibly indicative of my data variance settings preventing me from obtaining optimal frame overlap? Is the basic rule for setting the data variance on a node is if any of the values on the Node is going to change at any time during runtime then it should be set to DYNAMIC? Thanks. Alex -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Robert Osfield Sent: Wednesday, February 11, 2009 12:53 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Cull time doubled? Hi Alex, Good to hear that the settings worked in getting your build working with atomic ref counts. W.r.t performance, even atmoic ref counting is faster than using no thread safety on ref counts, and no ref counting is faster than thread unsafe ref counting. Once difference between OSG 1.x and 2.x is that 2.x provides extra threading models, including ones that overlap the draw with the update + cull traversals of the next frame. One of consequences of this threading is that the rendering back end has to use thread safe ref counting, so you while you gain performance from the better threading model, you loose a little from the extra cost of the ref counting. Even in your own tests the actual frame rate was shown to be the same or higher when using the new threading model than in 1.2, even though your cull and draw were way more expensive due to the lack of atomic ref counts. Might I suggest you examine the actual frame rates you get once again now that the atomic ref counts are in place. A lot has been written about the various threading models in 2.x over the last two years so have a look through the osg-users archives and search for items like DrawThreadPerContext, CullThreadPerCameraDrawTheadPerContext. FYI, Most of my models I get better performance, often significantly better when using the new threading models, one does need to make sure that your scene graph is set up with STATIC + DYNAMIC DataVariance correctly to allow the frames to overlap the most without endangering thread safety. Robert. On Wed, Feb 11, 2009 at 1:03 AM, Pecoraro, Alexander N <[email protected]> wrote: > I followed the instructions in the previous email and I was able to get > the 2.6.1 API to build with atomic ref counting on my Enterprise Redhat > box. This change caused a 33% improvement in my culling time and an 8% > improvement in my draw time when in cull thread per context mode. In > single threaded mode it made a similar amount of improvement in both > cull and draw. > > This improvement is definitely nice so thanks for the help, but I am > still confused as to how the 1.2 API is still able to perform about %12 > - %15 better than 2.6.1 even with atomic ref counting used. Although, I > will say that I only see this on certain databases - I have another > OpenFlight database that essentially gets the same level of performance > on both versions of the API. > > Has anyone else noticed a difference in performance between 1.2 and 2.6 > on any of their old databases? > > Are there other settings (build or runtime) that I can use to improve > performance? > > Are there different default settings or perhaps increased error catching > that was added in 2.X that could account for the difference that I am > seeing? > > Thanks. > > Alex > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Robert > Osfield > Sent: Tuesday, February 10, 2009 10:35 AM > To: OpenSceneGraph Users > Subject: Re: [osg-users] Cull time doubled? > > On Tue, Feb 10, 2009 at 4:39 PM, Jason Daly <[email protected]> wrote: >> On RHEL 5, you have to *explicitly* set CXXFLAGS to "-march=i486" or > higher >> *before* running CMake. For some reason, the default configuration > will >> evaluate to using mutexes, even if your CPU supports the GCC builtins. > > In long hand I think Jason is suggesting something like: > > > // remove the previous CMakeCache.txt to force a full reconfigure > rm CMakeCache.txt > > // set the CXXFLAGS to tell cmake that you plan to use a specific > architecture > export CXXFLAGS="-march=i686" > > // call the ./configure script or run cmake . > -DCMAKE_BUILD_TYPE=Release that it's equivalent to > ./configure > > // then run the parallel build to use all those loverly cores that > modern machines have :-) > make -j 4 > > > Could you let us know how you get on with this recipe. > > Robert. > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or > g > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
