From pub...@ Mon Aug 3 15:44:10 2020 From: pub...@ (Shrek Shao (...@...)) Date: Mon, 3 Aug 2020 15:44:10 -0700 Subject: [Public WebGL] Announcement of WEBGL_multi_draw move to public Message-ID: Dear WebGL community, We are happy to announce that the WEBGL_multi_draw extension has been moved to community approved. https://www.khronos.org/registry/webgl/extensions/WEBGL_multi_draw/ This extension helps reduce draw call overhead by allowing better batching, which can be useful for apps rendering large models composed of many individual parts, but which all use the same shaders. Such apps frequently face scalability issues with issuing large numbers of draw calls. We expect broad availability of this extension in browsers, since it delivers performance improvements even if implemented in the browser and not the graphics driver. Early profiling with Fraunhofer, a CAD app provider, showed considerable performance improvements when using the extension including ~25% reduction in CPU time, ~9% reduction in GPU time, ~99% reduction in draw calls issued, and ~20% frame rate improvement! We look forward to your using this extension and any feedback you have! We anticipate two additional follow-on extensions to this one, delivering draw calls supporting BaseVertex / BaseInstance functionality. Stay tuned! https://www.khronos.org/registry/webgl/extensions/WEBGL_draw_instanced_base_vertex_base_instance/ https://www.khronos.org/registry/webgl/extensions/WEBGL_multi_draw_instanced_base_vertex_base_instance/ Thanks, -Shrek -------------- next part -------------- An HTML attachment was scrubbed... URL: From pub...@ Wed Aug 5 15:55:28 2020 From: pub...@ (Ray Tran (...@...)) Date: Wed, 5 Aug 2020 23:55:28 +0100 Subject: [Public WebGL] WEBGL extension suggestion: EXT_shader_framebuffer_fetch In-Reply-To: References: <9B3B101D-5674-4D3D-8D08-41959AF1A531@callow.im> Message-ID: Hello, I wanted to get an update on the progress for adding the EXT_shader_framebuffer_fetch extension to WebGL? Has there been any further developments or consideration? Something that I also wanted to share is some useful numbers I found related to the performance gains that can be had on devices that support the EXT_shader_framebuffer_fetch extension that I found - this link refers to impressive performance gains of 28% (from 21fps to 27fps) in the Chrome Compositor running on the Tegra 3 based Nexus 7 Tablet (released in 2012): https://bugs.chromium.org/p/chromium/issues/detail?id=436481. I also want to just reiterate the importance (IMO) of allowing web game and app developers to optimize for what may be considered weaker and older GPUs, in order to be able deliver overall higher quality 3D games and apps on a wider range of devices and therefore larger audiences. I look forward to seeing this extension proposal move forward. Best regards, Ray. On Fri, May 15, 2020 at 4:31 PM Ray Tran wrote: > > Hi Ashley, > > I don't think there is an overlap between the extensions because > developers using each extension will not be getting the same thing: > > - The WEBGL_blend_equation_advanced_coherent extension provides > developers with an extended range of blend modes. > - The EXT_shader_framebuffer_fetch extension provides an extra > built-in fragment shader input. > > Providing developers with an extended range of blend modes can be (and > probably should be) implemented in several different ways depending on > the GPU architecture - one way, if a GPU supports the > EXT_shader_framebuffer_fetch extension, is to make use of the > gl_LastFragData[] extra built-in fragment shader input - but the > WEBGL_blend_equation_advanced_coherent extension isn't actually > dependent on the EXT_shader_framebuffer_fetch extension. > > And what can be done with the extra built-in fragment shader input, on > GPU architectures that support the EXT_shader_framebuffer_fetch > extension, isn't limited to extra blend modes - so it wouldn't be > ideal to limit developers who wish to use the > EXT_shader_framebuffer_fetch extension. > > Cheers, > Ray. > > On Fri, May 15, 2020 at 12:38 PM Ashley Gullen (ashley...@) > wrote: > > > > Out of curiosity, is this extension intended for implementing different kinds of blending in shaders? Is there any overlap with WEBGL_blend_equation_advanced_coherent? (Draft: https://www.khronos.org/registry/webgl/extensions/WEBGL_blend_equation_advanced_coherent/ - no implementations yet AFAIK) > > > > > > On Fri, 15 May 2020 at 11:20, Ray Tran (ray.tran...@) wrote: > >> > >> Hi Ken, > >> > >> Thanks for the reply - the pull request is here: https://github.com/KhronosGroup/WebGL/pull/3074 > >> > >> Do let me know if any changes need to be made to the proposal? > >> > >> Cheers, > >> Ray. > >> > >> > >> > >> On Mon, May 11, 2020 at 11:01 PM Ken Russell (kbr...@) wrote: > >>> > >>> Hi Ray, > >>> > >>> Yes, a high-impact but mostly mobile-only extension like this can certainly be considered. Would you please take a little time and put up a pull request on https://github.com/KhronosGroup/WebGL under https://github.com/KhronosGroup/WebGL/tree/master/extensions/proposals, following the XML pattern there? > >>> > >>> Thanks, > >>> > >>> -Ken > >>> > >>> > >>> > >>> On Mon, May 11, 2020 at 10:05 AM Mark Callow (khronos...@) wrote: > >>>> > >>>> > >>>> > >>>> On May 11, 2020, at 9:50, Ray Tran (ray.tran...@) wrote: > >>>> > >>>> I have also found that > >>>> major mobile GPU vendors have supported and advised developers to use > >>>> this extension to improve performance on their GPUs for many (5+) > >>>> years. > >>>> > >>>> > >>>> This is ironic given the opposition to adding programmable blending to OpenGL over many, many years, decades even, on the grounds that it would cause performance issues. > >>>> > >>>> Regards > >>>> > >>>> -Mark > >>>> > >>> > >>> > >>> -- > >>> I support flexible work schedules, and I?m sending this email now because it is within the hours I?m working today. Please do not feel obliged to reply straight away - I understand that you will reply during the hours you work, which may not match mine. > >>> ----------------------------------------------------------- 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 pub...@ Wed Aug 26 15:51:30 2020 From: pub...@ (Ken Russell (...@...)) Date: Wed, 26 Aug 2020 15:51:30 -0700 Subject: [Public WebGL] WEBGL extension suggestion: EXT_shader_framebuffer_fetch In-Reply-To: References: <9B3B101D-5674-4D3D-8D08-41959AF1A531@callow.im> Message-ID: Hi Ray, Sorry for the delay replying. Probably the best way to motivate this extension further would be to put up a pull request on https://github.com/KhronosGroup/WebGL containing a demo showing its intended use and (hopefully) performance improvement. Understanding that it wouldn't be possible to test the extension until it's prototyped in a browser, it could still help move it up the priority queue. Thanks, -Ken On Wed, Aug 5, 2020 at 3:56 PM Ray Tran (ray.tran...@) < public_webgl...@> wrote: > > Hello, > > I wanted to get an update on the progress for adding the > EXT_shader_framebuffer_fetch extension to WebGL? Has there been any > further developments or consideration? > > Something that I also wanted to share is some useful numbers I found > related to the performance gains that can be had on devices that > support the EXT_shader_framebuffer_fetch extension that I found - this > link refers to impressive performance gains of 28% (from 21fps to > 27fps) in the Chrome Compositor running on the Tegra 3 based Nexus 7 > Tablet (released in 2012): > https://bugs.chromium.org/p/chromium/issues/detail?id=436481. > > I also want to just reiterate the importance (IMO) of allowing web > game and app developers to optimize for what may be considered weaker > and older GPUs, in order to be able deliver overall higher quality 3D > games and apps on a wider range of devices and therefore larger > audiences. > > I look forward to seeing this extension proposal move forward. > > Best regards, > Ray. > > > On Fri, May 15, 2020 at 4:31 PM Ray Tran wrote: > > > > Hi Ashley, > > > > I don't think there is an overlap between the extensions because > > developers using each extension will not be getting the same thing: > > > > - The WEBGL_blend_equation_advanced_coherent extension provides > > developers with an extended range of blend modes. > > - The EXT_shader_framebuffer_fetch extension provides an extra > > built-in fragment shader input. > > > > Providing developers with an extended range of blend modes can be (and > > probably should be) implemented in several different ways depending on > > the GPU architecture - one way, if a GPU supports the > > EXT_shader_framebuffer_fetch extension, is to make use of the > > gl_LastFragData[] extra built-in fragment shader input - but the > > WEBGL_blend_equation_advanced_coherent extension isn't actually > > dependent on the EXT_shader_framebuffer_fetch extension. > > > > And what can be done with the extra built-in fragment shader input, on > > GPU architectures that support the EXT_shader_framebuffer_fetch > > extension, isn't limited to extra blend modes - so it wouldn't be > > ideal to limit developers who wish to use the > > EXT_shader_framebuffer_fetch extension. > > > > Cheers, > > Ray. > > > > On Fri, May 15, 2020 at 12:38 PM Ashley Gullen (ashley...@) > > wrote: > > > > > > Out of curiosity, is this extension intended for implementing > different kinds of blending in shaders? Is there any overlap with > WEBGL_blend_equation_advanced_coherent? (Draft: > https://www.khronos.org/registry/webgl/extensions/WEBGL_blend_equation_advanced_coherent/ > - no implementations yet AFAIK) > > > > > > > > > On Fri, 15 May 2020 at 11:20, Ray Tran (ray.tran...@) < > public_webgl...@> wrote: > > >> > > >> Hi Ken, > > >> > > >> Thanks for the reply - the pull request is here: > https://github.com/KhronosGroup/WebGL/pull/3074 > > >> > > >> Do let me know if any changes need to be made to the proposal? > > >> > > >> Cheers, > > >> Ray. > > >> > > >> > > >> > > >> On Mon, May 11, 2020 at 11:01 PM Ken Russell (kbr...@) < > public_webgl...@> wrote: > > >>> > > >>> Hi Ray, > > >>> > > >>> Yes, a high-impact but mostly mobile-only extension like this can > certainly be considered. Would you please take a little time and put up a > pull request on https://github.com/KhronosGroup/WebGL under > https://github.com/KhronosGroup/WebGL/tree/master/extensions/proposals, > following the XML pattern there? > > >>> > > >>> Thanks, > > >>> > > >>> -Ken > > >>> > > >>> > > >>> > > >>> On Mon, May 11, 2020 at 10:05 AM Mark Callow (khronos...@) < > public_webgl...@> wrote: > > >>>> > > >>>> > > >>>> > > >>>> On May 11, 2020, at 9:50, Ray Tran (ray.tran...@) < > public_webgl...@> wrote: > > >>>> > > >>>> I have also found that > > >>>> major mobile GPU vendors have supported and advised developers to > use > > >>>> this extension to improve performance on their GPUs for many (5+) > > >>>> years. > > >>>> > > >>>> > > >>>> This is ironic given the opposition to adding programmable blending > to OpenGL over many, many years, decades even, on the grounds that it would > cause performance issues. > > >>>> > > >>>> Regards > > >>>> > > >>>> -Mark > > >>>> > > >>> > > >>> > > >>> -- > > >>> I support flexible work schedules, and I?m sending this email now > because it is within the hours I?m working today. Please do not feel > obliged to reply straight away - I understand that you will reply during > the hours you work, which may not match mine. > > >>> > > ----------------------------------------------------------- > 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 > ----------------------------------------------------------- > > -- I support flexible work schedules, and I?m sending this email now because it is within the hours I?m working today. Please do not feel obliged to reply straight away - I understand that you will reply during the hours you work, which may not match mine. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pub...@ Sun Aug 30 09:25:58 2020 From: pub...@ (Ray Tran (...@...)) Date: Sun, 30 Aug 2020 17:25:58 +0100 Subject: [Public WebGL] WEBGL extension suggestion: EXT_shader_framebuffer_fetch In-Reply-To: References: <9B3B101D-5674-4D3D-8D08-41959AF1A531@callow.im> Message-ID: Hi Ken, Thanks for the suggestion - I have updated the extension proposal and submitted a PR here: https://github.com/KhronosGroup/WebGL/pull/3144 I have also put together a demo showing intended use in 3 commonly found use cases in 3D games and apps: https://raytranuk.github.io/tests/ext_demo/extension_proposal_demo.html (the demo is interactive after the autodemo stage - click the buttons to see individual effects) I also provide details in the PR description about the demo and the expected performance gains in PlayCanvas if the EXT_shader_framebuffer_fetch extension was supported in WebGL - and in the future would be happy to provide details to the community of the real results in PlayCanvas and provide tips on to how to achieve higher graphics quality and good performance in WebGL games and apps on mobile (tile-based) GPUs - something similar to a talk I did at SIGGRAPH 2016 about techniques used in a mobile VR game I worked on with a former employer: https://community.arm.com/cfs-file/__key/telligent-evolution-extensions-calendar-calendarfiles/00-00-00-00-05/7_2D00_mmg_2D00_siggraph2016_2D00_gunjack_2D00_ray.pdf I may also be able to get permission from my current employer to help implement the EXT_shader_framebuffer_fetch extension if that would help move this forward? Cheers, Ray. On Wed, Aug 26, 2020 at 11:52 PM Ken Russell (kbr...@) wrote: > > Hi Ray, > > Sorry for the delay replying. > > Probably the best way to motivate this extension further would be to put up a pull request on https://github.com/KhronosGroup/WebGL containing a demo showing its intended use and (hopefully) performance improvement. Understanding that it wouldn't be possible to test the extension until it's prototyped in a browser, it could still help move it up the priority queue. > > Thanks, > > -Ken > > > > On Wed, Aug 5, 2020 at 3:56 PM Ray Tran (ray.tran...@) wrote: >> >> >> Hello, >> >> I wanted to get an update on the progress for adding the >> EXT_shader_framebuffer_fetch extension to WebGL? Has there been any >> further developments or consideration? >> >> Something that I also wanted to share is some useful numbers I found >> related to the performance gains that can be had on devices that >> support the EXT_shader_framebuffer_fetch extension that I found - this >> link refers to impressive performance gains of 28% (from 21fps to >> 27fps) in the Chrome Compositor running on the Tegra 3 based Nexus 7 >> Tablet (released in 2012): >> https://bugs.chromium.org/p/chromium/issues/detail?id=436481. >> >> I also want to just reiterate the importance (IMO) of allowing web >> game and app developers to optimize for what may be considered weaker >> and older GPUs, in order to be able deliver overall higher quality 3D >> games and apps on a wider range of devices and therefore larger >> audiences. >> >> I look forward to seeing this extension proposal move forward. >> >> Best regards, >> Ray. >> >> >> On Fri, May 15, 2020 at 4:31 PM Ray Tran wrote: >> > >> > Hi Ashley, >> > >> > I don't think there is an overlap between the extensions because >> > developers using each extension will not be getting the same thing: >> > >> > - The WEBGL_blend_equation_advanced_coherent extension provides >> > developers with an extended range of blend modes. >> > - The EXT_shader_framebuffer_fetch extension provides an extra >> > built-in fragment shader input. >> > >> > Providing developers with an extended range of blend modes can be (and >> > probably should be) implemented in several different ways depending on >> > the GPU architecture - one way, if a GPU supports the >> > EXT_shader_framebuffer_fetch extension, is to make use of the >> > gl_LastFragData[] extra built-in fragment shader input - but the >> > WEBGL_blend_equation_advanced_coherent extension isn't actually >> > dependent on the EXT_shader_framebuffer_fetch extension. >> > >> > And what can be done with the extra built-in fragment shader input, on >> > GPU architectures that support the EXT_shader_framebuffer_fetch >> > extension, isn't limited to extra blend modes - so it wouldn't be >> > ideal to limit developers who wish to use the >> > EXT_shader_framebuffer_fetch extension. >> > >> > Cheers, >> > Ray. >> > >> > On Fri, May 15, 2020 at 12:38 PM Ashley Gullen (ashley...@) >> > wrote: >> > > >> > > Out of curiosity, is this extension intended for implementing different kinds of blending in shaders? Is there any overlap with WEBGL_blend_equation_advanced_coherent? (Draft: https://www.khronos.org/registry/webgl/extensions/WEBGL_blend_equation_advanced_coherent/ - no implementations yet AFAIK) >> > > >> > > >> > > On Fri, 15 May 2020 at 11:20, Ray Tran (ray.tran...@) wrote: >> > >> >> > >> Hi Ken, >> > >> >> > >> Thanks for the reply - the pull request is here: https://github.com/KhronosGroup/WebGL/pull/3074 >> > >> >> > >> Do let me know if any changes need to be made to the proposal? >> > >> >> > >> Cheers, >> > >> Ray. >> > >> >> > >> >> > >> >> > >> On Mon, May 11, 2020 at 11:01 PM Ken Russell (kbr...@) wrote: >> > >>> >> > >>> Hi Ray, >> > >>> >> > >>> Yes, a high-impact but mostly mobile-only extension like this can certainly be considered. Would you please take a little time and put up a pull request on https://github.com/KhronosGroup/WebGL under https://github.com/KhronosGroup/WebGL/tree/master/extensions/proposals, following the XML pattern there? >> > >>> >> > >>> Thanks, >> > >>> >> > >>> -Ken >> > >>> >> > >>> >> > >>> >> > >>> On Mon, May 11, 2020 at 10:05 AM Mark Callow (khronos...@) wrote: >> > >>>> >> > >>>> >> > >>>> >> > >>>> On May 11, 2020, at 9:50, Ray Tran (ray.tran...@) wrote: >> > >>>> >> > >>>> I have also found that >> > >>>> major mobile GPU vendors have supported and advised developers to use >> > >>>> this extension to improve performance on their GPUs for many (5+) >> > >>>> years. >> > >>>> >> > >>>> >> > >>>> This is ironic given the opposition to adding programmable blending to OpenGL over many, many years, decades even, on the grounds that it would cause performance issues. >> > >>>> >> > >>>> Regards >> > >>>> >> > >>>> -Mark >> > >>>> >> > >>> >> > >>> >> > >>> -- >> > >>> I support flexible work schedules, and I?m sending this email now because it is within the hours I?m working today. Please do not feel obliged to reply straight away - I understand that you will reply during the hours you work, which may not match mine. >> > >>> >> >> ----------------------------------------------------------- >> 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 >> ----------------------------------------------------------- >> > > > -- > I support flexible work schedules, and I?m sending this email now because it is within the hours I?m working today. Please do not feel obliged to reply straight away - I understand that you will reply during the hours you work, which may not match mine. > ----------------------------------------------------------- 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 -----------------------------------------------------------