Dirty regions - what CPU usage decrease should I expect?
#1
Greetings,

I have tried out the "dirty regions" function from yesterday's GIT version. It marks the "active" regions fine, but I see absolutely no decrease in CPU usage. On an Asrock A330ION running Linux, the CPU usage is still around 50% in the menu, even when the screen is perfectly still. Is this an expected behavior? Can anyone share their experiences from using "dirty regions" on an ION-powered platform?
Reply
#2
Dirty regions have been reported to take down CPU usage a bit on some systems. How much depends greatly on the drivers. We minimize what we send to the GPU which means that the CPU will do less work but overall the vast amount of usage decrease is within the GPU and not the CPU.

You might notice more if you set it up to use the nofliptimeout flag.

TBH I must say that 50% in menus sounds almost to much even before D-R, IIRC I have it at around 20% on my ION but it was a long time ago since I had that one up and running.
If you have problems please read this before posting

Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.

Image

"Well Im gonna download the code and look at it a bit but I'm certainly not a really good C/C++ programer but I'd help as much as I can, I mostly write in C#."
Reply
#3
topfs2 Wrote:We minimize what we send to the GPU which means that the CPU will do less work but overall the vast amount of usage decrease is within the GPU and not the CPU.

I guess this explains everything.

topfs2 Wrote:You might notice more if you set it up to use the nofliptimeout flag.

I've tried using <nofliptimeout>1000</nofliptimeout>, didn't change a thing.

topfs2 Wrote:TBH I must say that 50% in menus sounds almost to much even before D-R, IIRC I have it at around 20% on my ION but it was a long time ago since I had that one up and running.

It's been that way for me since I remember. I'm using the Transparency skin. It's not actually a problem, I'm simply curious what's causing a 50% CPU load while displaying an idle screen. I suppose Atom's limited processing power has something to do with it Smile
Reply
#4
have you got update library on strtup and set to run on background?
Reply
#5
Nope, I always update my library manually.
Reply
#6
nofliptimeout set to 1000 will only do something after nothing is rendered at all for 1 second (i.e. completely static screen for a second).

50% CPU sounds like something is wrong IMO.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
#7
If you comoile from source,I have noticed this before, you can compile twice the same revision with slight variances, some work better than others.

What I do is compile a second time once i notice something is off. Though this is not always a cure its over 90% cure

for e.g. I activated Dirty regions (1) and noticed when I pull context on any filename half the filename is yellow the rest is white, specially if proceeding the pull context I go to refresh movie information.

I also noticed that though there's no real cpu/gpu usage going marginal latency is introduced, evrything from network is dragging almost a full second.

Another oddity is that any movies in dvd format dont get a little SD flag, removing dirty regions the flag is returned and all of the above goes away.

I haven't noticed any rise on cpu above ~3% unless I'm scrapping then it goes apeshit.
Reply
#8
Thanks for your responses.

jmarshall, is there anything I could do to trace the reason for a ~50% CPU usage while XBMC is being practically idle? I've tried attaching to the process with strace, but it spits so much output it means nothing to a non-developer. Debugging log (level 2, turned on using the GUI option) doesn't show any background activity while I'm just sitting in the menus.

X3lectric, thanks for the tip, I might try that later on, though it's just been this way ever since I've used it, so I don't expect much of an improvement Smile Also, I haven't thought "something is off" for the very same reason - I just assumed it's normal.
Reply
#9
with xbmc I try not to assume anything especially on Linux. That recompile thing has fixed a multitude of sins large and small, it was by accident I found this out, when suddenly in one occasion I had what you describe and also just loading up to terminal, terrible picture, and list goes on of things a recompile fixed for me. sometimes I od two in a row as soon the trained eys goes I see something off.
Reply
#10
I've found the culprit - the Transparency! skin. Following the advice found here, I have switched back to the default Confluence skin. I was pretty shocked by the results. The CPU usage immediately dropped to 19-20%. Once I've enabled dirty regions (<algorithmdirtyregions>2</algorithmdirtyregions>), it dropped even more - to 10-11%. And when I've coupled it with nofliptimeout (<nofliptimeout>100</nofliptimeout>), it went down to... 5-6%. Which is fantastic!

