Hi all, I hope I'm not hijacking too much this thread. I just wanted the same kind of behaviour as Alex hoping it could help so let me know if I should start a new thread.
Robert, I checked for the Atomic Build and I got the same include/OpenThreads/Config as yours. Meanwhile when a switch the Threading model (pressing m) I don't see any notable improvement. I also tried to optimize my scene graph using the osgUtil::Optimizer with different options. An I don' t get neither an improvement. I tryed the following options : -- osgUtil::Optimizer::FLATTEN_STATIC_TRANSFORMS_DUPLICATING_SHARED_SUBGRAPHS (to rule the problem of PAT you mentionned previously) -- osgUtil::Optimizer::STATIC_OBJECT_DETECTION -- osgUtil::Optimizer::SPATIALIZE_GROUPS ( to get an octree structure) -- osgUtil::Optimizer::SHARE_DUPLICATE_STATE (to handle duplicated statesets) -- osgUtil::Optimizer::COPY_SHARED_NODES Here are my stats. Tell me if you think they are not normal considering that my CG is not a brand new one but a NVidia Quadro Fx 550 and the complexity of the 3D scene. Frame Rate : 8.5 Threading model: SingleThreaded Event/Update/Cull/Draw/GPU:0.1/0.06/30/23/115 Vertices: 4.5M Drawable:1382 Matrices:1382 triangle strips: 2.5M polygons: 3k This are thes stats I get in my own osg app. Note that the Threadingmodel is SingleThreaded because so far I get a segmentation fault when switching it in this app. But this is not the case in osgViewer. Here are the stats for the same model in osgviewer: Frame Rate : 7.5 Threading model: DrawThreadPerContext Event/Update/Cull/Draw/GPU:0.1/0.06/42/86/117 Vertices: 4.5M Drawable:1382 Matrices:1382 triangle strips: 2.5M polygons: 3k By the way I've also tried using small feature culling. I know it's enabled by default but there is a parameter which I don'tknow the default value : SmallFeatureCullingPixelSize. What would be a reasonable value for it. On Thu, Feb 12, 2009 at 10:25 AM, Robert Osfield <[email protected]>wrote: > Hi Alex, > > You would be best served in your investigation by attaching the > osgViewer::StatsHandler to your viewer. See the osgviewer.cpp example > code to see how. This event handler will give you some pretty useful > on screen stats. > > With the DrawThreadPerContext threading model what you should get is > the update + cull overlapping with the previous draw dispatch/gpu. > What I have see is that if the processor is overly contended then the > the cull and draw times go down. Processor affinity is set by > osgViewer which should avoid this contention. > > The other thing to look at is the DataVariance, in 2.x it's by default > using a value UNSPECIFIED, which means you haven't set it yet. For > your StateSet and Drawables you make sure that if they don't contain > any dynamic data that they are set to STATIC, and if they contain > dynamic data make sure it's set to DYNAMIC. The more STATIC you have > the more the frames will be able to overlap. The Optimizer has a > visitor that can help set the DataVaraince to either STATIC or > DYNAMIC, but will only override it if the value is currently > UNSPECIFIED. > > Robert. > > On Thu, Feb 12, 2009 at 12:17 AM, Pecoraro, Alexander N > <[email protected]> wrote: > > 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.org > > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- Loïc Simon
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
