New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 681341 link

Starred by 20 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows , Mac
Pri: 2
Type: Feature

Blocked on:
issue angleproject:2194
issue 180876

Blocking:
issue 792657
issue 894877
issue 712090



Sign in to add a comment

Investigate power reduction for WebGL

Project Member Reported by kbr@chromium.org, Jan 14 2017

Issue description

On dual-GPU macOS laptops, creating a WebGL context activates the discrete GPU. This consumes a significant amount of power compared to utilizing only the integrated GPU.

The WebGL specification defines the preferLowPowerToHighPerformance context creation attribute, which Chrome doesn't yet implement.

Several aspects aren't clear:

1) Whether this flag is sufficient. Chrome should implement it and see whether it helps with certain applications.

2) Whether dynamically disabling the discrete GPU while a WebGL context allocated while the discrete GPU was active will work.

3) If it is, whether auto-migrating contexts to the integrated GPU when, for example, tabs are backgrounded would be sufficient to save power.

4) Whether the WebGL application should have more control over which GPU is used, for example by adding a new hint indicating "low power" or "high performance" mode.

 

Comment 1 by kbr@chromium.org, Jan 15 2017

Cc: erikc...@chromium.org

Comment 2 by kbr@chromium.org, Jan 15 2017

Labels: Performance-Power

Comment 3 by kbr@chromium.org, Jan 15 2017

A CL for discussion has been posted:
https://codereview.chromium.org/2627323007/

It implements (3) above -- when a tab containing a WebGL tab is backgrounded, its use of the discrete GPU is released. It is reclaimed when the tab moves back to the foreground.

Trivially, it appears to work, but it's not clear whether this is truly legal on macOS. More discussion is needed.

Comment 4 by kbr@chromium.org, Jan 20 2017

Blockedon: 180876
Cc: jbau...@chromium.org
jbauman@ helpfully pointed out  Issue 180876  and in particular:
https://chromium.googlesource.com/chromium/src/+/97419c0f3a44da99c730fc57201172f44a637c8f

which details some of the problems encountered in this area before.

Comment 5 by kbr@chromium.org, Feb 3 2017

Cc: jmad...@chromium.org geoffl...@chromium.org
Components: Internals>GPU>ANGLE
Labels: OS-Windows
Rafael Cintron from Microsoft has pointed out that on Windows, the DirectComposition API can handle composition of GPU resources from both the integrated and discrete GPUs on dual-GPU laptops.

This raises the possibility that Chrome could both:

1) Use the integrated GPU for most tasks, and only activate the discrete GPU for WebGL;

2) Allow WebGL to choose whether to use the integrated or discrete GPU.

jbauman@, what is the current status of the use of DirectComposition in Chrome?

jmadill@, geofflang@, how close is ANGLE to being able to instantiate two Direct3D devices at the same time (even though the OpenGL ES contexts hosted on top of them would not be able to share resources)?

I'm currently working on a patch that allows more general usage of DirectComposition layers for compositing things together. One issue is that webgl content and normal web content would become unsynchronized (I think) if we put them on separate GPUs. Even if they're in separate DirectComposition layers on the same GPU it would be hard to make them work together.

Also we'd have to figure out how to choose which adapter to run on. Normally the graphics driver and D3D choose for us.

Comment 7 by kbr@chromium.org, Feb 4 2017

Thanks John for the feedback. It looks to me like using IDXGIAdapter::GetDesc to describe the adapters returned by IDXGIFactory::EnumAdapters should be sufficient. If we can simply detect systems with both Intel integrated and discrete GPUs, and explicitly choose one or the other, that should work.

The point about desynchronization is a good one. We should see what the properties are with your new patch.

Comment 8 by kbr@chromium.org, Feb 4 2017

Blocking: 678083
I've noticed that Discrete GPU is disabled by default on Windows machines with NVidia and integrated Intel cards (i5/i7).
In NVidia control panel it shows that Chrome is set by default integrated card.

When getting GPU info using WEBGL_debug_renderer_info it reports the one is set in control panel - integrated by default. Without ability for a developer to notify system about which GPU is preferred.

Although Edge on same cases would use NVidia card by default.

This behavior is battery friendly, but only for laptop cases, and only when really needed. And is subject to unfair competition as Edge will perform with WebGL content better as it is using NVidia card vs Integrated.

It would be great to have control over this to allow developer to at least notify system during creation of context which GPU to prefer. And possibly implement a functionality to notify system to preferably switch if possible to allow different mechanics implemented by developer to ensure battery performance on target devices.

Battery Status API - would be useful here, but recently it has been "attacked" by Sensors group regarding potential proposal on dropping it from browsers.

Comment 10 by kbr@chromium.org, Mar 6 2017

The new powerPreference WebGL context creation option that's in the top-of-tree spec at https://www.khronos.org/registry/webgl/specs/latest/1.0/ will allow this. However, Chrome would need more code to know how to enumerate the graphics adapters and explicitly select the discrete one on dual-GPU Windows systems. Additionally, this would only work well if WebGL was rendered into its own DirectComposition layer.

I'd very much like help with this aspect of the code; I know the macOS side well but the Windows side hardly at all.

Comment 11 by kbr@chromium.org, Apr 14 2017

Issue 702900 has been merged into this issue.

Comment 12 by kbr@chromium.org, Apr 26 2017

Cc: kbr@chromium.org djsollen@chromium.org
 Issue 678083  has been merged into this issue.

Comment 13 by kbr@chromium.org, Apr 26 2017

Cc: kbr@chromium.org djsollen@chromium.org
 Issue 678083  has been merged into this issue.

Comment 14 by kbr@chromium.org, Apr 26 2017

Blocking: -678083
 Issue 716290  has been merged into this issue.

Comment 16 by kbr@chromium.org, May 3 2017

Blocking: 712090
Cc: charliea@chromium.org
 Issue 720348  has been merged into this issue.

Comment 19 by sdy@chromium.org, Jun 19 2017

Labels: Hotlist-PlatformExcellence

Comment 20 by kbr@chromium.org, Oct 22 2017

Blockedon: angleproject:2194

Comment 21 by sdy@chromium.org, Nov 6 2017

For macOS, I tried changing the default by editing <https://chromium.googlesource.com/chromium/src/+/521360f6b018ac9870223305db6cabc619571140/gpu/gles2_conform_support/egl/context.cc#285> and it mostly worked. The only issue was that the WebGL context blanked out when another app caused the system to switch to the discrete GPU and then back to the integrated one, but it fixed itself when I resized the window.

Is there a chance of working on the Mac implementation (basically just the web platform plumbing) independent of the ANGLE issue? In addition to the significant power hit of using the discrete GPU, switching blocks the page on my machine for ~300ms. Staying on integrated could make sites like Google Keep load much faster. Any chance of working on it (at least the web platform plumbing) independent of the 

It's worth noting that Safari defaults to the integrated GPU for WebGL.
webgl_gpu.mp4
207 KB View Download

Comment 22 by sdy@chromium.org, Nov 6 2017

Sorry, meant to mention that the attachment in the last comment shows how power consumption in watts changes on my machine as a result of switching GPUs. (It's all above baseline because I'm recording the screen.)

Comment 23 by kbr@chromium.org, Mar 15 2018

Cc: bajones@chromium.org billorr@chromium.org
Blocking: 792657
Blocking: 894877

Sign in to add a comment