1579664 - Reduced performance after GPU switch

Status: RESOLVED FIXED

(Core :: Graphics: Layers, defect, P3)

Description

[Markus Stange [:mstange]]

On macOS systems with two GPUs (integrated and discrete), scrolling performance in Firefox on macOS is reduced when the current GPU is different from the GPU that was in use when the Firefox window was opened.

Steps to reproduce:

1. Install gfxCardStatus from https://gfx.io/
2. Start Firefox with one window, while the integrated GPU is in use.
3. Go to https://www.mozilla.org/en-US/.
4. Switch to the discrete GPU using gfxCardStatus.
5. Open another window of the same size and go to https://www.mozilla.org/en-US/.
6. Compare scrolling smoothness in the two windows, for example using Quartz Debug's FrameMeter overlay window.
7. Switch back to the integrated GPU and compare scrolling smoothness again.

Expected results:
Scrolling should be equally smooth in both windows and as smooth as possible.

Actual results:

	Opened on integrated GPU	Opened on discrete GPU
Scrolled on integrated GPU	55fps	20fps
Scrolled on discrete GPU	40fps-55fps	60fps

Comment 1

[Markus Stange [:mstange]]

Chrome recreates GLContexts when switching GPUs: https://codereview.chromium.org/231863002

Comment 2

[Markus Stange [:mstange]]

Recreating the GLContext would mean that we'd also need to recompile shaders on GPU switch, which is, in some ways, the opposite of what bug 1494763 wants to achieve. Maybe we could keep around two GLContexts, one for each GPU, and reuse them.
Switching GPUs changes a window's CGDirectDisplayID ([[[[window screen] deviceDescription] objectForKey:@"NSScreenNumber"] unsignedIntValue]).
I think the following might be a nice solution:

1. Create one GLContext per CGDirectDisplayID. For compositing into a window, use the GLContext for that window's screen.
2. When a CGDirectDisplayID becomes unused, because no window is on a screen with that ID any more, keep around the GLContext if that display ID is for the internal display (CGDisplayIsBuiltin), otherwise throw the GLContext away.

Comment 3

[Markus Stange [:mstange]]

Attachment: Bug 1579664 - Migrate compositor GLContexts to the active GPU after a GPU switch. r=jgilbert

Comment 4

[Markus Stange [:mstange]]

This is a regression from the Core Animation work. In the past, the OpenGL context from the compositor would follow the GPU switch. Today, all Firefox windows keep using the GPU that was driving the internal display when that Firefox window was opened.

Comment 5

[Markus Stange [:mstange]]

I've done some research on this. Useful resources:

• Technical Note TN2229: Supporting Multiple GPUs on Mac OS X
• Understanding Multi-GPU and Multi-Display Setups
• Device Selection and Fallback for Graphics Rendering in Metal
• The "Metal System Trace" tool in Instruments displays GPU usage broken down by GPU, even for OpenGL work.
• GLContextCGL::ForceGpuSwitchIfNeeded() in Chrome

One thing that was not clear to me in the past was the fact that, on a dual-GPU Macbook Pro, both GPUs can be used at all times. Only one of the GPUs drives the internal display at any given time, but you are free to use the other GPU for your own rendering. If you do so, getting your context onto the screen will incur a slow copy. You can pick the GPU during pixel format creation, or after creation using CGLSetVirtualScreen.
For example, if you include NSOpenGLPFAAllowOfflineRenderers, using NSOpenGLPFAScreenMask, 1 << 0 in the NSOpenGLPixelFormatAttribute list will pick the integrated GPU on my machine, whereas NSOpenGLPFAScreenMask, 1 << 6 will pick the discrete GPU, without forcing a GPU switch for the internal display, and regardless of which GPU currently drives the internal display.
Metal makes GPU selection a lot clearer: there's one MTLDevice for each GPU, and you can pick any. (You'll usually use the "default" device (which is the discrete GPU) or you get the device that currently drives a given screen.)

When an NSOpenGLContext is associated with an NSView, calling -[NSOpenGLContext update] migrates the context to the GPU that drives the screen that the window is on. This is how we were handling GPU switches before we switched to Core Animation.
For NSOpenGLContexts which are not associated with NSViews, -[NSOpenGLContext update] does not seem to have any useful effect.

Comment 6

[Markus Stange [:mstange]]

Attachment: Command line program to enumerate display masks and display IDs

Here's a small program that can be used to play with these things.

Only internal display, when using integrated GPU:

mstange@Markuss-MacBook-Pro enumerate-display-masks % ./test
Active display CGDirectDisplayIDs:
 - display mask: 00000000000000000000000000000001, display ID: 01111011110101111111001111111001
Available display masks for pixel format:
 - display mask: 00000000000000000000000000111111, display ID: 01111011110101111111001111111001, renderer: kCGLRendererIntelHD5000ID
 - display mask: 00000000000000000000011111000000, display ID: 01111011110101111111001111111001, renderer: kCGLRendererATIRadeonX4000ID (Radeon HD 7xxx)
 - display mask: 00000000000000000000000000000000, display ID: 00000000000000000000000000000000, renderer: kCGLRendererGenericFloatID (Apple Software Renderer)

Only internal display, when using discrete GPU:

mstange@Markuss-MacBook-Pro enumerate-display-masks % ./test
Active display CGDirectDisplayIDs:
 - display mask: 00000000000000000000000001000000, display ID: 00000100001010000000110000000110
Available display masks for pixel format:
 - display mask: 00000000000000000000000000111111, display ID: 00000100001010000000110000000110, renderer: kCGLRendererIntelHD5000ID
 - display mask: 00000000000000000000011111000000, display ID: 00000100001010000000110000000110, renderer: kCGLRendererATIRadeonX4000ID (Radeon HD 7xxx)
 - display mask: 00000000000000000000000000000000, display ID: 00000000000000000000000000000000, renderer: kCGLRendererGenericFloatID (Apple Software Renderer)

With connected external display, using discrete GPU:

mstange@Markuss-MacBook-Pro enumerate-display-masks % ./test
Active display CGDirectDisplayIDs:
 - display mask: 00000000000000000000000001000000, display ID: 00000100001010000000110000000110
 - display mask: 00000000000000000000001000000000, display ID: 00011011010101100010011001010101
Available display masks for pixel format:
 - display mask: 00000000000000000000000000111111, display ID: 00000100001010000000110000000110, renderer: kCGLRendererIntelHD5000ID
 - display mask: 00000000000000000000011111000000, display ID: 00000100001010000000110000000110, renderer: kCGLRendererATIRadeonX4000ID (Radeon HD 7xxx)
 - display mask: 00000000000000000000000000000000, display ID: 00000000000000000000000000000000, renderer: kCGLRendererGenericFloatID (Apple Software Renderer)

Comment 7

[Markus Stange [:mstange]]

I've filed bug 1597547 on WebGL.

Comment 8

[Markus Stange [:mstange]]

Attachment: Command line program to enumerate display masks and display IDs

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4ec011830a0b
Migrate compositor GLContexts to the active GPU after a GPU switch. r=jgilbert

Comment 10

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/mozilla-central/rev/4ec011830a0b

Comment 11

[Ryan VanderMeulen [:RyanVM]]

There's only one beta build left before Fx71 goes to RC and this seems like something which could use more baking time than the schedule allows for at this point in the cycle. Marking this as wontfix for 71 but feel free to nominate for uplift if you feel strongly otherwise about that assessment.

Comment 12

[Markus Stange [:mstange]]

I agree, this is a risky change that needs some time to bake.