Bug 226975 – iPhone 6S - iOS 15.0 - unable to retrieve WebGL2 context

• Component: WebGL
• Status: RESOLVED FIXED

[Luigi De Rosa]

Created attachment 431330 [details]
WebGL2 not active

Browser is unable to get webgl2 context, even though is well enabled in settings (by default).

version: iOS15.0
hardware: iPhone 6S

[Alexey Proskuryakov]

rdar://78966563

[Kenneth Russell]

Kyle mentioned on Slack that ANGLE's Metal backend looks for Apple GPU Family 4 at a minimum, possibly because of features around depth comparison samplers.

The restriction was added in:
https://chromium-review.googlesource.com/c/angle/angle/+/2433332

and is related to:
https://bugs.chromium.org/p/angleproject/issues/detail?id=5107

It's not completely clear to me why GPU Family 4 is needed. It doesn't seem to add features over GPU Family 3 that are required to implement GLES 3.0:
https://developer.apple.com/metal/Metal-Feature-Set-Tables.pdf

[Kimmo Kinnunen]

To recap:

Limitation "iOS GPU Family 4 || macOS GPU Family 1 means GLES 3.0" went in with the shadow texture implementation. This implementation was with GLSL -> SPIRV -> MSL code-path.
It is assumed that this intended to check support of non-trivial `sample_compare` `lod_options` parameters `lod` and `gradient`.

This check is errorneous since this is not what the docs say today, at least from the direct-to-msl implementation perspective.

The docs say that
 a) `sample_compare` has `lod_options`
 b) On macOS `sample_compare` does not support non-trivial `lod_options` prior to Metal 2.2 [sic]
 c) On macOS some hardware supports `sample_compare` `lod` and `gradient` Metal 2.3. [sic]


So the doc leaves a bit much for the reader to intrepret about non-trivial `lod_options`. My interpretation is:
 - On iOS it is always supported (unknown if this is true)
 - On macOS it is not supported by default
 - On macOS Metal >= 2.3 it is supported on unspecified GPUs

So the correct check is:
 `iOS || (macOS && Metal >= 2.3 && GPU == unspecified GPU)`

In direct-to-metal translator we already have feature flags for these features:

   ANGLE_FEATURE_CONDITION((&mFeatures), allowSamplerCompareGradient, supportsEitherGPUFamily(3,1));
    ANGLE_FEATURE_CONDITION((&mFeatures), allowSamplerCompareLod, supportsEitherGPUFamily(3,1));

The condition is not consistent with my interpretation of the specification. 
However, it is more convenient condition, since it enables support for all supported iOS devices.

The feature flag is queried in the _shaders_. As an aside: I don't understand why the shaders aren't generated per feature flag.

However, I'm not versed enough in the functions to understand if the `else` branches
are correct. If I understand correctly, they are not, as otherwise we shouldn't have
the `sample_compare` function in the first place.

The plan of action based on my interpretation:
1) To support WebGL 2.0 on iPhone, iPad at the A9, A10 processor level:
 - downgrade the GLES 3.0 GPU family check to 3.
2) To support GLSL shadow samplers correctly on new macOS versions:
 - implement the fallback correctly
 - implement the unspecified gpu check correctly
3) To support GLSL shadow samplers correctly on older macOS versions 
 - implement the Metal version check correctly

The fast path that currently is the only implemented version cannot be supported on older macOSes at the moment due to Metal versions shipped in these OSes.

Reference:

https://developer.apple.com/metal/Metal-Shading-Language-Specification.pdf

! ios-metal2.1: Support the unified graphics and computing language revision 2.1 programs for iOS 12.
! ios-metal2.2: Support the unified graphics and computing language revision 2.2 programs for iOS 13.
! ios-metal2.3: Support the unified graphics and computing language revision 2.3 programs for iOS 14.

! macos-metal2.1: Support the unified graphics and computing language revision 2.1 programs for macOS 10.14.
! macos-metal2.2: Support the unified graphics and computing language revision 2.2 programs for macOS 10.15.
! macos-metal2.3: Support the unified graphics and computing language revision 2.3 programs for macOS 11.0.


> On macOS prior to Metal 2.2, for sample_compare functions, bias and gradient* are not supported, and lod must be a zero constant. In Metal 2.3, this restriction is lifted for some hardware.
> Since Metal 2.2, you can specify a LOD range for a sampler.

[Kenneth Russell]

Great investigation Kimmo!

It would be great if we could address the issues you've found iteratively. Getting WebGL 2.0 support on A9 and A10 GPUs on iOS is probably the most time-critical issue. Would it be possible to separate out that change, and to do the needed macOS fixes in a follow-up bug?

Is there a way to find out if the assertion is true that sample_compare's lod_options are always supported on iOS?

[Kimmo Kinnunen]

Created attachment 432030 [details]
Patch

[EWS Watchlist]

Note that there are important steps to take when updating ANGLE. See https://trac.webkit.org/wiki/UpdatingANGLE

[Kenneth Russell]

Comment on attachment 432030 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=432030&action=review

> Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/DisplayMtl.mm:-374
> -#if TARGET_OS_SIMULATOR  // Simulator should be able to support ES3, despite not supporting iOS GPU

A bunch of tests are newly failing on the iOS simulator bot. Should this #ifdef be kept?

[Kyle Piddington]

Comment on attachment 432030 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=432030&action=review

>> Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/DisplayMtl.mm:-374
>> -#if TARGET_OS_SIMULATOR  // Simulator should be able to support ES3, despite not supporting iOS GPU
> 
> A bunch of tests are newly failing on the iOS simulator bot. Should this #ifdef be kept?

In this case, yes. iOS simulator supports GPUFamily 2, but not 3, which is why we're going to see test failures.

[Kimmo Kinnunen]

Created attachment 432152 [details]
Patch

[Kenneth Russell]

Comment on attachment 432152 [details]
Patch

Looks good! r+

[EWS]

Committed r279327 (239202@main): <https://commits.webkit.org/239202@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 432152 [details].