Please attach the Xorg.0.log and the output of dmesg and glxinfo.

Is this with DPM successfully changing clocks?

(In reply to comment #1)
> Please attach the Xorg.0.log and the output of dmesg and glxinfo.

Will post those later, when I'm back at that system.

> Is this with DPM successfully changing clocks?

As written in bug 74250, comment #8 reclocking doesn't seem to work for me. Whatever I've been doing, the output of cat /sys/kernel/debug/dri/0/radeon_pm_info /sys/kernel/debug/dri/64/radeon_pm_info stays:
> power level avg    sclk: 30000 mclk: 15000
> power level avg    sclk: 30000 mclk: 15000

(observed through a SSH connection, in order to keep the 3D applications running fullscreen). I can check the clocks with e.g. MediathekView too, but it would be very weird if the GPU would reclock for "simple" applications and not for the 3D applications, wouldn't it?

CPU profiles from sysprof or perf or oprofile might be interesting.

AFAICT Twitch requires Flash; what Flash plugin are you using in what browser?

Does doing anything in particular trigger it in MediathekView?

(In reply to comment #3)
> CPU profiles from sysprof or perf or oprofile might be interesting.

Ok, I'll try to do that; I might not be able to do that today, though.

> AFAICT Twitch requires Flash; what Flash plugin are you using in what
> browser?

Yes, Twitch, like YouTube, requires Flash. I use the plugin installed by flashplugin-nonfree and its update-flashplugin-nonfree script. It's the 64 bit version. I check the version number later again. But it was recently updated.
 
> Does doing anything in particular trigger it in MediathekView?

Sort of: just starting is enough. You get the grey window background at below average speed and then it takes seconds until the UI elements are drawn (list of shows, filter boxes, buttons). Afterwards you can trigger a new CPU spike by trying to click anything or even better on each keypress/character input into the title filter field on the left.

(In reply to comment #4)
> (In reply to comment #3)
> > AFAICT Twitch requires Flash; what Flash plugin are you using in what
> > browser?
> 
> Yes, Twitch, like YouTube, requires Flash. I use the plugin installed by
> flashplugin-nonfree and its update-flashplugin-nonfree script. It's the 64
> bit version. I check the version number later again. But it was recently
> updated.

Sorry, forgot to name the browser: Iceweasel 31.0-3 (aka Firefox 31.0).

Just to note this again: other video pages like YouTube don't show the problem Twitch has. And it's also only giving these spikes, when you try to watch a recorded broadcast, not for live streams.

(In reply to comment #4)
> Yes, Twitch, like YouTube, requires Flash.

Actually, YouTube doesn't require Flash, at least not for many videos.


> > Does doing anything in particular trigger it in MediathekView?
> 
> Sort of: just starting is enough. You get the grey window background at
> below average speed and then it takes seconds until the UI elements are
> drawn (list of shows, filter boxes, buttons). Afterwards you can trigger a
> new CPU spike by trying to click anything or even better on each
> keypress/character input into the title filter field on the left.

I can reproduce this with glamor from xserver 1.16.0, but not from current xserver Git master. So at least that part is already fixed.

(In reply to comment #6)
> (In reply to comment #4)
> > Yes, Twitch, like YouTube, requires Flash.
> 
> Actually, YouTube doesn't require Flash, at least not for many videos.

If I go by top, then the CPU usage of the plugin container spikes for all videos on YouTube (usually to about 30-50% on one core with Flash HW acceleration enabled). But as <https://www.youtube.com/html5> tells me I'm using the default player, that doesn't seem too surprising.
 
> > > Does doing anything in particular trigger it in MediathekView?
> > 
> > Sort of: just starting is enough. You get the grey window background at
> > below average speed and then it takes seconds until the UI elements are
> > drawn (list of shows, filter boxes, buttons). Afterwards you can trigger a
> > new CPU spike by trying to click anything or even better on each
> > keypress/character input into the title filter field on the left.
> 
> I can reproduce this with glamor from xserver 1.16.0, but not from current
> xserver Git master. So at least that part is already fixed.

Oh, nice. Do you know which commit resolves this? If not, do you need a bisect? If yes, will that commit be backported to the 1.16 branch?

Created attachment 103995 [details]
Xorg.0.log

Created attachment 103996 [details]
dmesg output

Created attachment 103997 [details]
glxinfo output

I've uploaded the requested files (attachment 103995 [details], attachment 103996 [details], attachment 103997 [details]) and now checked the installed Flash version, it is 11.2.202.394.

Created attachment 104000 [details]
X uses a lot of CPU cycles, as shown by top

As you can see from this top screenshot, X is using a lot of CPU cycles.

Created attachment 104001 [details]
sysporf points to libpixman

According to the sysprof output, libpixman is the place where moste CPU time goes. If you want the sysprof output, let me know and I e-mail it to you. Not sure I want to put it on the internet, as didn't have time to check what data might be disclosed.

(In reply to comment #13)
> According to the sysprof output, libpixman is the place where moste CPU time
> goes.

That just means the problem is a software rendering fallback path, but it doesn't show which one. You'd need to make sure at least the X server binaries are compiled with -fno-omit-frame-pointer and have debugging symbols.


(In reply to comment #7)
> Do you know which commit resolves this?

Not sure, but my guess would be http://cgit.freedesktop.org/xorg/xserver/commit/?id=45ebc4e3fac7f1a85167d05e2833949b89f02d64 or one of the commits surrounding it.

> If not, do you need a bisect?

That would be interesting.

> If yes, will that commit be backported to the 1.16 branch?

I can't predict the future, you'll have to nominate it and see. :)

Ok, since my bisecting adventures took too long I just built xorg/xserver:master, commit c52a2b1eba. That version doesn't exhibit this problem. I consider this fixed.