XBMC Weekly report 9

Sorry, I was late with the weekly but here it is:
http://xbmc.org/topfs2/2010/07/26/weekly-report-9/

Next week will be incredibly busy for me since I will be moving to an
intermidiate apartment before going to Canada, but I hope I'll manage to
get some hours to work on everything though. Otherwise I'll more than
make up for it in the new apartment were I have lots of free time :slight_smile:

Sorry, I was late with the weekly but here it is:
Status

 \* OMAP Overlay is hooked up to XBMC and works rather well \(for a
   few seconds\)

(for those not at the meeting this is sort of 'fixed' now - at least
the race condition is masked by less debug spew causing it to happen
so reliably and fast).

 \* Switched the yuv transformation from swscale to the NEON method
   created by mru\.
 \* Have created a hack that should get rid of the memcpy, needs
   major redesign though to get it into trunk though but probably
   ok to use for beagleboard and possibly tegra to gain some speed
   while decoding video\.

I've seen the way it loads giant jpeg's for the backgrounds and wish I
hadn't - a simpler theme would help that at least. Playing music uses
quite a lot of resources for what it's doing but I guess it usually
doesn't skip. 40% here, that's mostly in a resampling call.

Even with no video and not much else the gui seems remarkably sluggish
for so few widgets. Oprofile didn't tell me much beyond those two
issues in the paragraph above though.

Plan

 \* Get to the bottom of the deadlock which makes playback stop
   after a few seconds

This still needs fixing, but at least with the workaround it can be used a bit.

 \* Position the overlay properly according to skinning
   specifications \(rotation will not be possible but nearly no skin
   uses that on video control so no real biggie\)\.
 \* Get stuff rendering ontop of the overlay is still needed, so
   plan is to read through the documentation about the blending
   modes and how to setup so SGX shines through as supposed to\.

Good plan.

Risks

 \* Time…\. next week will be my final moving week and I need to
   clear out the entire apartment\. Hence I suspect the following
   week will be hard to get much work done in\. Weeks after this
   I’ll be setup and free in a new apartment  so I’ll take care of
   the time lost then\.

Well good luck. Not much time left though.

!Z

tis 2010-07-27 klockan 04:49 +0930 skrev Michael Zucchi:

> Sorry, I was late with the weekly but here it is:
> Status
>
> * OMAP Overlay is hooked up to XBMC and works rather well (for a
> few seconds)

(for those not at the meeting this is sort of 'fixed' now - at least
the race condition is masked by less debug spew causing it to happen
so reliably and fast).

Some more updates. Since then I've gotten rid of the tearing (had to
wait for vsync). I've also gotten the timing correctly and it should as
far as I can tell be synced properly now (granted alsa works)

> * Switched the yuv transformation from swscale to the NEON method
> created by mru.
> * Have created a hack that should get rid of the memcpy, needs
> major redesign though to get it into trunk though but probably
> ok to use for beagleboard and possibly tegra to gain some speed
> while decoding video.

I've added a method that does not use the memcpy it will void some
overlays (different from video presentation overlay) in the videoplayer
but I can't understand why they are used for at any rate.

480p bunny is almost fluid now and next I'll try to get some oprofiling
done (probably sunday, at earliest saturday).

I've seen the way it loads giant jpeg's for the backgrounds and wish I
hadn't - a simpler theme would help that at least. Playing music uses
quite a lot of resources for what it's doing but I guess it usually
doesn't skip. 40% here, that's mostly in a resampling call.

Hmm the resampling is not needed at all on linux and is a reminiscence
from xbox, now its only used to convert from float to int.

Even with no video and not much else the gui seems remarkably sluggish
for so few widgets. Oprofile didn't tell me much beyond those two
issues in the paragraph above though.

It really is sluggish, most seems to be wasted on the big backgrounds
afaict. Especially fading of two backgrounds between eachother. When
fading between 2 images we render both with blending enabled with
different alphas, very wasteful as we could fade them in a shader and
probably gain lots of speed.

At any rate its probably sane to add a configure / runtime switch for
disableing animations for beagleboard.

I've added a runtime switch for the dirty region rendering btw.

Add as advancedsettings.xml (~/.xbmc/userdata/advancedsettings.xml)
<advandedsettings>
  <gui>
    <usedirtyregions>true</usedirtyregions>
  </gui>
</advancedsettings>

> Plan
>
> * Get to the bottom of the deadlock which makes playback stop
> after a few seconds

This still needs fixing, but at least with the workaround it can be used a bit.

> * Position the overlay properly according to skinning
> specifications (rotation will not be possible but nearly no skin
> uses that on video control so no real biggie).
> * Get stuff rendering ontop of the overlay is still needed, so
> plan is to read through the documentation about the blending
> modes and how to setup so SGX shines through as supposed to.

Good plan.

Update on this, positioning and scaling should be correct now. Haven't
gotten it to render controls over the video yet though but I'll try and
make a sample app for this since it takes so much time testing and
tweaking this in xbmc.

> Risks
>
> * Time…. next week will be my final moving week and I need to
> clear out the entire apartment. Hence I suspect the following
> week will be hard to get much work done in. Weeks after this
> I’ll be setup and free in a new apartment so I’ll take care of
> the time lost then.

Well good luck. Not much time left though.

Yup, will need to work lots of hours when the move is done.

