So I tried to build my OSG using: With -D_OPENTHREADS_ATOMIC_USE_GCC_BUILTINS and that seemed to generate the include/OpenThreads/Config file with
#define _OPENTHREADS_ATOMIC_USE_GCC_BUILTINS but, then I got a linker undefined symbol error to the following functions: __sync_bool_compare_and_swap_4 __sync_add_and_fetch_4 __sync_sub_and_fetch_4 Any idea why this happened? Thanks. Alex -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Pecoraro, Alexander N Sent: Monday, February 09, 2009 3:41 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Cull time doubled? On my Linux box it was set to: _OPENTHREADS_ATOMIC_USE_MUTEX I'm going to see if switching to ATOMIC_USE_GCC_BUILTINS works better. On my Windows box it was set to: _OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED Is that the best choice for Windows? Alex -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Robert Osfield Sent: Monday, February 09, 2009 3:11 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Cull time doubled? Hi Alex, The cull is done pretty well the same between 1.x and 2.x so is very unlikely to be related to the difference. It could be that the database has been optimised differently in each case. Try switching off the Optimizer to see if this makes any difference. The next area to look at is the thread safe ref/unref that is now used by default, and should be using atomic ref counting. To see what is being use have a look at the file: include/OpenThreads/Config Mine looks like: /** Comments cut out... ... */ #ifndef _OPENTHREADS_CONFIG #define _OPENTHREADS_CONFIG #define _OPENTHREADS_ATOMIC_USE_GCC_BUILTINS /* #undef _OPENTHREADS_ATOMIC_USE_MIPOSPRO_BUILTINS */ /* #undef _OPENTHREADS_ATOMIC_USE_SUN */ /* #undef _OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED */ /* #undef _OPENTHREADS_ATOMIC_USE_BSD_ATOMIC */ /* #undef _OPENTHREADS_ATOMIC_USE_MUTEX */ /* #undef OT_LIBRARY_STATIC */ #endif Note that ATMOIC_USE_GCC_BUILTINS is used. What processor and OS type (32bit or 64bit) are you using? The long cull/draw/GPU times in draw thread per context suggest to me that the processor is being overly contended, as if CPU affinity isn't functioning well. If you only have a single core CPU then this will be the reason. Finally in all your mentioned cases the cull, draw and GPU times are all very long. I'd suspect that the scene graph might not be well balanced and could probably be done far more efficiently. Without knowing the database I wouldn't be able to say exactly what. Robert. On Mon, Feb 9, 2009 at 10:54 PM, Pecoraro, Alexander N <[email protected]> wrote: > I've gotten similar results for the osgviewer running on a Redhat > Enterprise 5 Linux desktop and a Window's XP laptop. I used an animation > path to make sure that I was looking at the database from the same > viewpoint when collecting statistics. > > Linux Stats: > 2.6.1 Draw Thread Per Ctx / 2.6.1 Single Threaded / 1.2 Single Threaded > Frame Rate: 16 / 11 / 15 > Cull Time: 42 / 34 / 16 > Draw Time: 62 / 55 / 49 > GPU Time: 62 / 55 / 48 > > Windows XP Stats (for this one I used OSG 2.8 rc1 because it has more > stats information so it allowed me to verify that the vertex and > primitive counts were the same for both versions of the viewer): > 2.8 Draw Thread Per Ctx / 2.8 Single Threaded / 1.2 Single Threaded > Frame Rate: 15 / 10 / 12 > Cull Time: 50 / 40 / 24 > Draw Time: 65 / 60 / 59 > GPU Time: 60 / 60 / 58 > > The biggest difference between the two versions of the viewer was always > the cull time, but on Linux the draw times were also fairly different > (and only slightly different on the Windows laptop). > >>> Is full compile optimization enabled? > > I just used the settings that were given to the Release build for the > Visual Studio project files and the Linux Makefiles. > > On Linux this translated to "-O3 -DNDEBUG" (at least that's what > cmake-gui says is defined for the CMAKE_CXX_FLAGS_RELEASE variable). > > On Viz Studio this translated to: > > Optimization: Maximize Speed > Inline Function Expansion: Any Suitable > Enable Intrinsic Functions: No > Favor Size or Speed: Neither > Omit Frame Pointers: No > Enable Fiber Safe Optimizations: No > Whole Program Optimization: No > >>> Is the atomic reference counting being compiled in correctly? > > How would I verify that atomic reference counting is compiled in > correctly? > > Is there something with how culling is done that has changed between OSG > 1.2 and OSG 2.6/2.8? > > Thanks. > > Alex > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Robert > Osfield > Sent: Friday, February 06, 2009 1:58 AM > To: OpenSceneGraph Users > Subject: Re: [osg-users] Cull time doubled? > > Hi Alex, > > There "shouldn't" be a performance drop if everything is compiled > correctly. What platform are you working on? Is full compile > optimization enabled? Is the atomic reference counting being compiled > in correctly? Could the CPU thread management causing problems? Try > out different threading models to see what happens. > > Robert. > > On Fri, Feb 6, 2009 at 12:28 AM, Pecoraro, Alexander N > <[email protected]> wrote: >> I've recently upgraded an old 3d viewer that was using OSG API version > 1.2 >> to version 2.6.1. Oddly enough some databases that I was using with > the old >> viewer actually perform worse with the new version of the API. For > some >> reason the cull time on these databases is 1.5 to 2 times higher on > version >> 2.6.1 than it was on version 1.2. The scene graph node structure is > exactly >> the same, but the culling time has increased. Why would that happen? > Has >> anyone else seen this? >> >> >> >> I can provide a small test case if anyone is interested in seeing what > I >> mean. >> >> >> >> Thanks. >> >> >> >> Alex >> >> _______________________________________________ >> 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.or g _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
