Bug 212005

<rdar://problem/63321499>

Created attachment 399608 [details] Patch

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

There are tests for this, but it won't change any expected results until 210524 is resolved. The final patch will include a change to the expectations.

I'm still new to this part of ANGLE, but based on Geoff Lang's feedback on my similar change upstream in ANGLE, https://chromium-review.googlesource.com/2203283 , only formatutilsgl.cpp should be changed. The idea is that ANGLE's GL backend should be advertising the correct extensions to the frontend in order to make the frontend think that these formats are filterable. Note also that OES_texture_half_float_linear is core in ES 3.0 - see Table 3.13 in the OpenGL ES 3.0.6 spec - but OES_texture_float_linear is still an extension. I'm still struggling a bit to make my change pass tests on all devices so that it can be accepted into ANGLE.

You're right - I misread the GL ES 3 documentation. For some reason I don't see iOS advertising this extension.

I think I see the problem. There are some slightly complicated rules for what is filterable, including this: Further, OpenGL ES 3.0 requires that the required floating-point formats with 16-bits per component ('half-float') are filterable, but does not support filtering for floating-point formats with 32-bits per component. Some OpenGL ES 3.0 implementations want a way to indicate that the required floating-point formats with 32-bit per component are also filterable _without_ adding the additional unsized formats from OES_texture_float. This is achieved by exposing this extension without exposing OES_texture_float. For an OpenGL ES 3.0 implementation, the following holds for the combination of the OES_texture_float, OES_texture_float_linear, and OES_texture_half_float_linear extensions: - If none of these extensions are supported: - floating-point formats with 32-bit per component are not filterable - floating-point formats with 16-bit per component are filterable - If OES_texture_float_linear is supported: - all floating-point formats in Table 3.13 are filterable - If OES_texture_float and OES_texture_float_linear are supported: - all floating-point formats in Table 3.13 are filterable - all formats of type FLOAT added by OES_texture_float are filterable - If OES_texture_half_float and OES_texture_half_float_linear are supported: - all floating-point formats in Table 3.13 are filterable - all formats of type HALF_FLOAT_OES added by OES_texture_half_float are filterable

A note that the above text is from the OES_texture_float_linear extension: https://www.khronos.org/registry/OpenGL/extensions/OES/OES_texture_float_linear.txt Which scenario is the case on iOS? On ES 3.0 contexts, is OES_texture_float_linear supported, but not OES_texture_float?

I'm going to edit the name of this bug from "OES_texture_float_linear is core functionality in ES 3" to "iOS mistakenly does not expose OES_texture_float_linear when using a GLES 3 context" I don't know why iOS doesn't claim to expose this extension, seeing as the functionality works.

(In reply to Kenneth Russell from comment #8) > Which scenario is the case on iOS? On ES 3.0 contexts, is > OES_texture_float_linear supported, but not OES_texture_float? On iOS ES 3.0 contexts, neither OES_texture_float_linear or OES_texture_float are listed as supported extensions. The latter case is ok, since floating point formats are supported by default, and you'd only expose that extension if you want indicate extra functionality on OES_texture_float_linear (support for the LUMINANCE, etc legacy formats). But the problem is that iOS *does* support the functionality of OES_texture_float_linear without advertising it.

And, as you know from the other bug, it doesn't claim to support OES_texture_float on ES 2.x contexts either.

(In reply to Dean Jackson from comment #11) > And, as you know from the other bug, it doesn't claim to support > OES_texture_float on ES 2.x contexts either. Oops. I'm wrong. It does advertise that on ES 2.x contexts. It doesn't advertise OES_texture_float_linear anywhere.

Current Safari on the iOS Simulator (without ANGLE) reports the following extensions from the WebGL 1.0 implementation: EXT_blend_minmax EXT_sRGB OES_texture_float OES_texture_float_linear OES_texture_half_float OES_texture_half_float_linear OES_standard_derivatives EXT_shader_texture_lod EXT_texture_filter_anisotropic OES_vertex_array_object OES_element_index_uint WEBGL_lose_context WEBKIT_WEBGL_compressed_texture_pvrtc WEBGL_depth_texture ANGLE_instanced_arrays WEBGL_debug_renderer_info I think WebKit's pre-ANGLE implementation just advertised OES_texture_float_linear if the underlying OpenGL ES implementation supported it. Doesn't that mean that Apple's ES 2.0 contexts (= WebGL 1.0) advertise OES_texture_float_linear?

I now suspect we were advertising support for something we didn't have, and the conformance test wasn't strong enough to detect that.

Yes. It was a mistake we ever exposed this on iOS.