| Priority | medium |
|---|---|
| Bug ID | 82055 |
| Assignee | dri-devel@lists.freedesktop.org |
| Summary | [HAWAII] Running some programs, when HW acceleration is on, c= auses X to spike in CPU usage =E2=86=92 unresponsive desktop |
| Severity | normal |
| Classification | Unclassified |
| OS | Linux (All) |
| Reporter | kai@dev.carbon-project.org |
| Hardware | x86-64 (AMD64) |
| Status | NEW |
| Version | git |
| Component | Drivers/Gallium/radeonsi |
| Product | Mesa |
When running certain programs (eg. MediathekView) or watching = recorded broadcasts on Twitch, X starts going up in CPU usage and the desktop becomes unresponsive, until you kill the stream or the program has finished its draw operations (can take several seconds). Interestingly enough, YouTube videos= are not affected. In both cases I had HW video acceleration on (through setting= s in /etc/adobe/mms.conf), without HW acceleration the plugin is just consuming ridiculous amounts of CPU cycles. The problem with Twitch is independent off chosen video quality. My desktop environment is KDE 4.13.3 with desktop effects enabled (composit= ing type=3DOpenGL 3.1, render target=3Dnative), disabling them has no effect on= this issue. I haven't seen these issues with my previous HD7850 (also using Glamor), therefore I think this is separate to bug 68524. My stack is (base: Debian Testing): GPU: Hawaii PRO [Radeon R9 290] (ChipID =3D 0x67b1) Linux: Git:~agdf5/linux:drm-next-3.17-rebased-on-fixes:fa053e7263 (calls it= self 3.16-rc6) + attachment 93015 [details]= [review] [review] libdrm: Git:master/libdrm-2.4.56 LLVM: SVN:trunk/r214546 (3.6 snapshot) libclc: Git:master/5b48f170c8 Mesa: Git:master/e41cc45361 DDX: Git:master/4b5060f357 + Patch from http://lists.x.org/archives/xorg-driver-ati/2014-July/026517.html X: 2:1.16.0-2 (1.16.0) Let me know, if you need further information.
Please attach the Xorg.0.log and the output of dmesg and glxin= fo. Is this with DPM successfully changing clocks?
(In reply to comment #1= ) > Please attach the Xorg.0.log and the output of d= mesg 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_i= nfo 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, bu= t it would be very weird if the GPU would reclock for "simple" applica= tions and not for the 3D applications, wouldn't it?
CPU profiles from sysprof or perf or oprofile might be interes= ting. AFAICT Twitch requires Flash; what Flash plugin are you using in what brows= er? Does doing anything in particular trigger it in MediathekView?
(In reply to comment #3= ) > CPU profiles from sysprof or perf or oprofile mi= ght 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 update= d. > Does doing anything in particular trigger it in = MediathekView? Sort of: just starting is enough. You get the grey window background at bel= ow average speed and then it takes seconds until the UI elements are drawn (li= st of shows, filter boxes, buttons). Afterwards you can trigger a new CPU spik= e by trying to click anything or even better on each keypress/character input in= to 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? >=20 > Yes, Twitch, like YouTube, requires Flash. I use the plugin installed = by > flashplugin-nonfree and its update-flashplugin-nonfree script. It's th= e 64 > bit version. I check the version number later again. But it was recent= ly > 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 prob= lem 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 i= t in MediathekView? >=20 > 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 trigg= er 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. >=20 > 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 trig= ger it in MediathekView? > >=20 > > Sort of: just starting is enough. You get the grey window backgro= und at > > below average speed and then it takes seconds until the UI elemen= ts 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. >=20 > I can reproduce this with glamor from xserver 1.16.0, but not from cur= rent > 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 bis= ect? If yes, will that commit be backported to the 1.16 branch?
I've uploaded the requested files (at= tachment 103995 [details], att= achment 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 1=
04001 [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. N=
ot
sure I want to put it on the internet, as didn't have time to check what da=
ta
might be disclosed.
(In reply to comment #= 13) > According to the sysprof output, libpixman is th= e 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 binar= ies 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/co= mmit/?id=3D45ebc4e3fac7f1a85167d05e2833949b89f02d64 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. :)
| What | Removed | Added |
|---|---|---|
| Status | NEW | RESOLVED |
| Resolution | --- | FIXED |
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.