OK, I am not sure what the bug is. 1) we actually run on intel GPU in retina
2) we run on NVIDIA/AMD, but when we collect GPU info, we haven't created a webgl context yet, so we are still on Intel

No matter what, after reading through the code, it seems when we dynamically switch between integrated/discrete GPUs, we don't update the driver bug workarounds. We will need to do that, but it's not trivia, because we need to make sure there is no racing.

(My comment collided somewhat with Mo's)

Whoa! Thank you for catching that Corentin.

The problem seems to be in the full GPU info collection, and which GPU is considered primary. It looks like the GL context that's created for full GPU info collection is created with the kCGLPFAAllowOfflineRenderers context creation attribute, and this causes the context to be created on the Intel GPU rather than the discrete GPU.

This problem isn't unique to the WebGL 2.0 conformance tests; it's happening with the WebGL 1.0 conformance tests on dual-GPU machines as seen here for example:

https://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_ng/builds/190493/steps/webgl_conformance_tests%20on%20NVIDIA%20GPU%20on%20Mac%20Retina%20%28with%20patch%29%20on%20Mac/logs/stdio

(Check another recent build on https://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_ng/ if that one's expired)

I am quite sure the WebGL tests are actually running on the discrete GPU.

Mo, what's the intended behavior in this situation? Which GPU are we supposed to apply driver bug workarounds, etc. for? We don't reset this knowledge when we switch GPUs, so are we supposed to apply workarounds for the integrated or discrete GPU? The compositor and probably the majority of web content will use the integrated GPU, but WebGL will use the discrete GPU exclusively.

The reverse can happen too. When forcing integrated graphics with gfxCardStatus about:gpu gives the following (GPU0 has the NVIDIA vendor ID but the gl_renderer string is for the Intel driver).

Deleted: gpu.html 4.4 KB

gpu.html 4.4 KB View Download

There's a bunch of workarounds that we can't dynamically adjust in a given context or context group.

I think we should handle this specifically on dual gpu mac.  We should always apply integrated gpu workarounds to non-webgl contexts (even they are created on the discrete gpu, they could be migrated to the integrated gpu at any time), and apply discrete gpu workarounds to webgl contexts.

Another option is always apply both discrete gpu + integrated gpu workarounds to non-webgl contexts, and apply discrete gpu workarounds to webgl contexts.

That sounds like it would work, since WebGL contexts are in their own client-side share group.

Another lower-risk option would be to make another exception for the specific driver bug workaround that's affecting the execution of these tests on the Retina MacBook Pros on the waterfall still running 10.9. The correctness issue would still remain, though.

I extended the exception to OSX 10.9 so that the other patch could land but the correctness issue is still worrying.

Is this still a P1 issue? Is there more work to be done here?

zmo@: Gentle ping to reassess this P1.  Is there a plan to apply workarounds for both GPUs in switchable GPU configurations?

Is this something we must fix for WebGL2 release?  I'll mark it as needed for M-55.  zmo@ please adjust priority if it's not required.