Raspberry Pi perf?
#1
Hi,

I'm running XBMC on Raspberry Pi + tvheadend (of the flavor RaspBMC) and I'm noticing that the perf is generally pretty good except when I'm playing a 1080i video with De-interlacing enabled while the XBMC menu s showing. Looking at top; playing video only seems to suck up roughly half of my processor speed at my current overclocked level while raising the menu up makes the idle time rocket down to 0. I'm a little surprised to see that drawing the menu (statically) on top of the video costs that much and I'm pretty convinced that it can run perfectly if some optimizations were done in some areas.

Has anyone investigated this? Does anyone have a working copy of perf or oprofile or a similar tool working? I've looked online for steps; but my quick personal attempts have produced builds where the hardware counters that it required weren't there.
Reply
#2
(2014-03-28, 09:17)tichris Wrote: I'm a little surprised to see that drawing the menu (statically) on top of the video costs that much and I'm pretty convinced that it can run perfectly if some optimizations were done in some areas.

Is this just guessing or do you have any knowledge about GLES and the OMX Video Player on the PI and internas for Rendering overlays?
AppleTV4/iPhone/iPod/iPad: HowTo find debug logs and everything else which the devs like so much: click here
HowTo setup NFS for Kodi: NFS (wiki)
HowTo configure avahi (zeroconf): Avahi_Zeroconf (wiki)
READ THE IOS FAQ!: iOS FAQ (wiki)
Reply
#3
(2014-03-28, 09:17)tichris Wrote: Has anyone investigated this? Does anyone have a working copy of perf or oprofile or a similar tool working? I've looked online for steps; but my quick personal attempts have produced builds where the hardware counters that it required weren't there.

oprofile works in timer interrupt mode. gperf also works and is the preferred tool of Ben Avison who has done numerous UI optimisations.
Looking at UI over video hasn't been specifically worked on, especially not in the live TV case (which may may be quite different from normal video playback).
If any text is scrolling or constantly changes in the overlay the CPU usage goes up significantly.
What does the debug overlay text report as the fps in this case? In most cases for a bypass renderer the GUI only updates at ~10fps which helps keep CPU down,
but some animated items on the overlay may cause this number to increase.

Feel free to look into this. Improvements are always possible (and welcome).

Read through these pull requests: https://github.com/xbmc/xbmc/pulls/bavison
for examples of where profile based optimisation has improved things.
You should be testing my newclock3 branch (used by milhouse and miappa builds) which includes some optimisations that are beneficial, but not yet accepted into xbmc master code.
Reply
#4
(2014-03-28, 12:26)Memphiz Wrote:
(2014-03-28, 09:17)tichris Wrote: I'm a little surprised to see that drawing the menu (statically) on top of the video costs that much and I'm pretty convinced that it can run perfectly if some optimizations were done in some areas.

Is this just guessing or do you have any knowledge about GLES and the OMX Video Player on the PI and internas for Rendering overlays?


This is an educated guess. I don't have direct experience with this particular BCM chip; but I've worked professionally for over 15years in graphics doing software engines/hardware engines. The closest I've gotten to this chip is @ Apple (ie: the 5th gen iPod had a BC VC2 chip); so I'd say I'm pretty qualified to make this "guess".

(2014-03-28, 14:01)popcornmix Wrote:
(2014-03-28, 09:17)tichris Wrote: Has anyone investigated this? Does anyone have a working copy of perf or oprofile or a similar tool working? I've looked online for steps; but my quick personal attempts have produced builds where the hardware counters that it required weren't there.

oprofile works in timer interrupt mode. gperf also works and is the preferred tool of Ben Avison who has done numerous UI optimisations.
Looking at UI over video hasn't been specifically worked on, especially not in the live TV case (which may may be quite different from normal video playback).
If any text is scrolling or constantly changes in the overlay the CPU usage goes up significantly.
What does the debug overlay text report as the fps in this case? In most cases for a bypass renderer the GUI only updates at ~10fps which helps keep CPU down,
but some animated items on the overlay may cause this number to increase.

Feel free to look into this. Improvements are always possible (and welcome).

Read through these pull requests: https://github.com/xbmc/xbmc/pulls/bavison
for examples of where profile based optimisation has improved things.
You should be testing my newclock3 branch (used by milhouse and miappa builds) which includes some optimisations that are beneficial, but not yet accepted into xbmc master code.

Thanks; this is useful. I'll start by setting myself up with the tools & the code and see what I can find. I haven't looked at the overlay; but weirdly it lags when nothing is animating. Maybe there's a loose unterminated animation that causes constant refreshes or something weird like that.
Reply
#5
(2014-03-29, 10:54)tichris Wrote: Thanks; this is useful. I'll start by setting myself up with the tools & the code and see what I can find. I haven't looked at the overlay; but weirdly it lags when nothing is animating. Maybe there's a loose unterminated animation that causes constant refreshes or something weird like that.

Yes, a control doesn't have to visibly change to be expensive - it just has to report it has changed.
With the default dirty region algorithm, any control that reports it has changed triggers the whole screen to be rendered.
There were some threads investigating this that fixed a few cases:
http://forum.xbmc.org/showthread.php?tid=156320
http://forum.xbmc.org/showthread.php?tid...id=1489448

To test if this is the problem you want to use:
Quote:visualizedirtyregions (http://wiki.xbmc.org/?title=advancedsettings.xml) should show you the "dirty" regions that are cauing the issue.
Normally that would just be animating/scrolling regions of the screen, but that bug is probably causing stationary parts of the screen to be considered dirty.

Use this in conjunction with:
<algorithmdirtyregions>1</algorithmdirtyregions>
Reply

Logout Mark Read Team Forum Stats Members Help
Raspberry Pi perf?0