Bug 212005 – [ANGLE] OES_texture_float_linear is core functionality in ES 3

• Component: WebGL
• Status: RESOLVED WONTFIX

[Dean Jackson]

[ANGLE] OES_texture_float_linear is core functionality in ES 3

[Radar WebKit Bug Importer]

<rdar://problem/63321499>

[Dean Jackson]

Created attachment 399608 [details]
Patch

[EWS Watchlist]

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

[Dean Jackson]

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.

[Kenneth Russell]

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.

[Dean Jackson]

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

[Dean Jackson]

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

[Kenneth Russell]

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?

[Dean Jackson]

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.

[Dean Jackson]

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

[Dean Jackson]

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

[Dean Jackson]

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

[Kenneth Russell]

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?

[Dean Jackson]

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

[Dean Jackson]

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