When I've switched back to Transparency!, the CPU load skyrocketed back to 47-48%. Turning off animated weather icons on the main screen brought it down to 33-34%. But what I was intrigued about the most is that no dirty regions settings brought the CPU load down even a notch. No matter what combination of dirty regions settings I've used, the CPU load would still oscillate around 35% in the menus, which is sort of unsatisfactory. Is it possible that a specific skin is not "dirty-regions-optimized"? Shall I report it to the skin maintainer?
Reply
#11
thats what I get without dirty regions enabled about 2% on Asrock ION 330 HT using default skin, compiled about 5 minutes ago
Reply
#12
Odd thing. I'm using Gentoo, maybe there is something off in the ebuild? strace stats show:

Code:
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
95.03    0.139977         273       512           poll
  2.16    0.003181           1      2134           sched_yield
  0.67    0.000987           0      3066           fstat64
  0.43    0.000627           0      3657           clock_gettime
  0.41    0.000600           0      2562      1535 read
  0.39    0.000575           0      2044      2044 access
  0.32    0.000469           0      4088           fcntl64
  0.30    0.000440           1       511           ioctl
  0.14    0.000205           0      1027           _llseek
  0.14    0.000204           0       511           select
  0.02    0.000032           2        20           gettimeofday
  0.00    0.000000           0         1           restart_syscall
  0.00    0.000000           0      1538           time
  0.00    0.000000           0       511           getpid
  0.00    0.000000           0         2           writev
  0.00    0.000000           0        20           futex
------ ----------- ----------- --------- --------- ----------------
100.00    0.147297                 22204      3579 total

An example strace file is available here. Apparently XBMC spends a lot of time polling fd 18, which I will know nothing about until I will be able to restart XBMC (I'm accessing the box remotely right now). Any obvious ideas as to what might be wrong?
Reply
#13
Kempniu Wrote:Is it possible that a specific skin is not "dirty-regions-optimized"? Shall I report it to the skin maintainer?

Dirty region only brings down CPU if the skin becomes static or changes little. Also some controls aren't hooked up yet and causes render all the time. Visualize will show this.

Generally speaking its somewhat a tradeoff between dynamic and static, if the skin is static it will use less CPU, if its dynamic it won't. So you'll have to decide what you value when you skin. On a normal machine they can handle being dynamic (even with high cpu) so if you like the looks then you'll just have to accept that it might be costlier Smile

We are exploring other optimizations which will help with dynamic skins a bit also.

In the end, isn't it better that you like the looks than it draws little resources Smile
If you have problems please read this before posting

Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.

Image

"Well Im gonna download the code and look at it a bit but I'm certainly not a really good C/C++ programer but I'd help as much as I can, I mostly write in C#."
Reply
#14
X3lectric Wrote:If you comoile from source,I have noticed this before, you can compile twice the same revision with slight variances, some work better than others.

This really shouldn't be needed, compiling same source with same compiler (and version) should produce the same binary AFAIK.

If your infact getting different binaries I suspect your using a weird compiler (but I guess you use linux and g++/gcc which is sane) or perhaps some hw problem? You might want to remove any optimizations when compiling though, --disable-optimizations should remove any -O3. They can give weird results at times (nothing which changes between compiles though I'd think).

It sounds unrelated and perhaps you just hit a bug which manifests itself rather randomly? or perhaps its hw? I'd try a memtest to be sure its not something getting corrupt.

EDIT: I actually tried it now and I compiled xbmc twice with git clean and everything in between, the produced files are binary identical. So if you see differing results then it must be something in your environment
If you have problems please read this before posting

Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.

Image

"Well Im gonna download the code and look at it a bit but I'm certainly not a really good C/C++ programer but I'd help as much as I can, I mostly write in C#."
Reply
#15
topfs2 Wrote:In the end, isn't it better that you like the looks than it draws little resources Smile

Couldn't agree more Smile And that's what I plan on doing in the long run, though my insightful nature prohibits me from simply getting over my high CPU utilisation when others report their CPU is almost idle in menus, that's all Smile
Reply

Logout Mark Read Team Forum Stats Members Help
Dirty regions - what CPU usage decrease should I expect?0