I'm quite interesting in getting my scenegraph more balanced scenegraph. I will take the time to think about it (and probably ask for help then).
Concerning the _OPENTHREADS_ATOMIC_USE_GCC_BUILTINS I didn't get how to generate the include/OpenThreads/Config file. Anyway, I don't get neither how it can come into play as I'm profiling with the SingleThreaded option and the results are too bad. regards, On Tue, Feb 10, 2009 at 5:32 PM, Robert Osfield <[email protected]>wrote: > Hi Simon, > > Like Alex I recommend that you have a look at whether your build is > using atomic ref counts. > > Second up, your explanation of your scene graphs suggest to me that is > very poorly balanced. You cull/draw times are all very long, even for > complex scenes I would expect cull and draw times 1/10th of these. > > Lots of PAT's all under a single Group node is really badly balanced - > you should try to create a quad tree structure as this improves cull > performance significantly as how subgraphs containing thousands of > nodes can be culled in a single op. Also see if you can use an design > that doesn't rely heavily of PAT's, as each transform in your scene > requires the view frustum to be transformed into the local coords of > the PAT, which is relative expensive operation. > > Robert. > > On Tue, Feb 10, 2009 at 8:50 AM, Simon Loic <[email protected]> wrote: > > I think I have a problem similar to Alex one. > > The stats I get follow : > > > > MultiThreaded/SingleThreaded > > Cull Time: 40/33 > > Draw Time: 55/52 > > GPU Time: 85/85 > > > > I also attached a callgrind output (you can use kcachegrind to analyse > it) > > where it seems that the osgUtil::SceneView::cull() costs 70% of > > osgViewer::Renderer::cull_draw() while osgUtil::SceneView::draw() counts > for > > only 30% !! However I'm not much aware with the way osgViewer works, yet > I > > find this result weird in comparison with the stats results. > > > > In my case I have a scene graph composed of many nodes (i don't think I > can > > post the .osg which is 16MB). The strucuture is not complex : I have a > > shadow scene as root with as child a group (the real root of the graph > some > > how). Then the root is connected to plenty of PositionAttitudeTransfoms > > having each one a child which is a geode. > > > > In fact the geode are quite complex polygonal meshes. So I would expect > that > > the draw part is more costly than the draw part. > > I hope this can help to see what is wrong for Alex and for me. > > > > > > On Tue, Feb 10, 2009 at 7:54 AM, J.P. Delport <[email protected]> > wrote: > >> > >> Hi, > >> > >> Mathias Fröhlich wrote: > >>> > >>> Hi, > >>> > >>> On Monday 09 February 2009 23:54, Pecoraro, Alexander N wrote: > >>>> > >>>> On Linux this translated to "-O3 -DNDEBUG" (at least that's what > >>>> cmake-gui says is defined for the CMAKE_CXX_FLAGS_RELEASE variable). > >>> > >>> May be I know cmake to little, but the only way to really make sure I > got > >>> cmake correct was to set CMAKE_VERBOSE_MAKEFILE=TRUE and see how the > build > >>> scripts really call the compiler. > >> > >> you can also run make <other options> VERBOSE=1 > >> on the normal cmake generated Makefile. > >> > >> jp > >> > >>> > >>> Robert, > >>> I know that it is a matter of taste if one sets this flag. But may be > it > >>> will help people to catch unoptimized builds due to the possible > >>> intransparency of cmakes compile flags handling. So should that be on > by > >>> default? > >>> > >>> Greetings > >>> > >>> Mathias > >>> > >> > >> -- > >> This message is subject to the CSIR's copyright terms and conditions, > >> e-mail legal notice, and implemented Open Document Format (ODF) > standard. > >> The full disclaimer details can be found at > >> http://www.csir.co.za/disclaimer.html. > >> > >> This message has been scanned for viruses and dangerous content by > >> MailScanner, and is believed to be clean. MailScanner thanks Transtec > >> Computers for their support. > >> > >> _______________________________________________ > >> 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 > > > > > _______________________________________________ > 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
