From khr...@ Fri Mar 4 23:14:46 2016 From: khr...@ (Gregg Tavares) Date: Sat, 5 Mar 2016 16:14:46 +0900 Subject: [Public WebGL] WebGL 2.0 uniform block layout Message-ID: AFAICT from the specs * WebGL 2.0 layout only supports std140 * The layout in GLSL default is implementation specific packed >From the ES 3.0 spec 2.11 > By default, uniforms contained within a uniform block are extracted from buffer storage in an implementation-dependent manner That means currently it is unspecified what the WebGL 2.0 uniform block layout is if the user does not manually specify std140 I assume the intent is that the default for all WebGL 2.0 is the same as std140 but that's not specified AFAICT. Also because of the current spec it's unclear if an shader that hasn't specified std140 is even allowed to compile. It seems like no. On top of that, if I understand correctly, *packed* is the default in OpenGL ES 3? If so, would it better if WebGL basically defined a standard packed format that equals std140? In that case shaders would run as is without each shader having to explicitly declare every uniform block as std140 WebGL implementations would just have to re-write shaders to that say layout(packed, ...) to layout(std140, ...) before compiling (or whatever they do now) Am I making any sense or am I missing something? -gregg -------------- next part -------------- An HTML attachment was scrubbed... URL: From khr...@ Sat Mar 5 08:49:29 2016 From: khr...@ (Gregg Tavares) Date: Sun, 6 Mar 2016 01:49:29 +0900 Subject: [Public WebGL] Uint8ClampedArray can not be used with WebGL Message-ID: I forgot why but currently calls to texImage2D check based on `type` that the corresponding ArrayBuffer type. for type `UNSIGNED_BYTE` currently `Uint8Array` is required which means I get an error if I pass in a `Uint8ClampedArray` gl = document.createElement("canvas").getContext("webgl"); gl.bindTexture(gl.TEXTURE_2D, gl.createTexture()); gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, 1, 1, 0, gl.RGBA, gl.UNSIGNED_BYTE, new Uint8ClampedArray(4)); WebGL: INVALID_OPERATION: texImage2D: type UNSIGNED_BYTE but ArrayBufferView not Uint8Array Should that change? Should it change for WebGL2 if not WebGL1? How about SharedArrays? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Sat Mar 5 10:09:45 2016 From: kbr...@ (Kenneth Russell) Date: Sat, 5 Mar 2016 11:09:45 -0700 Subject: [Public WebGL] Uint8ClampedArray can not be used with WebGL In-Reply-To: References: Message-ID: That's a bug. Uint8ClampedArray used to derive from Uint8Array but the type hierarchy was changed when typed arrays were folded into the ECMAScript spec. It should be fixed for both WebGL 1.0 and 2.0. I've filed https://github.com/KhronosGroup/WebGL/issues/1533 about this. Thanks for reporting the problem. -Ken On Sat, Mar 5, 2016 at 9:49 AM, Gregg Tavares wrote: > I forgot why but currently calls to texImage2D check based on `type` that > the corresponding ArrayBuffer type. > > for type `UNSIGNED_BYTE` currently `Uint8Array` is required which means I > get an error if I pass in a `Uint8ClampedArray` > > gl = document.createElement("canvas").getContext("webgl"); > gl.bindTexture(gl.TEXTURE_2D, gl.createTexture()); > gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, 1, 1, 0, gl.RGBA, > gl.UNSIGNED_BYTE, > new Uint8ClampedArray(4)); > > WebGL: INVALID_OPERATION: texImage2D: type UNSIGNED_BYTE but > ArrayBufferView not Uint8Array > > > Should that change? Should it change for WebGL2 if not WebGL1? > > How about SharedArrays? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Sat Mar 5 10:13:35 2016 From: kbr...@ (Kenneth Russell) Date: Sat, 5 Mar 2016 11:13:35 -0700 Subject: [Public WebGL] Uint8ClampedArray can not be used with WebGL In-Reply-To: References: Message-ID: Also: the intent is that SharedArrayBuffers will be accepted everywhere that ArrayBuffer is accepted in the WebGL API, and typed arrays viewing SharedArrayBuffers will be accepted everywhere as well. In WebGL, data races during texture and buffer uploads are harmless; they might result in incorrect rendering, but won't cause program logic to change its behavior. -Ken On Sat, Mar 5, 2016 at 11:09 AM, Kenneth Russell wrote: > That's a bug. Uint8ClampedArray used to derive from Uint8Array but the > type hierarchy was changed when typed arrays were folded into the > ECMAScript spec. It should be fixed for both WebGL 1.0 and 2.0. I've filed > https://github.com/KhronosGroup/WebGL/issues/1533 about this. Thanks for > reporting the problem. > > -Ken > > > On Sat, Mar 5, 2016 at 9:49 AM, Gregg Tavares > wrote: > >> I forgot why but currently calls to texImage2D check based on `type` that >> the corresponding ArrayBuffer type. >> >> for type `UNSIGNED_BYTE` currently `Uint8Array` is required which means I >> get an error if I pass in a `Uint8ClampedArray` >> >> gl = document.createElement("canvas").getContext("webgl"); >> gl.bindTexture(gl.TEXTURE_2D, gl.createTexture()); >> gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, 1, 1, 0, gl.RGBA, >> gl.UNSIGNED_BYTE, >> new Uint8ClampedArray(4)); >> >> WebGL: INVALID_OPERATION: texImage2D: type UNSIGNED_BYTE but >> ArrayBufferView not Uint8Array >> >> >> Should that change? Should it change for WebGL2 if not WebGL1? >> >> How about SharedArrays? >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Sat Mar 5 10:23:04 2016 From: kbr...@ (Kenneth Russell) Date: Sat, 5 Mar 2016 11:23:04 -0700 Subject: [Public WebGL] WebGL 2.0 uniform block layout In-Reply-To: References: Message-ID: Hi Gregg, Thanks for pointing this out; it's an oversight. Filed https://github.com/KhronosGroup/WebGL/issues/1534 to track it. Not sure which is the best direction; to require that WebGL 2.0 shaders explicitly state they are using the std140 layout, or treat the default layout as std140. I wonder whether auto-upgrading shaders to std140 could potentially cause compatibility issues between native ES 3.0 apps and WebGL 2.0 apps (at least, if porting WebGL 2.0 apps back to ES 3.0). -Ken On Sat, Mar 5, 2016 at 12:14 AM, Gregg Tavares wrote: > AFAICT from the specs > > * WebGL 2.0 layout only supports std140 > > * The layout in GLSL default is implementation specific packed > > From the ES 3.0 spec 2.11 > > > By default, uniforms contained within a uniform block are extracted from > buffer storage in an implementation-dependent manner > > That means currently it is unspecified what the WebGL 2.0 uniform block > layout is if the user does not manually specify std140 > > I assume the intent is that the default for all WebGL 2.0 is the same as > std140 but that's not specified AFAICT. > > Also because of the current spec it's unclear if an shader that hasn't > specified std140 is even allowed to compile. It seems like no. > > On top of that, if I understand correctly, *packed* is the default in > OpenGL ES 3? If so, would it better if WebGL basically defined a standard > packed format that equals std140? In that case shaders would run as is > without each shader having to explicitly declare every uniform block as > std140 > > WebGL implementations would just have to re-write shaders to that say > layout(packed, ...) to layout(std140, ...) before compiling (or whatever > they do now) > > Am I making any sense or am I missing something? > > -gregg > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wil...@ Tue Mar 8 13:17:59 2016 From: wil...@ (Will Eastcott) Date: Tue, 8 Mar 2016 21:17:59 +0000 Subject: [Public WebGL] Who maintains http://get.webgl.org? Message-ID: I was wondering who maintains http://get.webgl.org/. As you may know, the WebGL community tends to use this site as the starting point to figure out if a device actually supports WebGL. However, it specifies the following fragment shader: #ifdef GL_ES precision highp float; #endif void main() { gl_FragColor = vec4(0.4, 0.4, 0.4, 1.0); } If the GPU doesn't support highp (like the Mali 450 MP it would seem), then the page says 'Your browser supports WebGL' but the cube doesn't render and you get the console message: *** Error compiling shader :ERROR: 0:3: 'highp' : precision is not supported in fragment shader The weird thing is, Firefox let's you get away with specifying highp and you see the cube - whereas Chrome fails to compile the shader. I haven't got a clue who to take this up with. I think the fragment shader on the page is just plain wrong. But maybe there's a Chrome issue here too? Or is Firefox at fault? Any ideas? Thanks, Will -- Will Eastcott (@willeastcott ) CEO, PlayCanvas Ltd http://playcanvas.com ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Wed Mar 9 11:13:46 2016 From: kbr...@ (Kenneth Russell) Date: Wed, 9 Mar 2016 12:13:46 -0700 Subject: [Public WebGL] WebGL BOF at GDC Message-ID: [cross-posted to webgl-dev-list] Dear WebGL enthusiasts, If you are in the San Francisco area next week, please come to the WebGL Birds of a Feather session during GDC. Note that a GDC pass is not required to attend the session! More details and registration links here: https://www.khronos.org/news/events/2016-khronos-sessions-san-francisco Hope to see you there! -Ken -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Thu Mar 10 13:29:43 2016 From: kbr...@ (Kenneth Russell) Date: Thu, 10 Mar 2016 13:29:43 -0800 Subject: [Public WebGL] Who maintains http://get.webgl.org? In-Reply-To: References: Message-ID: Hi Will, Sorry for the delay replying. You're absolutely right, the fragment shader was wrong. Thanks for your pull request fixing it. -Ken P.S. I double-checked the WebGL repo and don't think there are other bogus uses of GL_ES. Some of the shaders ported from the OpenGL ES conformance suite still test that macro, though it's not necessary in WebGL (GL_ES is always defined). On Tue, Mar 8, 2016 at 1:17 PM, Will Eastcott wrote: > I was wondering who maintains http://get.webgl.org/. As you may know, the > WebGL community tends to use this site as the starting point to figure out > if a device actually supports WebGL. However, it specifies the following > fragment shader: > > #ifdef GL_ES > precision highp float; > #endif > void main() { > gl_FragColor = vec4(0.4, 0.4, 0.4, 1.0); > } > > If the GPU doesn't support highp (like the Mali 450 MP it would seem), > then the page says 'Your browser supports WebGL' but the cube doesn't > render and you get the console message: > > *** Error compiling shader :ERROR: 0:3: 'highp' : precision is not > supported in fragment shader > > The weird thing is, Firefox let's you get away with specifying highp and > you see the cube - whereas Chrome fails to compile the shader. > > I haven't got a clue who to take this up with. I think the fragment shader > on the page is just plain wrong. But maybe there's a Chrome issue here too? > Or is Firefox at fault? Any ideas? > > Thanks, > > Will > > -- > Will Eastcott (@willeastcott ) > CEO, PlayCanvas Ltd > http://playcanvas.com > ? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sun Mar 20 02:50:22 2016 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 20 Mar 2016 10:50:22 +0100 Subject: [Public WebGL] Systemic WebGL extension issue on new mobiles? Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dko...@ Mon Mar 21 07:12:06 2016 From: dko...@ (Daniel Koch) Date: Mon, 21 Mar 2016 14:12:06 +0000 Subject: [Public WebGL] Systemic WebGL extension issue on new mobiles? In-Reply-To: References: Message-ID: > 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, -Daniel On 2016-03-20, 5:50 AM, "owners-public_webgl...@ on behalf of Florian B?sch" on behalf of pyalot...@> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Mon Mar 21 10:01:15 2016 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Mon, 21 Mar 2016 18:01:15 +0100 Subject: [Public WebGL] Systemic WebGL extension issue on new mobiles? In-Reply-To: References: Message-ID: 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 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, > -Daniel > > > On 2016-03-20, 5:50 AM, "owners-public_webgl...@ on behalf of > Florian B?sch" pyalot...@> 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. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Mon Mar 21 13:21:10 2016 From: kbr...@ (Kenneth Russell) Date: Mon, 21 Mar 2016 13:21:10 -0700 Subject: [Public WebGL] Systemic WebGL extension issue on new mobiles? In-Reply-To: References: Message-ID: 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. -Ken On Mon, Mar 21, 2016 at 10:01 AM, Florian B?sch 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 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, >> -Daniel >> >> >> On 2016-03-20, 5:50 AM, "owners-public_webgl...@ on behalf of >> Florian B?sch" > pyalot...@> 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. >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Mon Mar 21 13:35:24 2016 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Mon, 21 Mar 2016 21:35:24 +0100 Subject: [Public WebGL] Systemic WebGL extension issue on new mobiles? In-Reply-To: References: Message-ID: 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 clear_uniforms_before_first_program_use max_texture_size_limit_4096 scalarize_vec_and_mat_constructor_args use_client_side_arrays_for_stream_buffers use_virtualized_gl_contexts 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_VENDOR ARM GL_RENDERER Mali-T880 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 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. > > -Ken > > > On Mon, Mar 21, 2016 at 10:01 AM, Florian B?sch 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 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, >>> -Daniel >>> >>> >>> On 2016-03-20, 5:50 AM, "owners-public_webgl...@ on behalf of >>> Florian B?sch" >> pyalot...@> 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. >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oet...@ Tue Mar 22 01:15:45 2016 From: oet...@ (Olli Etuaho) Date: Tue, 22 Mar 2016 08:15:45 +0000 Subject: [Public WebGL] Systemic WebGL extension issue on new mobiles? In-Reply-To: References: , Message-ID: <1458634576646.42830@nvidia.com> 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. -Olli ________________________________ From: owners-public_webgl...@ on behalf of Florian B?sch 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 clear_uniforms_before_first_program_use max_texture_size_limit_4096 scalarize_vec_and_mat_constructor_args use_client_side_arrays_for_stream_buffers use_virtualized_gl_contexts 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_VENDOR ARM GL_RENDERER Mali-T880 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 > 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. -Ken On Mon, Mar 21, 2016 at 10:01 AM, Florian B?sch > 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 > 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, -Daniel On 2016-03-20, 5:50 AM, "owners-public_webgl...@ on behalf of Florian B?sch" on behalf of pyalot...@> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue Mar 22 02:06:28 2016 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Tue, 22 Mar 2016 10:06:28 +0100 Subject: [Public WebGL] Systemic WebGL extension issue on new mobiles? In-Reply-To: <1458634576646.42830@nvidia.com> References: <1458634576646.42830@nvidia.com> Message-ID: So the solution is? WebGL gets worse on newer device, fact of life? On Tue, Mar 22, 2016 at 9:15 AM, Olli Etuaho 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. > > > -Olli > ------------------------------ > *From:* owners-public_webgl...@ > on behalf of Florian B?sch > *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 > clear_uniforms_before_first_program_use > max_texture_size_limit_4096 > scalarize_vec_and_mat_constructor_args > use_client_side_arrays_for_stream_buffers > use_virtualized_gl_contexts > 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_VENDOR ARM > GL_RENDERER Mali-T880 > 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 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. >> >> -Ken >> >> >> On Mon, Mar 21, 2016 at 10:01 AM, Florian B?sch 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 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, >>>> -Daniel >>>> >>>> >>>> On 2016-03-20, 5:50 AM, "owners-public_webgl...@ on behalf of >>>> Florian B?sch" >>> pyalot...@> 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. >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oet...@ Tue Mar 22 02:37:22 2016 From: oet...@ (Olli Etuaho) Date: Tue, 22 Mar 2016 09:37:22 +0000 Subject: [Public WebGL] Systemic WebGL extension issue on new mobiles? In-Reply-To: References: <1458634576646.42830@nvidia.com>, Message-ID: <1458639437112.66731@nvidia.com> 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. -Olli ________________________________ From: Florian B?sch 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 > 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. -Olli ________________________________ From: owners-public_webgl...@ > on behalf of Florian B?sch > 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 clear_uniforms_before_first_program_use max_texture_size_limit_4096 scalarize_vec_and_mat_constructor_args use_client_side_arrays_for_stream_buffers use_virtualized_gl_contexts 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_VENDOR ARM GL_RENDERER Mali-T880 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 > 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. -Ken On Mon, Mar 21, 2016 at 10:01 AM, Florian B?sch > 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 > 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, -Daniel On 2016-03-20, 5:50 AM, "owners-public_webgl...@ on behalf of Florian B?sch" on behalf of pyalot...@> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jan...@ Tue Mar 22 04:14:49 2016 From: Jan...@ (Jan-Harald Fredriksen) Date: Tue, 22 Mar 2016 11:14:49 +0000 Subject: [Public WebGL] Systemic WebGL extension issue on new mobiles? In-Reply-To: <1458639437112.66731@nvidia.com> References: <1458634576646.42830@nvidia.com>, <1458639437112.66731@nvidia.com> Message-ID: 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...@ [mailto:owners-public_webgl...@] 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. -Olli ________________________________ From: Florian B?sch > 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 > 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. -Olli ________________________________ From: owners-public_webgl...@ > on behalf of Florian B?sch > 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 clear_uniforms_before_first_program_use max_texture_size_limit_4096 scalarize_vec_and_mat_constructor_args use_client_side_arrays_for_stream_buffers use_virtualized_gl_contexts 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_VENDOR ARM GL_RENDERER Mali-T880 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 > 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. -Ken On Mon, Mar 21, 2016 at 10:01 AM, Florian B?sch > 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 > 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, -Daniel On 2016-03-20, 5:50 AM, "owners-public_webgl...@ on behalf of Florian B?sch" on behalf of pyalot...@> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Tue Mar 22 13:38:56 2016 From: jgi...@ (Jeff Gilbert) Date: Tue, 22 Mar 2016 13:38:56 -0700 Subject: [Public WebGL] Systemic WebGL extension issue on new mobiles? In-Reply-To: <1458634576646.42830@nvidia.com> References: <1458634576646.42830@nvidia.com> Message-ID: FWIW, Firefox should be emulating these already. On Tue, Mar 22, 2016 at 1:15 AM, Olli Etuaho 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. > > > -Olli > > ________________________________ > From: owners-public_webgl...@ on > behalf of Florian B?sch > 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 > clear_uniforms_before_first_program_use > max_texture_size_limit_4096 > scalarize_vec_and_mat_constructor_args > use_client_side_arrays_for_stream_buffers > use_virtualized_gl_contexts > 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_VENDOR ARM > GL_RENDERER Mali-T880 > 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 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. >> >> -Ken >> >> >> On Mon, Mar 21, 2016 at 10:01 AM, Florian B?sch 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 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, >>>> -Daniel >>>> >>>> >>>> On 2016-03-20, 5:50 AM, "owners-public_webgl...@ on behalf of >>>> Florian B?sch" >>> pyalot...@> 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. >>> >>> >> > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Thu Mar 24 14:48:26 2016 From: kbr...@ (Kenneth Russell) Date: Thu, 24 Mar 2016 14:48:26 -0700 Subject: [Public WebGL] Propose moving EXT_color_buffer_float to community approved Message-ID: WebGL community, I'd like to propose moving the EXT_color_buffer_float extension to community approved: https://www.khronos.org/registry/webgl/extensions/EXT_color_buffer_float/ While WebGL 2.0 implementations aren't on by default yet in browsers, there is already a conformance test for this extension; it is passing on multiple prototype implementations; and the extension will definitely be needed once the spec is finalized. Having it as a draft extension is causing some developers confusion. Any comments or objections? Thanks, -Ken -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Mon Mar 28 10:02:10 2016 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Mon, 28 Mar 2016 19:02:10 +0200 Subject: [Public WebGL] WEBGL_subscribe_uniform extension In-Reply-To: References: Message-ID: I suggest to move the WEBGL_subscribe_uniform extension to rejected, for the following reasons: 1. Asynchronous Time Warp (ATW, https://developer.oculus.com/blog/asynchronous-timewarp-on-oculus-rift/) is the preferred method to ensure most up to date HMD input -> display transform. This removes the main motivation for this extension. 2. No further input has been provided on this extension in 16 months 3. No evaluation beyond the initial prototype has occured for 22 fmonths 4. The extension no longer has a champion since 16 months 5. No other champion has come forward in the last 16 months 6. The issues around the extension formulation have not been addressed for 20 months. Repeated calls for a new maintainer the extension have gone unanswered with the last occurring over 12 months ago. I would also like to state on record that I think it's poor form to introduce an extension to the registry without the necessary commitment to see it trough to its conclusion. I strongly disapprove of this sort of registry littering with garbage. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Mon Mar 28 10:11:27 2016 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Mon, 28 Mar 2016 19:11:27 +0200 Subject: [Public WebGL] Propose moving EXT_color_buffer_float to community approved In-Reply-To: References: Message-ID: I have no objection against moving this extension to community approved. In particular I think it is non controversial to move it to community approved because: - It mirrors the ES 3.0 extension of the same name, and exposes the functionality without WebGL specific modifications, so there is very little chance of the specification making trouble further down the road. - Since it would only activate on WebGL 2.0 contexts, and will not be known on WebGL 1.0 contexts, there is no danger of any implementation issue with this extension breaking existing content. I believe it would be permitted to jump an extension from draft to khronos ratified if the khronos board would wish to do so? On Thu, Mar 24, 2016 at 10:48 PM, Kenneth Russell wrote: > WebGL community, > > I'd like to propose moving the EXT_color_buffer_float extension to > community approved: > https://www.khronos.org/registry/webgl/extensions/EXT_color_buffer_float/ > > While WebGL 2.0 implementations aren't on by default yet in browsers, > there is already a conformance test for this extension; it is passing on > multiple prototype implementations; and the extension will definitely be > needed once the spec is finalized. > > Having it as a draft extension is causing some developers confusion. > > Any comments or objections? > > Thanks, > > -Ken > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmi...@ Mon Mar 28 13:18:38 2016 From: dmi...@ (Kirill Dmitrenko) Date: Mon, 28 Mar 2016 23:18:38 +0300 Subject: [Public WebGL] WEBGL_subscribe_uniform extension In-Reply-To: References: Message-ID: <149461459196318@webcorp01d.yandex-team.ru> An HTML attachment was scrubbed... URL: From kbr...@ Mon Mar 28 14:52:30 2016 From: kbr...@ (Kenneth Russell) Date: Mon, 28 Mar 2016 14:52:30 -0700 Subject: [Public WebGL] WEBGL_subscribe_uniform extension In-Reply-To: <149461459196318@webcorp01d.yandex-team.ru> References: <149461459196318@webcorp01d.yandex-team.ru> Message-ID: Apologies for the long delay revisiting this topic. At this point I agree with rejecting this extension. It was always difficult to understand how it would be used effectively by applications, since the values the GPU saw would be a frame or two ahead of the CPU-side code. Additionally, nobody's working on the code any more. The most profitable thing to do at this point is to work on reducing the latency of all WebGL implementations, rather than working around the latency of specific ones. Any other comments? -Ken On Mon, Mar 28, 2016 at 1:18 PM, Kirill Dmitrenko wrote: > I support. More over, I think, the problem is more general and does affect > not only WebGL, but the whole platform. Thus more general solution has to > be introduced. Like a function to request current state of user input > devices (as, if understand correctly, done in gamepad API). > > 28.03.2016, 20:04, "Florian B?sch" : > > I suggest to move the WEBGL_subscribe_uniform extension to rejected, for > the following reasons: > > 1. Asynchronous Time Warp (ATW, > https://developer.oculus.com/blog/asynchronous-timewarp-on-oculus-rift/) > is the preferred method to ensure most up to date HMD input -> display > transform. This removes the main motivation for this extension. > 2. No further input has been provided on this extension in 16 months > 3. No evaluation beyond the initial prototype has occured for 22 > fmonths > 4. The extension no longer has a champion since 16 months > 5. No other champion has come forward in the last 16 months > 6. The issues around the extension formulation have not been addressed > for 20 months. > > Repeated calls for a new maintainer the extension have gone unanswered > with the last occurring over 12 months ago. > > I would also like to state on record that I think it's poor form to > introduce an extension to the registry without the necessary commitment to > see it trough to its conclusion. I strongly disapprove of this sort of > registry littering with garbage. > > > > -- > Kirill Dmitrenko > Yandex Maps Team > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Mon Mar 28 16:02:01 2016 From: kbr...@ (Kenneth Russell) Date: Mon, 28 Mar 2016 16:02:01 -0700 Subject: [Public WebGL] Propose moving EXT_color_buffer_float to community approved In-Reply-To: References: Message-ID: Thanks for your feedback Florian. The most significant gain will be to move the extension to community approved, so it can be enabled by default along with WebGL 2.0. Khronos has specific processes around ratification which shouldn't be bypassed, and that status impacts WebGL extensions very little. Any other comments? Hoping for feedback from Mark Callow and Jeff Gilbert as well. -Ken On Mon, Mar 28, 2016 at 10:11 AM, Florian B?sch wrote: > I have no objection against moving this extension to community approved. > In particular I think it is non controversial to move it to community > approved because: > > - It mirrors the ES 3.0 extension of the same name, and exposes the > functionality without WebGL specific modifications, so there is very little > chance of the specification making trouble further down the road. > - Since it would only activate on WebGL 2.0 contexts, and will not be > known on WebGL 1.0 contexts, there is no danger of any implementation issue > with this extension breaking existing content. > > I believe it would be permitted to jump an extension from draft to khronos > ratified if the khronos board would wish to do so? > > On Thu, Mar 24, 2016 at 10:48 PM, Kenneth Russell wrote: > >> WebGL community, >> >> I'd like to propose moving the EXT_color_buffer_float extension to >> community approved: >> https://www.khronos.org/registry/webgl/extensions/EXT_color_buffer_float/ >> >> While WebGL 2.0 implementations aren't on by default yet in browsers, >> there is already a conformance test for this extension; it is passing on >> multiple prototype implementations; and the extension will definitely be >> needed once the spec is finalized. >> >> Having it as a draft extension is causing some developers confusion. >> >> Any comments or objections? >> >> Thanks, >> >> -Ken >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From khr...@ Mon Mar 28 18:08:57 2016 From: khr...@ (Mark Callow) Date: Tue, 29 Mar 2016 10:08:57 +0900 Subject: [Public WebGL] Propose moving EXT_color_buffer_float to community approved In-Reply-To: References: Message-ID: <580CAB29-2E84-4AEF-A75D-805D40A29AF3@callow.im> > On Mar 29, 2016, at 8:02 AM, Kenneth Russell wrote: > > Any other comments? Hoping for feedback from Mark Callow and Jeff Gilbert as well. > I have no objections. I?ll be happy to see the extension enabled by default. Regards -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: