1597547 - WebGL GPU switching on macOS isn't working as intended

Status: NEW

(Core :: Graphics: CanvasWebGL, enhancement, P2)

Description

[Markus Stange [:mstange]]

On Mac configurations with multiple GPUs, I'm pretty sure our WebGL OpenGL contexts are never migrated on GPU switches. This causes a few unexpected effects.
See bug 1579664 comment 5 for some background.

Steps to reproduce, a)
0. Be on a dual-GPU Mac which is currently using the integrated GPU to drive the internal display.

1. Create a high-power WebGL context A. (triggers switch to discrete GPU)
2. Create a low-power WebGL context B.
3. Destroy A. (triggers switch to integrated GPU)
4. Keep rendering into B.

B keeps using the high-power discrete GPU, despite having requested low-power, and incurs an extra copy on the way to the screen. Each rendered frame engages both GPUs and a bunch of paging.

Steps to reproduce, b)
0. Be on a dual-GPU Mac which is currently using the integrated GPU to drive the internal display.

1. Create a default-power WebGL context.
2. Keep rendering into the context.

We will eventually force the discrete GPU to drive the internal display, but the WebGL context will still render using the integrated GPU, and it will incur an extra copy on the way to the screen. So we have high power usage but slow speed.

Comment 2

[code]

@:mstange: Thank you for your research! Your findings in bug 1579664 where very interessting and they also lead to an annoying behavior of Firefox (compared to Chrome) when it comes to emscripten-compiled performance-hungry "multimedia" apps such as games based on Unity, DosBox and the likes:

The first time you open them with Firefox on a MacBook Pro, the internal (slow) GPU is used. You can see in the log (shift+apple+j) , that after a second or so, the MacBook switches to the fast GPU, but Firefox still uses the slow GPU context, i.e. the Unity game app, DosBox-emscripten or whatever you are running is slow. Then, if you quickly press page reload (e.g. apple+R), then the fast GPU / discrete GPU is still active, and then also Firefox' GL context is tied to the correct GPU and then everything is fast as expected.

Chrome does this right in the first place.

I think this is a "dangerous" bug for Firefox' reputation, because people would tend to assume, that Firefox is just slow, because they would not expect that a simple page reload will triple or quadruple the frame rate.

(Also as described in at another bug, i.e. bug 1615061)

Comment 3

[Kelsey Gilbert [:jgilbert]]

WebGL's powerPreference:default now means low-power after bug 1579984 in 74.

Comment 4

[MaxGraey]

Hello everyone. Are there any updates? Previously, I could at least separately kill a separate process (Firefox Web Content) that initiated the switch to a discrete GPU. Now this process is Firefox itself and it is very inconvenient to overload it constantly