Hi Davide, You don't need to dig deep into the internals of the OSG. The differences are likely high level, non OSG specific.
Could please start by specifying how you are doing your tests, what framerates your are getting on each platform, what specific value is making your conclude the performance differences? What types of models and applications are you seeing the difference? What is your hardware setup in Windows + OSX? Robert. On Mon, Feb 2, 2009 at 4:00 PM, Davide Bacchet <davide.bacc...@gmail.com> wrote: > Hi Robert, > thanks for the quick answer. > What I feel strange is the different behavior that the standard osgviewer > class has on OSX and Win32. I mean, if the reason is the vsync, in win32 it > is ignored or handled differently (maybe by the graphics board driver or by > the OS itself). The main consequence is that the same application runs 15-20 > times slower on OSX, and I cannot use the same code across the platforms. > If I check the osgviewerGLUT example, the behavior looks almost identical in > both osx and win32. > Is there a way to disable the vsync check in a "plain" osgviewer > application? > I'm sorry if I'm asking stupid questions, I'm not so deep into the OSG > architecture yet... :) > thanks again, > Davide > (I reposted this mail using the correct subject, sorry....) >> >> HI Davide, >> >> In what way is this a problem? It's quite normal for a viewer to wait >> on barriers, as when you have vsync on the graphics thread will be >> gated by the refresh of the monitor, with the OpenGL driver just >> putting the calling thread to sleep while it waits for the next frame. >> If you switch off vysnc you'll find much high CPU utilization as you >> then see the frame loop throwing many for frames of data quickly at >> the OpenGL fifo. >> >> Robert. >> >> On Mon, Feb 2, 2009 at 1:42 PM, Davide Bacchet <davide.bacc...@gmail.com> >> wrote: >> > Hi to everybody, >> > >> > I'm having a problem under OSX with the osgviewer implementation. >> > The application is using only 5 to 10% of the processor power, because >> > the >> > most part of the time it is waiting on a mutex inside the >> > osgViewer::ViewerBase::renderingTraversals() call. >> > >> > Exactly the same code (I'm creating a multi-platform application) under >> > windows works like a charm; I can't try under linux. >> > >> > My laptop is a Macbook Core2Duo, with an integrated Intel graphics card. >> > Actually I'm using osg 2.4.0, but I tried with the version 2.6.0 too and >> > there is the same problem. >> > >> > Attached the call graph, with the number of milliseconds spent on each >> > function call (out of a total time of 3 sec). >> > As you can see, the renderingTraversal call performs 2 sub-calls: >> > OpenThreads::Condition::wait(...) and osgViewer::Renderer::cull(), but >> > it >> > waits for a huge amount of time (more than 95%). >> > >> > Call graph: >> > 2091 Thread_2503 >> > 2091 start >> > 2091 main >> > 2091 simpleGraphicsLoop() >> > 2089 graphics::GraphicsManager::update() >> > 2075 osgViewer::ViewerBase::renderingTraversals() >> > 2049 OpenThreads::Condition::wait(OpenThreads::Mutex*) >> > 2049 pthread_cond_wait >> > 2049 _pthread_cond_wait >> > 2041 semaphore_wait_signal_trap >> > 2041 semaphore_wait_signal_trap >> > 8 _pthread_cond_wait >> > 24 osgViewer::Renderer::cull() >> > 17 osgUtil::SceneView::cull() >> > >> > It's easy to reproduce the "problem" with the standard "osgviewer" >> > example >> > distributed with the library. >> > Does somebody encountered the same problem and, hopefully, solved it in >> > some >> > way? or there is some workarounds? or maybe I'm making some stupid >> > mistake... >> > >> > Thanks! >> > Davide Bacchet > > _______________________________________________ > 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
