Bug 236030

<rdar://problem/88393654>

Is this a recent regression in ANGLE compared to the state of things in Bug 228904?

Can you provide some more details? Does this mean initializing two ANGLE displays, one after the other, with different backends? Does it work in either order?

Created attachment 450748 [details] Patch

Created attachment 450755 [details] Patch

(In reply to Jonah RD from comment #3) > Can you provide some more details? > Does this mean initializing two ANGLE displays, one after the other, with > different backends? Does it work in either order? Initializing first WebGL1 with Metal. Then trying to initialize WebGL2 with OpenGL. The backend is a property of EGLDisplay ANGLE does not differentiate EGLDisplays per backend. Only per "power preference". Hence if we have initialised EGL_DEFAULT_DISPLAY with Metal, it will stay initialised as Metal, even if we ask OpenGL.

> Does it work in either order? No. Ask Metal -> Get Metal Ask OpenGL -> Get Metal Ask OpenGL -> Get OpenGL Ask Metal -> Get OpenGL The only difference is that A8 doesn't support WebGL2 with Metal. So those fail if WebGL1 is asked first.

Committed r289071 (246777@main): <https://commits.webkit.org/246777@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 450755 [details].

Comment on attachment 450755 [details] Patch I don't understand all the implications of this patch. Will it prevent dual-GPU MacBook Pros from using the discrete GPU? Are ANGLE changes needed / desired to make switching between the Metal and OpenGL backends more seamless?

(In reply to Kenneth Russell from comment #9) > Comment on attachment 450755 [details] > Patch > > I don't understand all the implications of this patch. Will it prevent > dual-GPU MacBook Pros from using the discrete GPU? It will not prevent dual-GPU MacBook Pros from using the discrete GPU, as I understand. Previously ANGLE used (NativeDisplay) as the key to store the EGLDisplay. We had to invent new NativeDisplays for power preference contexts, so that we would get power preference specific native displays. You proposed to change the EGL_GetPlatformDisplayEXT semantics. I said the semantics should be to key on all passed in attributes that affect the display behaviour. You proceeded to change the EGL_GetPlatformDisplayEXT implementation to key just on the power preference attribute. This change trusts that ANGLE keys on power preference. This change knows that ANGLE DOES NOT key on OpenGL vs Metal backend. Note: this particular bug would have existed prior to the semantics change, so I'm not saying that the semantics change would have broken anything. It just did not fix all the bugs in this class of bugs. https://chromium-review.googlesource.com/c/angle/angle/+/3231986 >> Geoff > Kimmo Kinnunen > Patchset 6 > Oct 21 > > I can explain this history here and the decision: > Thank you, makes sense. >>I think every parameter is too much to key on, many are small tweaks > I don't think anything passed as the display attributes is optional. I think omitting any of the attributes that WebKit passes causes similar bugs in WebKit that we have with the power preference. > Not saying this patch should block on it.. > Are ANGLE changes needed / desired to make switching between the Metal and > OpenGL backends more seamless? EGL_GetPlatformDisplayEXT should key on all passed in attributes that affect the display behaviour.

Thanks for the detailed history and reminder. Apologies if I or we didn't quite understand all the implications of earlier changes and decisions.

The ANGLE-side fix is ready to be downstreamed: https://chromium-review.googlesource.com/c/angle/angle/+/3440780

(In reply to Jonah RD from comment #12) > The ANGLE-side fix is ready to be downstreamed: > https://chromium-review.googlesource.com/c/angle/angle/+/3440780 Thanks for spending the time. Bug 236030 is tracking the webkit side work.

(In reply to Jonah RD from comment #12) > The ANGLE-side fix is ready to be downstreamed: > https://chromium-review.googlesource.com/c/angle/angle/+/3440780 Thanks for spending the time. Bug 236030 is tracking the webkit side work.

Looks like Bug 237313 tracks it.