New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 44 users
Status: Fixed
Closed: Oct 2011
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug

issue 100285
issue 100298
issue 100507
issue 107795

  • Only users with EditIssue permission may comment.

Sign in to add a comment
Chrome always triggers discrete gpu
Project Member Reported by, Jul 8 2011 Back to list
What steps will reproduce the problem?
1. Start chrome

What is the expected result?

No discrete gpu just yet

What happens instead?

discrete gpu is triggered

This is very likely caused by backer's change that allocates iosurfaces for all tabs. Previously they were allocated on demand on gpu process startup, not always when it's needed.

This probably causes higher battery drain, haven't measured though.

Safari somehow manages to run on the integrated gpu when coreanimation is active, maybe we can investigate what they do.
Status: Assigned
At the very least we shouldn't be enabling the discrete gpu until the compositor is needed.  How long has this been broken?
Since ~3 months:
Comment 3 by, Jul 15 2011
 Issue 89448  has been merged into this issue.
Comment 4 by, Jul 15 2011
zmo kindly volunteered to have a look.
Comment 5 by, Jul 19 2011
I added the gpu switch event handler, and wrap flush_events around some suspects.

From the below trace, it is clear which triggered the gpu switch.

#0  (anonymous namespace)::DisplayReconfigCallback (display=69675200, flags=1, gpu_data_manager=0x1670c0) at /Users/google/src/chrome/src/content/browser/gpu/
#1  0x98224992 in displayWillConfigNotifyProc ()
#2  0x980b522b in CGSPostLocalNotification ()
#3  0x980b4f3c in notifyDatagramHandler ()
#4  0x980b21f8 in CGSDispatchDatagramsFromStream ()
#5  0x980b1af1 in snarfEvents ()
#6  0x980b1831 in CGSGetNextEventRecordInternal ()
#7  0x980b174a in CGEventCreateNextEvent ()
#8  0x9745f8ee in PullEventsFromWindowServerOnConnection ()
#9  0x9745f879 in PullEventsFromWindowServer ()
#10 0x9760f22d in FlushEventQueue ()
#11 0x4079e553 in RenderWidgetHostViewMac::AllocateFakePluginWindowHandle (this=0x1391a1e0, opaque=true, root=true) at /Users/google/src/chrome/src/chrome/browser/renderer_host/
#12 0x40796b7c in RenderWidgetHostViewMac::GetCompositingSurface (this=0x1391a1e0) at /Users/google/src/chrome/src/chrome/browser/renderer_host/
#13 0x443ccea5 in RenderWidgetHost::GetCompositingSurface (this=0x181a200) at /Users/google/src/chrome/src/content/browser/renderer_host/
#14 0x443b7707 in RenderViewHost::CreateRenderView (this=0x181a200, frame_name=@0xbfffd5d8) at /Users/google/src/chrome/src/content/browser/renderer_host/
#15 0x4445656d in TabContents::CreateRenderViewForRenderManager (this=0x13914e20, render_view_host=0x181a200) at /Users/google/src/chrome/src/content/browser/tab_contents/
#16 0x4444abc0 in RenderViewHostManager::InitRenderView (this=0x13914edc, render_view_host=0x181a200, entry=@0x13918240) at /Users/google/src/chrome/src/content/browser/tab_contents/
#17 0x4444c77e in RenderViewHostManager::Navigate (this=0x13914edc, entry=@0x13918240) at /Users/google/src/chrome/src/content/browser/tab_contents/
#18 0x4445af45 in TabContents::NavigateToEntry (this=0x13914e20, entry=@0x13918240, reload_type=NavigationController::NO_RELOAD) at /Users/google/src/chrome/src/content/browser/tab_contents/
#19 0x4445b55c in TabContents::NavigateToPendingEntry (this=0x13914e20, reload_type=NavigationController::NO_RELOAD) at /Users/google/src/chrome/src/content/browser/tab_contents/
#20 0x44441077 in NavigationController::NavigateToPendingEntry (this=0x13914e80, reload_type=NavigationController::NO_RELOAD) at /Users/google/src/chrome/src/content/browser/tab_contents/
#21 0x4444288a in NavigationController::LoadEntry (this=0x13914e80, entry=0x13918240) at /Users/google/src/chrome/src/content/browser/tab_contents/
#22 0x44442afe in NavigationController::LoadURL (this=0x13914e80, url=@0xbfffdbe8, referrer=@0xbfffde38, transition=6) at /Users/google/src/chrome/src/content/browser/tab_contents/
#23 0x40af7934 in browser::Navigate (params=0xbfffddf0) at /Users/google/src/chrome/src/chrome/browser/ui/
#24 0x40ae4671 in BrowserInit::LaunchWithProfile::OpenTabsInBrowser (this=0xbfffe3fc, browser=0x164a50, process_startup=true, tabs=@0xbfffdfdc) at /Users/google/src/chrome/src/chrome/browser/ui/
#25 0x40ae479c in BrowserInit::LaunchWithProfile::OpenURLsInBrowser (this=0xbfffe3fc, browser=0x0, process_startup=true, urls=@0xbfffe034) at /Users/google/src/chrome/src/chrome/browser/ui/
#26 0x40ae6a16 in BrowserInit::LaunchWithProfile::ProcessLaunchURLs (this=0xbfffe3fc, process_startup=true, urls_to_open=@0xbfffe40c) at /Users/google/src/chrome/src/chrome/browser/ui/
#27 0x40ae744d in BrowserInit::LaunchWithProfile::Launch (this=0xbfffe3fc, profile=0x137430, urls_to_open=@0xbfffe40c, process_startup=true) at /Users/google/src/chrome/src/chrome/browser/ui/
#28 0x40ae7a14 in BrowserInit::LaunchBrowser (this=0xbfffe8e4, command_line=@0x114540, profile=0x137430, cur_dir=@0xbfffe918, process_startup=true, return_code=0xbfffe91c) at /Users/google/src/chrome/src/chrome/browser/ui/
#29 0x40ae84ab in BrowserInit::ProcessCmdLineImpl (command_line=@0x114540, cur_dir=@0xbfffe918, process_startup=true, profile=0x137430, return_code=0xbfffe91c, browser_init=0xbfffe8e4) at /Users/google/src/chrome/src/chrome/browser/ui/
#30 0x4006df4b in BrowserInit::Start (this=0xbfffe8e4, cmd_line=@0x114540, cur_dir=@0xbfffe918, profile=0x137430, return_code=0xbfffe91c) at browser_init.h:39
#31 0x4006c534 in BrowserMain (parameters=@0xbffff124) at /Users/google/src/chrome/src/chrome/browser/
#32 0x3fd2f8e9 in (anonymous namespace)::RunNamedProcessTypeMain (process_type=@0xbffff190, main_function_params=@0xbffff124) at /Users/google/src/chrome/src/chrome/app/
#33 0x3fd2f5bd in ChromeMain (argc=2, argv=0xbffff8b4) at /Users/google/src/chrome/src/chrome/app/
#34 0x3fd2359c in main (argc=2, argv=0xbffff8b4) at /Users/google/src/chrome/src/chrome/app/

