From chr...@ Thu Jun 1 01:04:33 2017 From: chr...@ (Christophe Riccio) Date: Thu, 1 Jun 2017 10:04:33 +0200 Subject: [Public WebGL] Promote WEBGL_compressed_texture_s3tc_srgb to community approved In-Reply-To: References: Message-ID: This is really great! Thanks everyone :) On Thu, Jun 1, 2017 at 3:59 AM, Kenneth Russell wrote: > Nothing else needs to be done. Thanks Christophe for pushing this and Jeff > for providing the needed second vote from a WebGL implementer. > > Promoted to community approved in https://github.com/ > KhronosGroup/WebGL/pull/2411 . > > Will be exposed in Chrome by default in http://crbug.com/728465 . > > > > On Wed, May 31, 2017 at 12:48 AM, Christophe Riccio < > christophe.riccio...@> wrote: > >> What is the next step to make this happen? >> >> For us not having this extension supported by a web browser means >> decompressing most textures at runtime which is not great :/ >> >> On Wed, May 31, 2017 at 12:20 AM, Jeff Gilbert >> wrote: >> >>> Mozilla supports promoting this to Community Approved. >>> >>> On Fri, May 26, 2017 at 4:51 AM, Christophe Riccio >>> wrote: >>> > Hi, >>> > >>> > Any update on this? We would like to ship linear rendering with WebGL >>> but >>> > this extension is still not community approved. >>> > Chrome is implementing this extension as draft and it works well for >>> us. >>> > >>> > Thanks, >>> > Christophe >>> > >>> > On Sat, Jan 14, 2017 at 10:58 PM, Kenneth Russell >>> wrote: >>> >> >>> >> Google supports moving this extension to community approved. >>> Appreciate >>> >> Unity pointing out its need, and pushing for its support. >>> >> >>> >> -Ken >>> >> >>> >> >>> >> >>> >> On Sat, Jan 14, 2017 at 8:55 AM, Christophe Riccio >>> >> wrote: >>> >>> >>> >>> Yes what Mark said. :) >>> >>> >>> >>> On Sat, Jan 14, 2017 at 2:34 PM, Mark Callow >>> wrote: >>> >>>> >>> >>>> >>> >>>> On Jan 14, 2017, at 22:15, Florian B?sch wrote: >>> >>>> >>> >>>> On Sat, Jan 14, 2017 at 1:11 PM, Christophe Riccio >>> >>>> wrote: >>> >>>>> >>> >>>>> (storing color in linear directly) >>> >>>> >>> >>>> sRGB stores nonlinear color. You write linear into gl_FragColor, but >>> >>>> stored is nonlinear. You just don't do the conversion. Performance >>> impact of >>> >>>> a gamma conversion prior to writing to gl_FragColor is neglible. >>> What isn't >>> >>>> neglible is the effects of blending, which you don't mention. >>> Blending in >>> >>>> nonlinear space produces incorrect results. However the conversion >>> with the >>> >>>> sRGB format is done inside the blending stage, and therefore >>> blending is >>> >>>> done in linear space and only after blending it's serialized to >>> nonlinear >>> >>>> space. >>> >>>> >>> >>>> >>> >>>> I think Christophe knows all that. His comment, which admittedly >>> made me >>> >>>> pause for a moment too, refers to the loss of quality that occurs >>> when you >>> >>>> have to store linear data in your texture, i.e. what happens if only >>> >>>> WEBGL_compressed_texture_s3tc is available. >>> >>>> >>> >>>> Regards >>> >>>> >>> >>>> -Mark >>> >>>> >>> >>> >>> >> >>> > >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mar...@ Thu Jun 1 09:10:30 2017 From: mar...@ (Marco Trivellato) Date: Thu, 1 Jun 2017 17:10:30 +0100 Subject: [Public WebGL] Promote WEBGL_compressed_texture_s3tc_srgb to community approved In-Reply-To: References: Message-ID: Great news, thanks! On Thu, Jun 1, 2017 at 9:04 AM, Christophe Riccio < christophe.riccio...@> wrote: > This is really great! > > Thanks everyone :) > > On Thu, Jun 1, 2017 at 3:59 AM, Kenneth Russell wrote: > >> Nothing else needs to be done. Thanks Christophe for pushing this and >> Jeff for providing the needed second vote from a WebGL implementer. >> >> Promoted to community approved in https://github.com/KhronosG >> roup/WebGL/pull/2411 . >> >> Will be exposed in Chrome by default in http://crbug.com/728465 . >> >> >> >> On Wed, May 31, 2017 at 12:48 AM, Christophe Riccio < >> christophe.riccio...@> wrote: >> >>> What is the next step to make this happen? >>> >>> For us not having this extension supported by a web browser means >>> decompressing most textures at runtime which is not great :/ >>> >>> On Wed, May 31, 2017 at 12:20 AM, Jeff Gilbert >>> wrote: >>> >>>> Mozilla supports promoting this to Community Approved. >>>> >>>> On Fri, May 26, 2017 at 4:51 AM, Christophe Riccio >>>> wrote: >>>> > Hi, >>>> > >>>> > Any update on this? We would like to ship linear rendering with WebGL >>>> but >>>> > this extension is still not community approved. >>>> > Chrome is implementing this extension as draft and it works well for >>>> us. >>>> > >>>> > Thanks, >>>> > Christophe >>>> > >>>> > On Sat, Jan 14, 2017 at 10:58 PM, Kenneth Russell >>>> wrote: >>>> >> >>>> >> Google supports moving this extension to community approved. >>>> Appreciate >>>> >> Unity pointing out its need, and pushing for its support. >>>> >> >>>> >> -Ken >>>> >> >>>> >> >>>> >> >>>> >> On Sat, Jan 14, 2017 at 8:55 AM, Christophe Riccio >>>> >> wrote: >>>> >>> >>>> >>> Yes what Mark said. :) >>>> >>> >>>> >>> On Sat, Jan 14, 2017 at 2:34 PM, Mark Callow >>>> wrote: >>>> >>>> >>>> >>>> >>>> >>>> On Jan 14, 2017, at 22:15, Florian B?sch wrote: >>>> >>>> >>>> >>>> On Sat, Jan 14, 2017 at 1:11 PM, Christophe Riccio >>>> >>>> wrote: >>>> >>>>> >>>> >>>>> (storing color in linear directly) >>>> >>>> >>>> >>>> sRGB stores nonlinear color. You write linear into gl_FragColor, >>>> but >>>> >>>> stored is nonlinear. You just don't do the conversion. Performance >>>> impact of >>>> >>>> a gamma conversion prior to writing to gl_FragColor is neglible. >>>> What isn't >>>> >>>> neglible is the effects of blending, which you don't mention. >>>> Blending in >>>> >>>> nonlinear space produces incorrect results. However the conversion >>>> with the >>>> >>>> sRGB format is done inside the blending stage, and therefore >>>> blending is >>>> >>>> done in linear space and only after blending it's serialized to >>>> nonlinear >>>> >>>> space. >>>> >>>> >>>> >>>> >>>> >>>> I think Christophe knows all that. His comment, which admittedly >>>> made me >>>> >>>> pause for a moment too, refers to the loss of quality that occurs >>>> when you >>>> >>>> have to store linear data in your texture, i.e. what happens if >>>> only >>>> >>>> WEBGL_compressed_texture_s3tc is available. >>>> >>>> >>>> >>>> Regards >>>> >>>> >>>> >>>> -Mark >>>> >>>> >>>> >>> >>>> >> >>>> > >>>> >>> >>> >> > -- *Marco Trivellato* Unity Technologies -------------- next part -------------- An HTML attachment was scrubbed... URL: From JKi...@ Tue Jun 6 05:10:36 2017 From: JKi...@ (Jesse van den Kieboom) Date: Tue, 6 Jun 2017 12:10:36 +0000 Subject: [Public WebGL] Possible issues with FBO and switching color textures Message-ID: <296E1202-DABA-477D-A68A-0790E151DF9F@esri.com> Hi all, We are experiencing a strange issue on certain machines and graphics cards using FBO?s. The issue is as follows: 1. Render some things to FBO with a texture color attachment (tex1) 2. Detach the color texture and attach a different texture (tex2) 3. Render some other things to the same FBO 4. Re-attach the original color texture (tex1) 5. Render some more things while reading back from the second texture (tex2) The problem that we are seeing is that not all the geometry from step 3 are actually rendered at the moment that we are reading back from tex2. Some questions: 1. It seems that doing an explicit flush between step 3 and 4 ?fixes? the problem, which we think could indicate a driver bug. Furthermore, this seems reproducible specifically on a GTX 960M with driver version 369.09. What semantics does WebGL place on flush, and how bad can the performance impact get? 2. Has anybody run into something like this + know about possible workarounds other than using flush? 3. We see this problem specifically on FF using ANGLE. Neither chrome, nor switching to OpenGL exposes this issue. Is there something in the differences of using ANGLE in FF vs Chrome that could explain this (both browsers are up to date). Thanks! Jesse van den Kieboom | Senior Software Engineer Esri R&D Zurich | F?rrlibuckstrasse 110 | 8005 Zurich | Switzerland jkieboom...@ | www.esri.com T: +41 44 204 6032 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Tue Jun 6 16:36:07 2017 From: kbr...@ (Kenneth Russell) Date: Tue, 6 Jun 2017 16:36:07 -0700 Subject: [Public WebGL] Possible issues with FBO and switching color textures In-Reply-To: <296E1202-DABA-477D-A68A-0790E151DF9F@esri.com> References: <296E1202-DABA-477D-A68A-0790E151DF9F@esri.com> Message-ID: CC'ing a few folks directly. Firefox and Chrome are likely using different versions of ANGLE at any particular version of each browser. It's possible that this was a bug that was discovered and worked around in ANGLE. Flushes should hopefully not be that expensive, so calling flush when swapping the framebuffer's attachments should be a reasonable workaround. Do you have a test case that reproduces this problem? We'll gladly work with you to add it to the WebGL conformance suite to try to prevent this from regressing again. Have you tried upgrading your drivers? NVIDIA's already released newer drivers. -Ken On Tue, Jun 6, 2017 at 5:10 AM, Jesse van den Kieboom wrote: > Hi all, > > We are experiencing a strange issue on certain machines and graphics cards > using FBO?s. The issue is as follows: > > > 1. Render some things to FBO with a texture color attachment (tex1) > 2. Detach the color texture and attach a different texture (tex2) > 3. Render some other things to the same FBO > 4. Re-attach the original color texture (tex1) > 5. Render some more things while reading back from the second texture > (tex2) > > > The problem that we are seeing is that not all the geometry from step 3 > are actually rendered at the moment that we are reading back from tex2. > Some questions: > > > 1. It seems that doing an explicit flush between step 3 and 4 ?fixes? > the problem, which we think could indicate a driver bug. Furthermore, this > seems reproducible specifically on a GTX 960M with driver version 369.09. > What semantics does WebGL place on flush, and how bad can the performance > impact get? > 2. Has anybody run into something like this + know about possible > workarounds other than using flush? > 3. We see this problem specifically on FF using ANGLE. Neither chrome, > nor switching to OpenGL exposes this issue. Is there something in the > differences of using ANGLE in FF vs Chrome that could explain this (both > browsers are up to date). > > > > Thanks! > > *Jesse van den Kieboom | Senior Software Engineer* > Esri R&D Zurich | F?rrlibuckstrasse 110 | 8005 Zurich | Switzerland > jkieboom...@ | www.esri.com > T: +41 44 204 6032 <+41%2044%20204%2060%2032> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mar...@ Tue Jun 6 20:01:26 2017 From: mar...@ (=?UTF-8?Q?Markus_M=C3=B6nig?=) Date: Wed, 7 Jun 2017 10:01:26 +0700 Subject: [Public WebGL] Chrome hangs on Shader Compile / Loop Unrolling Message-ID: Hi, we are working on an signed distance field modeller and renderer at www.raysupreme.com (Webgl v2 only). It supports a preview mode and a PBR based path tracer and is currently in alpha. The attached scene hangs Chrome during shader compilation of the path tracer. WebGL seems to try to unroll the path tracer loop which times out the GPU watchdog in Chrome because the map() function for the SDFs is getting quite big (200 lines in this example). Now, the loop for the path tracer, we could unroll this and write results for each pass into a float buffer, we understand this (it would be much slower though). But this unrolling is also creating issues for procedural content creation where nested loops are used to create for example smoke. We run into the same issues with Chrome and its GPU watch dog. Firefox works fine, but shader compilation can take up to 20 seconds (attached screenshot is from FF). So my question, will there be a way to control loop unrolling sometime in the future ? SDFs may sound like a freakish thing, but there a pro games under development using only SDFs, Shadertoy.com is very popular and we get a big interest from users in this tech because it is much easier to model with than complex mesh modelling. Thanks, -Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: House.jpg Type: image/jpeg Size: 488986 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: house(3) Type: application/octet-stream Size: 63720 bytes Desc: not available URL: From mar...@ Tue Jun 6 20:06:40 2017 From: mar...@ (=?UTF-8?Q?Markus_M=C3=B6nig?=) Date: Wed, 7 Jun 2017 10:06:40 +0700 Subject: [Public WebGL] Chrome hangs on Shader Compile / Loop Unrolling Message-ID: Hi, we are working on an signed distance field modeller and renderer at www.raysupreme.com (Webgl v2 only). It supports a preview mode and a PBR based path tracer and is currently in alpha. The attached scene hangs Chrome during shader compilation of the path tracer. WebGL seems to try to unroll the path tracer loop which times out the GPU watchdog in Chrome because the map() function for the SDFs is getting quite big (200 lines in this example). Now, the loop for the path tracer, we could unroll this and write results for each pass into a float buffer, we understand this (it would be much slower though). But this unrolling is also creating issues for procedural content creation where nested loops are used to create for example smoke. We run into the same issues with Chrome and its GPU watch dog. Firefox works fine, but shader compilation can take up to 20 seconds (attached screenshot is from FF). So my question, will there be a way to control loop unrolling sometime in the future ? SDFs may sound like a freakish thing, but there a pro games under development using only SDFs, Shadertoy.com is very popular and we get a big interest from users in this tech because it is much easier to model with than complex mesh modelling. Thanks, -Markus -------------- next part -------------- A non-text attachment was scrubbed... Name: House.jpg Type: image/jpeg Size: 488986 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: house(3) Type: application/octet-stream Size: 63720 bytes Desc: not available URL: From JKi...@ Wed Jun 7 01:43:23 2017 From: JKi...@ (Jesse van den Kieboom) Date: Wed, 7 Jun 2017 08:43:23 +0000 Subject: [Public WebGL] Possible issues with FBO and switching color textures In-Reply-To: References: <296E1202-DABA-477D-A68A-0790E151DF9F@esri.com> Message-ID: On 7 Jun 2017, at 01:36, Kenneth Russell > wrote: Firefox and Chrome are likely using different versions of ANGLE at any particular version of each browser. It's possible that this was a bug that was discovered and worked around in ANGLE. We actually asked around a bit more, and while I originally thought this was isolated to FF, this problem seems to also occur with Chrome with specific nvidia driver versions (specifically reproducible with NVIDIA Quadro K620, driver version 361.91, latest Chrome and FF). Is there a way to find out which ANGLE version is bundled with the browsers? Flushes should hopefully not be that expensive, so calling flush when swapping the framebuffer's attachments should be a reasonable workaround. In our specific scenario that I?m testing I?m measuring (using console.time) 2x increase (from ~1.5ms to ~3ms) on this particular machine. I understand this doesn?t mean much without knowing about the specifics of what we are rendering, but it seems significant for our specific work load. Is there a way to get more detailed profiling information on a stall caused by calling flush (e.g. I imagine this also needs to flush commands queued up in the browser to the GPU process)? Do you have a test case that reproduces this problem? We'll gladly work with you to add it to the WebGL conformance suite to try to prevent this from regressing again. I don?t have an isolated test case for this. I?m not sure how easy it will be to reproduce since if this is somehow triggered by a GPU driver queue specific problem, then we probably will need to get it in some specific state before the problem shows. I will try though if I find some time. Have you tried upgrading your drivers? NVIDIA's already released newer drivers. Yes, this seems to fix the issue that we are seeing. Unfortunately our regular user/consumer base does not tend to keep their drivers up to date and we want to avoid problems when we silently update our platform for the next release. -Ken On Tue, Jun 6, 2017 at 5:10 AM, Jesse van den Kieboom > wrote: Hi all, We are experiencing a strange issue on certain machines and graphics cards using FBO?s. The issue is as follows: 1. Render some things to FBO with a texture color attachment (tex1) 2. Detach the color texture and attach a different texture (tex2) 3. Render some other things to the same FBO 4. Re-attach the original color texture (tex1) 5. Render some more things while reading back from the second texture (tex2) The problem that we are seeing is that not all the geometry from step 3 are actually rendered at the moment that we are reading back from tex2. Some questions: 1. It seems that doing an explicit flush between step 3 and 4 ?fixes? the problem, which we think could indicate a driver bug. Furthermore, this seems reproducible specifically on a GTX 960M with driver version 369.09. What semantics does WebGL place on flush, and how bad can the performance impact get? 2. Has anybody run into something like this + know about possible workarounds other than using flush? 3. We see this problem specifically on FF using ANGLE. Neither chrome, nor switching to OpenGL exposes this issue. Is there something in the differences of using ANGLE in FF vs Chrome that could explain this (both browsers are up to date). Thanks! Jesse van den Kieboom | Senior Software Engineer Esri R&D Zurich | F?rrlibuckstrasse 110 | 8005 Zurich | Switzerland jkieboom...@ | www.esri.com T: +41 44 204 6032 Jesse van den Kieboom | Senior Software Engineer Esri R&D Zurich | F?rrlibuckstrasse 110 | 8005 Zurich | Switzerland jkieboom...@ | www.esri.com T: +41 44 204 6032 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jos...@ Wed Jun 7 10:52:36 2017 From: jos...@ (Joshua Groves) Date: Wed, 7 Jun 2017 11:52:36 -0600 Subject: [Public WebGL] Possible issues with FBO and switching color textures In-Reply-To: References: <296E1202-DABA-477D-A68A-0790E151DF9F@esri.com> Message-ID: > Is there a way to find out which ANGLE version is bundled with the browsers? You can find the ANGLE commit ID (and workarounds) in Chrome at chrome://gpu/ On Wed, Jun 7, 2017 at 2:43 AM, Jesse van den Kieboom wrote: > > On 7 Jun 2017, at 01:36, Kenneth Russell wrote: > > Firefox and Chrome are likely using different versions of ANGLE at any > particular version of each browser. It's possible that this was a bug that > was discovered and worked around in ANGLE. > > > We actually asked around a bit more, and while I originally thought this > was isolated to FF, this problem seems to also occur with Chrome with > specific nvidia driver versions (specifically reproducible with NVIDIA > Quadro K620, driver version 361.91, latest Chrome and FF). Is there a way > to find out which ANGLE version is bundled with the browsers? > > > Flushes should hopefully not be that expensive, so calling flush when > swapping the framebuffer's attachments should be a reasonable workaround. > > > In our specific scenario that I?m testing I?m measuring (using > console.time) 2x increase (from ~1.5ms to ~3ms) on this particular machine. > I understand this doesn?t mean much without knowing about the specifics of > what we are rendering, but it seems significant for our specific work load. > Is there a way to get more detailed profiling information on a stall caused > by calling flush (e.g. I imagine this also needs to flush commands queued > up in the browser to the GPU process)? > > > Do you have a test case that reproduces this problem? We'll gladly work > with you to add it to the WebGL conformance suite to try to prevent this > from regressing again. > > > I don?t have an isolated test case for this. I?m not sure how easy it will > be to reproduce since if this is somehow triggered by a GPU driver queue > specific problem, then we probably will need to get it in some specific > state before the problem shows. I will try though if I find some time. > > > Have you tried upgrading your drivers? NVIDIA's already released newer > drivers. > > > Yes, this seems to fix the issue that we are seeing. Unfortunately our > regular user/consumer base does not tend to keep their drivers up to date > and we want to avoid problems when we silently update our platform for the > next release. > > > -Ken > > > > On Tue, Jun 6, 2017 at 5:10 AM, Jesse van den Kieboom > wrote: > >> Hi all, >> >> We are experiencing a strange issue on certain machines and graphics >> cards using FBO?s. The issue is as follows: >> >> >> 1. Render some things to FBO with a texture color attachment (tex1) >> 2. Detach the color texture and attach a different texture (tex2) >> 3. Render some other things to the same FBO >> 4. Re-attach the original color texture (tex1) >> 5. Render some more things while reading back from the second texture >> (tex2) >> >> >> The problem that we are seeing is that not all the geometry from step 3 >> are actually rendered at the moment that we are reading back from tex2. >> Some questions: >> >> >> 1. It seems that doing an explicit flush between step 3 and 4 ?fixes? >> the problem, which we think could indicate a driver bug. Furthermore, this >> seems reproducible specifically on a GTX 960M with driver version 369.09. >> What semantics does WebGL place on flush, and how bad can the performance >> impact get? >> 2. Has anybody run into something like this + know about possible >> workarounds other than using flush? >> 3. We see this problem specifically on FF using ANGLE. Neither >> chrome, nor switching to OpenGL exposes this issue. Is there something in >> the differences of using ANGLE in FF vs Chrome that could explain this >> (both browsers are up to date). >> >> >> >> Thanks! >> >> *Jesse van den Kieboom | Senior Software Engineer* >> Esri R&D Zurich | F?rrlibuckstrasse 110 | 8005 Zurich | Switzerland >> jkieboom...@ | www.esri.com >> T: +41 44 204 6032 <+41%2044%20204%2060%2032> >> >> > > *Jesse van den Kieboom | Senior Software Engineer* > Esri R&D Zurich | F?rrlibuckstrasse 110 | 8005 Zurich | Switzerland > jkieboom...@ | www.esri.com > T: +41 44 204 6032 <+41%2044%20204%2060%2032> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Wed Jun 7 11:38:43 2017 From: kbr...@ (Kenneth Russell) Date: Wed, 7 Jun 2017 11:38:43 -0700 Subject: [Public WebGL] Chrome hangs on Shader Compile / Loop Unrolling In-Reply-To: References: Message-ID: Hi Markus, This topic has been discussed on the webgl-dev-list at https://groups.google.com/d/topic/webgl-dev-list/9caMjxg7xO8/discussion . As mentioned there and on the associated Chromium bug report, the browser is not doing any loop unrolling. The underlying GLSL compiler is, or may be. Chromium's GPU sub-process contains a watchdog that will terminate very long-running operations, like the compilations of your large shaders, in order to preserve user interactivity. There is no way to disable the watchdog from JavaScript. If you are using an embedded version of Chromium, you can disable the watchdog for your application's installer, as described on http://crbug.com/727071 . I think that you should adjust your rendering algorithms so that you can run fewer iterations of your large loops per cycle, and accumulate the results into a floating-point texture. That should shrink your shader size so that it can compile in a reasonable timeframe. -Ken On Tue, Jun 6, 2017 at 8:06 PM, Markus M?nig wrote: > Hi, > > we are working on an signed distance field modeller and renderer at > www.raysupreme.com (Webgl v2 only). It supports a preview mode and a > PBR based path tracer and is currently in alpha. > > The attached scene hangs Chrome during shader compilation of the path > tracer. WebGL seems to try to unroll the path tracer loop which times > out the GPU watchdog in Chrome because the map() function for the SDFs > is getting quite big (200 lines in this example). > > Now, the loop for the path tracer, we could unroll this and write > results for each pass into a float buffer, we understand this (it > would be much slower though). But this unrolling is also creating > issues for procedural content creation where nested loops are used to > create for example smoke. We run into the same issues with Chrome and > its GPU watch dog. Firefox works fine, but shader compilation can take > up to 20 seconds (attached screenshot is from FF). > > So my question, will there be a way to control loop unrolling sometime > in the future ? > > SDFs may sound like a freakish thing, but there a pro games under > development using only SDFs, Shadertoy.com is very popular and we get > a big interest from users in this tech because it is much easier to > model with than complex mesh modelling. > > Thanks, > > -Markus > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Wed Jun 7 12:15:27 2017 From: kbr...@ (Kenneth Russell) Date: Wed, 7 Jun 2017 12:15:27 -0700 Subject: [Public WebGL] Possible issues with FBO and switching color textures In-Reply-To: References: <296E1202-DABA-477D-A68A-0790E151DF9F@esri.com> Message-ID: On Wed, Jun 7, 2017 at 1:43 AM, Jesse van den Kieboom wrote: > > On 7 Jun 2017, at 01:36, Kenneth Russell wrote: > > Firefox and Chrome are likely using different versions of ANGLE at any > particular version of each browser. It's possible that this was a bug that > was discovered and worked around in ANGLE. > > > We actually asked around a bit more, and while I originally thought this > was isolated to FF, this problem seems to also occur with Chrome with > specific nvidia driver versions (specifically reproducible with NVIDIA > Quadro K620, driver version 361.91, latest Chrome and FF). Is there a way > to find out which ANGLE version is bundled with the browsers? > > This was answered at least for Chrome above. For Firefox, about:support contains some GPU information, but it looks like it doesn't contain the ANGLE build number. > > Flushes should hopefully not be that expensive, so calling flush when > swapping the framebuffer's attachments should be a reasonable workaround. > > > In our specific scenario that I?m testing I?m measuring (using > console.time) 2x increase (from ~1.5ms to ~3ms) on this particular machine. > I understand this doesn?t mean much without knowing about the specifics of > what we are rendering, but it seems significant for our specific work load. > Is there a way to get more detailed profiling information on a stall caused > by calling flush (e.g. I imagine this also needs to flush commands queued > up in the browser to the GPU process)? > In Chrome, flushes are asynchronous with respect to the JavaScript process which initiated them. Maybe your workload is GPU bound and that's causing back-pressure to the JavaScript process. You can use chrome://tracing to gather more detailed information about the behavior of all of the sub-processes. The output is most readable if you close all your other tabs, or start with a fresh user profile (e.g. --user-data-dir=/tmp/t1 ). Do you have a test case that reproduces this problem? We'll gladly work > with you to add it to the WebGL conformance suite to try to prevent this > from regressing again. > > > I don?t have an isolated test case for this. I?m not sure how easy it will > be to reproduce since if this is somehow triggered by a GPU driver queue > specific problem, then we probably will need to get it in some specific > state before the problem shows. I will try though if I find some time. > If you can invest the time to create a test case, that will help ensure this doesn't get broken again. > > > Have you tried upgrading your drivers? NVIDIA's already released newer > drivers. > > > Yes, this seems to fix the issue that we are seeing. Unfortunately our > regular user/consumer base does not tend to keep their drivers up to date > and we want to avoid problems when we silently update our platform for the > next release. > I would recommend you include a warning in your readme to upgrade drivers past this particular version. -Ken > > > -Ken > > > > On Tue, Jun 6, 2017 at 5:10 AM, Jesse van den Kieboom > wrote: > >> Hi all, >> >> We are experiencing a strange issue on certain machines and graphics >> cards using FBO?s. The issue is as follows: >> >> >> 1. Render some things to FBO with a texture color attachment (tex1) >> 2. Detach the color texture and attach a different texture (tex2) >> 3. Render some other things to the same FBO >> 4. Re-attach the original color texture (tex1) >> 5. Render some more things while reading back from the second texture >> (tex2) >> >> >> The problem that we are seeing is that not all the geometry from step 3 >> are actually rendered at the moment that we are reading back from tex2. >> Some questions: >> >> >> 1. It seems that doing an explicit flush between step 3 and 4 ?fixes? >> the problem, which we think could indicate a driver bug. Furthermore, this >> seems reproducible specifically on a GTX 960M with driver version 369.09. >> What semantics does WebGL place on flush, and how bad can the performance >> impact get? >> 2. Has anybody run into something like this + know about possible >> workarounds other than using flush? >> 3. We see this problem specifically on FF using ANGLE. Neither >> chrome, nor switching to OpenGL exposes this issue. Is there something in >> the differences of using ANGLE in FF vs Chrome that could explain this >> (both browsers are up to date). >> >> >> >> Thanks! >> >> *Jesse van den Kieboom | Senior Software Engineer* >> Esri R&D Zurich | F?rrlibuckstrasse 110 | 8005 Zurich | Switzerland >> jkieboom...@ | www.esri.com >> T: +41 44 204 6032 <+41%2044%20204%2060%2032> >> >> > > *Jesse van den Kieboom | Senior Software Engineer* > Esri R&D Zurich | F?rrlibuckstrasse 110 | 8005 Zurich | Switzerland > jkieboom...@ | www.esri.com > T: +41 44 204 6032 <+41%2044%20204%2060%2032> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mar...@ Wed Jun 7 18:13:11 2017 From: mar...@ (=?UTF-8?Q?Markus_M=C3=B6nig?=) Date: Thu, 8 Jun 2017 08:13:11 +0700 Subject: [Public WebGL] Chrome hangs on Shader Compile / Loop Unrolling In-Reply-To: References: Message-ID: Hi Ken, yes, sorry Ken, I should have changed the heading of this post. By posting this here I was more hoping to get an insight why what the GLSL compiler is doing and why and it's actually not about Chrome. For example for (int i=0; i < 1; ++i ) { ... // path tracer magic with iteration depth 1 } Hangs the compiler, with a compilation time of more than 10 seconds. Now //for (int i=0; i < 1; ++i ) { ... // path tracer magic with iteration depth 1, i.e. same as above just no for statement } Works fine and compiles in under a second ... . I am just wondering why there is no way to control the behaviour of the compiler re unrolling. In a user driven environment (which is different than a game environment) it is difficult to be able to contain the shader size when all loops get aggressively unrolled. -Markus On Thu, Jun 8, 2017 at 1:38 AM, Kenneth Russell wrote: > Hi Markus, > > This topic has been discussed on the webgl-dev-list at > https://groups.google.com/d/topic/webgl-dev-list/9caMjxg7xO8/discussion . As > mentioned there and on the associated Chromium bug report, the browser is > not doing any loop unrolling. The underlying GLSL compiler is, or may be. > > Chromium's GPU sub-process contains a watchdog that will terminate very > long-running operations, like the compilations of your large shaders, in > order to preserve user interactivity. There is no way to disable the > watchdog from JavaScript. If you are using an embedded version of Chromium, > you can disable the watchdog for your application's installer, as described > on http://crbug.com/727071 . > > I think that you should adjust your rendering algorithms so that you can run > fewer iterations of your large loops per cycle, and accumulate the results > into a floating-point texture. That should shrink your shader size so that > it can compile in a reasonable timeframe. > > -Ken > > > > On Tue, Jun 6, 2017 at 8:06 PM, Markus M?nig > wrote: >> >> Hi, >> >> we are working on an signed distance field modeller and renderer at >> www.raysupreme.com (Webgl v2 only). It supports a preview mode and a >> PBR based path tracer and is currently in alpha. >> >> The attached scene hangs Chrome during shader compilation of the path >> tracer. WebGL seems to try to unroll the path tracer loop which times >> out the GPU watchdog in Chrome because the map() function for the SDFs >> is getting quite big (200 lines in this example). >> >> Now, the loop for the path tracer, we could unroll this and write >> results for each pass into a float buffer, we understand this (it >> would be much slower though). But this unrolling is also creating >> issues for procedural content creation where nested loops are used to >> create for example smoke. We run into the same issues with Chrome and >> its GPU watch dog. Firefox works fine, but shader compilation can take >> up to 20 seconds (attached screenshot is from FF). >> >> So my question, will there be a way to control loop unrolling sometime >> in the future ? >> >> SDFs may sound like a freakish thing, but there a pro games under >> development using only SDFs, Shadertoy.com is very popular and we get >> a big interest from users in this tech because it is much easier to >> model with than complex mesh modelling. >> >> Thanks, >> >> -Markus > > ----------------------------------------------------------- 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 oet...@ Thu Jun 8 01:39:05 2017 From: oet...@ (Olli Etuaho) Date: Thu, 8 Jun 2017 08:39:05 +0000 Subject: [Public WebGL] Possible issues with FBO and switching color textures In-Reply-To: References: <296E1202-DABA-477D-A68A-0790E151DF9F@esri.com> Message-ID: <6b66547ad4e8405e8fd9165643c23e46@ukmail101.nvidia.com> Note that there are already some WebGL conformance tests that are similar to what your app is doing: https://www.khronos.org/registry/webgl/sdk/tests/conformance/rendering/framebuffer-switch.html https://www.khronos.org/registry/webgl/sdk/tests/conformance/rendering/framebuffer-texture-switch.html These exposed some driver bugs that have since been fixed to our knowledge. If they fail on the config that you?re having trouble with, then there?s probably no need for new tests. But I?d strongly suggest trying to make a new minimal test case in case any existing WebGL tests don?t cover the issue. -Olli From: Kenneth Russell [mailto:kbr...@] Sent: Wednesday, 7 June 2017 22.15 To: Jesse van den Kieboom Cc: public_webgl...@; Jamie Madill ; Geoff Lang ; Olli Etuaho ; Jeff Gilbert Subject: Re: [Public WebGL] Possible issues with FBO and switching color textures On Wed, Jun 7, 2017 at 1:43 AM, Jesse van den Kieboom > wrote: On 7 Jun 2017, at 01:36, Kenneth Russell > wrote: Firefox and Chrome are likely using different versions of ANGLE at any particular version of each browser. It's possible that this was a bug that was discovered and worked around in ANGLE. We actually asked around a bit more, and while I originally thought this was isolated to FF, this problem seems to also occur with Chrome with specific nvidia driver versions (specifically reproducible with NVIDIA Quadro K620, driver version 361.91, latest Chrome and FF). Is there a way to find out which ANGLE version is bundled with the browsers? This was answered at least for Chrome above. For Firefox, about:support contains some GPU information, but it looks like it doesn't contain the ANGLE build number. Flushes should hopefully not be that expensive, so calling flush when swapping the framebuffer's attachments should be a reasonable workaround. In our specific scenario that I?m testing I?m measuring (using console.time) 2x increase (from ~1.5ms to ~3ms) on this particular machine. I understand this doesn?t mean much without knowing about the specifics of what we are rendering, but it seems significant for our specific work load. Is there a way to get more detailed profiling information on a stall caused by calling flush (e.g. I imagine this also needs to flush commands queued up in the browser to the GPU process)? In Chrome, flushes are asynchronous with respect to the JavaScript process which initiated them. Maybe your workload is GPU bound and that's causing back-pressure to the JavaScript process. You can use chrome://tracing to gather more detailed information about the behavior of all of the sub-processes. The output is most readable if you close all your other tabs, or start with a fresh user profile (e.g. --user-data-dir=/tmp/t1 ). Do you have a test case that reproduces this problem? We'll gladly work with you to add it to the WebGL conformance suite to try to prevent this from regressing again. I don?t have an isolated test case for this. I?m not sure how easy it will be to reproduce since if this is somehow triggered by a GPU driver queue specific problem, then we probably will need to get it in some specific state before the problem shows. I will try though if I find some time. If you can invest the time to create a test case, that will help ensure this doesn't get broken again. Have you tried upgrading your drivers? NVIDIA's already released newer drivers. Yes, this seems to fix the issue that we are seeing. Unfortunately our regular user/consumer base does not tend to keep their drivers up to date and we want to avoid problems when we silently update our platform for the next release. I would recommend you include a warning in your readme to upgrade drivers past this particular version. -Ken -Ken On Tue, Jun 6, 2017 at 5:10 AM, Jesse van den Kieboom > wrote: Hi all, We are experiencing a strange issue on certain machines and graphics cards using FBO?s. The issue is as follows: 1. Render some things to FBO with a texture color attachment (tex1) 2. Detach the color texture and attach a different texture (tex2) 3. Render some other things to the same FBO 4. Re-attach the original color texture (tex1) 5. Render some more things while reading back from the second texture (tex2) The problem that we are seeing is that not all the geometry from step 3 are actually rendered at the moment that we are reading back from tex2. Some questions: 1. It seems that doing an explicit flush between step 3 and 4 ?fixes? the problem, which we think could indicate a driver bug. Furthermore, this seems reproducible specifically on a GTX 960M with driver version 369.09. What semantics does WebGL place on flush, and how bad can the performance impact get? 2. Has anybody run into something like this + know about possible workarounds other than using flush? 3. We see this problem specifically on FF using ANGLE. Neither chrome, nor switching to OpenGL exposes this issue. Is there something in the differences of using ANGLE in FF vs Chrome that could explain this (both browsers are up to date). Thanks! Jesse van den Kieboom | Senior Software Engineer Esri R&D Zurich | F?rrlibuckstrasse 110 | 8005 Zurich | Switzerland jkieboom...@ | www.esri.com T: +41 44 204 6032 Jesse van den Kieboom | Senior Software Engineer Esri R&D Zurich | F?rrlibuckstrasse 110 | 8005 Zurich | Switzerland jkieboom...@ | www.esri.com T: +41 44 204 6032 -------------- next part -------------- An HTML attachment was scrubbed... URL: From geo...@ Thu Jun 8 06:25:16 2017 From: geo...@ (Geoff Lang) Date: Thu, 08 Jun 2017 13:25:16 +0000 Subject: [Public WebGL] Chrome hangs on Shader Compile / Loop Unrolling In-Reply-To: References: Message-ID: Have you tried looping based on a uniform value? This should be allowed for ESSL 3 shaders. On Wed, Jun 7, 2017 at 9:13 PM Markus M?nig wrote: > > Hi Ken, > > yes, sorry Ken, I should have changed the heading of this post. By > posting this here I was more hoping to get an insight why what the > GLSL compiler is doing and why and it's actually not about Chrome. For > example > > for (int i=0; i < 1; ++i ) > { > ... // path tracer magic with iteration depth 1 > } > > Hangs the compiler, with a compilation time of more than 10 seconds. > > Now > > //for (int i=0; i < 1; ++i ) > { > ... // path tracer magic with iteration depth 1, i.e. same as above > just no for statement > } > > Works fine and compiles in under a second ... . I am just wondering > why there is no way to control the behaviour of the compiler re > unrolling. > > In a user driven environment (which is different than a game > environment) it is difficult to be able to contain the shader size > when all loops get aggressively unrolled. > > -Markus > > On Thu, Jun 8, 2017 at 1:38 AM, Kenneth Russell wrote: > > Hi Markus, > > > > This topic has been discussed on the webgl-dev-list at > > https://groups.google.com/d/topic/webgl-dev-list/9caMjxg7xO8/discussion > . As > > mentioned there and on the associated Chromium bug report, the browser is > > not doing any loop unrolling. The underlying GLSL compiler is, or may be. > > > > Chromium's GPU sub-process contains a watchdog that will terminate very > > long-running operations, like the compilations of your large shaders, in > > order to preserve user interactivity. There is no way to disable the > > watchdog from JavaScript. If you are using an embedded version of > Chromium, > > you can disable the watchdog for your application's installer, as > described > > on http://crbug.com/727071 . > > > > I think that you should adjust your rendering algorithms so that you can > run > > fewer iterations of your large loops per cycle, and accumulate the > results > > into a floating-point texture. That should shrink your shader size so > that > > it can compile in a reasonable timeframe. > > > > -Ken > > > > > > > > On Tue, Jun 6, 2017 at 8:06 PM, Markus M?nig < > markus.moenig...@> > > wrote: > >> > >> Hi, > >> > >> we are working on an signed distance field modeller and renderer at > >> www.raysupreme.com (Webgl v2 only). It supports a preview mode and a > >> PBR based path tracer and is currently in alpha. > >> > >> The attached scene hangs Chrome during shader compilation of the path > >> tracer. WebGL seems to try to unroll the path tracer loop which times > >> out the GPU watchdog in Chrome because the map() function for the SDFs > >> is getting quite big (200 lines in this example). > >> > >> Now, the loop for the path tracer, we could unroll this and write > >> results for each pass into a float buffer, we understand this (it > >> would be much slower though). But this unrolling is also creating > >> issues for procedural content creation where nested loops are used to > >> create for example smoke. We run into the same issues with Chrome and > >> its GPU watch dog. Firefox works fine, but shader compilation can take > >> up to 20 seconds (attached screenshot is from FF). > >> > >> So my question, will there be a way to control loop unrolling sometime > >> in the future ? > >> > >> SDFs may sound like a freakish thing, but there a pro games under > >> development using only SDFs, Shadertoy.com is very popular and we get > >> a big interest from users in this tech because it is much easier to > >> model with than complex mesh modelling. > >> > >> Thanks, > >> > >> -Markus > > > > > > ----------------------------------------------------------- > 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 > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Thu Jun 8 14:28:01 2017 From: kbr...@ (Kenneth Russell) Date: Thu, 8 Jun 2017 14:28:01 -0700 Subject: [Public WebGL] Chrome hangs on Shader Compile / Loop Unrolling In-Reply-To: References: Message-ID: Good idea Geoff. Markus, it's interesting that adding a single-iteration loop causes this pathology in Apple's GLSL compiler. Could you extract the shaders for this scene into a self-contained test case? It would help motivate improvements. We could possibly add it into the WebGL conformance suite. Note that the GL shading language doesn't provide any directives controlling loop unrolling, etc. This is purely an implementation issue in Apple's OpenGL driver. Thanks, -Ken On Thu, Jun 8, 2017 at 6:25 AM, Geoff Lang wrote: > Have you tried looping based on a uniform value? This should be allowed > for ESSL 3 shaders. > > On Wed, Jun 7, 2017 at 9:13 PM Markus M?nig > wrote: > >> >> Hi Ken, >> >> yes, sorry Ken, I should have changed the heading of this post. By >> posting this here I was more hoping to get an insight why what the >> GLSL compiler is doing and why and it's actually not about Chrome. For >> example >> >> for (int i=0; i < 1; ++i ) >> { >> ... // path tracer magic with iteration depth 1 >> } >> >> Hangs the compiler, with a compilation time of more than 10 seconds. >> >> Now >> >> //for (int i=0; i < 1; ++i ) >> { >> ... // path tracer magic with iteration depth 1, i.e. same as above >> just no for statement >> } >> >> Works fine and compiles in under a second ... . I am just wondering >> why there is no way to control the behaviour of the compiler re >> unrolling. >> >> In a user driven environment (which is different than a game >> environment) it is difficult to be able to contain the shader size >> when all loops get aggressively unrolled. >> >> -Markus >> >> On Thu, Jun 8, 2017 at 1:38 AM, Kenneth Russell wrote: >> > Hi Markus, >> > >> > This topic has been discussed on the webgl-dev-list at >> > https://groups.google.com/d/topic/webgl-dev-list/9caMjxg7xO8/discussion >> . As >> > mentioned there and on the associated Chromium bug report, the browser >> is >> > not doing any loop unrolling. The underlying GLSL compiler is, or may >> be. >> > >> > Chromium's GPU sub-process contains a watchdog that will terminate very >> > long-running operations, like the compilations of your large shaders, in >> > order to preserve user interactivity. There is no way to disable the >> > watchdog from JavaScript. If you are using an embedded version of >> Chromium, >> > you can disable the watchdog for your application's installer, as >> described >> > on http://crbug.com/727071 . >> > >> > I think that you should adjust your rendering algorithms so that you >> can run >> > fewer iterations of your large loops per cycle, and accumulate the >> results >> > into a floating-point texture. That should shrink your shader size so >> that >> > it can compile in a reasonable timeframe. >> > >> > -Ken >> > >> > >> > >> > On Tue, Jun 6, 2017 at 8:06 PM, Markus M?nig < >> markus.moenig...@> >> > wrote: >> >> >> >> Hi, >> >> >> >> we are working on an signed distance field modeller and renderer at >> >> www.raysupreme.com (Webgl v2 only). It supports a preview mode and a >> >> PBR based path tracer and is currently in alpha. >> >> >> >> The attached scene hangs Chrome during shader compilation of the path >> >> tracer. WebGL seems to try to unroll the path tracer loop which times >> >> out the GPU watchdog in Chrome because the map() function for the SDFs >> >> is getting quite big (200 lines in this example). >> >> >> >> Now, the loop for the path tracer, we could unroll this and write >> >> results for each pass into a float buffer, we understand this (it >> >> would be much slower though). But this unrolling is also creating >> >> issues for procedural content creation where nested loops are used to >> >> create for example smoke. We run into the same issues with Chrome and >> >> its GPU watch dog. Firefox works fine, but shader compilation can take >> >> up to 20 seconds (attached screenshot is from FF). >> >> >> >> So my question, will there be a way to control loop unrolling sometime >> >> in the future ? >> >> >> >> SDFs may sound like a freakish thing, but there a pro games under >> >> development using only SDFs, Shadertoy.com is very popular and we get >> >> a big interest from users in this tech because it is much easier to >> >> model with than complex mesh modelling. >> >> >> >> Thanks, >> >> >> >> -Markus >> > >> > >> >> ----------------------------------------------------------- >> 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 >> ----------------------------------------------------------- >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mar...@ Thu Jun 8 17:36:58 2017 From: mar...@ (=?UTF-8?Q?Markus_M=C3=B6nig?=) Date: Fri, 9 Jun 2017 07:36:58 +0700 Subject: [Public WebGL] Chrome hangs on Shader Compile / Loop Unrolling In-Reply-To: References: Message-ID: Hi, thanks for the suggestions. Using a uniform does the same, it hangs. But this is not limited to Apple, we are seeing the exact same behaviour on Windows too. What worries me is that part of the shaders are user based, like a material from a node editor. Which in some parts also needs some loops for creating procedural detail. We would never know what will crash the machine and what not. Ok, I will try to create a standalone test case. Its a good amount of work but it will be worth it I guess. Thanks -Markus On Fri, Jun 9, 2017 at 4:28 AM, Kenneth Russell wrote: > Good idea Geoff. > > Markus, it's interesting that adding a single-iteration loop causes this > pathology in Apple's GLSL compiler. Could you extract the shaders for this > scene into a self-contained test case? It would help motivate improvements. > We could possibly add it into the WebGL conformance suite. > > Note that the GL shading language doesn't provide any directives controlling > loop unrolling, etc. This is purely an implementation issue in Apple's > OpenGL driver. > > Thanks, > > -Ken > > > > On Thu, Jun 8, 2017 at 6:25 AM, Geoff Lang wrote: >> >> Have you tried looping based on a uniform value? This should be allowed >> for ESSL 3 shaders. >> >> On Wed, Jun 7, 2017 at 9:13 PM Markus M?nig >> wrote: >>> >>> >>> Hi Ken, >>> >>> yes, sorry Ken, I should have changed the heading of this post. By >>> posting this here I was more hoping to get an insight why what the >>> GLSL compiler is doing and why and it's actually not about Chrome. For >>> example >>> >>> for (int i=0; i < 1; ++i ) >>> { >>> ... // path tracer magic with iteration depth 1 >>> } >>> >>> Hangs the compiler, with a compilation time of more than 10 seconds. >>> >>> Now >>> >>> //for (int i=0; i < 1; ++i ) >>> { >>> ... // path tracer magic with iteration depth 1, i.e. same as above >>> just no for statement >>> } >>> >>> Works fine and compiles in under a second ... . I am just wondering >>> why there is no way to control the behaviour of the compiler re >>> unrolling. >>> >>> In a user driven environment (which is different than a game >>> environment) it is difficult to be able to contain the shader size >>> when all loops get aggressively unrolled. >>> >>> -Markus >>> >>> On Thu, Jun 8, 2017 at 1:38 AM, Kenneth Russell wrote: >>> > Hi Markus, >>> > >>> > This topic has been discussed on the webgl-dev-list at >>> > https://groups.google.com/d/topic/webgl-dev-list/9caMjxg7xO8/discussion >>> > . As >>> > mentioned there and on the associated Chromium bug report, the browser >>> > is >>> > not doing any loop unrolling. The underlying GLSL compiler is, or may >>> > be. >>> > >>> > Chromium's GPU sub-process contains a watchdog that will terminate very >>> > long-running operations, like the compilations of your large shaders, >>> > in >>> > order to preserve user interactivity. There is no way to disable the >>> > watchdog from JavaScript. If you are using an embedded version of >>> > Chromium, >>> > you can disable the watchdog for your application's installer, as >>> > described >>> > on http://crbug.com/727071 . >>> > >>> > I think that you should adjust your rendering algorithms so that you >>> > can run >>> > fewer iterations of your large loops per cycle, and accumulate the >>> > results >>> > into a floating-point texture. That should shrink your shader size so >>> > that >>> > it can compile in a reasonable timeframe. >>> > >>> > -Ken >>> > >>> > >>> > >>> > On Tue, Jun 6, 2017 at 8:06 PM, Markus M?nig >>> > >>> > wrote: >>> >> >>> >> Hi, >>> >> >>> >> we are working on an signed distance field modeller and renderer at >>> >> www.raysupreme.com (Webgl v2 only). It supports a preview mode and a >>> >> PBR based path tracer and is currently in alpha. >>> >> >>> >> The attached scene hangs Chrome during shader compilation of the path >>> >> tracer. WebGL seems to try to unroll the path tracer loop which times >>> >> out the GPU watchdog in Chrome because the map() function for the SDFs >>> >> is getting quite big (200 lines in this example). >>> >> >>> >> Now, the loop for the path tracer, we could unroll this and write >>> >> results for each pass into a float buffer, we understand this (it >>> >> would be much slower though). But this unrolling is also creating >>> >> issues for procedural content creation where nested loops are used to >>> >> create for example smoke. We run into the same issues with Chrome and >>> >> its GPU watch dog. Firefox works fine, but shader compilation can take >>> >> up to 20 seconds (attached screenshot is from FF). >>> >> >>> >> So my question, will there be a way to control loop unrolling sometime >>> >> in the future ? >>> >> >>> >> SDFs may sound like a freakish thing, but there a pro games under >>> >> development using only SDFs, Shadertoy.com is very popular and we get >>> >> a big interest from users in this tech because it is much easier to >>> >> model with than complex mesh modelling. >>> >> >>> >> Thanks, >>> >> >>> >> -Markus >>> > >>> > >>> >>> ----------------------------------------------------------- >>> 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 >>> ----------------------------------------------------------- >>> > ----------------------------------------------------------- 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 mar...@ Wed Jun 14 05:44:59 2017 From: mar...@ (=?UTF-8?Q?Markus_Sch=c3=bctz?=) Date: Wed, 14 Jun 2017 14:44:59 +0200 Subject: [Public WebGL] Current WebGL2 support Message-ID: Hi, According to https://webglstats.com, support for WebGL 2 has been around 50-60% on desktop for quite a while and around 15% on smartphones since may. Can anyone make sense of the stagnation on desktops? I would have thought that more machines should be able to support WebGL2 (OpenGL ES3?) features. Is it certain that the machines aren't capable of WebGL2 or are there other issues at hand? Related to that, I also ran into the issue that my 3 year old notebook with an Intel HD 4600 supports WebGL2 but my desktop PC with a GTX 980, newest driver and latest versions of firefox and chrome says it doesn't. Best, Markus ----------------------------------------------------------- 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 juj...@ Wed Jun 14 08:13:31 2017 From: juj...@ (=?UTF-8?Q?Jukka_Jyl=C3=A4nki?=) Date: Wed, 14 Jun 2017 18:13:31 +0300 Subject: [Public WebGL] Current WebGL2 support In-Reply-To: References: Message-ID: Related, I have run on an odd issue on Windows 10 with Asus GTX 1080 Ti, where I could not get WebGL 2 to work, but instead browsers would fail to initialize D3D11 context in ANGLE due to some 0x8000xxxx error from D3D context creation. Couldn't make heads or tails of that, and when trying to investigate I updated to latest Nvidia drivers, and the problem went away. Don't know if this is anything related to your GTX 980 issues, but thought to mention. Try checking the about:support page in Firefox or chrome://gpu on Chrome to see if these print out anything interesting. 2017-06-14 15:44 GMT+03:00 Markus Sch?tz : > > > Hi, > > According to https://webglstats.com, support for WebGL 2 has been around > 50-60% on desktop for quite a while > and around 15% on smartphones since may. > > Can anyone make sense of the stagnation on desktops? > I would have thought that more machines should be able to support WebGL2 > (OpenGL ES3?) features. > Is it certain that the machines aren't capable of WebGL2 or are there other > issues at hand? > > Related to that, I also ran into the issue that my 3 year old notebook with > an Intel HD 4600 supports WebGL2 > but my desktop PC with a GTX 980, newest driver and latest versions of > firefox and chrome says it doesn't. > > Best, > Markus > > > ----------------------------------------------------------- > 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 > ----------------------------------------------------------- > ----------------------------------------------------------- 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 jos...@ Wed Jun 14 08:35:00 2017 From: jos...@ (Joshua Groves) Date: Wed, 14 Jun 2017 09:35:00 -0600 Subject: [Public WebGL] Current WebGL2 support In-Reply-To: References: Message-ID: Most of the usage stagnation is likely due to the fact that WebGL2 is not enabled by default in all desktop browsers. For example, https://caniuse.com/#search=webgl2 only lists Chrome, Firefox and Opera as having enabled WebGL2 by default. So it's likely that support will continue to stagnate until other browsers enable it. This number appears to make sense considering the current usage share of Safari, Edge, Internet Explorer and other browsers which do not enable WebGL2 by default. Josh On Wed, Jun 14, 2017 at 6:44 AM, Markus Sch?tz wrote: > > > Hi, > > According to https://webglstats.com, support for WebGL 2 has been around > 50-60% on desktop for quite a while > and around 15% on smartphones since may. > > Can anyone make sense of the stagnation on desktops? > I would have thought that more machines should be able to support WebGL2 > (OpenGL ES3?) features. > Is it certain that the machines aren't capable of WebGL2 or are there > other issues at hand? > > Related to that, I also ran into the issue that my 3 year old notebook > with an Intel HD 4600 supports WebGL2 > but my desktop PC with a GTX 980, newest driver and latest versions of > firefox and chrome says it doesn't. > > Best, > Markus > > > ----------------------------------------------------------- > 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 > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Jun 14 08:58:57 2017 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 14 Jun 2017 17:58:57 +0200 Subject: [Public WebGL] Current WebGL2 support In-Reply-To: References: Message-ID: On Wed, Jun 14, 2017 at 5:35 PM, Joshua Groves wrote: > Most of the usage stagnation is likely due to the fact that WebGL2 is not > enabled by default in all desktop browsers. > That's incorrect. In a 30 day window, Chrome, Firefox and Opera service 82.6% of the desktop market share. In the same timeframe these browsers show up with 71% WebGL2 support. In other words their overall contribution to the lack of WebGL 2 is 29% of 82.6% = 24%. Browsers not supporting WebGL2 make 17.4% of the market share. Hence the non-support by browsers that do support WebGL2 has a bigger impact on the overall non availability of WebGL2, than browsers that don't implement WebGL2. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jos...@ Wed Jun 14 10:01:07 2017 From: jos...@ (Joshua Groves) Date: Wed, 14 Jun 2017 11:01:07 -0600 Subject: [Public WebGL] Current WebGL2 support In-Reply-To: References: Message-ID: Thanks for the correction. The 29% figure is higher than I anticipated. Perhaps browser vendors could clarify whether this is expected? If anyone is able to elaborate, I'm also interested in how much of that percentage is due to unsupported hardware, issues like Markus is experiencing, any OS restrictions, etc. On Wed, Jun 14, 2017 at 9:58 AM, Florian B?sch wrote: > On Wed, Jun 14, 2017 at 5:35 PM, Joshua Groves > wrote: > >> Most of the usage stagnation is likely due to the fact that WebGL2 is not >> enabled by default in all desktop browsers. >> > > That's incorrect. In a 30 day window, Chrome, Firefox and Opera service > 82.6% of the desktop market share. In the same timeframe these browsers > show up with 71% WebGL2 support. In other words their overall contribution > to the lack of WebGL 2 is 29% of 82.6% = 24%. Browsers not supporting > WebGL2 make 17.4% of the market share. Hence the non-support by browsers > that do support WebGL2 has a bigger impact on the overall non availability > of WebGL2, than browsers that don't implement WebGL2. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Thu Jun 15 12:59:39 2017 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Thu, 15 Jun 2017 21:59:39 +0200 Subject: [Public WebGL] Current WebGL2 support In-Reply-To: References: Message-ID: On Thu, Jun 15, 2017 at 9:44 PM, Jamie Madill wrote: > but I can tell you that there is a significant number of Chrome users on > Windows who are stuck on D3D9 because of older GPU hardware, and out of > date and/or buggy drivers. My knowledge of other OSes is more limited. > Unfortunately not a lot we can do about that short of buying everyone new > computers. :) > Filtering just for Chrome on windows I can see that WebGL2 support reached a plateau of around 70% within 2 months of activation and has now stayed there for the last 3 months. I take your statement to imply that this is about as far as WebGL2 will go for now. Observing the hardware turnover on Windows platforms, significant changes in hardware occur on a 4-year window or thereabouts. OS upgrades also seem to run on a very long timeframe, and I wouldn't expect anything much to move in the next few years there. My question about it though would be: how do we make sure that once that OS/hardware turnover has actually happened, that WebGL2 actually works? How do we ensure people do not get crappy hardware, buggy OS'es/drivers and outdated graphics APIs? -------------- next part -------------- An HTML attachment was scrubbed... URL: From khr...@ Thu Jun 15 14:47:27 2017 From: khr...@ (Mark Callow) Date: Thu, 15 Jun 2017 14:47:27 -0700 Subject: [Public WebGL] Current WebGL2 support In-Reply-To: References: Message-ID: > On Jun 15, 2017, at 12:59, Florian B?sch wrote: > > My question about it though would be: how do we make sure that once that OS/hardware turnover has actually happened, that WebGL2 actually works? How do we ensure people do not get crappy hardware, buggy OS'es/drivers and outdated graphics APIs? I?ll just note that I think Intel sells the largest number of GPU?s for PCs. The Intel OpenGL drivers have been pretty good for some time now. Intel has been quite involved in providing WebGL 2 conformance tests. Regards -Mark P.S. I have no connection to Intel. -------------- 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 URL: From kbr...@ Thu Jun 15 16:57:50 2017 From: kbr...@ (Kenneth Russell) Date: Thu, 15 Jun 2017 16:57:50 -0700 Subject: [Public WebGL] Current WebGL2 support In-Reply-To: References: Message-ID: Looking at Chrome's internal statistics, about 30% of Chrome users are stuck at Shader Model 3.0, implying that they're using ANGLE's Direct3D 9 backend. WebGL 2.0 requires Direct3D 11. This is certainly the reason WebGL 2.0's market penetration has plateaued on Windows -- older hardware. It's certainly unexpected that on an recent NVIDIA GPU, WebGL 2.0 would be unsupported. If you see an issue like this, please first try upgrading your drivers, and then file a bug with your respective browser. For Chrome, use crbug.com/ and include the plaintext contents of about:gpu . -Ken On Wed, Jun 14, 2017 at 10:01 AM, Joshua Groves wrote: > Thanks for the correction. The 29% figure is higher than I anticipated. > > Perhaps browser vendors could clarify whether this is expected? If anyone > is able to elaborate, I'm also interested in how much of that percentage is > due to unsupported hardware, issues like Markus is experiencing, any OS > restrictions, etc. > > On Wed, Jun 14, 2017 at 9:58 AM, Florian B?sch wrote: > >> On Wed, Jun 14, 2017 at 5:35 PM, Joshua Groves >> wrote: >> >>> Most of the usage stagnation is likely due to the fact that WebGL2 is >>> not enabled by default in all desktop browsers. >>> >> >> That's incorrect. In a 30 day window, Chrome, Firefox and Opera service >> 82.6% of the desktop market share. In the same timeframe these browsers >> show up with 71% WebGL2 support. In other words their overall contribution >> to the lack of WebGL 2 is 29% of 82.6% = 24%. Browsers not supporting >> WebGL2 make 17.4% of the market share. Hence the non-support by browsers >> that do support WebGL2 has a bigger impact on the overall non availability >> of WebGL2, than browsers that don't implement WebGL2. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Thu Jun 15 17:02:51 2017 From: kbr...@ (Kenneth Russell) Date: Thu, 15 Jun 2017 17:02:51 -0700 Subject: [Public WebGL] Current WebGL2 support In-Reply-To: References: Message-ID: On Thu, Jun 15, 2017 at 12:59 PM, Florian B?sch wrote: > On Thu, Jun 15, 2017 at 9:44 PM, Jamie Madill > wrote: > >> but I can tell you that there is a significant number of Chrome users on >> Windows who are stuck on D3D9 because of older GPU hardware, and out of >> date and/or buggy drivers. My knowledge of other OSes is more limited. >> Unfortunately not a lot we can do about that short of buying everyone new >> computers. :) >> > > Filtering just for Chrome on windows > I can see > that WebGL2 support reached a plateau of around 70% within 2 months of > activation and has now stayed there for the last 3 months. I take your > statement to imply that this is about as far as WebGL2 will go for now. > Observing the hardware turnover on Windows platforms, significant changes > in hardware occur on a 4-year window or thereabouts. OS upgrades also seem > to run on a very long timeframe, and I wouldn't expect anything much to > move in the next few years there. > > My question about it though would be: how do we make sure that once that > OS/hardware turnover has actually happened, that WebGL2 actually works? How > do we ensure people do not get crappy hardware, buggy OS'es/drivers and > outdated graphics APIs? > The Chrome team has been working with multiple GPU and operating system vendors to upstream the WebGL 2.0 conformance suite into their driver qualification tests to prevent regressions. This is an ongoing process, but worked well for WebGL 1.0 in the past. -Ken -------------- next part -------------- An HTML attachment was scrubbed... URL: From yan...@ Thu Jun 15 18:25:35 2017 From: yan...@ (Gu, Yang) Date: Fri, 16 Jun 2017 01:25:35 +0000 Subject: [Public WebGL] Current WebGL2 support In-Reply-To: References: Message-ID: <449511B60B07F243AAB9127EA4776CD05B72A4F2@SHSMSX104.ccr.corp.intel.com> We are the team at Intel that worked on WebGL 2 in the past 2.5 years with Khronos WebGL Working Group and Google Chrome Team (including ANGLE). Though we?re a very small team, and don?t have bandwidth to cover all variants of hardware, OS and driver, we still try very hard to get things better. Now we do the following things: 1. We order every new generation of Intel hardware, and now we have Haswell (GEN7.5), Broadwell (GEN8), Skylake (GEN9) and Kabylake (GEN9.5). Sometimes, we can get the newest hardware before its launch onto market. We?d focus more on newer hardware (within 3 years since its launch) than the old ones due to bandwidth. For example, now we focus more on Broadwell+ platforms, and spend less efforts on Haswell or even older platform like Ivybridge. 2. We cover 4 desktop platforms, including Windows, MacOS, Linux and ChromeOS. Again, we?d focus more newer versions. For example, now we only test against Windows 10, and for MacOS, we?d test both the latest stable and beta channel. Different OS has different cadence to release, but we try not to miss every big release. 3. For the driver, we also try to test against every big release. Again, different OS has different style of release. For driver that?s released often, like Linux Mesa driver, we test it periodically with master. 4. For above 3 factors (hardware, OS and driver), we do the combinations, and test them regularly with latest Chrome and CTS. Before the date Chrome M56 release that turned on WebGL 2 by default, we had daily test as Chrome and CTS (Conformance Test Suite) may have changes every day. Now we lower the frequency to once or twice a week to save efforts. We develop full automation test scripts to cover all the tests, report regression, and even bisect the regression of Chrome and driver (like Mesa driver for Linux and ChromeOS). Though the test itself is automatic, it still takes us non-trivial efforts to maintain the test infrastructure and analyze the issues. 5. Google has many test bots for Chrome, much more than we can afford? But so many machines mean they couldn?t upgrade the hardware, OS and driver as aggressively as us. Nevertheless, they still give us most generous support to gradually migrate their hardware to newer ones. Sometimes, we also suggest driver version to them that has best quality. 6. Chrome?s bug tracking system is another good friend that can help to collect issues from end users with real context. Sometimes, Google forward us some Intel GPU specific issues for further follow-up. Note that Google still have the best expertise on Chrome, and take care of most issues, especially issues general to all platforms. They spend tremendous efforts on this. 7. For every issue we know, either from our in-house test or Google, we will investigate in detail. And if it?s a driver issue, we?d work closely with our driver teams (Windows driver team, MacOS driver team and Mesa team for Linux and ChromeOS) to get it fixed ASAP. In the meantime, we will try to provide a small case to repro, and merge it into Khronos WebGL CTS, and Chrome test suites if necessary. And if possible, we?d try to work around the issue in Chrome as the driver fix may not reach the end users in any way soon. However, workaround is not always feasible because of too dramatic code changes, performance penalty, and other reasons. In all, the turnover of OS/hardware/driver doesn?t happen overnight, even the WannaCry ransomware didn?t do the magic? All we could do is to complete the conformance test suite as much as we can, test it often with combination of hardware, OS, driver and browser, and fix the issue ASAP. One thing we may do better is to test against pre-release hardware, OS, driver and browser, to get the issue fixed before it hits the users. We made some progress on this, but still many things are out of our control. Any suggestions are welcome! We hope to do better to deserve the title of ?largest number of GPU for PCs?. Regards, -Yang From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Mark Callow Sent: Friday, June 16, 2017 5:47 AM To: Florian B?sch Cc: Jamie Madill ; Joshua Groves ; Markus Sch?tz ; WebGL Mailinglist Subject: Re: [Public WebGL] Current WebGL2 support On Jun 15, 2017, at 12:59, Florian B?sch > wrote: My question about it though would be: how do we make sure that once that OS/hardware turnover has actually happened, that WebGL2 actually works? How do we ensure people do not get crappy hardware, buggy OS'es/drivers and outdated graphics APIs? I?ll just note that * I think Intel sells the largest number of GPU?s for PCs. * The Intel OpenGL drivers have been pretty good for some time now. * Intel has been quite involved in providing WebGL 2 conformance tests. Regards -Mark P.S. I have no connection to Intel. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Thu Jun 15 22:16:42 2017 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 16 Jun 2017 07:16:42 +0200 Subject: [Public WebGL] Current WebGL2 support In-Reply-To: References: Message-ID: On Fri, Jun 16, 2017 at 1:57 AM, Kenneth Russell wrote: > Looking at Chrome's internal statistics, about 30% of Chrome users are > stuck at Shader Model 3.0, implying that they're using ANGLE's Direct3D 9 > backend. WebGL 2.0 requires Direct3D 11. > Do you redistribute the DirectX runtime with Chrome? Here's what games typically do: https://www.junkship.net/News/2012/11/06/how-to-properly-distribute-directx-in-an-installer to get around the "old DirectX version" problem. > This is certainly the reason WebGL 2.0's market penetration has plateaued > on Windows -- older hardware. > Is it though? I know that steams statistics are biased towards gaming machines, but they claim http://store.steampowered.com/hwsurvey/videocard/ it's now 87.5% DX11 and up in the hardware population. Do you have an equivalent statistics for the hardware population that chrome sees? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Fri Jun 16 18:30:11 2017 From: kbr...@ (Kenneth Russell) Date: Fri, 16 Jun 2017 18:30:11 -0700 Subject: [Public WebGL] Current WebGL2 support In-Reply-To: References: Message-ID: On Thu, Jun 15, 2017 at 10:16 PM, Florian B?sch wrote: > On Fri, Jun 16, 2017 at 1:57 AM, Kenneth Russell wrote: > >> Looking at Chrome's internal statistics, about 30% of Chrome users are >> stuck at Shader Model 3.0, implying that they're using ANGLE's Direct3D 9 >> backend. WebGL 2.0 requires Direct3D 11. >> > > Do you redistribute the DirectX runtime with Chrome? Here's what games > typically do: https://www.junkship.net/News/2012/11/06/how-to- > properly-distribute-directx-in-an-installer to get around the "old > DirectX version" problem. > I'm not sure -- I think we redistribute the D3D compiler but not the runtime. > This is certainly the reason WebGL 2.0's market penetration has plateaued >> on Windows -- older hardware. >> > > Is it though? I know that steams statistics are biased towards gaming > machines, but they claim http://store.steampowered.com/hwsurvey/videocard/ > it's now 87.5% DX11 and up in the hardware population. Do you have an > equivalent statistics for the hardware population that chrome sees? > Apologies, I'm not sure how to query these statistics easily. All I can be sure of is that the 30% number is directly correlated to users stuck on D3D9. -Ken -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sat Jun 17 02:27:30 2017 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sat, 17 Jun 2017 11:27:30 +0200 Subject: [Public WebGL] Current WebGL2 support In-Reply-To: References: Message-ID: On Sat, Jun 17, 2017 at 3:30 AM, Kenneth Russell wrote: > On Thu, Jun 15, 2017 at 10:16 PM, Florian B?sch wrote: > >> On Fri, Jun 16, 2017 at 1:57 AM, Kenneth Russell wrote: >> >>> Looking at Chrome's internal statistics, about 30% of Chrome users are >>> stuck at Shader Model 3.0, implying that they're using ANGLE's Direct3D 9 >>> backend. WebGL 2.0 requires Direct3D 11. >>> >> >> Do you redistribute the DirectX runtime with Chrome? Here's what games >> typically do: https://www.junkship.net/News/2012/11/06/how-to-properly >> -distribute-directx-in-an-installer to get around the "old DirectX >> version" problem. >> > > I'm not sure -- I think we redistribute the D3D compiler but not the > runtime. > It's possible the number of people that only have the (system install) D3D9 but do have D3D11 compatible hardware is significant. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sat Jun 17 09:01:54 2017 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sat, 17 Jun 2017 18:01:54 +0200 Subject: [Public WebGL] Current WebGL2 support In-Reply-To: References: Message-ID: In case anybody wonders in the coming days about webglstats, the sample base is being expanded ~5x by delight-vr (about 1m samples/day). This is great news, but preliminary numbers suggest that WebGL2 support may be lower than from the previous sample base. Yesterday has it at 30%. This is probably due to a higher percentage of mobile visits being recorded (and WebGL2 being particularly low in support on mobiles). It underscores the need for a good sample base and I want to thank https://delight-vr.com/ from the bottom of my heart for helping improve the statistics. I will need to optimize updating a bit, it took 10h now to crunch trough yesterdays data :) On Sat, Jun 17, 2017 at 11:27 AM, Florian B?sch wrote: > On Sat, Jun 17, 2017 at 3:30 AM, Kenneth Russell wrote: > >> On Thu, Jun 15, 2017 at 10:16 PM, Florian B?sch wrote: >> >>> On Fri, Jun 16, 2017 at 1:57 AM, Kenneth Russell wrote: >>> >>>> Looking at Chrome's internal statistics, about 30% of Chrome users are >>>> stuck at Shader Model 3.0, implying that they're using ANGLE's Direct3D 9 >>>> backend. WebGL 2.0 requires Direct3D 11. >>>> >>> >>> Do you redistribute the DirectX runtime with Chrome? Here's what games >>> typically do: https://www.junkship.net/News/2012/11/06/how-to-properly >>> -distribute-directx-in-an-installer to get around the "old DirectX >>> version" problem. >>> >> >> I'm not sure -- I think we redistribute the D3D compiler but not the >> runtime. >> > > It's possible the number of people that only have the (system install) > D3D9 but do have D3D11 compatible hardware is significant. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From max...@ Sun Jun 18 21:22:56 2017 From: max...@ (Maksims Mihejevs) Date: Mon, 19 Jun 2017 05:22:56 +0100 Subject: [Public WebGL] Current WebGL2 support In-Reply-To: References: Message-ID: I wish some of popular io games and even io games portals would include the webglstats analytics. It definitely would improve sample even more. On 17 Jun 2017 5:55 p.m., "Florian B?sch" wrote: > In case anybody wonders in the coming days about webglstats, the sample > base is being expanded ~5x by delight-vr (about 1m samples/day). This is > great news, but preliminary numbers suggest that WebGL2 support may be > lower than from the previous sample base. Yesterday has it at 30%. This is > probably due to a higher percentage of mobile visits being recorded (and > WebGL2 being particularly low in support on mobiles). > > It underscores the need for a good sample base and I want to thank > https://delight-vr.com/ from the bottom of my heart for helping improve > the statistics. > > I will need to optimize updating a bit, it took 10h now to crunch trough > yesterdays data :) > > > On Sat, Jun 17, 2017 at 11:27 AM, Florian B?sch wrote: > >> On Sat, Jun 17, 2017 at 3:30 AM, Kenneth Russell wrote: >> >>> On Thu, Jun 15, 2017 at 10:16 PM, Florian B?sch >>> wrote: >>> >>>> On Fri, Jun 16, 2017 at 1:57 AM, Kenneth Russell >>>> wrote: >>>> >>>>> Looking at Chrome's internal statistics, about 30% of Chrome users are >>>>> stuck at Shader Model 3.0, implying that they're using ANGLE's Direct3D 9 >>>>> backend. WebGL 2.0 requires Direct3D 11. >>>>> >>>> >>>> Do you redistribute the DirectX runtime with Chrome? Here's what games >>>> typically do: https://www.junkship.net/News/2012/11/06/how-to-properly >>>> -distribute-directx-in-an-installer to get around the "old DirectX >>>> version" problem. >>>> >>> >>> I'm not sure -- I think we redistribute the D3D compiler but not the >>> runtime. >>> >> >> It's possible the number of people that only have the (system install) >> D3D9 but do have D3D11 compatible hardware is significant. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sun Jun 25 12:44:00 2017 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 25 Jun 2017 21:44:00 +0200 Subject: [Public WebGL] WebGL 2.1? Message-ID: According to specification/release cadence a WebGL 2.1 draft specification should be about ready now. Where is it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From cwa...@ Mon Jun 26 07:35:58 2017 From: cwa...@ (Corentin Wallez) Date: Mon, 26 Jun 2017 10:35:58 -0400 Subject: [Public WebGL] WebGL 2.1? In-Reply-To: References: Message-ID: I'm not sure what the cadence you are referring to, my understanding is that WebGL versions are ready when they are ready. That said, two things: - OpenGL ES 3.1 will be very difficult to support on OSX as compute would require using OpenCL or Metal. This would prevent shipping a WebGL 2.1 on OSX, at which point it might not make sense to make a new version of WebGL vs. extensions. - Apart from browser implementations, three things have to happen for a new WebGL version: spec-writing, having a CTS and adding support in ANGLE. The latter is well under way: contributors from Intel and NVIDIA have made great progress towards implementing ES 3.1 on top of D3D11 (and OpenGL) in ANGLE. On Sun, Jun 25, 2017 at 3:44 PM, Florian B?sch wrote: > According to specification/release cadence a WebGL 2.1 draft specification > should be about ready now. Where is it? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Mon Jun 26 11:54:03 2017 From: kbr...@ (Kenneth Russell) Date: Mon, 26 Jun 2017 11:54:03 -0700 Subject: [Public WebGL] WebGL 2.1? In-Reply-To: References: Message-ID: As Corentin points out, contributors from Intel and NVIDIA are making great progress adding the ES 3.1 feature set to ANGLE. This is a prerequisite for exposing this functionality as an extension to WebGL 2.0. This work is occurring in parallel to the following work on WebGL 2.0: - Addressing bug reports against WebGL 2.0 from customers - Exposing individual extensions needed urgently by customers - Providing better control of power vs. performance via the powerPreference flag - Optimizing video-to-texture uploads for better 360 video support in WebVR -Ken On Mon, Jun 26, 2017 at 7:35 AM, Corentin Wallez wrote: > I'm not sure what the cadence you are referring to, my understanding is > that WebGL versions are ready when they are ready. That said, two things: > > - OpenGL ES 3.1 will be very difficult to support on OSX as compute > would require using OpenCL or Metal. This would prevent shipping a WebGL > 2.1 on OSX, at which point it might not make sense to make a new version of > WebGL vs. extensions. > - Apart from browser implementations, three things have to happen for > a new WebGL version: spec-writing, having a CTS and adding support in > ANGLE. The latter is well under way: contributors from Intel and NVIDIA > have made great progress towards implementing ES 3.1 on top of D3D11 (and > OpenGL) in ANGLE. > > > On Sun, Jun 25, 2017 at 3:44 PM, Florian B?sch wrote: > >> According to specification/release cadence a WebGL 2.1 draft >> specification should be about ready now. Where is it? >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Mon Jun 26 12:13:20 2017 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Mon, 26 Jun 2017 21:13:20 +0200 Subject: [Public WebGL] WebGL 2.1? In-Reply-To: References: Message-ID: So I take it the answer is not anytime soon, if ever? I would've kinda hoped that WebGL would start to catch up (or at least keep pace) with the ES release schedule. But as it looks like WebGL 2.1 would be expanding on the lag again for the 2nd time... On Mon, Jun 26, 2017 at 8:54 PM, Kenneth Russell wrote: > As Corentin points out, contributors from Intel and NVIDIA are making > great progress adding the ES 3.1 feature set to ANGLE. This is a > prerequisite for exposing this functionality as an extension to WebGL 2.0. > This work is occurring in parallel to the following work on WebGL 2.0: > > - Addressing bug reports against WebGL 2.0 from customers > - Exposing individual extensions needed urgently by customers > - Providing better control of power vs. performance via the > powerPreference flag > - Optimizing video-to-texture uploads for better 360 video support in > WebVR > > -Ken > > > > On Mon, Jun 26, 2017 at 7:35 AM, Corentin Wallez > wrote: > >> I'm not sure what the cadence you are referring to, my understanding is >> that WebGL versions are ready when they are ready. That said, two things: >> >> - OpenGL ES 3.1 will be very difficult to support on OSX as compute >> would require using OpenCL or Metal. This would prevent shipping a WebGL >> 2.1 on OSX, at which point it might not make sense to make a new version of >> WebGL vs. extensions. >> - Apart from browser implementations, three things have to happen for >> a new WebGL version: spec-writing, having a CTS and adding support in >> ANGLE. The latter is well under way: contributors from Intel and NVIDIA >> have made great progress towards implementing ES 3.1 on top of D3D11 (and >> OpenGL) in ANGLE. >> >> >> On Sun, Jun 25, 2017 at 3:44 PM, Florian B?sch wrote: >> >>> According to specification/release cadence a WebGL 2.1 draft >>> specification should be about ready now. Where is it? >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Mon Jun 26 15:12:59 2017 From: kbr...@ (Kenneth Russell) Date: Mon, 26 Jun 2017 15:12:59 -0700 Subject: [Public WebGL] WebGL 2.1? In-Reply-To: References: Message-ID: It's not feasible for us to support compute shaders in WebGL on macOS or iOS -- this would require ANGLE to be ported to Metal, since there is no OpenGL version on these operating systems which supports compute shaders. For this reason we're focusing on exposing compute shaders as a WebGL 2.0 extension to be delivered on Windows, Linux, and Android. The GPU for the Web W3C Community Group is building a new lower-level API which will support compute everywhere, and which will be easier to port than OpenGL ES 3.1. On Mon, Jun 26, 2017 at 12:13 PM, Florian B?sch wrote: > So I take it the answer is not anytime soon, if ever? I would've kinda > hoped that WebGL would start to catch up (or at least keep pace) with the > ES release schedule. But as it looks like WebGL 2.1 would be expanding on > the lag again for the 2nd time... > > On Mon, Jun 26, 2017 at 8:54 PM, Kenneth Russell wrote: > >> As Corentin points out, contributors from Intel and NVIDIA are making >> great progress adding the ES 3.1 feature set to ANGLE. This is a >> prerequisite for exposing this functionality as an extension to WebGL 2.0. >> This work is occurring in parallel to the following work on WebGL 2.0: >> >> - Addressing bug reports against WebGL 2.0 from customers >> - Exposing individual extensions needed urgently by customers >> - Providing better control of power vs. performance via the >> powerPreference flag >> - Optimizing video-to-texture uploads for better 360 video support in >> WebVR >> >> -Ken >> >> >> >> On Mon, Jun 26, 2017 at 7:35 AM, Corentin Wallez >> wrote: >> >>> I'm not sure what the cadence you are referring to, my understanding is >>> that WebGL versions are ready when they are ready. That said, two things: >>> >>> - OpenGL ES 3.1 will be very difficult to support on OSX as compute >>> would require using OpenCL or Metal. This would prevent shipping a WebGL >>> 2.1 on OSX, at which point it might not make sense to make a new version of >>> WebGL vs. extensions. >>> - Apart from browser implementations, three things have to happen >>> for a new WebGL version: spec-writing, having a CTS and adding support in >>> ANGLE. The latter is well under way: contributors from Intel and NVIDIA >>> have made great progress towards implementing ES 3.1 on top of D3D11 (and >>> OpenGL) in ANGLE. >>> >>> >>> On Sun, Jun 25, 2017 at 3:44 PM, Florian B?sch wrote: >>> >>>> According to specification/release cadence a WebGL 2.1 draft >>>> specification should be about ready now. Where is it? >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From osk...@ Mon Jun 26 17:37:53 2017 From: osk...@ (Oskar Skrinjar) Date: Mon, 26 Jun 2017 20:37:53 -0400 Subject: [Public WebGL] WebGL 2 and compute shaders support In-Reply-To: References: Message-ID: <20170626203753.Horde.zWT9A0XVTkE13E-bV3-3OJi@vps15070.inmotionhosting.com> Hi all: 1. Is it known, at least approximately, when the compute shader extension for WebGL 2 will be available for Google Chrome and/or Firefox for desktops? 2. Any estimates on when WebGL 2 will be supported in IE/Edge? 3. Any estimates on when WebGL 2 will be supported in iOS? Thank you, Oskar Oskar Skrinjar, PhD Scientific Imaging and Visualization, LLC Website: http://www.scientificiv.com Email: oskar...@ Phone: 404 863 2371 ----------------------------------------------------------- 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 khr...@ Mon Jun 26 20:10:33 2017 From: khr...@ (Mark Callow) Date: Mon, 26 Jun 2017 20:10:33 -0700 Subject: [Public WebGL] WebGL 2.1? In-Reply-To: References: Message-ID: <40D6611B-F7D7-49D2-A75E-305C4AF64DCE@callow.im> > On Jun 26, 2017, at 15:12, Kenneth Russell wrote: > > It's not feasible for us to support compute shaders in WebGL on macOS or iOS -- this would require ANGLE to be ported to Metal, since there is no OpenGL version on these operating systems which supports compute shaders. For this reason we're focusing on exposing compute shaders as a WebGL 2.0 extension to be delivered on Windows, Linux, and Android. Could you use MoltenGL (GL on Metal)? 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 URL: From cwa...@ Mon Jun 26 20:28:19 2017 From: cwa...@ (Corentin Wallez) Date: Mon, 26 Jun 2017 23:28:19 -0400 Subject: [Public WebGL] WebGL 2.1? In-Reply-To: <40D6611B-F7D7-49D2-A75E-305C4AF64DCE@callow.im> References: <40D6611B-F7D7-49D2-A75E-305C4AF64DCE@callow.im> Message-ID: MoltenGL only supports ES 2.0 and there no evidence that it passed conformance. I don't think they would want to pass it as it would require adding state tracking and corner-case handling that would reduce performance a bit. Re: GPU for the Web, since we control the design of the API, we can make sure compute works portably more easily than through the lens of OpenGL. Chromium's prototype, NXT , already supports compute through GL and Metal, soon D3D12 and Vulkan, and had it working in a prototype Chromium fork. On Mon, Jun 26, 2017 at 11:10 PM, Mark Callow wrote: > > On Jun 26, 2017, at 15:12, Kenneth Russell wrote: > > It's not feasible for us to support compute shaders in WebGL on macOS or > iOS -- this would require ANGLE to be ported to Metal, since there is no > OpenGL version on these operating systems which supports compute shaders. > For this reason we're focusing on exposing compute shaders as a WebGL 2.0 > extension to be delivered on Windows, Linux, and Android. > > > Could you use MoltenGL (GL on Metal)? > > Regards > > -Mark > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cwa...@ Mon Jun 26 20:37:58 2017 From: cwa...@ (Corentin Wallez) Date: Mon, 26 Jun 2017 23:37:58 -0400 Subject: [Public WebGL] WebGL 2 and compute shaders support In-Reply-To: <20170626203753.Horde.zWT9A0XVTkE13E-bV3-3OJi@vps15070.inmotionhosting.com> References: <20170626203753.Horde.zWT9A0XVTkE13E-bV3-3OJi@vps15070.inmotionhosting.com> Message-ID: Hey Oskar, I don't know about 2) and 3). For 1): The compute extension for WebGL2 would still require a huge amount of work to happen just for CTS, and there is the spec to write, ANGLE to implement and browser implementations to write. So there is no ETA (and a lower bound of at least 6 month, if not a year). GPU for the Web's work would be another way to get compute on the Web, and as mentioned in the other thread, we (Chromium) have prototype that got compute running on OpenGL and Metal, and on the Web. My hope is that we can get something out in two years, but ~software estimates~ you know :) Corentin On Mon, Jun 26, 2017 at 8:37 PM, Oskar Skrinjar wrote: > > Hi all: > > > 1. Is it known, at least approximately, when the compute shader extension > for WebGL 2 will be available for Google Chrome and/or Firefox for desktops? > > 2. Any estimates on when WebGL 2 will be supported in IE/Edge? > > 3. Any estimates on when WebGL 2 will be supported in iOS? > > > Thank you, > > Oskar > > > > Oskar Skrinjar, PhD > Scientific Imaging and Visualization, LLC > Website: http://www.scientificiv.com > Email: oskar...@ > Phone: 404 863 2371 > > > ----------------------------------------------------------- > 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 > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Mon Jun 26 22:08:53 2017 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Tue, 27 Jun 2017 07:08:53 +0200 Subject: [Public WebGL] WebGL 2.1? In-Reply-To: References: Message-ID: On Tue, Jun 27, 2017 at 12:12 AM, Kenneth Russell wrote: > For this reason we're focusing on exposing compute shaders as a WebGL 2.0 > extension to be delivered on Windows, Linux, and Android. > There is no OpenGL ES compute shader extension (there is one for desktop GL though). Is there any advantage to doing an extension rather than an API revision? > The GPU for the Web W3C Community Group is building a new lower-level API > which will support compute everywhere, and which will be easier to port > than OpenGL ES 3.1. > Being an entirely new API without cross-vendor agreement it'll take a considerable amount of time till anything comes out of that. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Fra...@ Tue Jun 27 11:39:14 2017 From: Fra...@ (Frank Olivier) Date: Tue, 27 Jun 2017 18:39:14 +0000 Subject: [Public WebGL] WebGL 2 and compute shaders support In-Reply-To: <20170626203753.Horde.zWT9A0XVTkE13E-bV3-3OJi@vps15070.inmotionhosting.com> References: <20170626203753.Horde.zWT9A0XVTkE13E-bV3-3OJi@vps15070.inmotionhosting.com> Message-ID: IjIuIEFueSBlc3RpbWF0ZXMgb24gd2hlbiBXZWJHTCAyIHdpbGwgYmUgc3VwcG9ydGVkIGluIElF L0VkZ2U/Ig0KDQpXZSBhcmUgd29ya2luZyBvbiBpbXByb3ZpbmcgV2ViR0wgc3VwcG9ydCBpbiBF ZGdlOyBZb3UgY2FuIHRyYWNrIHByb2dyZXNzIG9mIEVkZ2UgZmVhdHVyZXMgYXQgc3RhdHVzLm1p Y3Jvc29mdGVkZ2UuY29tLiBXZSBkb24ndCBoYXZlIGFueSBlc3RpbWF0ZXMgLyBhbm5vdW5jZW1l bnRzIGp1c3QgcXVpdGUgeWV0Lg0KDQpJRTExIGlzIG5vdCBnZXR0aW5nIG5ldyBmZWF0dXJlcyBh bnltb3JlOyB3ZSdyZSB3b3JraW5nIGhhcmQgdG8gbW92ZSBJRSB1c2VycyB0byBldmVyZ3JlZW4g RWRnZS4NCg0KVGhhbmtzDQpGcmFuayBPbGl2aWVyDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogb3duZXJzLXB1YmxpY193ZWJnbEBraHJvbm9zLm9yZyBbbWFpbHRvOm93 bmVycy1wdWJsaWNfd2ViZ2xAa2hyb25vcy5vcmddIE9uIEJlaGFsZiBPZiBPc2thciBTa3Jpbmph cg0KU2VudDogTW9uZGF5LCBKdW5lIDI2LCAyMDE3IDU6MzggUE0NClRvOiBwdWJsaWNfd2ViZ2xA a2hyb25vcy5vcmcNClN1YmplY3Q6IFtQdWJsaWMgV2ViR0xdIFdlYkdMIDIgYW5kIGNvbXB1dGUg c2hhZGVycyBzdXBwb3J0DQoNCg0KSGkgYWxsOg0KDQoNCjEuIElzIGl0IGtub3duLCBhdCBsZWFz dCBhcHByb3hpbWF0ZWx5LCB3aGVuIHRoZSBjb21wdXRlIHNoYWRlciBleHRlbnNpb24gZm9yIFdl YkdMIDIgd2lsbCBiZSBhdmFpbGFibGUgZm9yIEdvb2dsZSBDaHJvbWUgYW5kL29yIEZpcmVmb3gg Zm9yIGRlc2t0b3BzPw0KDQoyLiBBbnkgZXN0aW1hdGVzIG9uIHdoZW4gV2ViR0wgMiB3aWxsIGJl IHN1cHBvcnRlZCBpbiBJRS9FZGdlPw0KDQozLiBBbnkgZXN0aW1hdGVzIG9uIHdoZW4gV2ViR0wg MiB3aWxsIGJlIHN1cHBvcnRlZCBpbiBpT1M/DQoNCg0KVGhhbmsgeW91LA0KDQpPc2thcg0KDQoN Cg0KT3NrYXIgU2tyaW5qYXIsIFBoRA0KU2NpZW50aWZpYyBJbWFnaW5nIGFuZCBWaXN1YWxpemF0 aW9uLCBMTEMNCldlYnNpdGU6IGh0dHA6Ly93d3cuc2NpZW50aWZpY2l2LmNvbQ0KRW1haWw6IG9z a2FyQHNjaWVudGlmaWNpdi5jb20NClBob25lOiA0MDQgODYzIDIzNzENCg0KDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWW91IGFy ZSBjdXJyZW50bHkgc3Vic2NyaWJlZCB0byBwdWJsaWNfd2ViZ2xAa2hyb25vcy5vcmcuDQpUbyB1 bnN1YnNjcmliZSwgc2VuZCBhbiBlbWFpbCB0byBtYWpvcmRvbW9Aa2hyb25vcy5vcmcgd2l0aCB0 aGUgZm9sbG93aW5nIGNvbW1hbmQgaW4gdGhlIGJvZHkgb2YgeW91ciBlbWFpbDoNCnVuc3Vic2Ny aWJlIHB1YmxpY193ZWJnbA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K ----------------------------------------------------------- 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...@ Tue Jun 27 15:14:09 2017 From: kbr...@ (Kenneth Russell) Date: Tue, 27 Jun 2017 15:14:09 -0700 Subject: [Public WebGL] WebGL 2.1? In-Reply-To: References: Message-ID: On Mon, Jun 26, 2017 at 10:08 PM, Florian B?sch wrote: > On Tue, Jun 27, 2017 at 12:12 AM, Kenneth Russell wrote: > >> For this reason we're focusing on exposing compute shaders as a WebGL 2.0 >> extension to be delivered on Windows, Linux, and Android. >> > There is no OpenGL ES compute shader extension (there is one for desktop > GL though). Is there any advantage to doing an extension rather than an API > revision? > The working group can motivate getting it out more quickly as an extension. Think of it like an "extension pack", a concept that was used in the OpenGL ES working group. For example, we will probably take the shortcut of using WebAssembly to compile the existing ES 3.1 conformance tests and run them on the web, rather than porting them to JavaScript, as was done for the WebGL 2.0 conformance tests. > The GPU for the Web W3C Community Group is building a new lower-level API >> which will support compute everywhere, and which will be easier to port >> than OpenGL ES 3.1. >> > Being an entirely new API without cross-vendor agreement it'll take a > considerable amount of time till anything comes out of that. > It's moving along more quickly than you might think. -Ken -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue Jun 27 15:23:38 2017 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 28 Jun 2017 00:23:38 +0200 Subject: [Public WebGL] WebGL 2.1? In-Reply-To: References: Message-ID: On Wed, Jun 28, 2017 at 12:14 AM, Kenneth Russell wrote: > It's moving along more quickly than you might think. > What's the status there. Is the current favorite the one that only runs on apple devices, or the one that doesn't have a JS interface? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rya...@ Tue Jun 27 15:50:39 2017 From: rya...@ (Ryan Patterson) Date: Tue, 27 Jun 2017 18:50:39 -0400 Subject: [Public WebGL] WebGL 2.1? In-Reply-To: References: Message-ID: With all due respect I disagree. Exposing new features as an extension sends a message to browser/OS vendors that the new features are optional and they need not add support for them. Exposing features on the core context sends a clear message that the new features are important and need to be supported. _____________ Ryan Patterson On Tue, Jun 27, 2017 at 6:10 PM, Kenneth Russell wrote: > There is no veto involved. As the WebGL working group we want the core > specification to remain portable. It's not a big deal to expose the new > features as an extension rather than on the core rendering context. > > > On Tue, Jun 27, 2017 at 5:34 AM, Ryan Patterson > wrote: > >> Why does Apple have a pocket veto on this? WebGL 2.1 (with compute >> shaders) should move forward. Apple can add the required openGL api's to >> their platforms if they care about their users. >> >> _____________ >> Ryan Patterson >> >> On Mon, Jun 26, 2017 at 6:12 PM, Kenneth Russell wrote: >> >>> It's not feasible for us to support compute shaders in WebGL on macOS or >>> iOS -- this would require ANGLE to be ported to Metal, since there is no >>> OpenGL version on these operating systems which supports compute shaders. >>> For this reason we're focusing on exposing compute shaders as a WebGL 2.0 >>> extension to be delivered on Windows, Linux, and Android. >>> >>> The GPU for the Web W3C Community Group is building a new lower-level >>> API which will support compute everywhere, and which will be easier to port >>> than OpenGL ES 3.1. >>> >>> >>> On Mon, Jun 26, 2017 at 12:13 PM, Florian B?sch >>> wrote: >>> >>>> So I take it the answer is not anytime soon, if ever? I would've kinda >>>> hoped that WebGL would start to catch up (or at least keep pace) with the >>>> ES release schedule. But as it looks like WebGL 2.1 would be expanding on >>>> the lag again for the 2nd time... >>>> >>>> On Mon, Jun 26, 2017 at 8:54 PM, Kenneth Russell >>>> wrote: >>>> >>>>> As Corentin points out, contributors from Intel and NVIDIA are making >>>>> great progress adding the ES 3.1 feature set to ANGLE. This is a >>>>> prerequisite for exposing this functionality as an extension to WebGL 2.0. >>>>> This work is occurring in parallel to the following work on WebGL 2.0: >>>>> >>>>> - Addressing bug reports against WebGL 2.0 from customers >>>>> - Exposing individual extensions needed urgently by customers >>>>> - Providing better control of power vs. performance via the >>>>> powerPreference flag >>>>> - Optimizing video-to-texture uploads for better 360 video support in >>>>> WebVR >>>>> >>>>> -Ken >>>>> >>>>> >>>>> >>>>> On Mon, Jun 26, 2017 at 7:35 AM, Corentin Wallez >>>>> wrote: >>>>> >>>>>> I'm not sure what the cadence you are referring to, my understanding >>>>>> is that WebGL versions are ready when they are ready. That said, two things: >>>>>> >>>>>> - OpenGL ES 3.1 will be very difficult to support on OSX as >>>>>> compute would require using OpenCL or Metal. This would prevent shipping a >>>>>> WebGL 2.1 on OSX, at which point it might not make sense to make a new >>>>>> version of WebGL vs. extensions. >>>>>> - Apart from browser implementations, three things have to happen >>>>>> for a new WebGL version: spec-writing, having a CTS and adding support in >>>>>> ANGLE. The latter is well under way: contributors from Intel and NVIDIA >>>>>> have made great progress towards implementing ES 3.1 on top of D3D11 (and >>>>>> OpenGL) in ANGLE. >>>>>> >>>>>> >>>>>> On Sun, Jun 25, 2017 at 3:44 PM, Florian B?sch >>>>>> wrote: >>>>>> >>>>>>> According to specification/release cadence a WebGL 2.1 draft >>>>>>> specification should be about ready now. Where is it? >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cwa...@ Tue Jun 27 16:23:49 2017 From: cwa...@ (Corentin Wallez) Date: Tue, 27 Jun 2017 19:23:49 -0400 Subject: [Public WebGL] WebGL 2.1? In-Reply-To: References: Message-ID: On Tue, Jun 27, 2017 at 6:50 PM, Ryan Patterson wrote: > With all due respect I disagree. Exposing new features as an extension > sends a message to browser/OS vendors that the new features are optional > and they need not add support for them. Exposing features on the core > context sends a clear message that the new features are important and need > to be supported. > > Making it optional is the point, as no browser will be able to support compute shaders in WebGL on OSX. The alternative would require someone (your company?) to donate many engineering years to make ANGLE GL ES 3.1 work on Metal. > _____________ > Ryan Patterson > > On Tue, Jun 27, 2017 at 6:10 PM, Kenneth Russell wrote: > >> There is no veto involved. As the WebGL working group we want the core >> specification to remain portable. It's not a big deal to expose the new >> features as an extension rather than on the core rendering context. >> >> >> On Tue, Jun 27, 2017 at 5:34 AM, Ryan Patterson >> wrote: >> >>> Why does Apple have a pocket veto on this? WebGL 2.1 (with compute >>> shaders) should move forward. Apple can add the required openGL api's to >>> their platforms if they care about their users. >>> >>> _____________ >>> Ryan Patterson >>> >>> On Mon, Jun 26, 2017 at 6:12 PM, Kenneth Russell wrote: >>> >>>> It's not feasible for us to support compute shaders in WebGL on macOS >>>> or iOS -- this would require ANGLE to be ported to Metal, since there is no >>>> OpenGL version on these operating systems which supports compute shaders. >>>> For this reason we're focusing on exposing compute shaders as a WebGL 2.0 >>>> extension to be delivered on Windows, Linux, and Android. >>>> >>>> The GPU for the Web W3C Community Group is building a new lower-level >>>> API which will support compute everywhere, and which will be easier to port >>>> than OpenGL ES 3.1. >>>> >>>> >>>> On Mon, Jun 26, 2017 at 12:13 PM, Florian B?sch >>>> wrote: >>>> >>>>> So I take it the answer is not anytime soon, if ever? I would've kinda >>>>> hoped that WebGL would start to catch up (or at least keep pace) with the >>>>> ES release schedule. But as it looks like WebGL 2.1 would be expanding on >>>>> the lag again for the 2nd time... >>>>> >>>>> On Mon, Jun 26, 2017 at 8:54 PM, Kenneth Russell >>>>> wrote: >>>>> >>>>>> As Corentin points out, contributors from Intel and NVIDIA are making >>>>>> great progress adding the ES 3.1 feature set to ANGLE. This is a >>>>>> prerequisite for exposing this functionality as an extension to WebGL 2.0. >>>>>> This work is occurring in parallel to the following work on WebGL 2.0: >>>>>> >>>>>> - Addressing bug reports against WebGL 2.0 from customers >>>>>> - Exposing individual extensions needed urgently by customers >>>>>> - Providing better control of power vs. performance via the >>>>>> powerPreference flag >>>>>> - Optimizing video-to-texture uploads for better 360 video support >>>>>> in WebVR >>>>>> >>>>>> -Ken >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Jun 26, 2017 at 7:35 AM, Corentin Wallez >>>>>> wrote: >>>>>> >>>>>>> I'm not sure what the cadence you are referring to, my understanding >>>>>>> is that WebGL versions are ready when they are ready. That said, two things: >>>>>>> >>>>>>> - OpenGL ES 3.1 will be very difficult to support on OSX as >>>>>>> compute would require using OpenCL or Metal. This would prevent shipping a >>>>>>> WebGL 2.1 on OSX, at which point it might not make sense to make a new >>>>>>> version of WebGL vs. extensions. >>>>>>> - Apart from browser implementations, three things have to >>>>>>> happen for a new WebGL version: spec-writing, having a CTS and adding >>>>>>> support in ANGLE. The latter is well under way: contributors from Intel and >>>>>>> NVIDIA have made great progress towards implementing ES 3.1 on top of D3D11 >>>>>>> (and OpenGL) in ANGLE. >>>>>>> >>>>>>> >>>>>>> On Sun, Jun 25, 2017 at 3:44 PM, Florian B?sch >>>>>>> wrote: >>>>>>> >>>>>>>> According to specification/release cadence a WebGL 2.1 draft >>>>>>>> specification should be about ready now. Where is it? >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: