Bug 110750

Summary:	Hangouts in ChromeOS pegs the GPU at max frequency
Product:	DRI	Reporter:	Nathan Ciobanu <nathan.d.ciobanu>
Component:	DRM/Intel	Assignee:	Intel GFX Bugs mailing list <intel-gfx-bugs>
Status:	RESOLVED MOVED	QA Contact:	Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity:	major
Priority:	medium	CC:	currojerez, intel-gfx-bugs
Version:	DRI git
Hardware:	x86-64 (AMD64)
OS:	Linux (All)
Whiteboard:	Triaged
i915 platform:	KBL	i915 features:

Description Nathan Ciobanu 2019-05-24 03:45:39 UTC

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.

Comment 1 Chris Wilson 2019-05-24 06:26:45 UTC

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.

Comment 2 Chris Wilson 2019-05-27 10:10:33 UTC

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?

Comment 3 Azhar 2019-05-28 19:42:53 UTC

(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?

Comment 4 Chris Wilson 2019-05-28 21:02:57 UTC

intel_gpu_overlay and intel_gpu_top should show them, and complain loudly if gputop does not!

Comment 5 Chris Wilson 2019-06-21 18:46:06 UTC

As this is ChromeOS is there an image I can download to get the same sw stack to reproduce the bug?

Comment 6 Nathan Ciobanu 2019-07-02 16:12:31 UTC

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.

Comment 7 Lakshmi 2019-08-28 12:31:22 UTC

Update: Chris is waiting for the hw.

Comment 8 Martin Peres 2019-11-29 19:08:06 UTC

-- 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.