Hi Alex, You should indeed just do updates in the update traversal unless you've specifically handling the buffering in case of viewers with multiple cameras running. You shouldn't need to put in mutexes in osgText, all you should need to do is set the DataVariance to DYNAMIC. Making sure all dynamically update StateSet and Drawables (ilke osgText::Text) have their DataVariance set to DYNAMIC tells the rendering threads when it's safe to let the next frame advance.
Robert. On Thu, Feb 12, 2009 at 6:57 PM, Pecoraro, Alexander N <alexander.n.pecor...@lmco.com> wrote: > To get my viewer to work in multithread mode I had to make sure that all > updates to the scene graph were happening in an update callback. I also had > to set all my osgText objects to use draw callbacks and put mutexes on the > string's that were being updated to prevent simultaneous access by both the > update callback thread and the render thread. > > > > Alex > > > > > > ________________________________ > > From: osg-users-boun...@lists.openscenegraph.org > [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Simon Loic > Sent: Thursday, February 12, 2009 3:57 AM > To: OpenSceneGraph Users > Subject: Re: [osg-users] Cull time doubled? > > > > 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 <robert.osfi...@gmail.com> > 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 > > <alexander.n.pecor...@lmco.com> 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: osg-users-boun...@lists.openscenegraph.org >> [mailto:osg-users-boun...@lists.openscenegraph.org] 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 >> <alexander.n.pecor...@lmco.com> 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: osg-users-boun...@lists.openscenegraph.org >>> [mailto:osg-users-boun...@lists.openscenegraph.org] 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 <jd...@ist.ucf.edu> 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 >>> osg-users@lists.openscenegraph.org >>> >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or >>> g >>> _______________________________________________ >>> osg-users mailing list >>> osg-users@lists.openscenegraph.org >>> >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or >> g >>> >> _______________________________________________ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or >> g >> _______________________________________________ >> 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 > > > -- > Loïc Simon > > _______________________________________________ > 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
