Migrate WebGL contexts on backgrounded tabs to the integrated GPU.

Migrate WebGL contexts on backgrounded tabs to the integrated GPU.

Use the canvas element's PageVisibilityObserver to detect when the tab
is moved to the background, and for WebGL contexts, give a hint that
they should use low power mode. This causes the CGLPixelFormatObj
which was causing the context to use the discrete GPU to be released.

It's not clear whether this is legal. In the past, problems were seen
where the discrete GPU on macOS supported certain resource formats
(textures, renderbuffers, etc.)  that the integrated GPU didn't. It's
not clear what happens to these resources if the system switches from
the discrete to the integrated GPU.

Lightly tested this manually with Google Maps, ShaderToy, and the
WebGL Aquarium. The cost of switching GPUs appears to be low though
not insignificant, but no obviously incorrect rendering was observed.

BUG=681341
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

[Ken Russell (switch to Gerrit), 2017-01-15 03:42:03]

Description was changed from

==========
Migrate WebGL contexts on backgrounded tabs to the integrated GPU.

Use the canvas element's PageVisibilityObserver to detect when the tab
is moved to the background, and for WebGL contexts, give a hint that
they should use low power mode. This causes the CGLPixelFormatObj
which was causing the context to use the discrete GPU to be released.

It's not clear whether this is legal. In the past, problems were seen
where the discrete GPU on macOS supported certain resource formats
(textures, renderbuffers, etc.)  that the integrated GPU didn't. It's
not clear what happens to these resources if the system switches from
the discrete to the integrated GPU.

Lightly tested this manually with Google Maps, ShaderToy, and the
WebGL Aquarium. The cost of switching GPUs appears to be low though
not insignificant, but no obviously incorrect rendering was observed.

BUG=681341
==========

to

==========
Migrate WebGL contexts on backgrounded tabs to the integrated GPU.

Use the canvas element's PageVisibilityObserver to detect when the tab
is moved to the background, and for WebGL contexts, give a hint that
they should use low power mode. This causes the CGLPixelFormatObj
which was causing the context to use the discrete GPU to be released.

It's not clear whether this is legal. In the past, problems were seen
where the discrete GPU on macOS supported certain resource formats
(textures, renderbuffers, etc.)  that the integrated GPU didn't. It's
not clear what happens to these resources if the system switches from
the discrete to the integrated GPU.

Lightly tested this manually with Google Maps, ShaderToy, and the
WebGL Aquarium. The cost of switching GPUs appears to be low though
not insignificant, but no obviously incorrect rendering was observed.

BUG=681341
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

[Ken Russell (switch to Gerrit), 2017-01-15 03:45:54]

kbr@chromium.org changed reviewers:
+ ccameron@chromium.org, jbauman@chromium.org, kainino@chromium.org,
vmiura@chromium.org, zmo@chromium.org

[Ken Russell (switch to Gerrit), 2017-01-15 03:45:54]

All: this CL is only for discussion and further testing; I don't intend to land
it in its current form.

It turned out to not be difficult in Chrome to try this out. More extensive
manual testing, as well as consultation with Apple's OpenGL team, would be
needed in order to ship this. It's also not clear to me if the logic is correct,
based on some observations with gfxCardStatus and rapid tab switching.

Please take a look and share your comments. Thanks. It would be great if others
would be willing to try building and testing this.

(I suppose it would be possible to land this behind a command-line flag to
enable broader testing.)

[jbauman, 2017-01-19 01:13:14]

https://codereview.chromium.org/2627323007/diff/1/ui/gl/gl_context_cgl.cc
File ui/gl/gl_context_cgl.cc (right):

https://codereview.chromium.org/2627323007/diff/1/ui/gl/gl_context_cgl.cc#new...
ui/gl/gl_context_cgl.cc:313: AllocateDiscretePixelFormat();
I'm not sure this would actually switch the context onto the discrete GPU. Once
an offscreen context is created it seems like it's stuck to a GPU until
GLContextCGL::ForceGpuSwitchIfNeeded does CGLSetVirtualScreen, and it won't do
that call if discrete_pixelformat_ exists.

See also
https://chromium.googlesource.com/chromium/src/+/97419c0f3a44da99c730fc572011...
for the issues we've had in the past with switching contexts from the integrated
GPU to the discrete GPU.

[ccameron, 2017-01-20 00:39:26]

The structure looks good, but, yeah, it'll need some thorough manual testing
(and fixes for the cap mismatch issue you mentioned).

Another thing to worry about is that sometimes the OS makes poor paging choices.

[Ken Russell (switch to Gerrit), 2017-01-20 04:34:52]

https://codereview.chromium.org/2627323007/diff/1/ui/gl/gl_context_cgl.cc
File ui/gl/gl_context_cgl.cc (right):

https://codereview.chromium.org/2627323007/diff/1/ui/gl/gl_context_cgl.cc#new...
ui/gl/gl_context_cgl.cc:313: AllocateDiscretePixelFormat();
On 2017/01/19 01:13:14, jbauman wrote:
> I'm not sure this would actually switch the context onto the discrete GPU.
Once
> an offscreen context is created it seems like it's stuck to a GPU until
> GLContextCGL::ForceGpuSwitchIfNeeded does CGLSetVirtualScreen, and it won't do
> that call if discrete_pixelformat_ exists.
> 
> See also
>
https://chromium.googlesource.com/chromium/src/+/97419c0f3a44da99c730fc572011...
> for the issues we've had in the past with switching contexts from the
integrated
> GPU to the discrete GPU.

Thanks for tracking down that change. I'd remembered it vaguely but not done the
code archaeology.

This CL definitely causes gfxCardStatus to think that the machine has switched
back to the integrated GPU, regardless of whether we're calling
CGLSetVirtualScreen. I'm not really sure exactly what effect it has and what
resources are being migrated between GPUs. We are hoping to get some more
details from Apple's OpenGL team about how integrated/discrete GPU transitions
work and exactly what is allowed, and needed, in order to save power in this
area.

[jbauman, 2017-01-20 06:24:47]

On 2017/01/20 04:34:52, Ken Russell OOO-till-Jan-27 wrote:
> https://codereview.chromium.org/2627323007/diff/1/ui/gl/gl_context_cgl.cc
> File ui/gl/gl_context_cgl.cc (right):
> 
>
https://codereview.chromium.org/2627323007/diff/1/ui/gl/gl_context_cgl.cc#new...
> ui/gl/gl_context_cgl.cc:313: AllocateDiscretePixelFormat();
> On 2017/01/19 01:13:14, jbauman wrote:
> > I'm not sure this would actually switch the context onto the discrete GPU.
> Once
> > an offscreen context is created it seems like it's stuck to a GPU until
> > GLContextCGL::ForceGpuSwitchIfNeeded does CGLSetVirtualScreen, and it won't
do
> > that call if discrete_pixelformat_ exists.
> > 
> > See also
> >
>
https://chromium.googlesource.com/chromium/src/+/97419c0f3a44da99c730fc572011...
> > for the issues we've had in the past with switching contexts from the
> integrated
> > GPU to the discrete GPU.
> 
> Thanks for tracking down that change. I'd remembered it vaguely but not done
the
> code archaeology.
> 
> This CL definitely causes gfxCardStatus to think that the machine has switched
> back to the integrated GPU, regardless of whether we're calling
> CGLSetVirtualScreen. I'm not really sure exactly what effect it has and what
> resources are being migrated between GPUs. We are hoping to get some more
> details from Apple's OpenGL team about how integrated/discrete GPU transitions
> work and exactly what is allowed, and needed, in order to save power in this
> area.

I think this code will migrate the context from the discrete GPU to the
integrated GPU, but not vice versa. I think that's hard to detect, besides
checking the performance of WebGL aquarium or something.