[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Systemic WebGL extension issue on new mobiles?

That's true, but the S7 does not support FP16 or FP32 at all in any form. But it does support ES 3.1 contexts. So the reason why WebGL wouldn't have them is I suppose that the driver doesn't expose the extensions on ES 2.0 contexts (because they support ES 3.1).

Explaining how renderability/filterability for FP32 is also lacking (as extensions) on the ES 3.1 context is a bit harder, because 4-year old mobile GPUs from the Nexus 4 does at least have FP32 filterability.

In any case, what is happening is that on brand new mobiles, WebGL got worse, which is extremely undesirable.

On Mon, Mar 21, 2016 at 3:12 PM, Daniel Koch <dkoch@nvidia.com> wrote:
>  and single/half floating point use, filtering and rendering to is part of OpenGL ES 3.1 core behavior.

This statement is incorrect. FP16 and FP32 *textures* are part of OpenGL ES 3.1, but filtering is only required for 16-bit float texture formats and rendering isn’t supported (or allowed without an extension) for either of them. 
The extensions you want for *renderability* are EXT_color_buffer_float and EXT_color_buffer_half_float.

Hope this helps,

On 2016-03-20, 5:50 AM, "owners-public_webgl@khronos.org on behalf of Florian Bösch" <owners-public_webgl@khronos.org on behalf of pyalot@gmail.com> wrote:

I have observed a fairly odd behavior between a Nexus 4 (android 5.1.1) and a Samsung Galaxy s7 (android 6.0.1).

Both support a number of WebGL extensions, but these extensions are not supported by the Samsung Galaxy s7:
  • OES_texture_float
  • OES_texture_half_float
  • OES_texture_half_float_linear
This is odd because the Samsung Galaxy S7 is an OpenGL ES 3.1 compatible device, and single/half floating point use, filtering and rendering to is part of OpenGL ES 3.1 core behavior.

I did notice that no floating point extensions are offered by the native OpenGL ES 3.1 context (which makes sense, because why would you offer something as an extension you support in core functionality).

Is it possible that WebGL contexts do not offer some extensions they do not get native extension support for (and do not emulate them via core functionality)?

If so, I believe we are in quite a bit of a pickle, because WebGL2 is nowhere near release/support in numbers, but extensions will "vanish" on more modern devices. So effectively WebGL 1 now becomes less usable on newer devices. I believe this to be highly counter-intuitive.