GNOME Bugzilla – Bug 640314
High CPU usage when playing videos
Last modified: 2021-07-05 13:52:16 UTC
I am experiencing an high CPU usage (stays around 22% of a core of an Intel i5 powered laptop) of Mutter when playing videos using Mplayer / Totem. Mutter + Gnome Shell are from git master compiled with jhbuild on Arch Linux, and this has been happening for some time (maybe always had, I just noticed some time ago). Note that it shouldn't have anything to do with decoding the movie, which is handled without any CPU notice by Mplayer (vdpau) while it takes another CPU slice with Totem (so 22% + Totem). Pausing the video stops the CPU usage. The same behaviour was reported by at least one other Arch Linux user. This does not happen with Metacity, where the CPU usage stays low. How can I help debugging this, I have no clue on what log I should enclose with the bug report. I'm willing to give all the info anybody needs, just point me in the right direction. Cheers, Alessandro
TBH, this probably is not a bug as such, but simply the cost of compositing; compositing means that all content is rendered twice, first by the application into the window, and then by the compositor combining all windows together. In cases where the window content changes across broad area of the window and fast (e.g., video playback), the overhead becomes significant. Other then generic optimatisation of the rendering pipeline, the only other thing to do, which deals with the worst case use case, is to turn off the compositor when showing fullscreen applications; MeeGo Netbook does this but it comes with its own pitfalls (like not being able to draw any of the Shell UI when in the fullscreen mode). Some profiling data on this would be useful.
(In reply to comment #1) > TBH, this probably is not a bug as such, but simply the cost of compositing; > compositing means that all content is rendered twice, first by the application > into the window, and then by the compositor combining all windows together. In > cases where the window content changes across broad area of the window and fast > (e.g., video playback), the overhead becomes significant. I don't think updating one window at 60fps would take 20% of a cpu on a modern machine. (It might take a lot of the GPU, but that won't show up on top.) The CPU usage should be independent of the size of the area being updated. > Other then generic optimatisation of the rendering pipeline, the only other > thing to do, which deals with the worst case use case, is to turn off the > compositor when showing fullscreen applications; MeeGo Netbook does this but it > comes with its own pitfalls (like not being able to draw any of the Shell UI > when in the fullscreen mode). > > Some profiling data on this would be useful. Definitely.
Created attachment 179212 [details] Full screen CPU with top
Created attachment 179213 [details] Resized window CPU usage
(In reply to comment #2) > I don't think updating one window at 60fps would take 20% of a cpu on a modern > machine. (It might take a lot of the GPU, but that won't show up on top.) The > CPU usage should be independent of the size of the area being updated. The CPU usage depends indeed on the size of the window. Full screen takes around 20% of a core, when resized it eats around 10%. I enclosed two screenshots showing the top output (I hope they are useful, I do not if they're should go in a bug report). This seems to be a rather high price to pay for compositing, aving a 10% CPU usage with a resized video playback kills my battery and overheats my legs. Specs of my laptop are: CPU: Intel i5 540 GPU: Nvidia 310M Hope you find this helpful. Cheers and thanks for the great work on the new GNOME experience :)
Can you attach the output of glxinfo?
Created attachment 179238 [details] glxinfo output Output of glxinfo, as requested. Card is listed above, driver is nvidia proprietary, version 260.19.36 (same happened with older versions)
Sorry for adding more noise, but I've changed laptop and it still bugs me on 3.0.2, using a SNB card. I am enclosing two screenshots containing a top windows and a powertop window while playing the same video fullscreen. One screenshot is taken under Gnome Shell, one using the fallback experience. You can see that using the Shell takes more CPU and something like 3-5 Watts more. The power consumption bugs me, my battery lasts more than 4 hours with normal work but as soon as I play a video it gets down to 2 hours at most. Does watching a movie really kill half of the battery with Gnome Shell, that is unfortunate. Enclosing also new glxinfo output for the SNB card. If it help mesa and xf86-video-intel are from git, compiled yesterday.
Created attachment 192443 [details] Power and CPU usage with Gnome Fallback experience
Created attachment 192444 [details] Power and CPU usage with Gnome Shell
Created attachment 192445 [details] Output of glxinfo
While playing a 640x360 h264 video in totem (fullscreen): * In a low power state[1], gnome-shell uses one whole core (100% CPU), and totem takes another full core (100% CPU). * In the default power state[2], gnome-shell uses 30% CPU, and totem uses another 30% CPU. I have an i5-M450 2.40GHz and an ATI HD 5450 running r600g, and I'm using kernel 3.2.1, mesa 8.0-rc1 (from git because I was told OGL perf was much improved in trunk), gnome-shell/totem 3.2, clutter 1.8.2. I'm attaching a sysprof output below, followed by glxinfo. 1. echo low > /sys/class/drm/card0/device/power_profile 2. echo auto > /sys/class/drm/card0/device/power_profile
Created attachment 205751 [details] Sysprof output, fullscreen totem + gnome-shell, card in high power state XZ compressed because bugzie doesn't like large attachments.
Created attachment 205752 [details] Sysprof output, fullscreen totem + gnome-shell, card in low power state XZ compressed because bugzie doesn't like large attachments.
Created attachment 205753 [details] glxinfo
I just started seeing this issue myself upon installing an nvidia card and the binary drivers. I had been using on-chip Ivy Bridge graphics before.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/mutter/-/issues/ Thank you for your understanding and your help.