[osg-users] CPU usage
Cory Riddell
Is this typical?
Cory
Robert Osfield
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.
> _______________________________________________
> osg-users mailing list
> osg-...@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Cory Riddell
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 observed by SysInternals Process Explorer).
My command line is "osgviewer.exe --window 100 100 200 200 cessna.osg". My video card is an ATI FireGL V7700 and the drivers are up to date.
Ah- I just noticed something-- an error message:
Windows Error #127: [Screen #0] ChooseMatchingPixelFormat() - wglChoosePixelFormatARB extension not found, trying GDI. Reason: The specified procedure could not be found.
I'm running over remote desktop right now, so perhaps that's related. I don't recall seeing this error message before.
Cory
Robert Osfield
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.
Adrian Egli OpenSceneGraph (3D)
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 the OSG core, may there is a bug inside or a thread running at max.
or robert has some idea,where i can start with debugging. may it's a windows vista bug
adrian
--
********************************************
Adrian Egli
Robert Osfield
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 is enabled? If so then disable Areo
and run the app again and look at the stats.
Robert.
Glenn Waldron
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...
Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : +1.703.652.4791
Simon Loic
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.
Loïc Simon
Adrian Egli OpenSceneGraph (3D)
/adrian
--
********************************************
Adrian Egli
Morné Pistorius
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 something similar..
Cheers,
Morne
On Mon, Feb 2, 2009 at 8:25 AM, Adrian Egli OpenSceneGraph (3D)
Simon Loic
Even with --SingleThreaded option one core is used at 100%.
Tell me if I should do other tests.
Jean-Sébastien Guay
> 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 thing.
About one core being pegged, some video drivers implement vsync as a
busy wait, which means that the CPU is not really pegged, it just looks
like that. If you were to actually run real code on that core, along
with OSG, you would see that that code would run at a normal speed
because the vsync busy wait would relinquish the CPU while it's waiting
for the next frame to start.
So my guess is that your ATI drivers are doing this, and what you're
seeing is just the idle time between frames being counted as active time
by Process Explorer because it's implemented as a busy wait. Of course,
I'm speculating here, you'll have to run a real app (not just osgviewer)
to see for yourself.
Note also that ATI's OpenGL drivers have never been the best... Though
they say they're getting better, they have a long way to go. So there
might be some of that here.
Hope this helps,
J-S
--
______________________________________________________
Jean-Sebastien Guay jean-seba...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
Adrian Egli OpenSceneGraph (3D)
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 bug inside the synchronisation.
But what i guess is:
When we are running under --SingleThreaded :
bool GraphicsWindowWin32::realizeImplementation()
wglMakeCurrent
SwapBuffers
all are called in the same thread.
if we are working without singlethreaded option, then the realize get call in the "master" thread and in the others wgl based method call get called in a second thread. may the operating system (driver) understand, that there must be more than one thread in the "world" and starts an extra synchronisation which cause the CPU overload.
/adrian
--
********************************************
Adrian Egli
Cory Riddell
Cory
Florian Winter
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
However, with the same application, CPU usage is only at 5% on the
following system:
nVidia GeForce 9400
Windows XP
I have tried --SingleThreaded on the ATI system, but it seems to have no
effect.
Furthermore, I also get 50% CPU usage on another dual-core system with
Windows Vista and nVidia GeForce 9400 if the single threaded model is
used. With the default threading model, CPU usage goes up to 100%.
I am using OSG version 2.6.0.
V-Sync was enabled in all tests (using global driver settings, e.g. in
Catalyst Control Center). The frame rate was constant and there was no
tearing.
So far, I have read all kinds of rumors about this issue from various
sources. There are even older threads about this on the OSG mailing
list. This is what I found so far:
http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2007-November/004363.html
http://www.gamedev.net/community/forums/topic.asp?topic_id=445562
Has anyone found a definitive solution to this problem yet?
Can anyone confirm or deny that this is actually a problem and not a bug
in Windows Task Manager showing the wrong CPU usage?
Has something been done to address this problem in newer versions of OSG?
Tearing prevention is absolutely necessary in my application, and a
"manual" implementation of V-sync seems to be not accurate enough for
the task.
Thanks in advance,
fw
Cory Riddell
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.
Perhaps the nVidia system is better at offloading working or blocks the
CPU differently than the ATI system. In the end, I think this just
points to the CPU being the bottleneck in the ATI system and something
else (video card?) being the bottleneck in the nVidia system.
Cory
Jason Daly
> 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 differently than the ATI system. In the end, I think this just
> points to the CPU being the bottleneck in the ATI system and something
> else (video card?) being the bottleneck in the nVidia system.
>
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.
First thing I'd suggest is to make sure you've got the latest drivers
for the ATI card. ATI's OpenGL support has gotten a lot better
recently, so it's possible that a driver upgrade will allow OSG to
properly detect the VSync signal.
--"J"
Cory Riddell
cow.osg on an ATI card? I had just been accepting that as normal.
Cory
Robert Osfield
On Fri, Jun 5, 2009 at 8:21 PM, Cory Riddell<co...@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 + Radeon 4670 + Kubuntu
9.04 (KDE) with Proprietary AMD/ATI drivers I get:
Tasks: 191 total, 1 running, 190 sleeping, 0 stopped, 0 zombie
Cpu(s): 1.2%us, 0.3%sy, 0.0%ni, 98.4%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 6021404k total, 935360k used, 5086044k free, 38756k buffers
Swap: 8000328k total, 0k used, 8000328k free, 353980k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3507 root 20 0 586m 114m 25m S 5 1.9 0:15.56 Xorg
4223 robert 20 0 254m 33m 22m S 4 0.6 0:09.40 osgviewer
3973 robert 20 0 255m 23m 17m S 1 0.4 0:04.44 kwin
The desktop compositor was on so added extra work, but as you can see
the CPU's are practically idle. Note this test was done with vsync
enabled, with osgviewer running at a solid 60Hz.
Robert.
Jean-Sébastien Guay
> 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,
you'll probably see that the nvidia system is running at a steady 60/75
(whatever your refresh rate is) while the ATI system is going at several
hundred frames per second (500 or more, most likely).
I've found the first time I run an OSG app on an ATI card, I have this
surprise, so I have to set the vsync setting to forced on in the control
center. I just always assume that vsync is on by default, and use ATI
pretty seldom, so I'm always being bitten by this one...
Hope this helps,
J-S
--
______________________________________________________
Jean-Sebastien Guay jean-seba...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
Florian Winter
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 the money. Check your frame rates,
> you'll probably see that the nvidia system is running at a steady
> 60/75 (whatever your refresh rate is) while the ATI system is going at
> several hundred frames per second (500 or more, most likely).
V-sync and frame rate was the first thing I checked. I measured the
frame rate on both systems using Fraps. The frame rate is at a constant
60 FPS on the ATI system and 75 FPS on the nVidia system. The different
frame rates might be due to using different monitors.
Cory Riddell
On Fri, Jun 5, 2009 at 8:21 PM, Cory Riddell<co...@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.
I updated my video drivers to the latest this morning and enabled vsync. Enabling vsync sent my framerate from 1200 fps to 15 fps! Vsync on or off made no difference on the cpu load- I always have 100% utilization on one core.
I have a FireGL V7700 with 512 MB of RAM. I'm running the 8.603 drivers on quad core XP Pro machine. My one-and-only monitor is a 24" Dell panel at 1920x1200.
I turned vsync back off. With it on, my cow looked like it was being rotated by a stepper motor.
If you or anybody else has troubleshooting suggestions, I would be very happy to hear them.
Cory
Cory Riddell
So, it seems that Heisenberg has struck again. I can't measure the thing with out radically changing it. Or perhaps I'm just not using the right tools. Does anybody have any suggestions for decent Windows performance analysis tools? I was using SysInternal's ProcessExplorer.
Cory
Cory Riddell wrote:
Ismail Pazarbasi
> osg-users mailing list
> osg-...@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
Hi Cory,
I don't know whether you tried (neither know whether it's even
possible at all) to profile the code? This may give you some hints, if
it works.
Ismail
Robert Osfield
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 the viewer which you can enable with pressing
's' successively to get different levels of stats reporting.
Robert.
Mario Valle
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
http://msdn.microsoft.com/en-us/library/cc305215.aspx
Hope it helps.
Ciao!
mario
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> osg-users mailing list
>> osg-...@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> osg-users mailing list
> osg-...@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Ing. Mario Valle
Data Analysis and Visualization Group | http://www.cscs.ch/~mvalle
Swiss National Supercomputing Centre (CSCS) | Tel: +41 (91) 610.82.60
v. Cantonale Galleria 2, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82