Some more updates. Since then I've gotten rid of the tearing (had to
wait for vsync). I've also gotten the timing correctly and it should as
far as I can tell be synced properly now (granted alsa works)

Nice. I will try again soon and let you know how it goes (been quite busy).

> * Have created a hack that should get rid of the memcpy, needs
> major redesign though to get it into trunk though but probably
> ok to use for beagleboard and possibly tegra to gain some speed
> while decoding video.

I've added a method that does not use the memcpy it will void some
overlays (different from video presentation overlay) in the videoplayer
but I can't understand why they are used for at any rate.

480p bunny is almost fluid now and next I'll try to get some oprofiling
done (probably sunday, at earliest saturday).

How is the stability going? Did you manage to track down that
deadlock issue, or just hide it? Although the profiling is important,
having something crash more quickly isn't really very useful.

Even with no video and not much else the gui seems remarkably sluggish
for so few widgets. Oprofile didn't tell me much beyond those two
issues in the paragraph above though.

It really is sluggish, most seems to be wasted on the big backgrounds
afaict. Especially fading of two backgrounds between eachother. When
fading between 2 images we render both with blending enabled with
different alphas, very wasteful as we could fade them in a shader and
probably gain lots of speed.

Well the loader for the background has a simple getpixel() putpixel()
type 'scaler' for the big images. It takes forever and bogs down the
system.

The slowness in general (once those background images are loaded)
doesn't seem to hit the cpu much, I wonder if it isn't some sort of
waiting around for vsync/some timer event or something? Or lock
thrashing or something similarly hidden? It's a bit hard to tell with
strace and multimedia which does that type of thing but it seemed to
be polling/selecting a lot, often with no delay. I couldn't get
enough working out of gdb for it to help any in working out what it
might be, or even if there was really no problem.

At any rate its probably sane to add a configure / runtime switch for
disableing animations for beagleboard.

Would it be better to just use a different theme which didn't try to
animate? It seems like this is exactly what the theme system is for,
and a configure option seems out of place for it.

And it could remove other stuff like the giant bitmaps that need
rescaling since the upper resolution is a bit limited. I did try
installing a different theme but it never seemed to show up on any
option after it was 'installed'.

I've added a runtime switch for the dirty region rendering btw.

Add as advancedsettings.xml (~/.xbmc/userdata/advancedsettings.xml)
<advandedsettings>
<gui>
<usedirtyregions>true</usedirtyregions>
</gui>
</advancedsettings>

I like how xml is so concise ...

Update on this, positioning and scaling should be correct now. Haven't
gotten it to render controls over the video yet though but I'll try and
make a sample app for this since it takes so much time testing and
tweaking this in xbmc.

That also sounds like a good plan, even the simplest change takes
several minutes to turn around to a runnable binary.

Hi Tobias,

I did a build last night and this morning gave it a go, but all I get
is a blank screen (admittedly a 20fps blank screen :wink: and lots of
errors about invalid shader 1 2 or 3. Just in-case you're unaware of
the issue ...

!Z

You mentioned you had a custom skin, is that already public?

regards,

Koen

I have not changed the shaders so if you get invalid shader I would guess that either Sgx has changed, doesn’t worl as expected or mosr probable that something have happen to your portable data. In the last case try removing ~/.xbmc and try again. Interesting that you hit 20 fps on invalid shaders, could swear I hit vsync on that. Invalid shaders is the roof of possible fps afaik and its what I hit on my optimized skin. In the skin I have avoided layers and alpha blending (stuff I have seen take lots during testings) and I get 20 easily (while navigating through the list) with dirty region turned on so I will have lots to write about regarding optimzing skins.

The skin is not public mostly because I used icons I had locally (no internet) and I dont have permission to use them. I am however switching to oxygen now and then it should be safe to upload.

The alpha stuff should be working now but I havent verified it and my darn SD card went corrupt but I have created a new rootfs using narcissus (fun on 2G :slight_smile: ) but will commit it tomorrow.

Cheers,
Tobiaa

I have not changed the shaders so if you get invalid shader I would guess
that either Sgx has changed, doesn't worl as expected or mosr probable that
something have happen to your portable data. In the last case try removing
~/.xbmc and try again. Interesting that you hit 20 fps on invalid shaders,
could swear I hit vsync on that. Invalid shaders is the roof of possible fps
afaik and its what I hit on my optimized skin. In the skin I have avoided
layers and alpha blending (stuff I have seen take lots during testings) and
I get 20 easily (while navigating through the list) with dirty region turned
on so I will have lots to write about regarding optimzing skins.

I was being facetious with the fps comment 'see look it - does 100fps,
you just can't see it!' :wink:

Power went out yesterday so i hope that didn't upset it. Tried
removing .xbmc, reboot, power cycle, no go. The SGX demos run fine.

I guess i'll have to try updating angstrom, although last time i did
that it broke things for a few days. I suppose it's a long shot - but
is it worth a make clean?

I might try a build from koen first though.

The skin is not public mostly because I used icons I had locally (no
internet) and I dont have permission to use them. I am however switching to
oxygen now and then it should be safe to upload.

Good stuff. Chuck a beagle in there somewhere? Even if it looks a
little cheesy.

The alpha stuff should be working now but I havent verified it and my darn
SD card went corrupt but I have created a new rootfs using narcissus (fun on
2G :slight_smile: ) but will commit it tomorrow.

Eek ok. No worries.

!Z