Comment 6 by, Jul 19 2011
kbr points out to me that it is possible to tell the OS that an application (i.e., chrome) is aware of gpu switch, thus, the application manages the switch instead of the OS.

As our plan is to put more and more pages into compositing mode, so delaying the creation of compositing surface won't actually help much.  The right solution might be to stay on integrated gpu for anything except WebGL. 
Comment 7 by, Jul 20 2011
Use a simple GLUT application using NSOpenGL APIs to confirm: initWithAttributes() to get a PixelFormat triggers the GPU switch.

From the tech notes:, it seems that using NSOpenGLPFA AllowOfflineRenderers might prevent the GPU switch.  Unfortunately, we tried it and it didn't work.
Comment 8 by, Aug 26 2011
 Issue 94141  has been merged into this issue.
Comment 9 by, Sep 12 2011
 Issue 75111  has been merged into this issue.
Comment 10 by, Sep 12 2011

This provides a solution for Lion.  Thanks to Chris Niederauer for the information.
QA1734 does not work on Linon running on early 2011 MBP.

Added the attribute, set its value to true and started Chrome - switched to discrete GPU.
Restarted system, started Chrome - switched to discrete GPU.

I don't believe that this attribute does anything if the application is not coded to make use of it.
It is not a workaround.
Comment 12 by, Sep 12 2011
There are steps chrome need to follow (described in to make it happen.  We are working on it.
Comment 13 by, Sep 15 2011
We can successfully get Chromium to stay on the integrated GPU on an Early 2011 MacBook Pro running 10.7 by following the instructions on to add the offline renderer attribute, and the instructions on to add the NSSupportsAutomaticGraphicsSwitching key to the Info.plist of and Chromium

However, we do not have a workable solution for switching to the discrete GPU on demand, which is a requirement in order to maintain competitive performance for WebGL content. We have found it is possible to force a switch to the discrete GPU (of course) simply by removing the kCGLPFAAllowOfflineRenderers bit when creating the pixel format for the context. However, as described in the second article above, this causes the system to stay on the discrete GPU for the lifetime of the process (in Chromium's case, the GPU process).

In Chromium's architecture, it would be possible to work around this limitation by killing and restarting the GPU process when the last tab rendering WebGL content has been closed, but this should not be necessary. A nightly build of WebKit on the same machine behaves as desired: while rendering CSS 3D content, it stays on the integrated GPU, and while rendering WebGL content, it uses the discrete GPU. When navigating away from WebGL content, it's the same OS process that continues to render to the screen, but the switch from discrete to integrated GPU still occurs.

We still need assistance to understand whether it is possible with public APIs to effect the desired switch.

I suppose we could always create a utility process that forces the discrete GPU on. Not the most elegant solution, but....
Comment 15 by, Sep 16 2011
Yes, it looks like that would work.

Comment 16 by, Sep 21 2011
Status: Started
Project Member Comment 17 by, Oct 13 2011
The following revision refers to this bug:

r105399 | | Thu Oct 13 15:55:50 PDT 2011

Changed paths:

Support dynamic switching between integrated and discrete GPUs on Mac OS X.

Change Chrome to allocate most OpenGL contexts with the
kCGLPFAAllowOfflineRenderers flag, and specify
NSSupportsAutomaticGraphicsSwitching in the Info.plist for the main
executable and helper apps. This keeps Chrome on the integrated GPU
except when using WebGL, accelerated 2D Canvas, Pepper 3D, and Core
Animation-based plugins (except Flash).

Chrome shares resources between OpenGL contexts in order to display WebGL
and other content in the compositor, and resource sharing doesn't work
between contexts allocated on different GPUs. Therefore, when the first
context for a given renderer requests the discrete GPU, the channel is
dropped and all contexts are reallocated on the discrete GPU. Similarly,
when the last context requesting the discrete GPU for a given renderer is
shut down, all contexts are dropped and reallocated on the integrated GPU.

Currently dynamic GPU switching is only supported on the latest Mac OS X
10.7 update and MacBook Pros with dual AMD / Intel GPUs, though this will
improve in future OS updates.

Tested with WebGL, CSS 3D, Flash and Unity3D content and observed desired
GPU switching behavior. Also added a layout test to WebKit under which when run in Chrome
catches an assertion failure related to the destruction of contexts. The
intent is to add it as a UI layout test on the GPU bots.

BUG= 88788 
Review URL:
Comment 18 by, Oct 14 2011
Blocking: 100285
Comment 19 by, Oct 14 2011
Blocking: 100298
Comment 20 by, Oct 14 2011
Labels: Mstone-16
Status: Fixed
Support for dynamic GPU switching has been added to Chrome per the above CL.

Currently it only has an effect on the latest MacBook Pros running 10.7.1, and only supports switching from the integrated to the discrete GPU, and not back. However, Apple has indicated that the behavior will improve in the future.

On these machines, Chrome will stay on the integrated GPU unless WebGL, Pepper 3D, or the accelerated 2D canvas are used.

Closing as fixed.

Comment 21 by, Oct 19 2011
Blockedon: 100507
Comment 22 by, Oct 19 2011
Blockedon: -100507
Comment 23 by, Oct 19 2011
Blocking: 100507
Is this a change that should get pushed to existing installs?
My copy still forces the discret GPU when Chrom starts up (15.0.874.92)
Comment 25 by, Oct 19 2011
This change will be in Chrome 16 and later. You can test the functionality now in Canary builds. See .

I have chrome 17.0.942.0 (dev), and it switches as soon as chrome starts.
misha, what is your macbok & OSX model/version?
Same: newest MacBook Pro running Lion. A version of Chromium two back or so
seemed to stay on integrated for a bit, but now it's immediately discrete
before the application load anything. Safari manages to stay integrated for
the entire life of the app...
Comment 29 by, Nov 21 2011
Please post the output of about:gpu.

There was a recent bug fix to Chrome's GPU blocklist which would cause the behavior you describe on OS versions prior to 10.7.2. I have verified that Canary and TOT Chromium stay on the integrated GPU on a Mid 2010 MacBook Pro with dual NVIDIA GeForce GT 330M / Intel GPUs and running 10.7.2.

I have an early 2011 MacBook Pro with an AMD Radeon HD 6750M 1024MB video
card and Lion 10.7.2. My Chrome starts with discrete graphics immediately
and never uses integrated. Also have a 2.2GHz core i7 quad processor.
Comment 31 by, Nov 22 2011
sambecker: please type "about:gpu" into the omnibox and post the output. Copy-paste will be fine and might work better than the HTML.

Please also try running Chrome from the Terminal and passing the command line argument


to ensure that any global settings you might have (including extensions and about:flags changes) aren't affecting things.

We don't have the precise hardware configuration you do, but on a 15" Early 2011 MacBook Pro with dual Intel and AMD Radeon HD 6490M GPUs running 10.7.2 and Chromium r110867, GPU switching is working correctly. When Chrome visits content requiring the GPU, it briefly switches to the discrete chip. Then, if the content isn't WebGL, it switches back to the integrated chip.

Comment 32 by, Nov 22 2011
BTW, the reason I pointed to is that there was a regression in Chrome's compositor on Mac OS soon after that revision, and just fixed within the past hour or so.

This seems to have been fixed for Lion, but not Snow Leopard. On Snow Leopard it still triggers discrete graphics.
Comment 34 by, Dec 16 2011
It is not technically possible for Google to make this work on Snow Leopard; Apple would have to help, as they did to make this work on Lion. I doubt very much that Apple would be receptive to working on this for their now-legacy OS.

Comment 35 by, Jan 5 2012
Blocking: 107795
Just digging this one up again as this behaviour is once again happening for Chrome 21 on Mountain Lion.
And occassionally in Lion for me. But it had been fixed for the longest
time... And is still better, in general,
If you see this in 10.8, can you file a new bug for that please (and then mention the bug number here)?
Labels: Restrict-AddIssueComment-Commit
Ah right, we had to disable gpu switching on 10.8 due to crashy apple drivers. That looks like a good bug to track the 10.8 issue.
Project Member Comment 41 by, Mar 10 2013
Blocking: -chromium:100285 -chromium:100298 -chromium:100507 -chromium:107795 chromium:100285 chromium:100298 chromium:100507 chromium:107795
Labels: -Area-Internals -Feature-GPU -Mstone-16 Cr-Internals-GPU Cr-Internals M-16
Project Member Comment 42 by, Mar 13 2013
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Sign in to add a comment