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

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



Good point wrt luminance/alpha formats.


Just to confirm the guesses below:

For the ES drivers on this device, we up-promote ES2.0 contexts to ES3.1 contexts, and don’t expose the OES_texture_float/half_float extensions.

The drivers support the EXT_color_buffer_float and half_float extensions for rendering to float.


Emulating luminance/luminance alpha using RGBA16F/ RGBA32F seems like a plausible workaround.


Also, I don’t think this is a new problem as such – it also affects previous Mali-based devices since we’ve never exposed OES_texture_float/half_float.

(That doesn’t mean this isn’t a problem, though.)


-- JH


From: owners-public_webgl@khronos.org [mailto:owners-public_webgl@khronos.org] On Behalf Of Olli Etuaho
Sent: 22. mars 2016 10:37
To: Florian Bösch
Cc: Kenneth Russell; Daniel Koch; public webgl
Subject: Re: [Public WebGL] Systemic WebGL extension issue on new mobiles?


As I said support can be added at least by emulating the luminance/alpha formats, and I think everyone agrees that some solution is needed here. I don't think I'm the right person to work on this though, since the issue is not affecting NVIDIA devices.



From: Florian Bösch <pyalot@gmail.com>
Sent: Tuesday, March 22, 2016 11:06 AM
To: Olli Etuaho
Cc: Kenneth Russell; Daniel Koch; public webgl
Subject: Re: [Public WebGL] Systemic WebGL extension issue on new mobiles?


So the solution is? WebGL gets worse on newer device, fact of life?


On Tue, Mar 22, 2016 at 9:15 AM, Olli Etuaho <oetuaho@nvidia.com> wrote:

The root of the issue is that GLES3 doesn't support every format that OES_texture_float supports, mainly the luminance/alpha float formats. Because of this Chromium is correctly not exposing WebGL OES_texture_float on these devices. The proper fix would be having driver support for the extensions, as on Tegra. But since driver support is probably not coming, Chromium would have to add emulation of these formats on top of the GLES3 formats to support the WebGL extensions.


In a way changing the WebGL OES_texture_float spec to not to require these legacy formats that almost nobody uses would also be nice, but the spec has already beed ratified for a long time.



From: owners-public_webgl@khronos.org <owners-public_webgl@khronos.org> on behalf of Florian Bösch <pyalot@gmail.com>
Sent: Monday, March 21, 2016 10:35 PM
To: Kenneth Russell
Cc: Daniel Koch; public webgl
Subject: Re: [Public WebGL] Systemic WebGL extension issue on new mobiles?


Graphics Feature Status

Canvas: Hardware accelerated

Flash: Hardware accelerated

Flash Stage3D: Hardware accelerated

Flash Stage3D Baseline profile: Hardware accelerated

Compositing: Hardware accelerated

Multiple Raster Threads: Disabled

Rasterization: Hardware accelerated

Video Decode: Hardware accelerated

Video Encode: Software only, hardware acceleration unavailable

WebGL: Hardware accelerated

Driver Bug Workarounds






Problems Detected

MediaCodec is still too buggy to use for encoding (b/11536167)

Disabled Features: accelerated_video_encode

ARM driver doesn't like uploading lots of buffer data constantly

Applied Workarounds: use_client_side_arrays_for_stream_buffers

The Mali-Txxx driver does not guarantee flush ordering: 154715, 10068, 269829, 294779, 285292

Applied Workarounds: use_virtualized_gl_contexts

Clear uniforms before first program use on all platforms: 124764, 349137

Applied Workarounds: clear_uniforms_before_first_program_use

Always rewrite vec/mat constructors to be consistent: 398694

Applied Workarounds: scalarize_vec_and_mat_constructor_args

Limit max texure size to 4096 on all of Android

Applied Workarounds: max_texture_size_limit_4096

Raster is using a single thread.

Disabled Features: multiple_raster_threads

GpuMemoryBuffer Status

ATC Software only

ATCIA Software only

DXT1 Software only

DXT5 Software only

ETC1 Software only

R_8 Software only

RGBA_4444 Software only

RGBX_8888 Software only

RGBA_8888 Software only

BGRX_8888 Software only

BGRA_8888 Software only

YUV_420 Software only

YUV_420_BIPLANAR Software only

UYVY_422 Software only

Version Information

Data exported 3/21/2016, 9:30:36 PM

Chrome version Chrome/49.0.2623.91

Operating system Android 6.0.1

Software rendering list version 10.17

Driver bug list version 8.46

ANGLE commit id 83aec70b3d94

2D graphics backend Skia

Command Line Args --use-mobile-user-agent --top-controls-show-threshold=0.5 --top-controls-hide-threshold=0.5 --use-mobile-user-agent --enable-begin-frame-scheduling --enable-pinch --enable-overlay-scrollbar --validate-input-event-stream --enable-longpress-drag-selection --touch-selection-strategy=direction --disable-gpu-process-crash-limit --main-frame-resizes-are-orientation-changes --disable-composited-antialiasing --ui-prioritize-in-gpu-process --profiler-timing=0 --prerender-from-omnibox=enabled --enable-dom-distiller --flag-switches-begin --flag-switches-end --enable-instant-extended-api

Driver Information

Initialization time 25

In-process GPU false

Sandboxed false

GPU0 VENDOR = 0x0000 [ARM], DEVICE= 0x0000 [Mali-T880]

Optimus false

AMD switchable false

Driver vendor

Driver version 1.

Driver date

Pixel shader version 3.10

Vertex shader version 3.10

Max. MSAA samples 16

Machine model name SM-G930F

Machine model version



GL_VERSION OpenGL ES 3.1 v1.r9p0-06dev0.d947148f2a553a38f36261838542a42f

GL_EXTENSIONS GL_EXT_debug_marker GL_ARM_rgba8 GL_ARM_mali_shader_binary GL_OES_depth24 GL_OES_depth_texture GL_OES_depth_texture_cube_map GL_OES_packed_depth_stencil GL_OES_rgb8_rgba8 GL_EXT_read_format_bgra GL_OES_compressed_paletted_texture GL_OES_compressed_ETC1_RGB8_texture GL_OES_standard_derivatives GL_OES_EGL_image GL_OES_EGL_image_external GL_OES_EGL_sync GL_OES_texture_npot GL_OES_vertex_half_float GL_OES_required_internalformat GL_OES_vertex_array_object GL_OES_mapbuffer GL_EXT_texture_format_BGRA8888 GL_EXT_texture_rg GL_EXT_texture_type_2_10_10_10_REV GL_OES_fbo_render_mipmap GL_OES_element_index_uint GL_EXT_shadow_samplers GL_OES_texture_compression_astc GL_KHR_texture_compression_astc_ldr GL_KHR_texture_compression_astc_hdr GL_KHR_debug GL_EXT_occlusion_query_boolean GL_EXT_disjoint_timer_query GL_EXT_blend_minmax GL_EXT_discard_framebuffer GL_OES_get_program_binary GL_OES_texture_3D GL_EXT_texture_storage GL_EXT_multisampled_render_to_texture GL_OES_surfaceless_context GL_OES_texture_stencil8 GL_EXT_shader_pixel_local_storage GL_ARM_shader_framebuffer_fetch GL_ARM_shader_framebuffer_fetch_depth_stencil GL_ARM_mali_program_binary GL_EXT_sRGB GL_EXT_sRGB_write_control GL_EXT_texture_sRGB_decode GL_KHR_blend_equation_advanced GL_KHR_blend_equation_advanced_coherent GL_OES_texture_storage_multisample_2d_array GL_OES_shader_image_atomic GL_EXT_robustness GL_EXT_draw_buffers_indexed GL_OES_draw_buffers_indexed GL_EXT_texture_border_clamp GL_OES_texture_border_clamp GL_EXT_texture_cube_map_array GL_OES_texture_cube_map_array GL_OES_sample_variables GL_OES_sample_shading GL_OES_shader_multisample_interpolation GL_EXT_shader_io_blocks GL_OES_shader_io_blocks GL_EXT_tessellation_shader GL_OES_tessellation_shader GL_EXT_primitive_bounding_box GL_OES_primitive_bounding_box GL_EXT_geometry_shader GL_OES_geometry_shader GL_ANDROID_extension_pack_es31a GL_EXT_gpu_shader5 GL_OES_gpu_shader5 GL_EXT_texture_buffer GL_OES_texture_buffer GL_EXT_copy_image GL_OES_copy_image GL_EXT_color_buffer_half_float GL_EXT_color_buffer_float GL_OVR_multiview GL_OVR_multiview2 GL_OVR_multiview_multisampled_render_to_texture GL_ARM_packed_arithmetic

Disabled Extensions

Window system binding vendor

Window system binding version

Window system binding extensions

Direct rendering Yes

Reset notification strategy 0x8252

GPU process crash count 0


On Mon, Mar 21, 2016 at 9:21 PM, Kenneth Russell <kbr@google.com> wrote:

Could you please enable USB debugging on your device and copy/paste the ASCII text (no formatting is fine; actually is best) from about:gpu? You're right, on these more recent devices it's very poor behavior if WebGL regresses in functionality.





On Mon, Mar 21, 2016 at 10:01 AM, Florian Bösch <pyalot@gmail.com> wrote:

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.





IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.