Bug 1600178 Comment 10 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

(In reply to Bert Peers [:bpeers] from comment #9)
> >> we'd be switching based on "which GPU is driving the display that contains the majority of pixels of this Window", which we somehow need to figure out (in response to a window move/resize?);
> 
> > Windows cannot straddle screens on macOS. A window always maps to one GPU. And we can register notifications with macOS that will be called whenever the GPU for a window changes (with a combination of windowDidChangeScreen: and CGDisplayRegisterReconfigurationCallback).
> 
> Ah, interesting. I was going by [this page, just below Fig. 1-11](https://developer.apple.com/library/archive/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_pg_concepts/opengl_pg_concepts.html#//apple_ref/doc/uid/TP40001987-CH208-SW16): "OpenGL dynamically switches renderers when the virtual screen that contains the majority of the pixels in an OpenGL window changes. ".

Interesting. I think at the time when this documentation was written, windows were able to straddle screens, but it got changed in a later release.

>  But the specifics don't matter if there is an OS callback that does the right thing.

True.

---

I read your description of the proposed implementations, and they all sound reasonable to me, but I don't know this code well enough to make an educated assessment. I think we need sotaro, nical, gw or kvark here, possibly all of them.

> Also, have we tried what happens if we broadcast a device reset when there is an active GPU switch?  That sounds like it should "work", just probably with a lot of flicker if we destroy the compositor and all.  But it could confirm that it solves our problem (by forcing a webrender re-create the hard way).

I have not tried this. I don't know if the code for device resets is even fully hooked up on macOS.

> (I have a single iGPU in the 13" MBP so I can't try)

I think we should get you a machine with two GPUs then, if you want to keep working on this bug.
(In reply to Bert Peers [:bpeers] from comment #9)
> >> we'd be switching based on "which GPU is driving the display that contains the majority of pixels of this Window", which we somehow need to figure out (in response to a window move/resize?);
> >
> > Windows cannot straddle screens on macOS. A window always maps to one GPU. And we can register notifications with macOS that will be called whenever the GPU for a window changes (with a combination of windowDidChangeScreen: and CGDisplayRegisterReconfigurationCallback).
> 
> Ah, interesting. I was going by [this page, just below Fig. 1-11](https://developer.apple.com/library/archive/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_pg_concepts/opengl_pg_concepts.html#//apple_ref/doc/uid/TP40001987-CH208-SW16): "OpenGL dynamically switches renderers when the virtual screen that contains the majority of the pixels in an OpenGL window changes. ".

Interesting. I think at the time when this documentation was written, windows were able to straddle screens, but it got changed in a later release.

>  But the specifics don't matter if there is an OS callback that does the right thing.

True.

---

I read your description of the proposed implementations, and they all sound reasonable to me, but I don't know this code well enough to make an educated assessment. I think we need sotaro, nical, gw or kvark here, possibly all of them.

> Also, have we tried what happens if we broadcast a device reset when there is an active GPU switch?  That sounds like it should "work", just probably with a lot of flicker if we destroy the compositor and all.  But it could confirm that it solves our problem (by forcing a webrender re-create the hard way).

I have not tried this. I don't know if the code for device resets is even fully hooked up on macOS.

> (I have a single iGPU in the 13" MBP so I can't try)

I think we should get you a machine with two GPUs then, if you want to keep working on this bug.

Back to Bug 1600178 Comment 10