[VikingGe]

Hey guys,

so there it is, yet another thread about performance issues. Thing is, I don't have a clue what the problem is in this case.

I'm running XBMC (Gotham) on Arch Linux on an HP EliteBook 725, with the following specs:
CPU: AMD A10 7350B (4x 2.1 GHz)
GPU: integrated (Radeon R6)
RAM: 2x4GB DDR3-1600
Screen resolution: 1366x768

While XBMC's GUI runs fine, when trying to play back 720p hi10p files, I'm getting around 18 FPS, 720p 8-bit video plays at around 20 FPS. That said, with VSync enabled it hits a wall at 15 FPS. And all of this is choppy as hell.
This is ridiculous. Even my old Intel Atom-based netbook was able to play the very same files without any issues, and the A10 is like 10 times faster on the CPU side and even more when it comes to the GPU. And it's just XBMC, mplayer or VLC play those files fine as well.

So here's what I tried:
- Forcing the CPU to run at 2.8 GHz instead of ~1.3 (power saving mode). CPU load went down a bit (from, like, 30% to 15%), didn't affect the frame rate.
- Forcing the GPU into a high performance state. Didn't change a thing.
- Setting resolution to 640x480. Again, nothing.
- Disabling KDE's desktop effects. Nothing.
- Playing around with video playback and acceleration settings. It doesn't support hardware decoding, so that obviously didn't change anything, and setting the rendering method to Software reduced the frame rate even further.
- Playing around with audio settings, just like people on the forums suggested. Whatever I do, nothing changes.
- Disabling PulseAudio. No change at all.
- Booting into the default kernel rather than the ck-patched one. No changes.

So what I didn't try is Catalyst because Catalyst doesn't even work. It might be a GPU driver issue, but the open-source radeon driver manages to run Minecraft at a solid 30 FPS. And, like I said, XBMC does much better on my old netbook (Intel Atom N470, 1x1.86 GHz, no hw acceleration) and on my desktop machine (Phenom II X6, GTX 670, hw acceleration disabled), both running Arch Linux.

Edit:
Debug log

Any ideas?

[fritsch]

I looked at the log. It sodes not look too bad. Hi10p is done on the CPU anyways, so the GPU should not have to do something with it.

Can you post the output of vdpauinfo?

Btw. you could also try openelec from an usb stick - same issues?

[VikingGe]

I didn't even have vdpau libraries installed, but now that I have... vdpauinfo.

so the GPU should not have to do something with it.

The GPU does the rendering/presentation though, so I thought there might be performance issues.

Btw. you could also try openelec from an usb stick - same issues?

Just tried that, with OpenELEC it actually works. So am I basically looking for a different XBMC build?

[fritsch]

I have no idea what your Arch Linux is doing. OpenELEC is more or less kodi mainline.

Sorry, this is not an xbmc issue then.

[VikingGe]

I just checked, OpenELEC (at least the version I have tested) uses a 3.16 kernel, my Arch Linux install is already at 3.17. So I just installed an LTS kernel (3.14.something) and although it doesn't properly support the hardware, XBMC works just the way we all love it.

It seems like there really is a probelm with latest radeon-si drivers. I'll try a few things and if nothing works, I'll probably just revert to a 3.16 kernel.
Edit: Confirmed, 3.16 kernel works fine as well.

[fritsch]

Outsch!

That could be the powerstates they implemented. Please report an upstream kernel bug then. It might be good to try kernel 3.18-rc7+ - There are some positive reports in my initial radeon oss vdpau thread.

Edit: OpenELEC 5 RC1 also uses 3.17.x -> can you try that?

[VikingGe]

GPU power management was already implemented in 3.16, or what exactly are you referring to?

In OpenELEC 4.97 it is slow as well, yes. I'll report on 3.18 results as soon as it has finished building (linux-git AUR package still says rc6, but I guess I'm getting more recent code).

Edit: Still slow on 3.18.
I can file a bug report about this and probably do some profiling. If you know of anything that might be useful information, please tell me as I don't know anything about XBMC's rendering internals.

[fritsch]

You will have the same issue with every other OpenGL program (Edit: in combination with UVD decoding). I think your dmesg will show that only one clock level is found and will use the lowest.

bugs.freedesktop.org is the place to go.

[da.schizzle]

Did you file a bug report? any responses?
I have a kabini apu and the same problems with the new 3.17 kernel. Im using OpenELEC. 5.0
Sadly i cant revert back to 3.16 (OpenELEC 4.2.X) because this one crashes randomly on many kabini systems and mine as well.
OpenELEC 5.0 fixed this but now i have the slow playback with some files.

[fritsch]

Your issue is something else. The OP only gets a single powerstate, so the gpu is constantly clocked too low.

OE has another issue with non hw accelerated files are slow as hell. I tried to debug this, by installing an Ubuntu system with the very same kernel, mesa and so on ... i could not reproduce at all, so no idea what to do there.