What version of Linux/GCC/processor that supports the built-in atomic functions?
Thanks. Alex -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Pecoraro, Alexander N Sent: Monday, February 09, 2009 5:19 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Cull time doubled? >> It could be that the database has been optimised differently in each case. The frame rates and times from first email were from an unoptimized scene graph (i.e. I set the OSG_OPTIMIZER env var to OFF). >> What processor and OS type (32bit or 64bit) are you using? On the Enterprise Redhat Linux computer I have 4 64 bit dual core Xeon 3Ghz processors. On my Windows XP computer I have an Intel 64 bit Core2 DUO 2Ghz CPU. BTW, I found in the GCC documentation that if the gcc linker reports an undefined reference to __sync_add_and_fetch_4 then that means the built-in atomic functions are not supported on your processor. So my Linux computer must not support atomic built in functions, but that means that both the 1.2 version of the API and the 2.6 version of the API are not using the built-in atomic functions, but still exhibiting large differences in cull time. >> I'd suspect that the scene graph might not be well balanced and could probably be done far more efficiently. I'd suspect that you are probably right, but I would expect that the amount of inefficiency would be the same in both versions of the API. 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
