hybr wrote:
Hi, Gianni Ambrosio
It can be the case that in old drivers vsync were disabled, and in new ones
its enabled by default.
OK, it seems I got the point but I have some questions.
Basically the monitor refresh rate is 60Hz but the timer to update the widget
was 10 milliseconds
In the meanwhile I found a way to get the screen refresh rate to use as default
in the timer. I don't know if there is something helpful in the OSG libs but
since nobody answers ... here is the code:
DEVMODE lpDevMode;
memset(lpDevMode, 0, sizeof(DEVMODE));
lpDevMode.dmSize = sizeof(DEVMODE);
Looking at the posts It seems somebody uses OSG viewers embedded in Qt widgets.
Could you please give me a feedback regarding my problem?
Thanks
Gianni
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=39419#39419
Well, updating the driver works fine. But I have a couple of questions.
On my PC (WinXP) at the end of the day I experience the same bad behaviour
while if I restart windows the CPU usage is very low. Any explanation for that?
Moreover, which is the core problem in OSG related to that?
Regards
Hi All,
I found a strange behaviour in a QT application using OSG. On a PC with a
NVIDIA Quadro FX 550 gfx card the CPU usage was 50% just running my qt app with
an osg Viewer.
After several investigation we updated the gfx card drivers to 6.14.12.6705 and
the cpu usage magically fell down.
FYI, I just pushed a fix to make osgEarth work correctly with
--run-on-demand.
Glenn Waldron : Pelican Mapping
On Sun, Feb 20, 2011 at 11:34 AM, Neil Neilson n...@nlneilson.com wrote:
Hi Jean
I tried the --run-on-demand in a .bat file
osgviewer --run-on-demand
On Feb 21, 2011, at 12:38 AM, Neil Neilson wrote:
Hi Jean
My third notebook has a Mobile Intel(R) 945GM Express Chipset
That is the one I use most for development.
The refresh rate is set at 60 Hertz
I don't know if that is the vsync you are referring to.
If it is then osgEarth must be
Hi Norman
That code looks interesting. I would need to step through that and use
some std::cout to understand it.
I tried a half dozen times to install with ossimplanet 1.8.4. It shows the
globe and
terrain but MS ends it with iglicd32.dll. It said the log would be in ..\TEMP
or sometimes
Hi, Neil.
iglicd32.dll is intel opengl driver dll, and apparently they are not so good at
writing opengl drivers atm, i've had some problems with intel cards and it's
ends up being driver bugs from time to time. If ossimplanet use compressed
textures try to enable them in graphics options in
Hi hybr,
Thanks for the info, I have had problems with the Intel 945G
Intel was just getting into the video card/drivers
6.14.10.4436 2006 is Toshiba's version of the latest driver
Previously I had to get an older driver for Java's jogl (JNI of OpenGL)
I just tried
winxp_14324.exe
Hi Neil,
After trying the examples using a pre-built 2.9.9 and the latest from the SVN
built with VS10 the CPU usage is high.
On a dual core one is nearly max and the other core is minimal.
Apart from the run on demand functionality that others suggested, you
should make sure vsync is
Hi Jean
I tried the --run-on-demand in a .bat file
osgviewer --run-on-demand C:\OpenSceneGraph-2.9.9\data\cessna.osg
That worked very well, the CPU was nearly 0 when the image was not being
changed.
I have 2 Notebooks with ATI and a Desktop NVIDIA cards. Changing something
there
would not
Hi Neil,
I have 2 Notebooks with ATI and a Desktop NVIDIA cards. Changing something
there
would not help if an app is run on someone else's computer but that is good to
know.
My comment about the differences between ATI's drivers and Nvidia's only
concerned *default* settings. You can
Hi Jean
My third notebook has a Mobile Intel(R) 945GM Express Chipset
That is the one I use most for development.
The refresh rate is set at 60 Hertz
I don't know if that is the vsync you are referring to.
If it is then osgEarth must be changing it because when zoomed way out
pressing the S key
Hi,
What can be done to reduce CPU usage when the image is not being
changed/updated?
After trying the examples using a pre-built 2.9.9 and the latest from the SVN
built with VS10 the CPU usage is high.
On a dual core one is nearly max and the other core is minimal.
With an app that much of
Hi Niel
I have not tried this myself, but I remember that support was added for
manually handling the render loop.
OSG will default to a render loop that follows your screen refresh, and if
this is forced off it will redraw as fast as possible. But i think there is
support for handling when to
Neil,
osgviewer --run-on-demand
(probably doesn't work with osgEarth at the moment though.)
Glenn
On Sat, Feb 19, 2011 at 1:15 PM, Neil Neilson n...@nlneilson.com wrote:
Hi,
What can be done to reduce CPU usage when the image is not being
changed/updated?
After trying the examples
Hi Ralf and Glen,
It's good to know something has been done on this.
Maybe osgearth_viewer will have the same capability before long.
Usually when an app does not have scope the CPU drops.
Even when an example is minimized to the task bar the
CPU is the same but switches which core uses the
Try Windows Performance Analysis Tools
They use the kernel already in place hooks to collect statistics.
http://msdn.microsoft.com/en-us/performance/cc825801.aspx
http://blogs.msdn.com/pigscanfly/archive/2008/03/02/using-the-windows-sample-profiler-with-xperf.aspx
Hi,
Jean-Sébastien Guay wrote:
Hi all,
I doubt that's the case if he's just running cow.osg. More likely,
VSync is not being properly detected on the ATI system, so the viewer
is just running free and not waiting for the frame to be drawn on the
screen.
I think Jason's guess is right on
Hi Robert,
On Fri, Jun 5, 2009 at 8:21 PM, Cory Riddellc...@codeware.com wrote:
Does anybody see less than 100% CPU utilization when running osgviewer
cow.osg on an ATI card? I had just been accepting that as normal.
100% CPU is not normal at all.
Yikes! I think
I had my cpu monitor open while running osgviewer. I just noticed that
after closing the cpu monitor, my vsync'd framerate immediately jumped
to 60 (the monitor native rate).
So, it seems that Heisenberg has struck again. I can't measure the
thing with out radically changing it. Or perhaps
On Mon, Jun 8, 2009 at 3:59 PM, Cory Riddellc...@codeware.com wrote:
Hi Robert,
On Fri, Jun 5, 2009 at 8:21 PM, Cory Riddellc...@codeware.com wrote:
Does anybody see less than 100% CPU utilization when running osgviewer
cow.osg on an ATI card? I had just been accepting that as normal.
Hi Cory,
In general I'd recommend doing all benchmarking with a system as near
to final delivery as possible, so no external tools, definitely no
debug build, run with vsync on etc. The OSG itself has some
performance stats that you can use, for instance osgviewer has the
StatsHandler added to
Hi Cory,
On Fri, Jun 5, 2009 at 8:21 PM, Cory Riddellc...@codeware.com wrote:
Does anybody see less than 100% CPU utilization when running osgviewer
cow.osg on an ATI card? I had just been accepting that as normal.
100% CPU is not normal at all.
Running osgviewer cow.osg on my Intel Core i7 +
Hi all,
I doubt that's the case if he's just running cow.osg. More likely,
VSync is not being properly detected on the ATI system, so the viewer is
just running free and not waiting for the frame to be drawn on the screen.
I think Jason's guess is right on the money. Check your frame rates,
Hi,
Sorry for reusing this old thread. It seems that nobody has found a
solution for the problem yet that also works for me.
When running osgviewer cow.osg on a dual-core PC, I get a CPU usage of
50%, which indicates that one core is used at 100%.
System:
ATI Mobility Radeon HD 2400
Windows XP
Out of curiosity, do you get similar frame rates on the two systems? Are
the other stats similar?
I had asked about this one time and in the end I decided that it was
using 100% of one core intentionally. The run loop is not throttled in
any way, and so I think it will use as much cpu as it can.
Cory Riddell wrote:
I had asked about this one time and in the end I decided that it was
using 100% of one core intentionally. The run loop is not throttled in
any way, and so I think it will use as much cpu as it can.
Perhaps the nVidia system is better at offloading working or blocks the
CPU
Does anybody see less than 100% CPU utilization when running osgviewer
cow.osg on an ATI card? I had just been accepting that as normal.
Cory
Jason Daly wrote:
Cory Riddell wrote:
I had asked about this one time and in the end I decided that it was
using 100% of one core intentionally. The
Greate news (or bad news) that means we have not a windows issue. what
happens when you switch to singelthreaded ?
/adrian
2009/2/1 Simon Loic simon1l...@gmail.com
Hi,
in my case when I am runing osgviewer on a ubuntu distribution with 4 cores
I get 25% of cpu, which means that one of my
Hi J-S
i am working with NVidia GPU, and i have same behaviour. So there should be
another problem than the busy wait. Of course can VSync give some problem in
performance or at least we get a smaller FPS displayed. But here we have
some strang behavior of our osgViewer (renderer). My there is a
I'm running locally now and am seeing the same behavior. Running with
--SingleThreaded makes no difference.
Cory
On Mon, Feb 2, 2009 at 9:53 AM, Adrian Egli OpenSceneGraph (3D)
3dh...@gmail.com wrote:
Hi J-S
i am working with NVidia GPU, and i have same behaviour. So there should be
Hi guys,
Just one more data point: a colleague of mine tested our OSG app in
linux last week and also found one of the cores (on his 8 core
machine) utilising 100% cpu. After some investigation, this turned
out to a call to schedyield on the thread in the gl driver. Posibly
you are seeing
Hi Cory,
I'll have to defer to others on the situation under Windows when doing
remote desktop. My guess is that it's likely to be a driver issue.
Well, using Remote Desktop adds a variable into the mix for sure, so
eliminating this and running the app locally would eliminate one
possible
Hi Adrian,
Even with --SingleThreaded option one core is used at 100%.
Tell me if I should do other tests.
On Mon, Feb 2, 2009 at 9:25 AM, Adrian Egli OpenSceneGraph (3D)
3dh...@gmail.com wrote:
Greate news (or bad news) that means we have not a windows issue. what
happens when you switch to
Hi Cory,
I'll have to defer to others on the situation under Windows when doing
remote desktop. My guess is that it's likely to be a driver issue.
Robert.
On Sat, Jan 31, 2009 at 3:27 PM, Cory Riddell c...@codeware.com wrote:
I'm not sure about vysync. I'll look that up and check it.
I
Hi Cory,
I am working with Windows Vista dual core system. I get 50% CPU usage when i
am running osgviewer cow.osg if i start
osgviewer cow.osg --SingleThreaded i have no longer 50% CPU usage , now i
have about 0.5-3% CPU usage !
i am very busy at the moment, but may tomorrow i will debug
Adrian,
I have observed an intermittent problem on Windows in which osgviewer
starts up using a high CPU %, but then cycling through the threading
modes with 'm' makes the problem go away - even when you return to the
mode in which you started. I never did figure out why.
Just a data point...
Hi Adrian,
This sounds like it could be a barrier that Windows is implementing
inefficiently, and locking up a core whilest sitting on a barrier.
This could possibly be a issue with OpenThreads implementation under
Windows, or even just the OpenGL driver issue.
Are you running the app when Areo
Hi,
in my case when I am runing osgviewer on a ubuntu distribution with 4 cores
I get 25% of cpu, which means that one of my cores is over used. One of my
colleagues have exactly the same behavior. Thus I don't think this is
windows related only.
On Sun, Feb 1, 2009 at 2:55 PM, Glenn Waldron
Hi Cory,
It's not normal to have this high level of CPU usage for this model,
the expceptions to this would be:
You have vysync switched off, so the app is racing as fast it can
to dispatch frames
You've compiled the OSG with debug build.
Robert.
On Fri, Jan 30, 2009 at 8:36 PM, Cory
I'm not sure about vysync. I'll look that up and check it.
I thought about the possibility of it being a debug build and I don't think
that's it. In my bin directory I have osgviewer.exe at 25,600 bytes and
osgviewerd.exe at 81,920 bytes. Both executables give me the same CPU
pegging behavior (as
When I run the osg viewer app and load just about any osg file (like
cesna.osg), my CPU usage is a constant 23% - 30%. This is with no
interaction, it is basically using an entire CPU core. Fortunatelly I have a
4 core machine, so it hasn't been a problem so far, but I'm wondering what
this means
44 matches
Mail list logo