Running Hangouts on ChromeOS pegs the GPU at max frequency while the camera is enabled. A quicker way to reproduce this issue is to access this URL in the Chrome browser: https://appr.tc/?debug=loopback&vsc=vp8&vrc=vp8 A bisect of the ChromeOS kernel releases has pointed to this patch as the point when this issue started occurring: "7b92c1bd0540 - drm/i915: Avoid keeping waitboost active for signaling threads" which has been backported to chromeos-4.4 and later kernels. It is quite evident what the patch and the subsequent work intended to do but a user space client like Hangouts seems to increase power consumption with no benefit from the increased performance - IIUC. The GPU utilization is between 30 to 40% while the frequency is max at 1050MHz (on my i7 KBL-Y Pixelbook). As an experiment we capped the max GT frequency to 500MHz and saw a drop of about 2W with no hit to performance. Question is: how can we improve the power consumption given the above patch in the Hangouts case? Note; On Ubuntu running Hangouts in the Chrome browser we see more GPU frequency scaling but power consumption is still really high. Since this is more of a question I haven't included logs yet but let me know if you want to see something and I will upload.
On an upstream kernel, grab the frequency, rc6 and load graphs. And you have to identify when the GPU is being boosted for compositor frame delivery as opposed to video transcode -- the compositor is very sensitive to latency and people notice the dropped frames, so the frequency boosting is very much tuned to minimise complaints there.
Fwiw, chromium+hangouts was CPU bound on my bdw laptop and the GPU was not being persistently boosted but bouncing along around 800MHz. I doubt that my install of chromium has the right libva integration?
(In reply to Chris Wilson from comment #1) > On an upstream kernel, grab the frequency, rc6 and load graphs. And you have > to identify when the GPU is being boosted for compositor frame delivery as > opposed to video transcode -- the compositor is very sensitive to latency > and people notice the dropped frames, so the frequency boosting is very much > tuned to minimise complaints there. Hi Chris, > grab the frequency, rc6 and load graphs how do i generate load graphs using gputop? Also gputop does not have rc6 counters? Were you suggesting using gputop or some other binary to get the data?
intel_gpu_overlay and intel_gpu_top should show them, and complain loudly if gputop does not!
As this is ChromeOS is there an image I can download to get the same sw stack to reproduce the bug?
There are no ChromeOS images that you can get easily online, best to check it on a KBL-based Chromebook like Google Pixelbook. If that's not a possibility I can DM you an alternative.
Update: Chris is waiting for the hw.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/302.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.