[Bug 82055] New: [HAWAII] Running some programs, when HW acceleration is on, causes X to spike in CPU usage → unresponsive desktop
https://bugs.freedesktop.org/show_bug.cgi?id=82055
Priority: medium Bug ID: 82055 Assignee: dri-devel@lists.freedesktop.org Summary: [HAWAII] Running some programs, when HW acceleration is on, causes X to spike in CPU usage → 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 settings 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 (compositing type=OpenGL 3.1, render target=native), 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 = 0x67b1) Linux: Git:~agdf5/linux:drm-next-3.17-rebased-on-fixes:fa053e7263 (calls itself 3.16-rc6) + attachment 93015 [details] [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.
https://bugs.freedesktop.org/show_bug.cgi?id=82055
--- Comment #1 from Michel Dänzer michel@daenzer.net --- Please attach the Xorg.0.log and the output of dmesg and glxinfo.
Is this with DPM successfully changing clocks?
https://bugs.freedesktop.org/show_bug.cgi?id=82055
--- Comment #2 from Kai kai@dev.carbon-project.org --- (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?
https://bugs.freedesktop.org/show_bug.cgi?id=82055
--- Comment #3 from Michel Dänzer michel@daenzer.net --- 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?
https://bugs.freedesktop.org/show_bug.cgi?id=82055
--- Comment #4 from Kai kai@dev.carbon-project.org --- (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.
https://bugs.freedesktop.org/show_bug.cgi?id=82055
--- Comment #5 from Kai kai@dev.carbon-project.org --- (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.
https://bugs.freedesktop.org/show_bug.cgi?id=82055
--- Comment #6 from Michel Dänzer michel@daenzer.net --- (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.
https://bugs.freedesktop.org/show_bug.cgi?id=82055
--- Comment #7 from Kai kai@dev.carbon-project.org --- (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?
https://bugs.freedesktop.org/show_bug.cgi?id=82055
--- Comment #8 from Kai kai@dev.carbon-project.org --- Created attachment 103995 --> https://bugs.freedesktop.org/attachment.cgi?id=103995&action=edit Xorg.0.log
https://bugs.freedesktop.org/show_bug.cgi?id=82055
--- Comment #9 from Kai kai@dev.carbon-project.org --- Created attachment 103996 --> https://bugs.freedesktop.org/attachment.cgi?id=103996&action=edit dmesg output
https://bugs.freedesktop.org/show_bug.cgi?id=82055
--- Comment #10 from Kai kai@dev.carbon-project.org --- Created attachment 103997 --> https://bugs.freedesktop.org/attachment.cgi?id=103997&action=edit glxinfo output
https://bugs.freedesktop.org/show_bug.cgi?id=82055
--- Comment #11 from Kai kai@dev.carbon-project.org --- I've uploaded the requested files (attachment 103995, attachment 103996, attachment 103997) and now checked the installed Flash version, it is 11.2.202.394.
https://bugs.freedesktop.org/show_bug.cgi?id=82055
--- Comment #12 from Kai kai@dev.carbon-project.org --- Created attachment 104000 --> https://bugs.freedesktop.org/attachment.cgi?id=104000&action=edit 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.
https://bugs.freedesktop.org/show_bug.cgi?id=82055
--- Comment #13 from Kai kai@dev.carbon-project.org --- Created attachment 104001 --> https://bugs.freedesktop.org/attachment.cgi?id=104001&action=edit 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.
https://bugs.freedesktop.org/show_bug.cgi?id=82055
--- Comment #14 from Michel Dänzer michel@daenzer.net --- (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=45ebc4e3fac7f1a85167d05e... 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. :)
https://bugs.freedesktop.org/show_bug.cgi?id=82055
Kai kai@dev.carbon-project.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #15 from Kai kai@dev.carbon-project.org --- 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.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org