Re: [osg-users] OSX issue with the osgviewer class
Robert, thanks again.
Now it is clear what's happening and I try to work on forcing the frame rate
to 60 fps somehow.
Thanks again for helping me figuring out everything!
Davide
P.S.
I'm thinking about using a multithreaded approach, one thread for updating
the graphics, and one (or more) threads for the calculations (it's a physics
engine b.t.w.). Is there documentation or any good example of usage of
OpenThreads somewhere?
> Message: 18
> Date: Wed, 4 Feb 2009 09:55:45 +
> From: Robert Osfield
> Subject: Re: [osg-users] OSX issue with the osgviewer class
> To: OpenSceneGraph Users
> Message-ID:
><7ffb8e9b0902040155i599422d7q56c814501adf4...@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi Davide,
>
> The osgViewer will attempt by default to enable vysnc, but.. OpenGL
> drivers can override this. Go have a look at you OpenGL driver
> settings for vysnc.
>
> BTW, it's perfectly ordinary and correct to expect a difference
> between vsync on/off. For graphics development often you'll switch
> vsync off to get a feel for performance scaling, but for delivery of
> the application you almost always should enable vysnc as visual
> quality is far higher, and the compute system is more well balanced,
> and in terms of user interaction a frame rate higher than vsync is
> absolutely no use whatsoever.
>
> For my own work I almost always have vysnc on, only occasionally when
> I want to do some particular type of benchmarking do I disable vsync.
> When you have vsync on it's still possible to look at performance, for
> instance have a look at the on screen stats that the OSG provides -
> just run osgviewer on few different models and press 's' a couple of
> times to see the different types of stats available.
>
> You need to get over this present hurdle of understanding what is
> actually going on, once you have you'll know exactly why you are
> getting the results you are, and why there isn't anything at all to
> worry about, and finally you start looking at the real metrics that
> mean something.
>
> Robert.
>
> On Wed, Feb 4, 2009 at 9:35 AM, Davide Bacchet
> wrote:
> > Hello guys,
> > I finally get to my other windows laptop and run the testcase on that
> system
> > too.
> > Both compiled in release, using osg as a shared lib; the results:
> > WIN32:
> > *** test using GLUT ***
> > cpu time: 1641 milliseconds
> > effective time: 1.64645 seconds
> > average fps: 607.367
> > *** test using osgviewer class only ***
> > cpu time: 1656 milliseconds
> > effective time: 1.66006 seconds
> > average fps: 602.389
> > OSX:
> > *** test using GLUT ***
> > cpu time: 391.799 milliseconds
> > effective time: 2.70822 seconds
> > average fps: 369.246
> > *** test using osgviewer class only ***
> > cpu time: 943.835 milliseconds
> > effective time: 16.8232 seconds
> > average fps: 59.4417
> > beside the performance difference (I guess because of the integrated
> intel
> > graphics on my macbook), what I feel strange is that on win32 the
> osgviewer
> > class is not bound to the 60Hz refresh rate, and the performances are
> > consistent in GLUT/nonGLUT "mode" (607 vs 602 fps), while in OSX there is
> a
> > huge difference between the two (369 vs 60 fps).
> > Maybe this is already known, or it's simply a matter of better setting up
> > the application.
> > If the testcase is needed I can attach it (is it possible to this mailing
> > list?) or paste the source code the the email, it's a single file. Or you
> > can reproduce it using the standard "osgviewer" application distributed
> with
> > osg.
> > The calls I'm doing to create the viewer are basically:
> > osgViewer::Viewer* viewer = new osgViewer::Viewer();
> > viewer->setSceneData( myscenenode*** );
> > viewer->setCameraManipulator(new osgGA::TrackballManipulator);
> > viewer->addEventHandler(new osgViewer::StatsHandler);
> > viewer->realize();
> > while (true)
> > {
> > // update the viewer
> > viewer->frame();
> > (...)
> > }
> > thanks again!
> > Davide
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSX issue with the osgviewer class
Hi Davide,
The osgViewer will attempt by default to enable vysnc, but.. OpenGL
drivers can override this. Go have a look at you OpenGL driver
settings for vysnc.
BTW, it's perfectly ordinary and correct to expect a difference
between vsync on/off. For graphics development often you'll switch
vsync off to get a feel for performance scaling, but for delivery of
the application you almost always should enable vysnc as visual
quality is far higher, and the compute system is more well balanced,
and in terms of user interaction a frame rate higher than vsync is
absolutely no use whatsoever.
For my own work I almost always have vysnc on, only occasionally when
I want to do some particular type of benchmarking do I disable vsync.
When you have vsync on it's still possible to look at performance, for
instance have a look at the on screen stats that the OSG provides -
just run osgviewer on few different models and press 's' a couple of
times to see the different types of stats available.
You need to get over this present hurdle of understanding what is
actually going on, once you have you'll know exactly why you are
getting the results you are, and why there isn't anything at all to
worry about, and finally you start looking at the real metrics that
mean something.
Robert.
On Wed, Feb 4, 2009 at 9:35 AM, Davide Bacchet wrote:
> Hello guys,
> I finally get to my other windows laptop and run the testcase on that system
> too.
> Both compiled in release, using osg as a shared lib; the results:
> WIN32:
> *** test using GLUT ***
> cpu time: 1641 milliseconds
> effective time: 1.64645 seconds
> average fps: 607.367
> *** test using osgviewer class only ***
> cpu time: 1656 milliseconds
> effective time: 1.66006 seconds
> average fps: 602.389
> OSX:
> *** test using GLUT ***
> cpu time: 391.799 milliseconds
> effective time: 2.70822 seconds
> average fps: 369.246
> *** test using osgviewer class only ***
> cpu time: 943.835 milliseconds
> effective time: 16.8232 seconds
> average fps: 59.4417
> beside the performance difference (I guess because of the integrated intel
> graphics on my macbook), what I feel strange is that on win32 the osgviewer
> class is not bound to the 60Hz refresh rate, and the performances are
> consistent in GLUT/nonGLUT "mode" (607 vs 602 fps), while in OSX there is a
> huge difference between the two (369 vs 60 fps).
> Maybe this is already known, or it's simply a matter of better setting up
> the application.
> If the testcase is needed I can attach it (is it possible to this mailing
> list?) or paste the source code the the email, it's a single file. Or you
> can reproduce it using the standard "osgviewer" application distributed with
> osg.
> The calls I'm doing to create the viewer are basically:
> osgViewer::Viewer* viewer = new osgViewer::Viewer();
> viewer->setSceneData( myscenenode*** );
> viewer->setCameraManipulator(new osgGA::TrackballManipulator);
> viewer->addEventHandler(new osgViewer::StatsHandler);
> viewer->realize();
> while (true)
> {
> // update the viewer
> viewer->frame();
> (...)
> }
> thanks again!
> Davide
>
>>
>> Robert,
>> I set up a simple test, with only a rotating cube displayed with:
>> 1) osgviewer using GLUT
>> 2) osgviewer standalone class
>>
>> in both I used double-buffered 800x600 window.
>> I only tested on my mac yet, but tomorrow I will test on windows too.
>> The results are:
>> ** standalone **
>> cpu time: 1001.35 milliseconds
>> effective time: 16.796 seconds
>> average fps: 59.538
>> ** using glut **
>> cpu time: 458.949 milliseconds
>> effective time: 2.71029 seconds
>> average fps: 368.964
>>
>> I think that you were right and I was misinterpreting the results: it is
>> evident that the standalone osgviewer version is fixed on 60Hz, which is
>> my
>> laptop display refresh rate.
>> The glut version seems not to be bound to the display refresh but the
>> doublebuffering is enabled...
>> Probably there is something I still ignore just under the hood, on how the
>> refresh is handled.
>>
>> The same difference appears with the standard "osgviewer" and
>> "osgviewerGLUT" applications built with cmake (in both 2.4.0 and 2.6.0)
>>
>> Tomorrow I will try on windows, with the same code. For what I observed, I
>> expect to have a fps higher to 60Hz there, I will let you know.
>> Just in case, is it possible to attach the testcase to a message directed
>> to
>> the mailing list?
>>
>>
>> thanks!
>
>
> ___
> 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
Re: [osg-users] OSX issue with the osgviewer class
Hello guys,
I finally get to my other windows laptop and run the testcase on that system
too.
Both compiled in release, using osg as a shared lib; the results:
WIN32:
*** test using GLUT ***
cpu time: 1641 milliseconds
effective time: 1.64645 seconds
average fps: 607.367
*** test using osgviewer class only ***
cpu time: 1656 milliseconds
effective time: 1.66006 seconds
average fps: 602.389
OSX:
*** test using GLUT ***
cpu time: 391.799 milliseconds
effective time: 2.70822 seconds
average fps: 369.246
*** test using osgviewer class only ***
cpu time: 943.835 milliseconds
effective time: 16.8232 seconds
average fps: 59.4417
beside the performance difference (I guess because of the integrated intel
graphics on my macbook), what I feel strange is that on win32 the osgviewer
class is not bound to the 60Hz refresh rate, and the performances are
consistent in GLUT/nonGLUT "mode" (607 vs 602 fps), while in OSX there is a
huge difference between the two (369 vs 60 fps).
Maybe this is already known, or it's simply a matter of better setting up
the application.
If the testcase is needed I can attach it (is it possible to this mailing
list?) or paste the source code the the email, it's a single file. Or you
can reproduce it using the standard "osgviewer" application distributed with
osg.
The calls I'm doing to create the viewer are basically:
osgViewer::Viewer* viewer = new osgViewer::Viewer();
viewer->setSceneData( myscenenode*** );
viewer->setCameraManipulator(new osgGA::TrackballManipulator);
viewer->addEventHandler(new osgViewer::StatsHandler);
viewer->realize();
while (true)
{
// update the viewer
viewer->frame();
(...)
}
thanks again!
Davide
>
> Robert,
> I set up a simple test, with only a rotating cube displayed with:
> 1) osgviewer using GLUT
> 2) osgviewer standalone class
>
> in both I used double-buffered 800x600 window.
> I only tested on my mac yet, but tomorrow I will test on windows too.
> The results are:
> ** standalone **
> cpu time: 1001.35 milliseconds
> effective time: 16.796 seconds
> average fps: 59.538
> ** using glut **
> cpu time: 458.949 milliseconds
> effective time: 2.71029 seconds
> average fps: 368.964
>
> I think that you were right and I was misinterpreting the results: it is
> evident that the standalone osgviewer version is fixed on 60Hz, which is my
> laptop display refresh rate.
> The glut version seems not to be bound to the display refresh but the
> doublebuffering is enabled...
> Probably there is something I still ignore just under the hood, on how the
> refresh is handled.
>
> The same difference appears with the standard "osgviewer" and
> "osgviewerGLUT" applications built with cmake (in both 2.4.0 and 2.6.0)
>
> Tomorrow I will try on windows, with the same code. For what I observed, I
> expect to have a fps higher to 60Hz there, I will let you know.
> Just in case, is it possible to attach the testcase to a message directed
> to
> the mailing list?
>
>
> thanks!
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSX issue with the osgviewer class
Robert, I set up a simple test, with only a rotating cube displayed with: 1) osgviewer using GLUT 2) osgviewer standalone class in both I used double-buffered 800x600 window. I only tested on my mac yet, but tomorrow I will test on windows too. The results are: ** standalone ** cpu time: 1001.35 milliseconds effective time: 16.796 seconds average fps: 59.538 ** using glut ** cpu time: 458.949 milliseconds effective time: 2.71029 seconds average fps: 368.964 I think that you were right and I was misinterpreting the results: it is evident that the standalone osgviewer version is fixed on 60Hz, which is my laptop display refresh rate. The glut version seems not to be bound to the display refresh but the doublebuffering is enabled... Probably there is something I still ignore just under the hood, on how the refresh is handled. The same difference appears with the standard "osgviewer" and "osgviewerGLUT" applications built with cmake (in both 2.4.0 and 2.6.0) Tomorrow I will try on windows, with the same code. For what I observed, I expect to have a fps higher to 60Hz there, I will let you know. Just in case, is it possible to attach the testcase to a message directed to the mailing list? thanks! Message: 8 > Date: Tue, 3 Feb 2009 11:09:12 + > From: Robert Osfield > Subject: Re: [osg-users] OSX issue with the osgviewer class > To: OpenSceneGraph Users > Message-ID: ><7ffb8e9b0902030309g7ed6464cjca4962cb51186...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi Davide, > > On Tue, Feb 3, 2009 at 9:57 AM, Davide Bacchet > wrote: > > I compared a Macbook core2Duo 2GHz, intel graphics with a dell dimension > > laptop, pentium 4 2.0GHz and nvidia graphics. > > What it is feeling strange to me is that there is almost no difference in > > performances if I use GLUT (like in the "osgviewerGLUT" example) but a > huge > > difference if I use the plain osgviewer class (like in the "osgviewer" > > example) > > I'm setting up a very simple example to try to reproduce the problem with > a > > single file, I will post it tomorrow morning as soon as I can access a > > windows machine > > There "shouldn't" be a performance difference between osgviewerGLUT > and osgviewer like your seeing, rather if you see a performance > difference it should be that the standard viewer should be faster as > multi-threading should be use. For such a small difference it'd a > small difference, but it should be there. > > The fact that you aren't see a performance improvement, rather than > opposite suggets to me that the OpenGL driver/Carbon is not creating a > properly accelerated graphics context, and may well be dropping down > to software rendering. It shouldn't be doing this, but it's the only > thing I can think of that might explain this pattern. > > I've used quite a few macs over the years, including a brief look at > using a Mac mini that had Intel graphics and it worked OK with the > standard osgviewer. Fill rate was very poor, but it was still able to > do the cow.osg at 60Hz. None of my previous Mac experience has seen a > drop down to software rendering though. > > One test it would be worth doing is resizing the window to see if this > affects performance, if it does then this scream out that the graphics > context is being done on the CPU. > > BTW, do you see performance issues with osgviewer cow.osg? > > Robert. > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSX issue with the osgviewer class
Hi Davide, On Tue, Feb 3, 2009 at 9:57 AM, Davide Bacchet wrote: > I compared a Macbook core2Duo 2GHz, intel graphics with a dell dimension > laptop, pentium 4 2.0GHz and nvidia graphics. > What it is feeling strange to me is that there is almost no difference in > performances if I use GLUT (like in the "osgviewerGLUT" example) but a huge > difference if I use the plain osgviewer class (like in the "osgviewer" > example) > I'm setting up a very simple example to try to reproduce the problem with a > single file, I will post it tomorrow morning as soon as I can access a > windows machine There "shouldn't" be a performance difference between osgviewerGLUT and osgviewer like your seeing, rather if you see a performance difference it should be that the standard viewer should be faster as multi-threading should be use. For such a small difference it'd a small difference, but it should be there. The fact that you aren't see a performance improvement, rather than opposite suggets to me that the OpenGL driver/Carbon is not creating a properly accelerated graphics context, and may well be dropping down to software rendering. It shouldn't be doing this, but it's the only thing I can think of that might explain this pattern. I've used quite a few macs over the years, including a brief look at using a Mac mini that had Intel graphics and it worked OK with the standard osgviewer. Fill rate was very poor, but it was still able to do the cow.osg at 60Hz. None of my previous Mac experience has seen a drop down to software rendering though. One test it would be worth doing is resizing the window to see if this affects performance, if it does then this scream out that the graphics context is being done on the CPU. BTW, do you see performance issues with osgviewer cow.osg? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSX issue with the osgviewer class
Hi Ulrich, thanks for answering too :) Hi Davide, > > (...) > > That could be your problem right there... > especially when you're using lots of textures, shaders(!) and such. I think I'm doing something wrong or missing some important call while setting up the application. Or more probably misinterpreting the results. I was not using textures or shaders; the scene I was representing contains only 20 cubes and 20 spheres. > > What kind of setups are you comparing it against? I compared a Macbook core2Duo 2GHz, intel graphics with a dell dimension laptop, pentium 4 2.0GHz and nvidia graphics. What it is feeling strange to me is that there is almost no difference in performances if I use GLUT (like in the "osgviewerGLUT" example) but a huge difference if I use the plain osgviewer class (like in the "osgviewer" example) I'm setting up a very simple example to try to reproduce the problem with a single file, I will post it tomorrow morning as soon as I can access a windows machine Thanks!!Davide ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSX issue with the osgviewer class
Hi Davide, Quoting Davide Bacchet : > 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. >... > > > My laptop is a Macbook Core2Duo, with an integrated Intel graphics card. That could be your problem right there... especially when you're using lots of textures, shaders(!) and such. What kind of setups are you comparing it against? /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSX issue with the osgviewer class
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 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 >> 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
Re: [osg-users] OSX issue with the osgviewer class
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 > 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
Re: [osg-users] OSX issue with the osgviewer class
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 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
