This has happened to me a number of times; I can generate a report next time it happens  if that would be helpful (and someone could give me a pointer to a doc that explains how to get a trace with the right format and data)

The plaintext contents of about:gpu would be helpful. Just copy/pasting it into a comment here would be fine. Thanks.

attached it as a text file.

I was able to reproduce by opening google maps zooming around and then closing the tab. I can't remember if I have force canvas on on gmaps via a cookie or not, though.

I closed all tabs except this one, and all apps, and still the high perf GPU is stuck on.
Hope that helps

Deleted: stuck.txt 7.9 KB

stuck.txt 7.9 KB View Download

Comment 4 by vijayp@gmail.com, Today (moments ago)
Delete comment ⚐
Not sure if this is a related bug but "preventing sleep" also seems to be stuck at YES for Chrome and it seems to happen in tandem with the dGPU feature. 

I don't know enough about how applications can block sleep but neither safari nor "cat /dev/random > /dev/null) triggers the preventing sleep state in Activity Monitor

P1 to get to the bottom of what's going on with the new hardware. 

According to about:gpu, Chrome thinks that the Intel GPU and not the discrete AMD GPU is active.

pinkerton@: who will own the triage of this bug? Which Chrome office has one of these machines? Our group in MTV doesn't have one but perhaps there's one in the building.

@vijayp: how exactly are you determining that the discrete GPU is stuck "on"? The only reliable mechanism is as follows:

Apple Menu -> About This Mac -> System Report... -> Graphics/Displays

Both GPUs will show up in the list. The one with the entries "Displays:" / "Color LCD:" is the active one.

After kbr's comment, I played around with this a bit more. Here's what I can reproduce reliably.
- the activity monitor app  "requires high perf" field is consistently "yes" for as long as I bothered to wait after I use google maps in chrome.
- the system report method shows it using the radeon when google maps is running in a tab that has focus. When that tab no longer has focus, it seems to continue using the high performance GPU for as long as I waited.

- when the google maps tab is closed, after some time, the system report shows displays attached to the intel GPU, but the activity monitor continues to report that the process requires the high perf GPU.

I previously relied on the activity monitor to discern whether chrome had the gpu stuck on or not.

So I guess there are actually two questions here:
- if google maps is in a background tab, is it expected that the high perf GPU is required? If so, then there is likely a bug somewhere

- if the activity monitor and the system report differ in terms of gpu requirements, who is right? If the system report is right, there's maybe a caching bug in activity monitor, and if the activity monitor is right, then maybe there is a bug in chrome somewhere.

(sorry I meant to write "is it unexpected")

+mark and rsesek, two more Mac wizards

This sounds like an accounting bug in the Activity Monitor. The behavior of Chrome's GPU sub-system is as expected, and as on other Mac models and OS versions. There is a 10 second delay between closing down the last tab utilizing WebGL (and therefore activating the discrete GPU) and switching back to the integrated GPU. This is done to have some hysteresis in the system and prevent dithering between the two GPUs.

Downgrading to P2 as it's now clear that this is just a reporting problem and isn't actually affecting battery life. Does anyone know whether Chrome is in any way responsible for reporting this information to the Activity Monitor? I suspect not.

Is there anything that you’d like us to look at on one of these machines? We have one (a 15" MacBookPro13,3, on-board Intel HD 530 and discrete Radeon Pro 455) in New York. Or are we just down to answering Ken’s questions from comment 11 now? If so:

We don’t tell anything what to report in Activity Monitor. That’s handled by the system. And magic.

Thanks Mark for confirming.

After looking into this more on a slightly older MacBook Pro (Retina, 15", Mid 2015 -- AMD Radeon R9 M370X discrete GPU), the same problem is reproducible there. Changing the synopsis.

It looks to me like Chrome is leaking IOSurfaces in the browser compositor after displaying pages containing WebGL. To reproduce:

1) run:

ioreg -n IOSurfaceRoot

(Thanks ccameron for pointing to this command and for your command line utility in https://bugs.chromium.org/p/chromium/issues/detail?id=158469#c12 )

Note the "retain" count.

2) Navigate Chrome Canary on a MacBook Pro to http://webglsamples.org/aquarium/aquarium.html .

3) Shut down that tab and wait 10 seconds for Chrome's GPU sub-process to switch back to the integrated GPU.

4) run "ioreg -n IOSurfaceRoot" again.

Note that the retain count has increased by ~4. This doesn't happen when visiting simple pages like www.google.com .

I think that this is the reason the browser process is still reported as requiring the high-performance GPU. Utilities like gfxCardStatus report that the system has switched back to the integrated GPU, but I think the browser process is holding on to IOSurfaces that were allocated while running on the discrete GPU.

This is probably fall-out from the fix for  Issue 581777 , when WebGL was promoted into its own layer. Erik, would you be able to help investigate this?

Reducing the CC: list.

Erik, can I please assign this to you?

I'm pretty sure there's a bug in Activity Monitor's "Requires High Perf GPU". [There may very well also be IOSurface leaks, but if so, I'm not finding them.]

Observations:
1) I cannot replicate the "ioreg -n IOSurfaceRoot" result.
2) Launch Chrome from the terminal, navigate to webgl aquarium. Notice that "Chrome", "Chrome Helper", "bash", and "Terminal" all require high GPU.
3) Now quit Chrome. Notice that "bash" and "Terminal" still require high GPU. Pretty sure we're not leaking resources into bash or Terminal. ;)

I'm guessing that Activity Monitor propagates the "Requires High Perf GPU" flag up the process hierarchy, but has a bug where it fails to propagate the negative case up the process hierarchy.

Thanks for investigating Erik. If it's not reproducible, it's not reproducible.