Bug 226975

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

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.

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?

Created attachment 432030 [details] Patch

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

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?

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.

Created attachment 432152 [details] Patch

Comment on attachment 432152 [details] Patch Looks good! r+

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].