From khr...@ Wed Mar 1 02:04:38 2017 From: khr...@ (Mark Callow) Date: Wed, 1 Mar 2017 19:04:38 +0900 Subject: [Public WebGL] async shader compiliation In-Reply-To: References: <45108D48-4016-4B84-B4B9-B036D4E095B9@callow.im> Message-ID: <956D5C19-A9E6-432A-91FD-A980874A0AE9@callow.im> > On Feb 28, 2017, at 1:21, Maksims Mihejevs wrote: > > (if they are ubershaders) Throughout the time I?ve been working with OpenGL ES 2+, ubershaders have generally been regarded as something to avoid. At the dawn of OpenGL ES 2 the concern was whether such shaders could be compiled and would fit in the available memory of the devices of those days. There was also concern about introducing lots of extra tests and branches for every vertex or fragment. The first example of an ?ubershader? was a shader to mimic the OpenGL ES 1 fixed-function pipeline. This was abandoned in favor of a set of smaller shaders, chosen and loaded according to the fixed-function state in use. As far as I know this was the model adopted by all IHV?s who provided OpenGL ES 1 support on their OpenGL ES 2 parts. To avoid doubt, let me state that I am not trying to downplay the importance of async shader compilation. 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 max...@ Wed Mar 1 02:58:26 2017 From: max...@ (Maksims Mihejevs) Date: Wed, 1 Mar 2017 10:58:26 +0000 Subject: [Public WebGL] async shader compiliation In-Reply-To: <956D5C19-A9E6-432A-91FD-A980874A0AE9@callow.im> References: <45108D48-4016-4B84-B4B9-B036D4E095B9@callow.im> <956D5C19-A9E6-432A-91FD-A980874A0AE9@callow.im> Message-ID: > > This was abandoned in favor of a set of smaller shaders, chosen and loaded > according to the fixed-function state in use. This is pretty much what we do, and many other nowadays uber shader systems do: they make shader code based on provided arguments. For example if only diffuseMap is used, then shader will be very simple. If diffuseMap + PBR used, it will get a bit more complicated, and so on. Some of things are driven by uniforms where possible, for example intensity for colour or opacity. But some will lead to shader re-generation, like availability of certain texture on material. So shaders include *only* what is used by material and specific mesh being rendered with that material. Ubershader - is pretty much the only way to go decent with Forward Renderer. We do need async shader compilation, but more we need is faster shader compilation in first place. Cheers, Max On 1 March 2017 at 10:04, Mark Callow wrote: > > On Feb 28, 2017, at 1:21, Maksims Mihejevs wrote: > > (if they are ubershaders) > > > Throughout the time I?ve been working with OpenGL ES 2+, ubershaders have > generally been regarded as something to avoid. At the dawn of OpenGL ES 2 > the concern was whether such shaders could be compiled and would fit in the > available memory of the devices of those days. There was also concern about > introducing lots of extra tests and branches for every vertex or fragment. > The first example of an ?ubershader? was a shader to mimic the OpenGL ES 1 > fixed-function pipeline. This was abandoned in favor of a set of smaller > shaders, chosen and loaded according to the fixed-function state in use. As > far as I know this was the model adopted by all IHV?s who provided OpenGL > ES 1 support on their OpenGL ES 2 parts. > > To avoid doubt, let me state that I am not trying to downplay the > importance of async shader compilation. > > Regards > > -Mark > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From max...@ Wed Mar 1 08:41:33 2017 From: max...@ (Maksims Mihejevs) Date: Wed, 1 Mar 2017 16:41:33 +0000 Subject: [Public WebGL] async shader compiliation In-Reply-To: References: <45108D48-4016-4B84-B4B9-B036D4E095B9@callow.im> <956D5C19-A9E6-432A-91FD-A980874A0AE9@callow.im> Message-ID: > > Max, would you be able to make a self-contained test case which just > compiles all of the shaders from After the Flood back-to-back, measuring > the time between starting compiling the first one and linking the last one? Hi Kenneth. I've made isolated example with shader compilation. http://moka.co/shader-compilation/ - online version. Find archive in attachment to run it on local machine. Please run this and post some results. This example uses shaders from After the Flood WebGL 2.0 demo https://playcanv.as/p/44MRmJRU/ which is what real-world next-gen apps usually look like. I will remind that we've been optimizing this app a lot before release, and made shaders compilation times twice faster by reducing a lot of unnecessary shader code. App is very simple - it gets some info about device, then gets WebGL 2.0 context, loads raw text file with many shaders. Then it compiles each shader, makes program, links it, and gets some attributes and uniforms. It prevents any caching to take in place as well (either driver or browser), as noticed that was happening and made testing harder. It does it by adding random float constant to each shader. Box at the bottom - is animated by CSS, and turns orange just before compilation start. For the time it is orange/frozen page is unresponsive. In most cases many things turn unresponsive, for example when tabs share JS thread. Or any other webgl content in browser. Tested this on few platforms, so here are some results: Windows; GTX 880M; ANGLE (DX11); i7-4810MQ; Chrome 58; ~*5,300 ms* Windows; GTX 1070; ANGLE (DX11); i7-6820HK; Chrome 56; ~*7,200 ms* Windows; GTX 980; ANGLE (DX11); i7-4790; Chrome 56; ~*6,300 ms* Windows; GTX 980 Ti; ANGLE (DX11); i7 3770k; Chrome 56; ~*5,100 ms* Windows; GTX 970; ANGLE (DX11); i7-3770; Firefox 52; ~*7,600 ms* Windows; GTX 970; ANGLE (DX11); i7-3770; Chrome 58; ~*5,500 ms* Windows; GTX 970; (GL); i7-3770; Chrome 58; ~*3,200 ms* Windows; Intel HD 4000; ANGLE (DX11); Chrome 56; ~*11,000 ms* Linux; GTX 970; i7-6700; Chrome 56; ~*1,900 ms* Linux; GTX 670; i7-6700; Firefox 51; ~*2,100 ms* Linux; GTX 980 Ti; i5 4690k; Chrome 56; ~*2,200 ms* Mac Book 13" late 2013; Inter Iris; i7; ~*900 ms* iMac 27" late 2012; GTX 660M; i5; Chrome 56; ~*900 ms* iMac 27" late 2012; GTX 660M; i5; Firefox 51; ~*930 ms* Android; One Plus Two; Adreno 430; Firefox 52; ~*9,600 ms* Android; One Plus Two; Adreno 430; Chrome 58; ~*11,600 ms* Android; One Plus Three; Adreno 530; Chrome 56; ~*7,500 ms* What is interesting, that on Android, compilation takes a bit longer than linking. When on Desktop Linux and Windows compilation is 3-10 times faster than linking. Although old Mac Book and iMac linking is way faster than compilation, although their fill-rate capabilities are poor. Is Apple doing GLSL compilation better? *I mean: GTX 1070 with i7-6820HK CPU, compiling as slow as Android OP3.. Really?* You can clearly see from tests that linking/compilation times are jumping all around very inconsistently. ANGLE path is clearly loosing dramatically against GL path. *Do remember this is not most complex WebGL app and this bold times - is for how long whole thing freezes page and in some cases whole device.* Looking forward to hear back from you guys. Kind Regards, Max On 1 March 2017 at 10:58, Maksims Mihejevs wrote: > This was abandoned in favor of a set of smaller shaders, chosen and loaded >> according to the fixed-function state in use. > > > This is pretty much what we do, and many other nowadays uber shader > systems do: they make shader code based on provided arguments. > For example if only diffuseMap is used, then shader will be very simple. > If diffuseMap + PBR used, it will get a bit more complicated, and so on. > Some of things are driven by uniforms where possible, for example intensity > for colour or opacity. But some will lead to shader re-generation, like > availability of certain texture on material. So shaders include *only* > what is used by material and specific mesh being rendered with that > material. > > Ubershader - is pretty much the only way to go decent with Forward > Renderer. > > We do need async shader compilation, but more we need is faster shader > compilation in first place. > > Cheers, > Max > > On 1 March 2017 at 10:04, Mark Callow wrote: > >> >> On Feb 28, 2017, at 1:21, Maksims Mihejevs wrote: >> >> (if they are ubershaders) >> >> >> Throughout the time I?ve been working with OpenGL ES 2+, ubershaders have >> generally been regarded as something to avoid. At the dawn of OpenGL ES 2 >> the concern was whether such shaders could be compiled and would fit in the >> available memory of the devices of those days. There was also concern about >> introducing lots of extra tests and branches for every vertex or fragment. >> The first example of an ?ubershader? was a shader to mimic the OpenGL ES 1 >> fixed-function pipeline. This was abandoned in favor of a set of smaller >> shaders, chosen and loaded according to the fixed-function state in use. As >> far as I know this was the model adopted by all IHV?s who provided OpenGL >> ES 1 support on their OpenGL ES 2 parts. >> >> To avoid doubt, let me state that I am not trying to downplay the >> importance of async shader compilation. >> >> Regards >> >> -Mark >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: shader-cache.zip Type: application/zip Size: 87853 bytes Desc: not available URL: From zmo...@ Wed Mar 1 20:04:03 2017 From: zmo...@ (Zhenyao Mo) Date: Wed, 1 Mar 2017 20:04:03 -0800 Subject: [Public WebGL] async shader compiliation In-Reply-To: References: <45108D48-4016-4B84-B4B9-B036D4E095B9@callow.im> <956D5C19-A9E6-432A-91FD-A980874A0AE9@callow.im> Message-ID: Thinking more on the implementation side, currently Chrome uses virtual contexts on many GPUs in Android and also on Linux NVidia due to driver bugs (for example, flush order isn't guaranteed) and performance (MakeCurrent is very slow). This kills the possibility of implementing an efficient async shader compile. Of course if we can justify the need, then we can push driver vendors to fix the issues, but that's proven to be an uneasy task. I am not saying I don't support async shader compile, just want to point out some unpleasant reality. ----------------------------------------------------------- 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...@ Wed Mar 1 23:27:48 2017 From: kbr...@ (Kenneth Russell) Date: Wed, 1 Mar 2017 23:27:48 -0800 Subject: [Public WebGL] async shader compiliation In-Reply-To: References: <45108D48-4016-4B84-B4B9-B036D4E095B9@callow.im> <956D5C19-A9E6-432A-91FD-A980874A0AE9@callow.im> Message-ID: Hi Max, Thank you for the test case; it's great. I filed http://crbug.com/697758 about profiling and optimizing the shader translator. We'll need to figure out how fast things can possibly go on the various platforms, but I'm pretty sure there are improvements to be made. Very coincidentally, today Kai from our team met an engineer who'd achieved a massive speedup on a shader compiler in an earlier project, and we're looking forward to working with them on this one. :) -Ken On Wed, Mar 1, 2017 at 8:41 AM, Maksims Mihejevs wrote: > Max, would you be able to make a self-contained test case which just >> compiles all of the shaders from After the Flood back-to-back, measuring >> the time between starting compiling the first one and linking the last one? > > > Hi Kenneth. > > I've made isolated example with shader compilation. > > http://moka.co/shader-compilation/ - online version. Find archive in > attachment to run it on local machine. > Please run this and post some results. > This example uses shaders from After the Flood WebGL 2.0 demo > https://playcanv.as/p/44MRmJRU/ which is what real-world next-gen apps > usually look like. > I will remind that we've been optimizing this app a lot before release, > and made shaders compilation times twice faster by reducing a lot of > unnecessary shader code. > > App is very simple - it gets some info about device, then gets WebGL 2.0 > context, loads raw text file with many shaders. Then it compiles each > shader, makes program, links it, and gets some attributes and uniforms. > It prevents any caching to take in place as well (either driver or > browser), as noticed that was happening and made testing harder. It does it > by adding random float constant to each shader. > Box at the bottom - is animated by CSS, and turns orange just before > compilation start. For the time it is orange/frozen page is unresponsive. > In most cases many things turn unresponsive, for example when tabs share JS > thread. Or any other webgl content in browser. > > Tested this on few platforms, so here are some results: > > > Windows; GTX 880M; ANGLE (DX11); i7-4810MQ; Chrome 58; ~*5,300 ms* > Windows; GTX 1070; ANGLE (DX11); i7-6820HK; Chrome 56; ~*7,200 ms* > Windows; GTX 980; ANGLE (DX11); i7-4790; Chrome 56; ~*6,300 ms* > Windows; GTX 980 Ti; ANGLE (DX11); i7 3770k; Chrome 56; ~*5,100 ms* > Windows; GTX 970; ANGLE (DX11); i7-3770; Firefox 52; ~*7,600 ms* > Windows; GTX 970; ANGLE (DX11); i7-3770; Chrome 58; ~*5,500 ms* > Windows; GTX 970; (GL); i7-3770; Chrome 58; ~*3,200 ms* > Windows; Intel HD 4000; ANGLE (DX11); Chrome 56; ~*11,000 ms* > Linux; GTX 970; i7-6700; Chrome 56; ~*1,900 ms* > Linux; GTX 670; i7-6700; Firefox 51; ~*2,100 ms* > Linux; GTX 980 Ti; i5 4690k; Chrome 56; ~*2,200 ms* > Mac Book 13" late 2013; Inter Iris; i7; ~*900 ms* > iMac 27" late 2012; GTX 660M; i5; Chrome 56; ~*900 ms* > iMac 27" late 2012; GTX 660M; i5; Firefox 51; ~*930 ms* > Android; One Plus Two; Adreno 430; Firefox 52; ~*9,600 ms* > Android; One Plus Two; Adreno 430; Chrome 58; ~*11,600 ms* > Android; One Plus Three; Adreno 530; Chrome 56; ~*7,500 ms* > > > What is interesting, that on Android, compilation takes a bit longer than > linking. When on Desktop Linux and Windows compilation is 3-10 times faster > than linking. Although old Mac Book and iMac linking is way faster than > compilation, although their fill-rate capabilities are poor. Is Apple doing > GLSL compilation better? > *I mean: GTX 1070 with i7-6820HK CPU, compiling as slow as Android OP3.. > Really?* > > You can clearly see from tests that linking/compilation times are jumping > all around very inconsistently. > ANGLE path is clearly loosing dramatically against GL path. > > *Do remember this is not most complex WebGL app and this bold times - is > for how long whole thing freezes page and in some cases whole device.* > > Looking forward to hear back from you guys. > > Kind Regards, > Max > > On 1 March 2017 at 10:58, Maksims Mihejevs wrote: > >> This was abandoned in favor of a set of smaller shaders, chosen and >>> loaded according to the fixed-function state in use. >> >> >> This is pretty much what we do, and many other nowadays uber shader >> systems do: they make shader code based on provided arguments. >> For example if only diffuseMap is used, then shader will be very simple. >> If diffuseMap + PBR used, it will get a bit more complicated, and so on. >> Some of things are driven by uniforms where possible, for example intensity >> for colour or opacity. But some will lead to shader re-generation, like >> availability of certain texture on material. So shaders include *only* >> what is used by material and specific mesh being rendered with that >> material. >> >> Ubershader - is pretty much the only way to go decent with Forward >> Renderer. >> >> We do need async shader compilation, but more we need is faster shader >> compilation in first place. >> >> Cheers, >> Max >> >> On 1 March 2017 at 10:04, Mark Callow wrote: >> >>> >>> On Feb 28, 2017, at 1:21, Maksims Mihejevs wrote: >>> >>> (if they are ubershaders) >>> >>> >>> Throughout the time I?ve been working with OpenGL ES 2+, ubershaders >>> have generally been regarded as something to avoid. At the dawn of OpenGL >>> ES 2 the concern was whether such shaders could be compiled and would fit >>> in the available memory of the devices of those days. There was also >>> concern about introducing lots of extra tests and branches for every vertex >>> or fragment. The first example of an ?ubershader? was a shader to mimic the >>> OpenGL ES 1 fixed-function pipeline. This was abandoned in favor of a set >>> of smaller shaders, chosen and loaded according to the fixed-function state >>> in use. As far as I know this was the model adopted by all IHV?s who >>> provided OpenGL ES 1 support on their OpenGL ES 2 parts. >>> >>> To avoid doubt, let me state that I am not trying to downplay the >>> importance of async shader compilation. >>> >>> Regards >>> >>> -Mark >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Wed Mar 1 23:30:06 2017 From: kbr...@ (Kenneth Russell) Date: Wed, 1 Mar 2017 23:30:06 -0800 Subject: [Public WebGL] async shader compiliation In-Reply-To: References: <45108D48-4016-4B84-B4B9-B036D4E095B9@callow.im> <956D5C19-A9E6-432A-91FD-A980874A0AE9@callow.im> Message-ID: Good points Mo. I do wonder though whether even on these platforms we could still spawn a background thread in Chrome's GPU process dedicated to shader compilation and program linking. Resource sharing still works even on these badly behaved platforms, and the background thread would have its own dedicated OpenGL context, sharing the compile and link results with the main thread. -Ken On Wed, Mar 1, 2017 at 8:04 PM, Zhenyao Mo wrote: > > Thinking more on the implementation side, currently Chrome uses > virtual contexts on many GPUs in Android and also on Linux NVidia due > to driver bugs (for example, flush order isn't guaranteed) and > performance (MakeCurrent is very slow). This kills the possibility of > implementing an efficient async shader compile. > > Of course if we can justify the need, then we can push driver vendors > to fix the issues, but that's proven to be an uneasy task. > > I am not saying I don't support async shader compile, just want to > point out some unpleasant reality. > > ----------------------------------------------------------- > 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 khr...@ Thu Mar 2 00:02:46 2017 From: khr...@ (Mark Callow) Date: Thu, 2 Mar 2017 17:02:46 +0900 Subject: [Public WebGL] async shader compiliation In-Reply-To: References: <45108D48-4016-4B84-B4B9-B036D4E095B9@callow.im> <956D5C19-A9E6-432A-91FD-A980874A0AE9@callow.im> Message-ID: <46F963AA-92C0-4292-B8BE-19BBC0EC4F83@callow.im> > On Mar 2, 2017, at 1:41, Maksims Mihejevs wrote: > > What is interesting, that on Android, compilation takes a bit longer than linking. When on Desktop Linux and Windows compilation is 3-10 times faster than linking. Although old Mac Book and iMac linking is way faster than compilation, although their fill-rate capabilities are poor. Is Apple doing GLSL compilation better? It is difficult to compare. I know of at least 1 OpenGL ES 2.0 implementation where ?compilation? consists of making a copy of the shader source. Everything else is done at link time. I have no idea if the same is true of the vendor?s OpenGL ES 3 implementation. (The vendor is not one of the ones you tested.) I think the only way to make a valid comparison between implementations is to compare the sum of compile and link times. 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 pya...@ Thu Mar 2 02:13:18 2017 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Thu, 2 Mar 2017 11:13:18 +0100 Subject: [Public WebGL] async shader compiliation In-Reply-To: <46F963AA-92C0-4292-B8BE-19BBC0EC4F83@callow.im> References: <45108D48-4016-4B84-B4B9-B036D4E095B9@callow.im> <956D5C19-A9E6-432A-91FD-A980874A0AE9@callow.im> <46F963AA-92C0-4292-B8BE-19BBC0EC4F83@callow.im> Message-ID: On Wed, Mar 1, 2017 at 11:04 AM, Mark Callow wrote: > Throughout the time I?ve been working with OpenGL ES 2+, ubershaders have > generally been regarded as something to avoid. > The problem is in no way specific to ubershaders. On Wed, Mar 1, 2017 at 11:58 AM, Maksims Mihejevs wrote: > > We do need async shader compilation, but more we need is faster shader > compilation in first place. > Faster would be nice, but for technical reasons cannot be achieved quickly or comprehensively. Async can be achieved to some degree and work comprehensibly within expectations, without too much difficulty. That's why we need Async more, because it's a solvable problem. On Thu, Mar 2, 2017 at 5:04 AM, Zhenyao Mo wrote: > Thinking more on the implementation side, currently Chrome uses > virtual contexts on many GPUs in Android and also on Linux NVidia due > to driver bugs (for example, flush order isn't guaranteed) and > performance (MakeCurrent is very slow). This kills the possibility of > implementing an efficient async shader compile. > > Of course if we can justify the need, then we can push driver vendors > to fix the issues, but that's proven to be an uneasy task. > > I am not saying I don't support async shader compile, just want to > point out some unpleasant reality. The efficiency of shader compilation, and the asynchronicity of it are two seperate mostly unrelated things. One is solvable to some degree (asynchronicity) comprehensibly, and the other is difficult/impossible to solve (speed). Let's focus on the one we can solve, not on objections or "realities" to the problem we can't, as a justification to not solve the problem we can solve. On Thu, Mar 2, 2017 at 8:30 AM, Kenneth Russell wrote: > Good points Mo. I do wonder though whether even on these platforms we > could still spawn a background thread in Chrome's GPU process dedicated to > shader compilation and program linking. Resource sharing still works even > on these badly behaved platforms, and the background thread would have its > own dedicated OpenGL context, sharing the compile and link results with the > main thread. > Many platforms only do any actual work at the linking stage. Separate contexts aren't going to get you out of the clinch to implement fence/wait on a CPU bound process that should not block the tab compositor and JS-thread. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Thu Mar 2 02:28:11 2017 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Thu, 2 Mar 2017 11:28:11 +0100 Subject: [Public WebGL] async shader compiliation In-Reply-To: References: <45108D48-4016-4B84-B4B9-B036D4E095B9@callow.im> <956D5C19-A9E6-432A-91FD-A980874A0AE9@callow.im> <46F963AA-92C0-4292-B8BE-19BBC0EC4F83@callow.im> Message-ID: P.S. The speed mess we're in is because both Khronos and Microsoft did it wrong. Khronos a good idea (a machine independent standard format) but took a wrong turn because supplying source text to be compiled by drivers is predestined to run into compilation speed problems. Microsoft had a good idea (machine independent bytecode) but took a wrong turn at the implementation (making it an unspecified proprietary format rather than an open standard to build toolchains atop). Both took a wrong turn by not focusing enough on modularity of GPU programs. In an ideal world these mistakes would not have happened decades ago, and the entire driver/API ecosystem would not be built upon these mistakes. We do not live in that world. And now these mistakes are nigh impossible to correct. Which is sad, and unnecessary, but it is what it is. None of that precludes solving UX issues we do have with asynchronicity. On Thu, Mar 2, 2017 at 11:13 AM, Florian B?sch wrote: > On Wed, Mar 1, 2017 at 11:04 AM, Mark Callow wrote: > >> Throughout the time I?ve been working with OpenGL ES 2+, ubershaders have >> generally been regarded as something to avoid. >> > The problem is in no way specific to ubershaders. > > On Wed, Mar 1, 2017 at 11:58 AM, Maksims Mihejevs > wrote: >> >> We do need async shader compilation, but more we need is faster shader >> compilation in first place. >> > Faster would be nice, but for technical reasons cannot be achieved quickly > or comprehensively. Async can be achieved to some degree and work > comprehensibly within expectations, without too much difficulty. That's why > we need Async more, because it's a solvable problem. > > On Thu, Mar 2, 2017 at 5:04 AM, Zhenyao Mo wrote: > >> Thinking more on the implementation side, currently Chrome uses >> virtual contexts on many GPUs in Android and also on Linux NVidia due >> to driver bugs (for example, flush order isn't guaranteed) and >> performance (MakeCurrent is very slow). This kills the possibility of >> implementing an efficient async shader compile. >> >> Of course if we can justify the need, then we can push driver vendors >> to fix the issues, but that's proven to be an uneasy task. >> >> I am not saying I don't support async shader compile, just want to >> point out some unpleasant reality. > > The efficiency of shader compilation, and the asynchronicity of it are two > seperate mostly unrelated things. One is solvable to some degree > (asynchronicity) comprehensibly, and the other is difficult/impossible to > solve (speed). Let's focus on the one we can solve, not on objections or > "realities" to the problem we can't, as a justification to not solve the > problem we can solve. > > On Thu, Mar 2, 2017 at 8:30 AM, Kenneth Russell wrote: > >> Good points Mo. I do wonder though whether even on these platforms we >> could still spawn a background thread in Chrome's GPU process dedicated to >> shader compilation and program linking. Resource sharing still works even >> on these badly behaved platforms, and the background thread would have its >> own dedicated OpenGL context, sharing the compile and link results with the >> main thread. >> > Many platforms only do any actual work at the linking stage. Separate > contexts aren't going to get you out of the clinch to implement fence/wait > on a CPU bound process that should not block the tab compositor and > JS-thread. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zmo...@ Thu Mar 2 09:44:55 2017 From: zmo...@ (Zhenyao Mo) Date: Thu, 2 Mar 2017 09:44:55 -0800 Subject: [Public WebGL] async shader compiliation In-Reply-To: References: <45108D48-4016-4B84-B4B9-B036D4E095B9@callow.im> <956D5C19-A9E6-432A-91FD-A980874A0AE9@callow.im> Message-ID: Good point, if resource sharing is working. On Wed, Mar 1, 2017 at 11:30 PM, Kenneth Russell wrote: > Good points Mo. I do wonder though whether even on these platforms we could > still spawn a background thread in Chrome's GPU process dedicated to shader > compilation and program linking. Resource sharing still works even on these > badly behaved platforms, and the background thread would have its own > dedicated OpenGL context, sharing the compile and link results with the main > thread. > > -Ken > > > On Wed, Mar 1, 2017 at 8:04 PM, Zhenyao Mo wrote: >> >> >> Thinking more on the implementation side, currently Chrome uses >> virtual contexts on many GPUs in Android and also on Linux NVidia due >> to driver bugs (for example, flush order isn't guaranteed) and >> performance (MakeCurrent is very slow). This kills the possibility of >> implementing an efficient async shader compile. >> >> Of course if we can justify the need, then we can push driver vendors >> to fix the issues, but that's proven to be an uneasy task. >> >> I am not saying I don't support async shader compile, just want to >> point out some unpleasant reality. >> >> ----------------------------------------------------------- >> 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 zmo...@ Thu Mar 2 09:46:42 2017 From: zmo...@ (Zhenyao Mo) Date: Thu, 2 Mar 2017 09:46:42 -0800 Subject: [Public WebGL] async shader compiliation In-Reply-To: References: <45108D48-4016-4B84-B4B9-B036D4E095B9@callow.im> <956D5C19-A9E6-432A-91FD-A980874A0AE9@callow.im> <46F963AA-92C0-4292-B8BE-19BBC0EC4F83@callow.im> Message-ID: On Thu, Mar 2, 2017 at 2:13 AM, Florian B?sch wrote: > On Wed, Mar 1, 2017 at 11:04 AM, Mark Callow wrote: >> >> Throughout the time I?ve been working with OpenGL ES 2+, ubershaders have >> generally been regarded as something to avoid. > > The problem is in no way specific to ubershaders. > > On Wed, Mar 1, 2017 at 11:58 AM, Maksims Mihejevs > wrote: >> >> We do need async shader compilation, but more we need is faster shader >> compilation in first place. > > Faster would be nice, but for technical reasons cannot be achieved quickly > or comprehensively. Async can be achieved to some degree and work > comprehensibly within expectations, without too much difficulty. That's why > we need Async more, because it's a solvable problem. > > On Thu, Mar 2, 2017 at 5:04 AM, Zhenyao Mo wrote: >> >> Thinking more on the implementation side, currently Chrome uses >> virtual contexts on many GPUs in Android and also on Linux NVidia due >> to driver bugs (for example, flush order isn't guaranteed) and >> performance (MakeCurrent is very slow). This kills the possibility of >> implementing an efficient async shader compile. >> >> Of course if we can justify the need, then we can push driver vendors >> to fix the issues, but that's proven to be an uneasy task. >> >> I am not saying I don't support async shader compile, just want to >> point out some unpleasant reality. > > The efficiency of shader compilation, and the asynchronicity of it are two > seperate mostly unrelated things. One is solvable to some degree > (asynchronicity) comprehensibly, and the other is difficult/impossible to > solve (speed). Let's focus on the one we can solve, not on objections or > "realities" to the problem we can't, as a justification to not solve the > problem we can solve. You miss the point. I am not talking about efficiency of shader compilation, but efficiency of context switching. But Ken's right, there is a way to make it work on bad drivers if resource sharing is still working on them. > > On Thu, Mar 2, 2017 at 8:30 AM, Kenneth Russell wrote: >> >> Good points Mo. I do wonder though whether even on these platforms we >> could still spawn a background thread in Chrome's GPU process dedicated to >> shader compilation and program linking. Resource sharing still works even on >> these badly behaved platforms, and the background thread would have its own >> dedicated OpenGL context, sharing the compile and link results with the main >> thread. > > Many platforms only do any actual work at the linking stage. Separate > contexts aren't going to get you out of the clinch to implement fence/wait > on a CPU bound process that should not block the tab compositor and > JS-thread. > ----------------------------------------------------------- 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...@ Tue Mar 7 10:07:00 2017 From: juj...@ (=?UTF-8?Q?Jukka_Jyl=C3=A4nki?=) Date: Tue, 7 Mar 2017 20:07:00 +0200 Subject: [Public WebGL] async shader compiliation In-Reply-To: References: <45108D48-4016-4B84-B4B9-B036D4E095B9@callow.im> <956D5C19-A9E6-432A-91FD-A980874A0AE9@callow.im> <46F963AA-92C0-4292-B8BE-19BBC0EC4F83@callow.im> Message-ID: Firefox 52 today releases WebAssembly support, and if you are on a browser that supports it, you can visit Epic's Unreal Engine 4 Zen Garden demo ported to WebAssembly and WebGL 2 at https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGarden.html That site precompiles all built shaders before launching and shows a visual progress meter while doing it. If you want to capture timing data from the run in a deterministically reproducible manner, visit https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGarden.html?playback&novsync&cpuprofiler which runs a timedemo style prerecorded rendering and shows result numbers at the end. 2017-03-02 19:46 GMT+02:00 Zhenyao Mo : > On Thu, Mar 2, 2017 at 2:13 AM, Florian B?sch wrote: > > On Wed, Mar 1, 2017 at 11:04 AM, Mark Callow wrote: > >> > >> Throughout the time I?ve been working with OpenGL ES 2+, ubershaders > have > >> generally been regarded as something to avoid. > > > > The problem is in no way specific to ubershaders. > > > > On Wed, Mar 1, 2017 at 11:58 AM, Maksims Mihejevs > > wrote: > >> > >> We do need async shader compilation, but more we need is faster shader > >> compilation in first place. > > > > Faster would be nice, but for technical reasons cannot be achieved > quickly > > or comprehensively. Async can be achieved to some degree and work > > comprehensibly within expectations, without too much difficulty. That's > why > > we need Async more, because it's a solvable problem. > > > > On Thu, Mar 2, 2017 at 5:04 AM, Zhenyao Mo wrote: > >> > >> Thinking more on the implementation side, currently Chrome uses > >> virtual contexts on many GPUs in Android and also on Linux NVidia due > >> to driver bugs (for example, flush order isn't guaranteed) and > >> performance (MakeCurrent is very slow). This kills the possibility of > >> implementing an efficient async shader compile. > >> > >> Of course if we can justify the need, then we can push driver vendors > >> to fix the issues, but that's proven to be an uneasy task. > >> > >> I am not saying I don't support async shader compile, just want to > >> point out some unpleasant reality. > > > > The efficiency of shader compilation, and the asynchronicity of it are > two > > seperate mostly unrelated things. One is solvable to some degree > > (asynchronicity) comprehensibly, and the other is difficult/impossible to > > solve (speed). Let's focus on the one we can solve, not on objections or > > "realities" to the problem we can't, as a justification to not solve the > > problem we can solve. > > You miss the point. I am not talking about efficiency of shader > compilation, but efficiency of context switching. > > But Ken's right, there is a way to make it work on bad drivers if > resource sharing is still working on them. > > > > > On Thu, Mar 2, 2017 at 8:30 AM, Kenneth Russell wrote: > >> > >> Good points Mo. I do wonder though whether even on these platforms we > >> could still spawn a background thread in Chrome's GPU process dedicated > to > >> shader compilation and program linking. Resource sharing still works > even on > >> these badly behaved platforms, and the background thread would have its > own > >> dedicated OpenGL context, sharing the compile and link results with the > main > >> thread. > > > > Many platforms only do any actual work at the linking stage. Separate > > contexts aren't going to get you out of the clinch to implement > fence/wait > > on a CPU bound process that should not block the tab compositor and > > JS-thread. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From max...@ Tue Mar 7 10:51:28 2017 From: max...@ (Maksims Mihejevs) Date: Tue, 7 Mar 2017 18:51:28 +0000 Subject: [Public WebGL] async shader compiliation In-Reply-To: References: <45108D48-4016-4B84-B4B9-B036D4E095B9@callow.im> <956D5C19-A9E6-432A-91FD-A980874A0AE9@callow.im> <46F963AA-92C0-4292-B8BE-19BBC0EC4F83@callow.im> Message-ID: Thanks for link Jukka. So as cold start, on Ubuntu in Chrome 58, it took ~15 seconds to compile shaders. After it shaders got cached, presumably by system, as even cache clear with incognito window on next runs gave smaller numbers ~2 seconds. Nice demo! But loading times are just not for web at all. WebAssembly compilation is still stalling a browser for about 15 seconds. And everything in the demo seems like speed up :) On warm starts it takes 30+ seconds to start. Seems like data.gz (86Mb) file is not getting cached, as well as wasm.gz (13.6Mb). It is good to see that this becomes more and more real now. Regarding shaders in this particular demo, is there anything complicated? Because graphics looks very mobile-like with pretty much little dynamic stuff (Any PBR?). Cheers, Max On 7 March 2017 at 18:07, Jukka Jyl?nki wrote: > Firefox 52 today releases WebAssembly support, and if you are on a browser > that supports it, you can visit Epic's Unreal Engine 4 Zen Garden demo > ported to WebAssembly and WebGL 2 at > > https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGarden.html > > That site precompiles all built shaders before launching and shows a > visual progress meter while doing it. If you want to capture timing data > from the run in a deterministically reproducible manner, visit > > https://s3.amazonaws.com/mozilla-games/ZenGarden/ > EpicZenGarden.html?playback&novsync&cpuprofiler > > which runs a timedemo style prerecorded rendering and shows result numbers > at the end. > > > 2017-03-02 19:46 GMT+02:00 Zhenyao Mo : > >> On Thu, Mar 2, 2017 at 2:13 AM, Florian B?sch wrote: >> > On Wed, Mar 1, 2017 at 11:04 AM, Mark Callow wrote: >> >> >> >> Throughout the time I?ve been working with OpenGL ES 2+, ubershaders >> have >> >> generally been regarded as something to avoid. >> > >> > The problem is in no way specific to ubershaders. >> > >> > On Wed, Mar 1, 2017 at 11:58 AM, Maksims Mihejevs >> > wrote: >> >> >> >> We do need async shader compilation, but more we need is faster shader >> >> compilation in first place. >> > >> > Faster would be nice, but for technical reasons cannot be achieved >> quickly >> > or comprehensively. Async can be achieved to some degree and work >> > comprehensibly within expectations, without too much difficulty. That's >> why >> > we need Async more, because it's a solvable problem. >> > >> > On Thu, Mar 2, 2017 at 5:04 AM, Zhenyao Mo wrote: >> >> >> >> Thinking more on the implementation side, currently Chrome uses >> >> virtual contexts on many GPUs in Android and also on Linux NVidia due >> >> to driver bugs (for example, flush order isn't guaranteed) and >> >> performance (MakeCurrent is very slow). This kills the possibility of >> >> implementing an efficient async shader compile. >> >> >> >> Of course if we can justify the need, then we can push driver vendors >> >> to fix the issues, but that's proven to be an uneasy task. >> >> >> >> I am not saying I don't support async shader compile, just want to >> >> point out some unpleasant reality. >> > >> > The efficiency of shader compilation, and the asynchronicity of it are >> two >> > seperate mostly unrelated things. One is solvable to some degree >> > (asynchronicity) comprehensibly, and the other is difficult/impossible >> to >> > solve (speed). Let's focus on the one we can solve, not on objections or >> > "realities" to the problem we can't, as a justification to not solve the >> > problem we can solve. >> >> You miss the point. I am not talking about efficiency of shader >> compilation, but efficiency of context switching. >> >> But Ken's right, there is a way to make it work on bad drivers if >> resource sharing is still working on them. >> >> > >> > On Thu, Mar 2, 2017 at 8:30 AM, Kenneth Russell wrote: >> >> >> >> Good points Mo. I do wonder though whether even on these platforms we >> >> could still spawn a background thread in Chrome's GPU process >> dedicated to >> >> shader compilation and program linking. Resource sharing still works >> even on >> >> these badly behaved platforms, and the background thread would have >> its own >> >> dedicated OpenGL context, sharing the compile and link results with >> the main >> >> thread. >> > >> > Many platforms only do any actual work at the linking stage. Separate >> > contexts aren't going to get you out of the clinch to implement >> fence/wait >> > on a CPU bound process that should not block the tab compositor and >> > JS-thread. >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue Mar 7 11:02:21 2017 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Tue, 7 Mar 2017 20:02:21 +0100 Subject: [Public WebGL] async shader compiliation In-Reply-To: References: <45108D48-4016-4B84-B4B9-B036D4E095B9@callow.im> <956D5C19-A9E6-432A-91FD-A980874A0AE9@callow.im> <46F963AA-92C0-4292-B8BE-19BBC0EC4F83@callow.im> Message-ID: On Tue, Mar 7, 2017 at 7:51 PM, Maksims Mihejevs wrote: > WebAssembly compilation is still stalling a browser for about 15 seconds. > Well they are compiling Unreal Engine (which is a bunch of C++ code) trough emscripten (which is known to produce copious amounts of output. I think a WebAssembly and Web optimized language will have far smaller bytecode, load faster and have faster development times than running a C++ compiler everytime you change a line. -------------- next part -------------- An HTML attachment was scrubbed... URL: From juj...@ Tue Mar 7 11:27:09 2017 From: juj...@ (=?UTF-8?Q?Jukka_Jyl=C3=A4nki?=) Date: Tue, 7 Mar 2017 21:27:09 +0200 Subject: [Public WebGL] async shader compiliation In-Reply-To: References: <45108D48-4016-4B84-B4B9-B036D4E095B9@callow.im> <956D5C19-A9E6-432A-91FD-A980874A0AE9@callow.im> <46F963AA-92C0-4292-B8BE-19BBC0EC4F83@callow.im> Message-ID: I currently have a bug on that demo build that it does not cache the wasm.gz file, the page only caches the compiled Wasm Module, which Chrome does not support. We'll have a version soon which first tries to cache the Module, and if that fails, it'll try to cache the original wasm.gz bytes instead. That should go live soon for when Chrome launches Wasm support (next week?) 2017-03-07 21:02 GMT+02:00 Florian B?sch : > On Tue, Mar 7, 2017 at 7:51 PM, Maksims Mihejevs > wrote: > >> WebAssembly compilation is still stalling a browser for about 15 seconds. >> > > Well they are compiling Unreal Engine (which is a bunch of C++ code) > trough emscripten (which is known to produce copious amounts of output. I > think a WebAssembly and Web optimized language will have far smaller > bytecode, load faster and have faster development times than running a C++ > compiler everytime you change a line. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From flo...@ Tue Mar 7 12:18:06 2017 From: flo...@ (Floh) Date: Tue, 7 Mar 2017 21:18:06 +0100 Subject: [Public WebGL] async shader compiliation In-Reply-To: References: <45108D48-4016-4B84-B4B9-B036D4E095B9@callow.im> <956D5C19-A9E6-432A-91FD-A980874A0AE9@callow.im> <46F963AA-92C0-4292-B8BE-19BBC0EC4F83@callow.im> Message-ID: That's not really the fault of the programming language, but of the engine design. UE4 (and similar 'traditional' game engines) are huge million-line codebases which haven't been designed for a small executable size. It is possible to create full 3D MMO clients at a fraction of the size (0.5..2 MBytes), the whole code base just needs to be designed from the ground up for a small size, unnecessary engine features must not be included in the build, and the compiler needs to be able to perform aggressive dead code elimination (e.g. minimal use of dynamic-dispatch/runtime-polymorphism). Those games won't look quite as fancy and won't have the latest realtime 3D-hair and GPU-accelerated physics, but they can start fast and stream their assets during gameplay. We did a proof-of-concept a few months ago where we built a simple 3D action-client/server game with a WebSocket backend written in Go, and 3 different clients, one in C++ via emscripten, one in Typescript with Babylon.js, and one in Unity exported to HTML5. The Typescript client was around 350 KBytes (most of this was the minified/compressed babylon.js blob), the C++ client was 410 KByte, and the Unity client was around 4.5 MByte, all sizes compressed. We didn't write an UE4 client (although it would be interesting how it compares to Unity, I'm pretty sure it would be quite a bit bigger). On Tue, Mar 7, 2017 at 8:02 PM, Florian B?sch wrote: > On Tue, Mar 7, 2017 at 7:51 PM, Maksims Mihejevs wrote: >> >> WebAssembly compilation is still stalling a browser for about 15 seconds. > > > Well they are compiling Unreal Engine (which is a bunch of C++ code) trough > emscripten (which is known to produce copious amounts of output. I think a > WebAssembly and Web optimized language will have far smaller bytecode, load > faster and have faster development times than running a C++ compiler > everytime you change a line. ----------------------------------------------------------- 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 pya...@ Tue Mar 7 12:24:24 2017 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Tue, 7 Mar 2017 21:24:24 +0100 Subject: [Public WebGL] async shader compiliation In-Reply-To: References: <45108D48-4016-4B84-B4B9-B036D4E095B9@callow.im> <956D5C19-A9E6-432A-91FD-A980874A0AE9@callow.im> <46F963AA-92C0-4292-B8BE-19BBC0EC4F83@callow.im> Message-ID: On Tue, Mar 7, 2017 at 9:18 PM, Floh wrote: > That's not really the fault of the programming language, but of the > engine design. UE4 (and similar 'traditional' game engines) are huge > million-line codebases which haven't been designed for a small > executable size. It is possible to create full 3D MMO clients at a > fraction of the size (0.5..2 MBytes), the whole code base just needs > to be designed from the ground up for a small size, unnecessary engine > features must not be included in the build, and the compiler needs to > be able to perform aggressive dead code elimination (e.g. minimal use > of dynamic-dispatch/runtime-polymorphism). > It's difficult to write maintainable idiosyncratic C++ that doesn't end up using all those code-producing features and hard to eliminate dead code paths. That's what I mean by better programming language. Plus emscripten itself being tasked with translating C++ to an alien bytecode format has to tack on quite a bit of overhead you only really need if you do C/C++ code generation, which is inherently built to output homungous code to a local filesystem geared towards x86/64. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue Mar 7 12:26:03 2017 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Tue, 7 Mar 2017 21:26:03 +0100 Subject: [Public WebGL] async shader compiliation In-Reply-To: References: <45108D48-4016-4B84-B4B9-B036D4E095B9@callow.im> <956D5C19-A9E6-432A-91FD-A980874A0AE9@callow.im> <46F963AA-92C0-4292-B8BE-19BBC0EC4F83@callow.im> Message-ID: P.S. I've built an optimizing brainfuck compiler that does not adhere to cdecls and conventional use of C++ registers/constructs and the output is quite a bit smaller than compiling brainfuck to C++ and compiling C++ to x86. On Tue, Mar 7, 2017 at 9:24 PM, Florian B?sch wrote: > On Tue, Mar 7, 2017 at 9:18 PM, Floh wrote: > >> That's not really the fault of the programming language, but of the >> engine design. UE4 (and similar 'traditional' game engines) are huge >> million-line codebases which haven't been designed for a small >> executable size. It is possible to create full 3D MMO clients at a >> fraction of the size (0.5..2 MBytes), the whole code base just needs >> to be designed from the ground up for a small size, unnecessary engine >> features must not be included in the build, and the compiler needs to >> be able to perform aggressive dead code elimination (e.g. minimal use >> of dynamic-dispatch/runtime-polymorphism). >> > It's difficult to write maintainable idiosyncratic C++ that doesn't end up > using all those code-producing features and hard to eliminate dead code > paths. That's what I mean by better programming language. Plus emscripten > itself being tasked with translating C++ to an alien bytecode format has to > tack on quite a bit of overhead you only really need if you do C/C++ code > generation, which is inherently built to output homungous code to a local > filesystem geared towards x86/64. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Thu Mar 16 10:57:54 2017 From: kbr...@ (Kenneth Russell) Date: Thu, 16 Mar 2017 10:57:54 -0700 Subject: [Public WebGL] WebGL Next WG created Message-ID: WebGL community, Khronos has created a WebGL Next working group -- separate from the current WebGL working group -- to take the next evolutionary step in the API: toward the low-level, explicit graphics APIs like Direct3D 12, Metal, and Vulkan. The "next" WebGL will break compatibility with current WebGL in order to deliver the dramatic performance improvements afforded by these lower-level APIs. If you are interested in participating in these discussions, please join the public_webgl_next mailing list: https://www.khronos.org/webgl/public-mailing-list/ The creation of Github repositories, and further announcements, will be posted to that mailing list. Looking forward to working with you all to design this new API! -Ken -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Thu Mar 16 11:49:03 2017 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Thu, 16 Mar 2017 19:49:03 +0100 Subject: [Public WebGL] WebGL Next WG created In-Reply-To: References: Message-ID: I'm a little confused now, what is the relationship between this group, and the w3c community group, WebNXT and WebGPU? On Thu, Mar 16, 2017 at 6:57 PM, Kenneth Russell wrote: > WebGL community, > > Khronos has created a WebGL Next working group -- separate from the > current WebGL working group -- to take the next evolutionary step in the > API: toward the low-level, explicit graphics APIs like Direct3D 12, Metal, > and Vulkan. The "next" WebGL will break compatibility with current WebGL in > order to deliver the dramatic performance improvements afforded by these > lower-level APIs. > > If you are interested in participating in these discussions, please join > the public_webgl_next mailing list: > > https://www.khronos.org/webgl/public-mailing-list/ > > The creation of Github repositories, and further announcements, will be > posted to that mailing list. > > Looking forward to working with you all to design this new API! > > -Ken > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Thu Mar 16 13:23:28 2017 From: kbr...@ (Kenneth Russell) Date: Thu, 16 Mar 2017 13:23:28 -0700 Subject: [Public WebGL] WebGL Next WG created In-Reply-To: References: Message-ID: "WebGL Next" is Khronos' forum for designing a next-generation graphics and compute API for the web. The W3C community group, and this forum, do have a great deal of overlap in their charters. It's likely that one or the other will end up being where this API is standardized. NXT is Google's contribution in this area, and it'll soon be made to Khronos' forum. Please sign up to public_webgl_next for future announcements. -Ken On Thu, Mar 16, 2017 at 11:49 AM, Florian B?sch wrote: > I'm a little confused now, what is the relationship between this group, > and the w3c community group, WebNXT and WebGPU? > > On Thu, Mar 16, 2017 at 6:57 PM, Kenneth Russell wrote: > >> WebGL community, >> >> Khronos has created a WebGL Next working group -- separate from the >> current WebGL working group -- to take the next evolutionary step in the >> API: toward the low-level, explicit graphics APIs like Direct3D 12, Metal, >> and Vulkan. The "next" WebGL will break compatibility with current WebGL in >> order to deliver the dramatic performance improvements afforded by these >> lower-level APIs. >> >> If you are interested in participating in these discussions, please join >> the public_webgl_next mailing list: >> >> https://www.khronos.org/webgl/public-mailing-list/ >> >> The creation of Github repositories, and further announcements, will be >> posted to that mailing list. >> >> Looking forward to working with you all to design this new API! >> >> -Ken >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From din...@ Fri Mar 17 15:04:32 2017 From: din...@ (Dean Jackson) Date: Sat, 18 Mar 2017 09:04:32 +1100 Subject: [Public WebGL] Use powerPreference to request high or low power GPUs Message-ID: <16021C25-8A73-4304-8619-5BCDCEF935B4@apple.com> Hello WebGL community, We recently added powerPreference to the WebGL 1.0 specification, which allows content developers to give a hint as to what type of GPU they require. https://www.khronos.org/registry/webgl/specs/latest/1.0/#5.2.1 This replaces the old preferLowPowerToHighPerformance which, even though WebKit implemented it, never shipped in a form that actually changed behaviour. Here's an example. If you're on a macOS system with two GPUs (e.g. a Macbook Pro), you'd request the more powerful and power hungry GPU using: let gl = canvas.getContext("webgl", { powerPreference: "high-performance" }); Note that, as the specification suggests, it doesn't guarantee you'll get the GPU, and you'll be at the front of the line if the system needs to reset some WebGL contexts in order to reclaim system resources. You MUST have a registered event handler for the webglcontextlost and webglcontextrestored events if you want the user agent to respect your request for high-performance. WebKit and Safari Technology Preview have implemented this attribute, so you can try them out now. Some details on the current WebKit implementation: - the default value for powerPreference is equivalent to "low-power" (i.e. we still prioritise power use). - even if you get the discrete GPU, you WILL swap to the integrated GPU if your tab is moved to the background, or the page is hidden. This shouldn't cause any issues, but please let me know if you think it is. - similarly, if you request "low-power" you might be swapped to the discrete GPU if another page or system app turns it on. Other browser engines are indicating they'll be implementing this soon too. The behaviour on other operating systems and hardware might be slightly different. Dean ----------------------------------------------------------- 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...@ Sat Mar 18 20:45:59 2017 From: khr...@ (Gregg Tavares) Date: Sun, 19 Mar 2017 12:45:59 +0900 Subject: [Public WebGL] Use powerPreference to request high or low power GPUs In-Reply-To: <16021C25-8A73-4304-8619-5BCDCEF935B4@apple.com> References: <16021C25-8A73-4304-8619-5BCDCEF935B4@apple.com> Message-ID: I think it's great such a feature exists. I'm a little sad no public discussion was had on the feature. Looking at the spec it's not as simple as let gl = canvas.getContext("webgl", { powerPreference: "high-performance" }); It's more like canvas.addEventListener('webglcontextlost`, function() {}); canvas.addEventListener('webglcontextrestored`, function() {}); let gl = canvas.getContext("webgl", { powerPreference: "high-performance" }); According the the spec, without the first 2 lines the setting is ignored. It's not clear why that part was important. Sure I get you might lose the context and get restored on a different GPU but that was already the case before this new setting (on windows with 2 GPUs just disable one and assuming the browser handles it you'd lose the context and get restored on the new one). so what's the need for the requiring the listeners for the hint to have any effect? It's also not clear from the spec what gets reported. For example the alpha, depth, stencil, and basically all of the other attributes are READable after creation to see what you actually got. For example you might request {stencil: true} then later you check if you actually got a stencil buffer const gl = canvas.getContext("webgl", { stencil: true }); const haveStencil = gl.getContextAttributes().stencil; It's not clear (at least to me) from the spec if I can do the same with `powerPerformance` canvas.addEventListener('webglcontextlost`, function() {}); canvas.addEventListener('webglcontextrestored`, function() {}); const gl = canvas.getContext("webgl", { powerPreference: "high-performance" }); const havePerf = gl.getContextAttributes().powerPreference === "high-performance"; if (!havePerf) { alert("Dear user, this site requires a gamer ready GPU. Sucks to be you"); } I suppose that doesn't make any sense on a typical 1 GPU machine but it is confusing that all the other attributes are readable and this one is different. On Sat, Mar 18, 2017 at 7:04 AM, Dean Jackson wrote: > > Hello WebGL community, > > We recently added powerPreference to the WebGL 1.0 specification, which > allows content developers to give a hint as to what type of GPU they > require. > > https://www.khronos.org/registry/webgl/specs/latest/1.0/#5.2.1 > > This replaces the old preferLowPowerToHighPerformance which, even though > WebKit implemented it, never shipped in a form that actually changed > behaviour. > > Here's an example. If you're on a macOS system with two GPUs (e.g. a > Macbook Pro), you'd request the more powerful and power hungry GPU using: > > let gl = canvas.getContext("webgl", { powerPreference: > "high-performance" }); > > Note that, as the specification suggests, it doesn't guarantee you'll get > the GPU, and you'll be at the front of the line if the system needs to > reset some WebGL contexts in order to reclaim system resources. You MUST > have a registered event handler for the webglcontextlost and > webglcontextrestored events if you want the user agent to respect your > request for high-performance. > > WebKit and Safari Technology Preview have implemented this attribute, so > you can try them out now. Some details on the current WebKit implementation: > > - the default value for powerPreference is equivalent to "low-power" (i.e. > we still prioritise power use). > - even if you get the discrete GPU, you WILL swap to the integrated GPU if > your tab is moved to the background, or the page is hidden. This shouldn't > cause any issues, but please let me know if you think it is. > - similarly, if you request "low-power" you might be swapped to the > discrete GPU if another page or system app turns it on. > > Other browser engines are indicating they'll be implementing this soon > too. The behaviour on other operating systems and hardware might be > slightly different. > > Dean > > > ----------------------------------------------------------- > 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 max...@ Sun Mar 19 03:54:38 2017 From: max...@ (Maksims Mihejevs) Date: Sun, 19 Mar 2017 10:54:38 +0000 Subject: [Public WebGL] Use powerPreference to request high or low power GPUs In-Reply-To: References: <16021C25-8A73-4304-8619-5BCDCEF935B4@apple.com> Message-ID: I assume on context restoration, engines that have features relying on certain extensions or webgl optional capabilities, should query them again to ensure behaviours of certain parts is updated. For example some engine could use deferred rendering if draw_buffer extension and number of MRT is more than few. Then on context loss and restore it might go to low-power (integrated) gpu. Things then will change, as it unlikely to handle deferred, and should change behaviour. I bet most engines will have troubles with handling capabilities changes during application running. And events handlers make it more clear that something like so might happen. Otherwise people will just create high power context, then it will recreate context, and things will go very wrong from there. So most existing engines will have to make an effort to ensure such scenario is handled well. This feature was long awaited, as we've noticed inconsistencies between what GPU is attached to what browser on Windows machines with Nvidia + Intel cases (extremely common). So this feature will allow a developer make a choice and potentially get much better performance from their WebGL content. And additionally can clearly see where use od low-power will be in demand too, e.g. product customisers where we don't want to burn users laptop battery all the way. I believe it is very important other vendors will implement this as well. Cheers, Max On 19 Mar 2017 3:46 a.m., "Gregg Tavares" wrote: I think it's great such a feature exists. I'm a little sad no public discussion was had on the feature. Looking at the spec it's not as simple as let gl = canvas.getContext("webgl", { powerPreference: "high-performance" }); It's more like canvas.addEventListener('webglcontextlost`, function() {}); canvas.addEventListener('webglcontextrestored`, function() {}); let gl = canvas.getContext("webgl", { powerPreference: "high-performance" }); According the the spec, without the first 2 lines the setting is ignored. It's not clear why that part was important. Sure I get you might lose the context and get restored on a different GPU but that was already the case before this new setting (on windows with 2 GPUs just disable one and assuming the browser handles it you'd lose the context and get restored on the new one). so what's the need for the requiring the listeners for the hint to have any effect? It's also not clear from the spec what gets reported. For example the alpha, depth, stencil, and basically all of the other attributes are READable after creation to see what you actually got. For example you might request {stencil: true} then later you check if you actually got a stencil buffer const gl = canvas.getContext("webgl", { stencil: true }); const haveStencil = gl.getContextAttributes().stencil; It's not clear (at least to me) from the spec if I can do the same with `powerPerformance` canvas.addEventListener('webglcontextlost`, function() {}); canvas.addEventListener('webglcontextrestored`, function() {}); const gl = canvas.getContext("webgl", { powerPreference: "high-performance" }); const havePerf = gl.getContextAttributes().powerPreference === "high-performance"; if (!havePerf) { alert("Dear user, this site requires a gamer ready GPU. Sucks to be you"); } I suppose that doesn't make any sense on a typical 1 GPU machine but it is confusing that all the other attributes are readable and this one is different. On Sat, Mar 18, 2017 at 7:04 AM, Dean Jackson wrote: > > Hello WebGL community, > > We recently added powerPreference to the WebGL 1.0 specification, which > allows content developers to give a hint as to what type of GPU they > require. > > https://www.khronos.org/registry/webgl/specs/latest/1.0/#5.2.1 > > This replaces the old preferLowPowerToHighPerformance which, even though > WebKit implemented it, never shipped in a form that actually changed > behaviour. > > Here's an example. If you're on a macOS system with two GPUs (e.g. a > Macbook Pro), you'd request the more powerful and power hungry GPU using: > > let gl = canvas.getContext("webgl", { powerPreference: > "high-performance" }); > > Note that, as the specification suggests, it doesn't guarantee you'll get > the GPU, and you'll be at the front of the line if the system needs to > reset some WebGL contexts in order to reclaim system resources. You MUST > have a registered event handler for the webglcontextlost and > webglcontextrestored events if you want the user agent to respect your > request for high-performance. > > WebKit and Safari Technology Preview have implemented this attribute, so > you can try them out now. Some details on the current WebKit implementation: > > - the default value for powerPreference is equivalent to "low-power" (i.e. > we still prioritise power use). > - even if you get the discrete GPU, you WILL swap to the integrated GPU if > your tab is moved to the background, or the page is hidden. This shouldn't > cause any issues, but please let me know if you think it is. > - similarly, if you request "low-power" you might be swapped to the > discrete GPU if another page or system app turns it on. > > Other browser engines are indicating they'll be implementing this soon > too. The behaviour on other operating systems and hardware might be > slightly different. > > Dean > > > ----------------------------------------------------------- > 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...@ Sun Mar 19 14:05:36 2017 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 19 Mar 2017 22:05:36 +0100 Subject: [Public WebGL] meaning of the specification of FBO sampling and interpretation by UAs Message-ID: The ES specification states that the result of sampling from a texture attached to a framebuffer at the same time as sampling to that framebuffer is undefined. Google chrome seems to interprete this as: If a texture is bound to any texturing unit while that framebuffer is used it's an error. However a different interpretation of this would be: If a texture that is bound is *actually sampled* during the framebuffer operation it's an error. Which of these interpretations is the correct one? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sun Mar 19 14:07:06 2017 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 19 Mar 2017 22:07:06 +0100 Subject: [Public WebGL] Re: meaning of the specification of FBO sampling and interpretation by UAs In-Reply-To: References: Message-ID: I might add, OpenGL adopts the latter more lenient interptation (at least with nvidia drivers), and that works fine on Chrome on these systems, but on Windows Chrome/ANGLE use a more strict interpretation. On Sun, Mar 19, 2017 at 10:05 PM, Florian B?sch wrote: > The ES specification states that the result of sampling from a texture > attached to a framebuffer at the same time as sampling to that framebuffer > is undefined. > > Google chrome seems to interprete this as: If a texture is bound to any > texturing unit while that framebuffer is used it's an error. > > However a different interpretation of this would be: If a texture that is > bound is *actually sampled* during the framebuffer operation it's an > error. > > Which of these interpretations is the correct one? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zmo...@ Mon Mar 20 09:45:14 2017 From: zmo...@ (Zhenyao Mo) Date: Mon, 20 Mar 2017 09:45:14 -0700 Subject: [Public WebGL] meaning of the specification of FBO sampling and interpretation by UAs In-Reply-To: References: Message-ID: Definitely the latter. If a texture is not sampled, there is no reason to generate an error. Since ANGLE shader translator provides enough information what textures are actually sampled (or at least a close estimation, if a sampler is defined and statically accessed), we can have a more refined behavior. This seems to be a behavior difference between Chrome's GPU command buffer and ANGLE, and we should fix the ANGLE behavior. On Sun, Mar 19, 2017 at 2:05 PM, Florian B?sch wrote: > The ES specification states that the result of sampling from a texture > attached to a framebuffer at the same time as sampling to that framebuffer > is undefined. > > Google chrome seems to interprete this as: If a texture is bound to any > texturing unit while that framebuffer is used it's an error. > > However a different interpretation of this would be: If a texture that is > bound is actually sampled during the framebuffer operation it's an error. > > Which of these interpretations is the correct one? ----------------------------------------------------------- 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 zmo...@ Mon Mar 20 09:46:24 2017 From: zmo...@ (Zhenyao Mo) Date: Mon, 20 Mar 2017 09:46:24 -0700 Subject: [Public WebGL] Re: meaning of the specification of FBO sampling and interpretation by UAs In-Reply-To: References: Message-ID: To clarify, drivers never generate errors in such situation. It's simply an undefined behavior. The error you see is not from NVidia drivers, but from Chrome's GPU command buffer. On Sun, Mar 19, 2017 at 2:07 PM, Florian B?sch wrote: > I might add, OpenGL adopts the latter more lenient interptation (at least > with nvidia drivers), and that works fine on Chrome on these systems, but > on Windows Chrome/ANGLE use a more strict interpretation. > > On Sun, Mar 19, 2017 at 10:05 PM, Florian B?sch wrote: >> >> The ES specification states that the result of sampling from a texture >> attached to a framebuffer at the same time as sampling to that framebuffer >> is undefined. >> >> Google chrome seems to interprete this as: If a texture is bound to any >> texturing unit while that framebuffer is used it's an error. >> >> However a different interpretation of this would be: If a texture that is >> bound is actually sampled during the framebuffer operation it's an error. >> >> Which of these interpretations is the correct one? > > ----------------------------------------------------------- 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 pya...@ Mon Mar 20 09:48:56 2017 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Mon, 20 Mar 2017 17:48:56 +0100 Subject: [Public WebGL] Re: meaning of the specification of FBO sampling and interpretation by UAs In-Reply-To: References: Message-ID: I'm not 100% sure it's the case, the error I looked at was somewhat complex. Do we have unit-test for it? On Mon, Mar 20, 2017 at 5:46 PM, Zhenyao Mo wrote: > To clarify, drivers never generate errors in such situation. It's > simply an undefined behavior. The error you see is not from NVidia > drivers, but from Chrome's GPU command buffer. > > On Sun, Mar 19, 2017 at 2:07 PM, Florian B?sch wrote: > > I might add, OpenGL adopts the latter more lenient interptation (at least > > with nvidia drivers), and that works fine on Chrome on these systems, > but > > on Windows Chrome/ANGLE use a more strict interpretation. > > > > On Sun, Mar 19, 2017 at 10:05 PM, Florian B?sch > wrote: > >> > >> The ES specification states that the result of sampling from a texture > >> attached to a framebuffer at the same time as sampling to that > framebuffer > >> is undefined. > >> > >> Google chrome seems to interprete this as: If a texture is bound to any > >> texturing unit while that framebuffer is used it's an error. > >> > >> However a different interpretation of this would be: If a texture that > is > >> bound is actually sampled during the framebuffer operation it's an > error. > >> > >> Which of these interpretations is the correct one? > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zmo...@ Mon Mar 20 10:14:59 2017 From: zmo...@ (Zhenyao Mo) Date: Mon, 20 Mar 2017 10:14:59 -0700 Subject: [Public WebGL] Re: meaning of the specification of FBO sampling and interpretation by UAs In-Reply-To: References: Message-ID: We have WebGL conformance tests for feedback loop detection, but we don't have a positive test that a texture is bound but not sampled, that it is not feedback loop and no error should be generated. The ES spec doesn't generate GL errors on feedback loops. It's simply stating the results are undefined. On Mon, Mar 20, 2017 at 9:48 AM, Florian B?sch wrote: > I'm not 100% sure it's the case, the error I looked at was somewhat complex. > Do we have unit-test for it? > > On Mon, Mar 20, 2017 at 5:46 PM, Zhenyao Mo wrote: >> >> To clarify, drivers never generate errors in such situation. It's >> simply an undefined behavior. The error you see is not from NVidia >> drivers, but from Chrome's GPU command buffer. >> >> On Sun, Mar 19, 2017 at 2:07 PM, Florian B?sch wrote: >> > I might add, OpenGL adopts the latter more lenient interptation (at >> > least >> > with nvidia drivers), and that works fine on Chrome on these systems, >> > but >> > on Windows Chrome/ANGLE use a more strict interpretation. >> > >> > On Sun, Mar 19, 2017 at 10:05 PM, Florian B?sch >> > wrote: >> >> >> >> The ES specification states that the result of sampling from a texture >> >> attached to a framebuffer at the same time as sampling to that >> >> framebuffer >> >> is undefined. >> >> >> >> Google chrome seems to interprete this as: If a texture is bound to any >> >> texturing unit while that framebuffer is used it's an error. >> >> >> >> However a different interpretation of this would be: If a texture that >> >> is >> >> bound is actually sampled during the framebuffer operation it's an >> >> error. >> >> >> >> Which of these interpretations is the correct one? >> > >> > > > ----------------------------------------------------------- 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...@ Mon Mar 20 11:25:01 2017 From: kbr...@ (Kenneth Russell) Date: Mon, 20 Mar 2017 11:25:01 -0700 Subject: [Public WebGL] Re: meaning of the specification of FBO sampling and interpretation by UAs In-Reply-To: References: Message-ID: It's not feasible to detect during a given draw call that the bound program sampled a texture which actually ended up causing a rendering feedback loop. For this reason Chrome's detection of feedback loops iterates over all of the samplers of the currently bound program, and looks at the texture objects bound to those texture units. If any of those textures are bound to the current framebuffer object, it generates an error. This is a conservative check, but covers all of the undefined cases on mobile hardware. When this check was instituted some time ago, content which was updated to render correctly with it started working on mobile devices where it had previously failed. -Ken On Mon, Mar 20, 2017 at 10:14 AM, Zhenyao Mo wrote: > > We have WebGL conformance tests for feedback loop detection, but we > don't have a positive test that a texture is bound but not sampled, > that it is not feedback loop and no error should be generated. > > The ES spec doesn't generate GL errors on feedback loops. It's simply > stating the results are undefined. > > On Mon, Mar 20, 2017 at 9:48 AM, Florian B?sch wrote: > > I'm not 100% sure it's the case, the error I looked at was somewhat > complex. > > Do we have unit-test for it? > > > > On Mon, Mar 20, 2017 at 5:46 PM, Zhenyao Mo wrote: > >> > >> To clarify, drivers never generate errors in such situation. It's > >> simply an undefined behavior. The error you see is not from NVidia > >> drivers, but from Chrome's GPU command buffer. > >> > >> On Sun, Mar 19, 2017 at 2:07 PM, Florian B?sch > wrote: > >> > I might add, OpenGL adopts the latter more lenient interptation (at > >> > least > >> > with nvidia drivers), and that works fine on Chrome on these systems, > >> > but > >> > on Windows Chrome/ANGLE use a more strict interpretation. > >> > > >> > On Sun, Mar 19, 2017 at 10:05 PM, Florian B?sch > >> > wrote: > >> >> > >> >> The ES specification states that the result of sampling from a > texture > >> >> attached to a framebuffer at the same time as sampling to that > >> >> framebuffer > >> >> is undefined. > >> >> > >> >> Google chrome seems to interprete this as: If a texture is bound to > any > >> >> texturing unit while that framebuffer is used it's an error. > >> >> > >> >> However a different interpretation of this would be: If a texture > that > >> >> is > >> >> bound is actually sampled during the framebuffer operation it's an > >> >> error. > >> >> > >> >> Which of these interpretations is the correct one? > >> > > >> > > > > > > > ----------------------------------------------------------- > 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 Mar 20 14:47:57 2017 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Mon, 20 Mar 2017 22:47:57 +0100 Subject: [Public WebGL] Re: meaning of the specification of FBO sampling and interpretation by UAs In-Reply-To: References: Message-ID: I believe the behavior should be specified and implemented on all platforms the same, indifferently from the backend or UA. Agreed? On Mon, Mar 20, 2017 at 7:25 PM, Kenneth Russell wrote: > It's not feasible to detect during a given draw call that the bound > program sampled a texture which actually ended up causing a rendering > feedback loop. For this reason Chrome's detection of feedback loops > iterates over all of the samplers of the currently bound program, and looks > at the texture objects bound to those texture units. If any of those > textures are bound to the current framebuffer object, it generates an error. > > This is a conservative check, but covers all of the undefined cases on > mobile hardware. When this check was instituted some time ago, content > which was updated to render correctly with it started working on mobile > devices where it had previously failed. > > -Ken > > > > On Mon, Mar 20, 2017 at 10:14 AM, Zhenyao Mo wrote: > >> >> We have WebGL conformance tests for feedback loop detection, but we >> don't have a positive test that a texture is bound but not sampled, >> that it is not feedback loop and no error should be generated. >> >> The ES spec doesn't generate GL errors on feedback loops. It's simply >> stating the results are undefined. >> >> On Mon, Mar 20, 2017 at 9:48 AM, Florian B?sch wrote: >> > I'm not 100% sure it's the case, the error I looked at was somewhat >> complex. >> > Do we have unit-test for it? >> > >> > On Mon, Mar 20, 2017 at 5:46 PM, Zhenyao Mo wrote: >> >> >> >> To clarify, drivers never generate errors in such situation. It's >> >> simply an undefined behavior. The error you see is not from NVidia >> >> drivers, but from Chrome's GPU command buffer. >> >> >> >> On Sun, Mar 19, 2017 at 2:07 PM, Florian B?sch >> wrote: >> >> > I might add, OpenGL adopts the latter more lenient interptation (at >> >> > least >> >> > with nvidia drivers), and that works fine on Chrome on these >> systems, >> >> > but >> >> > on Windows Chrome/ANGLE use a more strict interpretation. >> >> > >> >> > On Sun, Mar 19, 2017 at 10:05 PM, Florian B?sch >> >> > wrote: >> >> >> >> >> >> The ES specification states that the result of sampling from a >> texture >> >> >> attached to a framebuffer at the same time as sampling to that >> >> >> framebuffer >> >> >> is undefined. >> >> >> >> >> >> Google chrome seems to interprete this as: If a texture is bound to >> any >> >> >> texturing unit while that framebuffer is used it's an error. >> >> >> >> >> >> However a different interpretation of this would be: If a texture >> that >> >> >> is >> >> >> bound is actually sampled during the framebuffer operation it's an >> >> >> error. >> >> >> >> >> >> Which of these interpretations is the correct one? >> >> > >> >> > >> > >> > >> >> ----------------------------------------------------------- >> 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 zmo...@ Mon Mar 20 15:04:31 2017 From: zmo...@ (Zhenyao Mo) Date: Mon, 20 Mar 2017 15:04:31 -0700 Subject: [Public WebGL] Re: meaning of the specification of FBO sampling and interpretation by UAs In-Reply-To: References: Message-ID: That is the goal. We have conformance tests for that. The behavior difference between Windows (ANGLE) and the rest (GPU command buffer) indicates the testing isn't sufficient and we should definitely improve it. On Mon, Mar 20, 2017 at 2:47 PM, Florian B?sch wrote: > I believe the behavior should be specified and implemented on all platforms > the same, indifferently from the backend or UA. Agreed? > > On Mon, Mar 20, 2017 at 7:25 PM, Kenneth Russell wrote: >> >> It's not feasible to detect during a given draw call that the bound >> program sampled a texture which actually ended up causing a rendering >> feedback loop. For this reason Chrome's detection of feedback loops iterates >> over all of the samplers of the currently bound program, and looks at the >> texture objects bound to those texture units. If any of those textures are >> bound to the current framebuffer object, it generates an error. >> >> This is a conservative check, but covers all of the undefined cases on >> mobile hardware. When this check was instituted some time ago, content which >> was updated to render correctly with it started working on mobile devices >> where it had previously failed. >> >> -Ken >> >> >> >> On Mon, Mar 20, 2017 at 10:14 AM, Zhenyao Mo wrote: >>> >>> >>> We have WebGL conformance tests for feedback loop detection, but we >>> don't have a positive test that a texture is bound but not sampled, >>> that it is not feedback loop and no error should be generated. >>> >>> The ES spec doesn't generate GL errors on feedback loops. It's simply >>> stating the results are undefined. >>> >>> On Mon, Mar 20, 2017 at 9:48 AM, Florian B?sch wrote: >>> > I'm not 100% sure it's the case, the error I looked at was somewhat >>> > complex. >>> > Do we have unit-test for it? >>> > >>> > On Mon, Mar 20, 2017 at 5:46 PM, Zhenyao Mo wrote: >>> >> >>> >> To clarify, drivers never generate errors in such situation. It's >>> >> simply an undefined behavior. The error you see is not from NVidia >>> >> drivers, but from Chrome's GPU command buffer. >>> >> >>> >> On Sun, Mar 19, 2017 at 2:07 PM, Florian B?sch >>> >> wrote: >>> >> > I might add, OpenGL adopts the latter more lenient interptation (at >>> >> > least >>> >> > with nvidia drivers), and that works fine on Chrome on these >>> >> > systems, >>> >> > but >>> >> > on Windows Chrome/ANGLE use a more strict interpretation. >>> >> > >>> >> > On Sun, Mar 19, 2017 at 10:05 PM, Florian B?sch >>> >> > wrote: >>> >> >> >>> >> >> The ES specification states that the result of sampling from a >>> >> >> texture >>> >> >> attached to a framebuffer at the same time as sampling to that >>> >> >> framebuffer >>> >> >> is undefined. >>> >> >> >>> >> >> Google chrome seems to interprete this as: If a texture is bound to >>> >> >> any >>> >> >> texturing unit while that framebuffer is used it's an error. >>> >> >> >>> >> >> However a different interpretation of this would be: If a texture >>> >> >> that >>> >> >> is >>> >> >> bound is actually sampled during the framebuffer operation it's an >>> >> >> error. >>> >> >> >>> >> >> Which of these interpretations is the correct one? >>> >> > >>> >> > >>> > >>> > >>> >>> ----------------------------------------------------------- >>> 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 kbr...@ Mon Mar 20 15:40:27 2017 From: kbr...@ (Kenneth Russell) Date: Mon, 20 Mar 2017 15:40:27 -0700 Subject: [Public WebGL] Re: meaning of the specification of FBO sampling and interpretation by UAs In-Reply-To: References: Message-ID: If you have specific tests which behave differently on Windows vs. non-Windows platforms, please do file an issue and include a test case. We'll add it to the conformance suite and normalize the behavior. Thanks, -Ken On Mon, Mar 20, 2017 at 3:04 PM, Zhenyao Mo wrote: > That is the goal. We have conformance tests for that. The behavior > difference between Windows (ANGLE) and the rest (GPU command buffer) > indicates the testing isn't sufficient and we should definitely > improve it. > > On Mon, Mar 20, 2017 at 2:47 PM, Florian B?sch wrote: > > I believe the behavior should be specified and implemented on all > platforms > > the same, indifferently from the backend or UA. Agreed? > > > > On Mon, Mar 20, 2017 at 7:25 PM, Kenneth Russell wrote: > >> > >> It's not feasible to detect during a given draw call that the bound > >> program sampled a texture which actually ended up causing a rendering > >> feedback loop. For this reason Chrome's detection of feedback loops > iterates > >> over all of the samplers of the currently bound program, and looks at > the > >> texture objects bound to those texture units. If any of those textures > are > >> bound to the current framebuffer object, it generates an error. > >> > >> This is a conservative check, but covers all of the undefined cases on > >> mobile hardware. When this check was instituted some time ago, content > which > >> was updated to render correctly with it started working on mobile > devices > >> where it had previously failed. > >> > >> -Ken > >> > >> > >> > >> On Mon, Mar 20, 2017 at 10:14 AM, Zhenyao Mo wrote: > >>> > >>> > >>> We have WebGL conformance tests for feedback loop detection, but we > >>> don't have a positive test that a texture is bound but not sampled, > >>> that it is not feedback loop and no error should be generated. > >>> > >>> The ES spec doesn't generate GL errors on feedback loops. It's simply > >>> stating the results are undefined. > >>> > >>> On Mon, Mar 20, 2017 at 9:48 AM, Florian B?sch > wrote: > >>> > I'm not 100% sure it's the case, the error I looked at was somewhat > >>> > complex. > >>> > Do we have unit-test for it? > >>> > > >>> > On Mon, Mar 20, 2017 at 5:46 PM, Zhenyao Mo > wrote: > >>> >> > >>> >> To clarify, drivers never generate errors in such situation. It's > >>> >> simply an undefined behavior. The error you see is not from NVidia > >>> >> drivers, but from Chrome's GPU command buffer. > >>> >> > >>> >> On Sun, Mar 19, 2017 at 2:07 PM, Florian B?sch > >>> >> wrote: > >>> >> > I might add, OpenGL adopts the latter more lenient interptation > (at > >>> >> > least > >>> >> > with nvidia drivers), and that works fine on Chrome on these > >>> >> > systems, > >>> >> > but > >>> >> > on Windows Chrome/ANGLE use a more strict interpretation. > >>> >> > > >>> >> > On Sun, Mar 19, 2017 at 10:05 PM, Florian B?sch > > >>> >> > wrote: > >>> >> >> > >>> >> >> The ES specification states that the result of sampling from a > >>> >> >> texture > >>> >> >> attached to a framebuffer at the same time as sampling to that > >>> >> >> framebuffer > >>> >> >> is undefined. > >>> >> >> > >>> >> >> Google chrome seems to interprete this as: If a texture is bound > to > >>> >> >> any > >>> >> >> texturing unit while that framebuffer is used it's an error. > >>> >> >> > >>> >> >> However a different interpretation of this would be: If a texture > >>> >> >> that > >>> >> >> is > >>> >> >> bound is actually sampled during the framebuffer operation it's > an > >>> >> >> error. > >>> >> >> > >>> >> >> Which of these interpretations is the correct one? > >>> >> > > >>> >> > > >>> > > >>> > > >>> > >>> ----------------------------------------------------------- > >>> 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 Mar 22 10:12:11 2017 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 22 Mar 2017 18:12:11 +0100 Subject: [Public WebGL] The miserable state of affairs of floating point support Message-ID: Having looked supporting different formats for rendering to and sampling from, I'd like to share my observations. *Extensions are claimed that are not supported* On iOS the implementation claims to support OES_texture_float_linear but this does not actually work and it defaults (silently) to nearest. *Float16Array still does not exist* It's still a major pain to deal with generating data to upload to Half-Float textures because despite repeated prodding on the ECMA-ML as well as here, we *still* don't have a Float16Array. *Some implementations do not accept Uint16Array upload to half-float textures* Safari and iOS refuse to accept an array for texImage2D to upload to half-float textures. Even though it's now in the specification that this is permissible. We talked about this. It was agreed we would allow that. *Setting linear blending mode on textures that don't support it generates no error* The UA complains about an unrenderable texture when you draw sampling from it, so it knows that the blending mode isn't supported. But you can't get an error from it either at texParameter or draw*. This is extremely awkward, because apparently (see above) the linear extensions have no meaning whatsoever, so you have to actually draw to figure out if blending works and then readback the results. If you (the UA) already knows that linear doesn't work, please don't make developers integrate a unit test to figure it out? *The color_buffer extensions have no meaning* Platforms (such as Chrome) that support drawing to floating point textures do not expose these extensions, leaving you no choice but to getExtension it and then promptly ignore anything you got and test if you can actually construct an FBO that is indicated as valid and draw to it and then read the drawn texture (trough another FBO because see blow). *readPixels of floats may or may not work* Some platforms do not implement readPixels from a floating point texture. Some do. Because of that, you can't directly test some of the more interesting properties of floating point textures (such as blending, filtering, clamping, etc.) but you have to do it trough a proxy unsigned byte FBO because you can't rely on readPixels. *Some devices do not expose floating point textures even though they support them* For reasons that completely boggle me, the fairly new Samsung S7 (just a year old) which has perfectly fine and working support for a variety of floating point textures/operations do not expose that to WebGL (by some combination of unlucky ES config and whatnot). That's a fairly big problem. Because samsung devices are fairly popular, it means floating point support on mobiles is actually retrograde, mean reverting slowly back to somewhere anno 2012 or so. ----- The only qualifier I can find for the situation is miserable and utterly broken. It's hurting WebGL. It should be addressed. It should have been addressed long ago, and most of these things came up in the past years at one point or another. I don't understand why they are not addressed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From max...@ Wed Mar 22 10:48:15 2017 From: max...@ (Maksims Mihejevs) Date: Wed, 22 Mar 2017 17:48:15 +0000 Subject: [Public WebGL] The miserable state of affairs of floating point support In-Reply-To: References: Message-ID: We have experienced another issue. On one mobile platform it was advertised that Float 32 texture is supported. And after actually testing it (because you have to test regardless of what is advertised by extension), it did "worked". But there was a weird catch: writing float 32 pixel, and then reading it, it would loose precision. So even it worked, it actually was changed. Either due to some emulation and repacking to different formats there was some issues and data gets modified, or by some other bug, where we literally missing some bytes or actual values are modified. Here is actual code for testing this in our engine: https://github.com/playcanvas/engine/blob/master/src/graphics/device.js#L739-L795 This was a surprise for us and did lead to some time figuring out, what is actually a problem. We were trying to implement Variance Shadow Maps with float32 textures, and some data got modified breaking the feature only on some devices. This is of course not acceptable at all, and renders feature unusable in many scenarios where precision of data should persist. Cheers, Max On 22 March 2017 at 17:12, Florian B?sch wrote: > Having looked supporting different formats for rendering to and sampling > from, I'd like to share my observations. > > *Extensions are claimed that are not supported* > > On iOS the implementation claims to support OES_texture_float_linear but > this does not actually work and it defaults (silently) to nearest. > > > *Float16Array still does not exist* > > It's still a major pain to deal with generating data to upload to > Half-Float textures because despite repeated prodding on the ECMA-ML as > well as here, we *still* don't have a Float16Array. > > > *Some implementations do not accept Uint16Array upload to half-float > textures* > > Safari and iOS refuse to accept an array for texImage2D to upload to > half-float textures. Even though it's now in the specification that this is > permissible. We talked about this. It was agreed we would allow that. > > > *Setting linear blending mode on textures that don't support it generates > no error* > > The UA complains about an unrenderable texture when you draw sampling from > it, so it knows that the blending mode isn't supported. But you can't get > an error from it either at texParameter or draw*. This is extremely > awkward, because apparently (see above) the linear extensions have no > meaning whatsoever, so you have to actually draw to figure out if blending > works and then readback the results. If you (the UA) already knows that > linear doesn't work, please don't make developers integrate a unit test to > figure it out? > > > *The color_buffer extensions have no meaning* > > Platforms (such as Chrome) that support drawing to floating point textures > do not expose these extensions, leaving you no choice but to getExtension > it and then promptly ignore anything you got and test if you can actually > construct an FBO that is indicated as valid and draw to it and then read > the drawn texture (trough another FBO because see blow). > > > *readPixels of floats may or may not work* > > Some platforms do not implement readPixels from a floating point texture. > Some do. Because of that, you can't directly test some of the more > interesting properties of floating point textures (such as blending, > filtering, clamping, etc.) but you have to do it trough a proxy unsigned > byte FBO because you can't rely on readPixels. > > > *Some devices do not expose floating point textures even though they > support them* > > For reasons that completely boggle me, the fairly new Samsung S7 (just a > year old) which has perfectly fine and working support for a variety of > floating point textures/operations do not expose that to WebGL (by some > combination of unlucky ES config and whatnot). That's a fairly big problem. > Because samsung devices are fairly popular, it means floating point support > on mobiles is actually retrograde, mean reverting slowly back to somewhere > anno 2012 or so. > > ----- > > > The only qualifier I can find for the situation is miserable and utterly > broken. It's hurting WebGL. It should be addressed. It should have been > addressed long ago, and most of these things came up in the past years at > one point or another. I don't understand why they are not addressed. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Wed Mar 22 18:19:37 2017 From: kbr...@ (Kenneth Russell) Date: Wed, 22 Mar 2017 18:19:37 -0700 Subject: [Public WebGL] The miserable state of affairs of floating point support In-Reply-To: References: Message-ID: On Wed, Mar 22, 2017 at 10:48 AM, Maksims Mihejevs wrote: > We have experienced another issue. > > On one mobile platform it was advertised that Float 32 texture is > supported. And after actually testing it (because you have to test > regardless of what is advertised by extension), it did "worked". > But there was a weird catch: writing float 32 pixel, and then reading it, > it would loose precision. So even it worked, it actually was changed. > Either due to some emulation and repacking to different formats there was > some issues and data gets modified, or by some other bug, where we > literally missing some bytes or actual values are modified. > > Here is actual code for testing this in our engine: https://github.com/ > playcanvas/engine/blob/master/src/graphics/device.js#L739-L795 > This was a surprise for us and did lead to some time figuring out, what is > actually a problem. We were trying to implement Variance Shadow Maps with > float32 textures, and some data got modified breaking the feature only on > some devices. > > This is of course not acceptable at all, and renders feature unusable in > many scenarios where precision of data should persist. > Does this behavior persist in WebGL 2.0 if you use EXT_color_buffer_float and explicitly render to an FP32 texture, using highp precision variables in your shaders? I'm not sure what the guarantees were in older OpenGL ES versions, but since ES 3.0 provides exact control over textures' internal formats, I would expect this round-trip to be guaranteed. > > Cheers, > Max > > On 22 March 2017 at 17:12, Florian B?sch wrote: > >> Having looked supporting different formats for rendering to and sampling >> from, I'd like to share my observations. >> >> *Extensions are claimed that are not supported* >> >> On iOS the implementation claims to support OES_texture_float_linear but >> this does not actually work and it defaults (silently) to nearest. >> >> Could you please submit a conformance test verifying this behavior? > >> *Float16Array still does not exist* >> >> It's still a major pain to deal with generating data to upload to >> Half-Float textures because despite repeated prodding on the ECMA-ML as >> well as here, we *still* don't have a Float16Array. >> > Can't help with this. Sorry. *Some implementations do not accept Uint16Array upload to half-float >> textures* >> >> Safari and iOS refuse to accept an array for texImage2D to upload to >> half-float textures. Even though it's now in the specification that this is >> permissible. We talked about this. It was agreed we would allow that. >> > I confirm that Safari on macOS is failing https://www.khronos.org/registry/webgl/sdk/tests/conformance/extensions/oes-texture-half-float.html . Please confirm that it's failing on iOS and file a bug on bugs.webkit.org. *Setting linear blending mode on textures that don't support it generates >> no error* >> >> The UA complains about an unrenderable texture when you draw sampling >> from it, so it knows that the blending mode isn't supported. But you can't >> get an error from it either at texParameter or draw*. This is extremely >> awkward, because apparently (see above) the linear extensions have no >> meaning whatsoever, so you have to actually draw to figure out if blending >> works and then readback the results. If you (the UA) already knows that >> linear doesn't work, please don't make developers integrate a unit test to >> figure it out? >> > Please file an issue about this on https://github.com/KhronosGroup/WebGL . The browser vendors can discuss making this change. *The color_buffer extensions have no meaning* >> >> Platforms (such as Chrome) that support drawing to floating point >> textures do not expose these extensions, leaving you no choice but to >> getExtension it and then promptly ignore anything you got and test if you >> can actually construct an FBO that is indicated as valid and draw to it and >> then read the drawn texture (trough another FBO because see blow). >> > This behavior is much clarified and simpler in WebGL 2.0. There's only one extension: EXT_color_buffer_float, and it provides a strong guarantee about renderability without adding a lot of feature detection code to the WebGL implementation itself and impacting startup time of all WebGL apps. Please try WebGL 2.0. If you see issues in this area in that version then please file bugs. *readPixels of floats may or may not work* >> >> Some platforms do not implement readPixels from a floating point texture. >> Some do. Because of that, you can't directly test some of the more >> interesting properties of floating point textures (such as blending, >> filtering, clamping, etc.) but you have to do it trough a proxy unsigned >> byte FBO because you can't rely on readPixels. >> > This should again be much clarified in WebGL 2.0 and there should be strong guarantees about readPixels' behavior there. *Some devices do not expose floating point textures even though they >> support them* >> >> For reasons that completely boggle me, the fairly new Samsung S7 (just a >> year old) which has perfectly fine and working support for a variety of >> floating point textures/operations do not expose that to WebGL (by some >> combination of unlucky ES config and whatnot). That's a fairly big problem. >> Because samsung devices are fairly popular, it means floating point support >> on mobiles is actually retrograde, mean reverting slowly back to somewhere >> anno 2012 or so. >> > We just tested Chrome Dev on a Samsung Galaxy S7 Edge and it passes the render-to-RGBA-texture portion of https://www.khronos.org/registry/webgl/sdk/tests/conformance/extensions/oes-texture-float.html . (RGB textures are not renderable.) It also seems to support EXT_color_buffer_float for WebGL 2.0. If you have a scenario on a newer device like this where render-to-FP-texture is not working at all then please file a bug. If you're trying to save memory, then rendering to R32F and RG32F textures is available as of WebGL 2.0. The only qualifier I can find for the situation is miserable and utterly >> broken. It's hurting WebGL. It should be addressed. It should have been >> addressed long ago, and most of these things came up in the past years at >> one point or another. I don't understand why they are not addressed. >> > WebGL 2.0 should solve many longstanding issues with rendering to floating-point textures. It's supported in Firefox on Android now and will be in Chrome 58 on Android. Please help us make sure that these issues are addressed in the most recent version, and we can work on backporting some of the fixes to WebGL 1.0 + extensions. -Ken -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Thu Mar 23 02:08:03 2017 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Thu, 23 Mar 2017 10:08:03 +0100 Subject: [Public WebGL] The miserable state of affairs of floating point support In-Reply-To: References: Message-ID: On Thu, Mar 23, 2017 at 2:19 AM, Kenneth Russell wrote: > On 22 March 2017 at 17:12, Florian B?sch wrote: >> >>> Having looked supporting different formats for rendering to and sampling >>> from, I'd like to share my observations. >>> >>> *Extensions are claimed that are not supported* >>> >>> On iOS the implementation claims to support OES_texture_float_linear but >>> this does not actually work and it defaults (silently) to nearest. >>> >>> > Could you please submit a conformance test verifying this behavior? > The conformance test to verify float linear already exists, and it fails pretty much every suite contained in it, including the non linear filtering behavior I described. https://www.khronos.org/registry/webgl/ sdk/tests/conformance/extensions/oes-texture-float- linear.html?webglVersion=1&quiet=0 > *Float16Array still does not exist* >>> >>> It's still a major pain to deal with generating data to upload to >>> Half-Float textures because despite repeated prodding on the ECMA-ML as >>> well as here, we *still* don't have a Float16Array. >>> >> > Can't help with this. Sorry. > Why not? > > *Some implementations do not accept Uint16Array upload to half-float >>> textures* >>> >>> Safari and iOS refuse to accept an array for texImage2D to upload to >>> half-float textures. Even though it's now in the specification that this is >>> permissible. We talked about this. It was agreed we would allow that. >>> >> > I confirm that Safari on macOS is failing https://www.khronos.or > g/registry/webgl/sdk/tests/conformance/extensions/oes-textur > e-half-float.html . Please confirm that it's failing on iOS and file a > bug on bugs.webkit.org. > Bug Submitted: https://bugs.webkit.org/show_bug.cgi?id=169999 > *Setting linear blending mode on textures that don't support it generates >>> no error* >>> >>> The UA complains about an unrenderable texture when you draw sampling >>> from it, so it knows that the blending mode isn't supported. But you can't >>> get an error from it either at texParameter or draw*. This is extremely >>> awkward, because apparently (see above) the linear extensions have no >>> meaning whatsoever, so you have to actually draw to figure out if blending >>> works and then readback the results. If you (the UA) already knows that >>> linear doesn't work, please don't make developers integrate a unit test to >>> figure it out? >>> >> > Please file an issue about this on https://github.com/KhronosGroup/WebGL > . The browser vendors can discuss making this change. > Filed: https://github.com/KhronosGroup/WebGL/issues/2344 > *The color_buffer extensions have no meaning* >>> >>> Platforms (such as Chrome) that support drawing to floating point >>> textures do not expose these extensions, leaving you no choice but to >>> getExtension it and then promptly ignore anything you got and test if you >>> can actually construct an FBO that is indicated as valid and draw to it and >>> then read the drawn texture (trough another FBO because see blow). >>> >> > This behavior is much clarified and simpler in WebGL 2.0. There's only one > extension: EXT_color_buffer_float, and it provides a strong guarantee about > renderability without adding a lot of feature detection code to the WebGL > implementation itself and impacting startup time of all WebGL apps. Please > try WebGL 2.0. If you see issues in this area in that version then please > file bugs. > The fix for this issue exists, it's color_buffer float extensions. I've filed bugs for you to implement it. You want me to file again? *readPixels of floats may or may not work* >>> >>> Some platforms do not implement readPixels from a floating point >>> texture. Some do. Because of that, you can't directly test some of the more >>> interesting properties of floating point textures (such as blending, >>> filtering, clamping, etc.) but you have to do it trough a proxy unsigned >>> byte FBO because you can't rely on readPixels. >>> >> > This should again be much clarified in WebGL 2.0 and there should be > strong guarantees about readPixels' behavior there. > The specification of color-buffer-float clearly specifies that area, it states that: "The format and type combination RGBA and FLOAT becomes valid for reading from a floating-point rendering buffer." *Some devices do not expose floating point textures even though they >>> support them* >>> >>> For reasons that completely boggle me, the fairly new Samsung S7 (just a >>> year old) which has perfectly fine and working support for a variety of >>> floating point textures/operations do not expose that to WebGL (by some >>> combination of unlucky ES config and whatnot). That's a fairly big problem. >>> Because samsung devices are fairly popular, it means floating point support >>> on mobiles is actually retrograde, mean reverting slowly back to somewhere >>> anno 2012 or so. >>> >> > We just tested Chrome Dev on a Samsung Galaxy S7 Edge and it passes the > render-to-RGBA-texture portion of https://www.khronos.org/reg > istry/webgl/sdk/tests/conformance/extensions/oes-texture-float.html . > (RGB textures are not renderable.) It also seems to support > EXT_color_buffer_float for WebGL 2.0. If you have a scenario on a newer > device like this where render-to-FP-texture is not working at all then > please file a bug. > > If you're trying to save memory, then rendering to R32F and RG32F textures > is available as of WebGL 2.0. > They are not available in WebGL 1, and that is the problem. I'll elaborate on this just below. But to note, my Nexus 4 supported floating point textures, but my Galaxy S7 doesn't, and that is a problem because.... The only qualifier I can find for the situation is miserable and utterly >>> broken. It's hurting WebGL. It should be addressed. It should have been >>> addressed long ago, and most of these things came up in the past years at >>> one point or another. I don't understand why they are not addressed. >>> >> > WebGL 2.0 should solve many longstanding issues with rendering to > floating-point textures. It's supported in Firefox on Android now and will > be in Chrome 58 on Android. Please help us make sure that these issues are > addressed in the most recent version, and we can work on backporting some > of the fixes to WebGL 1.0 + extensions. > - WebGL 1.0 enjoys 96% overall support with 7% major performance caveat ==> 89% usable WebGL 2.0 - WebGL 2.0 is at 44% support with 6.5% major performance caveat ==> 41% usable WebGL 2.0 (I predicted this) - WebGL 2.0 has reached a plateau at its current support level that persisted for the last 1-2 months, it's no longer quickly gaining much support (I predicted this too) I hate sounding like a broken record. WebGL 2.0 is not a substitute for a well functioning WebGL 1.0 for a long time. To the ears of a webapp dev that's like "We don't fix this because there's a new shiny thing, which you can't use more than half of the time, and that's how it's gonna be for years." It's not good. It's anything but good. -------------- next part -------------- An HTML attachment was scrubbed... URL: From khr...@ Thu Mar 23 22:02:58 2017 From: khr...@ (Gregg Tavares) Date: Fri, 24 Mar 2017 14:02:58 +0900 Subject: [Public WebGL] The miserable state of affairs of floating point support In-Reply-To: References: Message-ID: On Thu, Mar 23, 2017 at 6:08 PM, Florian B?sch wrote: > On Thu, Mar 23, 2017 at 2:19 AM, Kenneth Russell wrote: > >> On 22 March 2017 at 17:12, Florian B?sch wrote: >>> >>>> Having looked supporting different formats for rendering to and >>>> sampling from, I'd like to share my observations. >>>> >>>> *Extensions are claimed that are not supported* >>>> >>>> On iOS the implementation claims to support OES_texture_float_linear >>>> but this does not actually work and it defaults (silently) to nearest. >>>> >>>> >> Could you please submit a conformance test verifying this behavior? >> > > The conformance test to verify float linear already exists, and it fails > pretty much every suite contained in it, including the non linear filtering > behavior I described. https://www.khronos.org/registry/webgl/sdk/tests/ > conformance/extensions/oes-texture-float-linear.html? > webglVersion=1&quiet=0 > > >> *Float16Array still does not exist* >>>> >>>> It's still a major pain to deal with generating data to upload to >>>> Half-Float textures because despite repeated prodding on the ECMA-ML as >>>> well as here, we *still* don't have a Float16Array. >>>> >>> >> Can't help with this. Sorry. >> > > Why not? > That's a JavaScript issue, not a WebGL issue. This is the WebGL forum. If you want Float16Array you'd need to go petition the JavaScript guys (I see that you have) Yes, TypedArrays started here but they were correctly passed off to JS. I doubt they'll see any traction though for pretty much the same reason nothing like that exists in any other language I know of. it's a niche feature. You can have a C/C++ array of float, short, unsigned short, int, unsigned int etc but there's no half AFAIK > > >> >> *Some implementations do not accept Uint16Array upload to half-float >>>> textures* >>>> >>>> Safari and iOS refuse to accept an array for texImage2D to upload to >>>> half-float textures. Even though it's now in the specification that this is >>>> permissible. We talked about this. It was agreed we would allow that. >>>> >>> >> I confirm that Safari on macOS is failing https://www.khronos.or >> g/registry/webgl/sdk/tests/conformance/extensions/oes-textur >> e-half-float.html . Please confirm that it's failing on iOS and file a >> bug on bugs.webkit.org. >> > > Bug Submitted: https://bugs.webkit.org/show_bug.cgi?id=169999 > > >> *Setting linear blending mode on textures that don't support it generates >>>> no error* >>>> >>>> The UA complains about an unrenderable texture when you draw sampling >>>> from it, so it knows that the blending mode isn't supported. But you can't >>>> get an error from it either at texParameter or draw*. This is extremely >>>> awkward, because apparently (see above) the linear extensions have no >>>> meaning whatsoever, so you have to actually draw to figure out if blending >>>> works and then readback the results. If you (the UA) already knows that >>>> linear doesn't work, please don't make developers integrate a unit test to >>>> figure it out? >>>> >>> >> Please file an issue about this on https://github.com/KhronosGroup/WebGL >> . The browser vendors can discuss making this change. >> > > Filed: https://github.com/KhronosGroup/WebGL/issues/2344 > You can't generate errors at texParam time. That's the spec. It's perfectly valid to have intermediate steps where textures are in an invalid state on the road to making them valid. A very common example 1) gl.texImage2D(..., npot) // texture invalid as default min filtering is incompatible with npot textures 2) gl.texParameteri(..., gl.TEXTURE_MIN_FILTER, gl.LINEAR); // now it's safe If you follow the road of generating errors then that very common code would fail at step 1 and you'd have to reverse the order. (which would maybe be great but would break tons of content) You also can't at draw time as plenty of apps work and shipped even though some of their textures may not be renderable. Suddenly generating errors where there were none before would break content. A simple example might be var tex = gl.createTexture(); var img = new Image(); img.onload = function() { gl.bindTexture(...); gl.texImage2D(...); ... } startRenderLoop() Until the texture loads you won't see the texture, there will be warning in the JS console but otherwise the app will work just fine > > >> *The color_buffer extensions have no meaning* >>>> >>>> Platforms (such as Chrome) that support drawing to floating point >>>> textures do not expose these extensions, leaving you no choice but to >>>> getExtension it and then promptly ignore anything you got and test if you >>>> can actually construct an FBO that is indicated as valid and draw to it and >>>> then read the drawn texture (trough another FBO because see blow). >>>> >>> >> This behavior is much clarified and simpler in WebGL 2.0. There's only >> one extension: EXT_color_buffer_float, and it provides a strong guarantee >> about renderability without adding a lot of feature detection code to the >> WebGL implementation itself and impacting startup time of all WebGL apps. >> Please try WebGL 2.0. If you see issues in this area in that version then >> please file bugs. >> > > The fix for this issue exists, it's color_buffer float extensions. I've > filed bugs for you to implement it. You want me to file again? > this is never going to be fixed for WebGL1 as it would break too much content. The whole issue was WebGL shipped for > year with OES_texture_float and the ability to use them as a framebuffer attachments before Mark Callow pointed out that was wrong and that we needed EXT_color_float_buffer. So it was added but the original method (make floating point texture, attach, check for FRAMEBUFFER_COMPLETE) was left. It's fixed in WebGL2 because that will not break any content but it can't be fixed in WebGL1 without breaking sites. > > *readPixels of floats may or may not work* >>>> >>>> Some platforms do not implement readPixels from a floating point >>>> texture. Some do. Because of that, you can't directly test some of the more >>>> interesting properties of floating point textures (such as blending, >>>> filtering, clamping, etc.) but you have to do it trough a proxy unsigned >>>> byte FBO because you can't rely on readPixels. >>>> >>> >> This should again be much clarified in WebGL 2.0 and there should be >> strong guarantees about readPixels' behavior there. >> > > The specification of color-buffer-float clearly specifies that area, it > states that: "The format and type combination RGBA and FLOAT becomes valid > for reading from a floating-point rendering buffer." > Agreed: Add a conformance test? > > *Some devices do not expose floating point textures even though they >>>> support them* >>>> >>>> For reasons that completely boggle me, the fairly new Samsung S7 (just >>>> a year old) which has perfectly fine and working support for a variety of >>>> floating point textures/operations do not expose that to WebGL (by some >>>> combination of unlucky ES config and whatnot). That's a fairly big problem. >>>> Because samsung devices are fairly popular, it means floating point support >>>> on mobiles is actually retrograde, mean reverting slowly back to somewhere >>>> anno 2012 or so. >>>> >>> >> We just tested Chrome Dev on a Samsung Galaxy S7 Edge and it passes the >> render-to-RGBA-texture portion of https://www.khronos.org/reg >> istry/webgl/sdk/tests/conformance/extensions/oes-texture-float.html . >> (RGB textures are not renderable.) It also seems to support >> EXT_color_buffer_float for WebGL 2.0. If you have a scenario on a newer >> device like this where render-to-FP-texture is not working at all then >> please file a bug. >> >> If you're trying to save memory, then rendering to R32F and RG32F >> textures is available as of WebGL 2.0. >> > > They are not available in WebGL 1, and that is the problem. I'll elaborate > on this just below. But to note, my Nexus 4 supported floating point > textures, but my Galaxy S7 doesn't, and that is a problem because.... > > The only qualifier I can find for the situation is miserable and utterly >>>> broken. It's hurting WebGL. It should be addressed. It should have been >>>> addressed long ago, and most of these things came up in the past years at >>>> one point or another. I don't understand why they are not addressed. >>>> >>> >> WebGL 2.0 should solve many longstanding issues with rendering to >> floating-point textures. It's supported in Firefox on Android now and will >> be in Chrome 58 on Android. Please help us make sure that these issues are >> addressed in the most recent version, and we can work on backporting some >> of the fixes to WebGL 1.0 + extensions. >> > > - WebGL 1.0 enjoys 96% overall support with 7% major performance > caveat ==> 89% usable WebGL 2.0 > - WebGL 2.0 is at 44% support with 6.5% major performance caveat ==> > 41% usable WebGL 2.0 (I predicted this) > - WebGL 2.0 has reached a plateau at its current support level that > persisted for the last 1-2 months, it's no longer quickly gaining much > support (I predicted this too) > > I hate sounding like a broken record. WebGL 2.0 is not a substitute for a > well functioning WebGL 1.0 for a long time. To the ears of a webapp dev > that's like "We don't fix this because there's a new shiny thing, which you > can't use more than half of the time, and that's how it's gonna be for > years." It's not good. It's anything but good. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Mar 24 04:41:22 2017 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 24 Mar 2017 12:41:22 +0100 Subject: [Public WebGL] The miserable state of affairs of floating point support In-Reply-To: References: Message-ID: On Fri, Mar 24, 2017 at 6:02 AM, Gregg Tavares wrote:> That's a JavaScript issue, not a WebGL issue. This is the WebGL forum. If > you want Float16Array you'd need to go petition the JavaScript guys (I see > that you have) > > Yes, TypedArrays started here but they were correctly passed off to JS. I > doubt they'll see any traction though for pretty much the same reason > nothing like that exists in any other language I know of. it's a niche > feature. You can have a C/C++ array of float, short, unsigned short, int, > unsigned int etc but there's no half AFAIK These are the numeric data types that GPUs (which come with every consumer device sold on this planet) support trough APIs like the GL family: - Unsigned byte -> Uint8Array - Signed byte -> Int8Array - Unsigned short -> Uint16Array - Signed short -> Int16Array - Unsigned Integer -> Uint32Array - Signed Integer -> Int32Array - Fixed -> *???* - Half-Float -> *???* - Float -> Float32Array - Double -> Float64Array All numbers in JS are doubles. JIT code may accelerate things if it detects paths that only deal with certain types, but JIT'ing is not part of the JS specification. It's part of an implementation ooptimization. Data that is passed off to the GPU or read back from it is often processed on the CPU side for various purposes. This is simple to understand, CPUs need to understand the numbers they put into and get from the GPU to productively work with it. Javascript is a dynamically typed language, this has some advantages. For instance you want to write some code that modifies a collection of numbers in some way: var addToArr = function(arr, n){ for(var i=0; i> filed bugs for you to implement it. You want me to file again? >> > > this is never going to be fixed for WebGL1 as it would break too much > content. The whole issue was WebGL shipped for > year with > OES_texture_float and the ability to use them as a framebuffer attachments > before Mark Callow pointed out that was wrong and that we needed > EXT_color_float_buffer. So it was added but the original method (make > floating point texture, attach, check for FRAMEBUFFER_COMPLETE) was left. > > It's fixed in WebGL2 because that will not break any content but it can't > be fixed in WebGL1 without breaking sites > You didn't understand the issue. The isn't that these extension would break things if they're interpreted literally. That's not a problem. The problem is that UA (such as chrome) have elected to not support this extension, even though they support the functionality exposed by the extension. This a problem. Because the absence of the extension does not indicate the absence of the functionality. If you want to stay with the traditional behavior, there is nothing preventing you from doing just that, just implement the extension, enable it by default as per usual. But right now, they're meaningless, which makes everybody jump trough idiotic hoops for no gain. > The specification of color-buffer-float clearly specifies that area, it >> states that: "The format and type combination RGBA and FLOAT becomes valid >> for reading from a floating-point rendering buffer." >> > > Agreed: Add a conformance test? > The conformance test already exists. It's the one for the color-buffer float extensions. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Mar 24 05:10:15 2017 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 24 Mar 2017 13:10:15 +0100 Subject: [Public WebGL] The miserable state of affairs of floating point support In-Reply-To: References: Message-ID: Here would be a somewhat comical and horrendously inefficient implementation of Float16Array. While that works for normal JS code, somewhat at least, it'd still run into trouble with texImage2D/bufferData/TypedArray functionalities etc. Is this really where we ant to be? var twoPm14 = Math.pow(2, -14);var smallest = twoPm14/1024;var largest = Math.pow(2, 30-15) * (1 + 1023/1024); var toHalf = (function() { var floatView = new Float32Array(1); var int32View = new Int32Array(floatView.buffer); return function toHalf( fval ) { floatView[0] = fval; var fbits = int32View[0]; var sign = (fbits >> 16) & 0x8000; // sign only var val = ( fbits & 0x7fffffff ) + 0x1000; // rounded value if( val >= 0x47800000 ) { // might be or become NaN/Inf if( ( fbits & 0x7fffffff ) >= 0x47800000 ) { // is or must become NaN/Inf if( val < 0x7f800000 ) { // was value but too large return sign | 0x7c00; // make it +/-Inf } return sign | 0x7c00 | // remains +/-Inf or NaN ( fbits & 0x007fffff ) >> 13; // keep NaN (and Inf) bits } return sign | 0x7bff; // unrounded not quite Inf } if( val >= 0x38800000 ) { // remains normalized value return sign | val - 0x38000000 >> 13; // exp - 127 + 15 } if( val < 0x33000000 ) { // too small for subnormal return sign; // becomes +/-0 } val = ( fbits & 0x7fffffff ) >> 23; // tmp exp for subnormal calc return sign | ( ( fbits & 0x7fffff | 0x800000 ) // add subnormal bit + ( 0x800000 >>> val - 102 ) // round depending on cut off >> 126 - val ); // div by 2^(1-(exp-127+15)) and >> 13 | exp=0 };}()); var fromHalf = function(n){ var sign = 1 - ((n & 0x8000) >> 14); var exponent = (n & 0x7c00) >> 10; var mantissa = (n & 0x03ff); if(exponent === 0){ if(mantissa !== 0){ return sign * twoPm14 * (mantissa/1024); } else{ return sign * 0; } } else if(exponent < 31){ return sign * Math.pow(2, exponent-15) * (1 + mantissa/1024); } else{ if(mantissa === 0){ return sign * Infinity; } else{ return NaN; } }}; var Float16Array = function(size){ var array = this.array = new Uint16Array(size); var self = this; var defineProperty = function(n){ Object.defineProperty(self, n, { get: function(){ return fromHalf(array[n]); }, set: function(value){ return array[n] = toHalf(value); } }); } for(var i=0; i From max...@ Fri Mar 24 12:47:32 2017 From: max...@ (Maksims Mihejevs) Date: Fri, 24 Mar 2017 19:47:32 +0000 Subject: [Public WebGL] The miserable state of affairs of floating point support In-Reply-To: References: Message-ID: Regarding float32 precision issues. I've made two examples one using WebGL 1.0 context and another WebGL 2.0 context. There are 5 boxes with colors. Top-left: float texture can render - if webgl2, this is always green, and if webgl1, then it actually tests if can render and read back to float texture. Top-right: half-float texture can render - if webgl2, this is always green, and if webgl1, then it actually tests if can render and read back to half-float texture. middle-left: float texture precision test - it writes float data, and reads back. If value has lost a precision, then box will be yellow. If value persisted then box will be green. If float texture not supported box will be red. middle-right: half-float texture precision test - it writes half-float data, and reads back. If value has lost a precision, then box will be yellow. If value persisted then box will be green. If float texture not supported box will be red. bottom-left: same as middle-left (float texture) but it is green if precision is all-good and will be red if precision is not right or float textures are not supported. WebGL2: https://playcanv.as/e/b/qLBgDD1n/ WebGL1: https://playcanv.as/e/b/f0mK8l43/ So from One Plus 2 device, I am getting no half-float support at all, and not right precision on float textures. Although device has Qualcomm MSM8994 Snapdragon 810 on it, which is decent GPU. Please verify on some mobile devices this as well in order to identify the devices with not full float texture precision, I do believe they are not that rare exceptions, which means that float textures are might be not suitable for many use cases. We in PlayCanvas engine test texture float precision and if it is not full precision, we assume that this exception is not supported at all then. Otherwise we had loads of artifacts and rendering issues of features that relied on float textures with false precision. Kind Regards, Max On 23 March 2017 at 01:19, Kenneth Russell wrote: > > > On Wed, Mar 22, 2017 at 10:48 AM, Maksims Mihejevs > wrote: > >> We have experienced another issue. >> >> On one mobile platform it was advertised that Float 32 texture is >> supported. And after actually testing it (because you have to test >> regardless of what is advertised by extension), it did "worked". >> But there was a weird catch: writing float 32 pixel, and then reading it, >> it would loose precision. So even it worked, it actually was changed. >> Either due to some emulation and repacking to different formats there was >> some issues and data gets modified, or by some other bug, where we >> literally missing some bytes or actual values are modified. >> >> Here is actual code for testing this in our engine: >> https://github.com/playcanvas/engine/blob/master/src >> /graphics/device.js#L739-L795 >> This was a surprise for us and did lead to some time figuring out, what >> is actually a problem. We were trying to implement Variance Shadow Maps >> with float32 textures, and some data got modified breaking the feature only >> on some devices. >> >> This is of course not acceptable at all, and renders feature unusable in >> many scenarios where precision of data should persist. >> > > Does this behavior persist in WebGL 2.0 if you use EXT_color_buffer_float > and explicitly render to an FP32 texture, using highp precision variables > in your shaders? I'm not sure what the guarantees were in older OpenGL ES > versions, but since ES 3.0 provides exact control over textures' internal > formats, I would expect this round-trip to be guaranteed. > > > > >> >> Cheers, >> Max >> >> On 22 March 2017 at 17:12, Florian B?sch wrote: >> >>> Having looked supporting different formats for rendering to and sampling >>> from, I'd like to share my observations. >>> >>> *Extensions are claimed that are not supported* >>> >>> On iOS the implementation claims to support OES_texture_float_linear but >>> this does not actually work and it defaults (silently) to nearest. >>> >>> > Could you please submit a conformance test verifying this behavior? > > > >> >>> *Float16Array still does not exist* >>> >>> It's still a major pain to deal with generating data to upload to >>> Half-Float textures because despite repeated prodding on the ECMA-ML as >>> well as here, we *still* don't have a Float16Array. >>> >> > Can't help with this. Sorry. > > > *Some implementations do not accept Uint16Array upload to half-float >>> textures* >>> >>> Safari and iOS refuse to accept an array for texImage2D to upload to >>> half-float textures. Even though it's now in the specification that this is >>> permissible. We talked about this. It was agreed we would allow that. >>> >> > I confirm that Safari on macOS is failing https://www.khronos. > org/registry/webgl/sdk/tests/conformance/extensions/oes- > texture-half-float.html . Please confirm that it's failing on iOS and > file a bug on bugs.webkit.org. > > > *Setting linear blending mode on textures that don't support it generates >>> no error* >>> >>> The UA complains about an unrenderable texture when you draw sampling >>> from it, so it knows that the blending mode isn't supported. But you can't >>> get an error from it either at texParameter or draw*. This is extremely >>> awkward, because apparently (see above) the linear extensions have no >>> meaning whatsoever, so you have to actually draw to figure out if blending >>> works and then readback the results. If you (the UA) already knows that >>> linear doesn't work, please don't make developers integrate a unit test to >>> figure it out? >>> >> > Please file an issue about this on https://github.com/KhronosGroup/WebGL > . The browser vendors can discuss making this change. > > > *The color_buffer extensions have no meaning* >>> >>> Platforms (such as Chrome) that support drawing to floating point >>> textures do not expose these extensions, leaving you no choice but to >>> getExtension it and then promptly ignore anything you got and test if you >>> can actually construct an FBO that is indicated as valid and draw to it and >>> then read the drawn texture (trough another FBO because see blow). >>> >> > This behavior is much clarified and simpler in WebGL 2.0. There's only one > extension: EXT_color_buffer_float, and it provides a strong guarantee about > renderability without adding a lot of feature detection code to the WebGL > implementation itself and impacting startup time of all WebGL apps. Please > try WebGL 2.0. If you see issues in this area in that version then please > file bugs. > > > *readPixels of floats may or may not work* >>> >>> Some platforms do not implement readPixels from a floating point >>> texture. Some do. Because of that, you can't directly test some of the more >>> interesting properties of floating point textures (such as blending, >>> filtering, clamping, etc.) but you have to do it trough a proxy unsigned >>> byte FBO because you can't rely on readPixels. >>> >> > This should again be much clarified in WebGL 2.0 and there should be > strong guarantees about readPixels' behavior there. > > > *Some devices do not expose floating point textures even though they >>> support them* >>> >>> For reasons that completely boggle me, the fairly new Samsung S7 (just a >>> year old) which has perfectly fine and working support for a variety of >>> floating point textures/operations do not expose that to WebGL (by some >>> combination of unlucky ES config and whatnot). That's a fairly big problem. >>> Because samsung devices are fairly popular, it means floating point support >>> on mobiles is actually retrograde, mean reverting slowly back to somewhere >>> anno 2012 or so. >>> >> > We just tested Chrome Dev on a Samsung Galaxy S7 Edge and it passes the > render-to-RGBA-texture portion of https://www.khronos.org/ > registry/webgl/sdk/tests/conformance/extensions/oes-texture-float.html . > (RGB textures are not renderable.) It also seems to support > EXT_color_buffer_float for WebGL 2.0. If you have a scenario on a newer > device like this where render-to-FP-texture is not working at all then > please file a bug. > > If you're trying to save memory, then rendering to R32F and RG32F textures > is available as of WebGL 2.0. > > > The only qualifier I can find for the situation is miserable and utterly >>> broken. It's hurting WebGL. It should be addressed. It should have been >>> addressed long ago, and most of these things came up in the past years at >>> one point or another. I don't understand why they are not addressed. >>> >> > WebGL 2.0 should solve many longstanding issues with rendering to > floating-point textures. It's supported in Firefox on Android now and will > be in Chrome 58 on Android. Please help us make sure that these issues are > addressed in the most recent version, and we can work on backporting some > of the fixes to WebGL 1.0 + extensions. > > -Ken > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Fri Mar 24 13:32:18 2017 From: kbr...@ (Kenneth Russell) Date: Fri, 24 Mar 2017 13:32:18 -0700 Subject: [Public WebGL] The miserable state of affairs of floating point support In-Reply-To: References: Message-ID: ES6 Proxies can be used to implement the [] operator more efficiently. Here's a small example which does a little work (incrementing the value being set by 1) upon array indexing. The "buffer" property is supported for uploading the result to WebGL. I don't know how efficient it would be to support all of the Typed Array properties as well as the indexing operations -- seems they'd all have to be checked at the beginning of the handler's get function, which could be inefficient. But at least it's not necessary to define a property for each of the indices. function createWrapperArray(size) { let handler = { get: function(target, propKey, receiver) { if (propKey == 'buffer') return target.buffer; let index = Number(propKey); return target[index] - 1.0; }, set: function(target, propKey, value, receiver) { let index = Number(propKey); target[index] = value + 1.0; } } var array = new Float32Array(size); var proxy = new Proxy(array, handler); return proxy; } I think with a little work a Float16Array can be implemented using ES6 proxies that behaves almost exactly like the other typed array types, although some shimming of the WebGLRenderingContext would be needed in order to pass them seamlessly to the various data upload APIs. (If you're always willing to call "array.buffer" during upload, then they can behave exactly like the other typed arrays.) -Ken On Fri, Mar 24, 2017 at 5:10 AM, Florian B?sch wrote: > Here would be a somewhat comical and horrendously inefficient > implementation of Float16Array. While that works for normal JS code, > somewhat at least, it'd still run into trouble with texImage2D/bufferData/TypedArray > functionalities etc. Is this really where we ant to be? > > var twoPm14 = Math.pow(2, -14);var smallest = twoPm14/1024;var largest = Math.pow(2, 30-15) * (1 + 1023/1024); > var toHalf = (function() { > var floatView = new Float32Array(1); > var int32View = new Int32Array(floatView.buffer); > > return function toHalf( fval ) { > floatView[0] = fval; > var fbits = int32View[0]; > var sign = (fbits >> 16) & 0x8000; // sign only > var val = ( fbits & 0x7fffffff ) + 0x1000; // rounded value > > if( val >= 0x47800000 ) { // might be or become NaN/Inf > if( ( fbits & 0x7fffffff ) >= 0x47800000 ) { > // is or must become NaN/Inf > if( val < 0x7f800000 ) { // was value but too large > return sign | 0x7c00; // make it +/-Inf > } > return sign | 0x7c00 | // remains +/-Inf or NaN > ( fbits & 0x007fffff ) >> 13; // keep NaN (and Inf) bits > } > return sign | 0x7bff; // unrounded not quite Inf > } > if( val >= 0x38800000 ) { // remains normalized value > return sign | val - 0x38000000 >> 13; // exp - 127 + 15 > } > if( val < 0x33000000 ) { // too small for subnormal > return sign; // becomes +/-0 > } > val = ( fbits & 0x7fffffff ) >> 23; // tmp exp for subnormal calc > return sign | ( ( fbits & 0x7fffff | 0x800000 ) // add subnormal bit > + ( 0x800000 >>> val - 102 ) // round depending on cut off > >> 126 - val ); // div by 2^(1-(exp-127+15)) and >> 13 | exp=0 > };}()); > var fromHalf = function(n){ > var sign = 1 - ((n & 0x8000) >> 14); > var exponent = (n & 0x7c00) >> 10; > var mantissa = (n & 0x03ff); > > if(exponent === 0){ > if(mantissa !== 0){ > return sign * twoPm14 * (mantissa/1024); > } > else{ > return sign * 0; > } > } > else if(exponent < 31){ > return sign * Math.pow(2, exponent-15) * (1 + mantissa/1024); > } > else{ > if(mantissa === 0){ > return sign * Infinity; > } > else{ > return NaN; > } > }}; > var Float16Array = function(size){ > var array = this.array = new Uint16Array(size); > var self = this; > > var defineProperty = function(n){ > Object.defineProperty(self, n, { > get: function(){ > return fromHalf(array[n]); > }, > set: function(value){ > return array[n] = toHalf(value); > } > }); > } > > for(var i=0; i defineProperty(i.toFixed(0)); > }} > var foo = new Float16Array(1000); > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Fri Mar 24 14:06:36 2017 From: kbr...@ (Kenneth Russell) Date: Fri, 24 Mar 2017 14:06:36 -0700 Subject: [Public WebGL] The miserable state of affairs of floating point support In-Reply-To: References: Message-ID: On Fri, Mar 24, 2017 at 12:47 PM, Maksims Mihejevs wrote: > Regarding float32 precision issues. > I've made two examples one using WebGL 1.0 context and another WebGL 2.0 > context. > Thanks Max for putting this together. > > There are 5 boxes with colors. > > Top-left: float texture can render - if webgl2, this is always green, and > if webgl1, then it actually tests if can render and read back to float > texture. > Top-right: half-float texture can render - if webgl2, this is always > green, and if webgl1, then it actually tests if can render and read back to > half-float texture. > middle-left: float texture precision test - it writes float data, and > reads back. If value has lost a precision, then box will be yellow. If > value persisted then box will be green. If float texture not supported box > will be red. > middle-right: half-float texture precision test - it writes half-float > data, and reads back. If value has lost a precision, then box will be > yellow. If value persisted then box will be green. If float texture not > supported box will be red. > bottom-left: same as middle-left (float texture) but it is green if > precision is all-good and will be red if precision is not right or float > textures are not supported. > > WebGL2: https://playcanv.as/e/b/qLBgDD1n/ > WebGL1: https://playcanv.as/e/b/f0mK8l43/ > > So from One Plus 2 device, I am getting no half-float support at all, and > not right precision on float textures. Although device has Qualcomm MSM8994 > Snapdragon 810 on it, which is decent GPU. > Results on a Google Pixel with Chrome Dev: WebGL 1.0: Top-left: green Top-right: red Middle-left: yellow Middle-right: red Bottom-left: red WebGL 2.0: All boxes green. In Chrome it looks like the WebGL 1.0 extension OES_texture_half_float isn't allowing these textures to be renderable. This looks like an accident and I've filed http://crbug.com/705083 about it. Sorry about that. For the floating-point texture precision issue in WebGL 1.0: could you please reduce this a little further and provide a standalone test case outside PlayCanvas? Maybe https://www.khronos.org/registry/webgl/sdk/tests/conformance/extensions/oes-texture-float.html would be a good starting point. I'll be glad to file this bug then, or feel free to yourself and email me the bug ID. Just want to make sure that it isn't a bug in the shader (like using mediump for float instead of highp), and it's difficult to tell that with your current example. Chrome's using OpenGL ES 3.0 contexts internally, so it would be trivial to upgrade the internalformat of these textures from "RGBA" to "RGBA32F", if that's all that's needed to give a hint to the driver to actually allocate it with 32-bit precision per channel. Thanks, -Ken P.S. I tried both your test cases and the oes-texture-half-float.html conformance test in Firefox and Firefox Aurora on Android, but didn't get good results for any of them. Please verify on some mobile devices this as well in order to identify the > devices with not full float texture precision, I do believe they are not > that rare exceptions, which means that float textures are might be not > suitable for many use cases. > We in PlayCanvas engine test texture float precision and if it is not full > precision, we assume that this exception is not supported at all then. > Otherwise we had loads of artifacts and rendering issues of features that > relied on float textures with false precision. > > Kind Regards, > Max > > On 23 March 2017 at 01:19, Kenneth Russell wrote: > >> >> >> On Wed, Mar 22, 2017 at 10:48 AM, Maksims Mihejevs >> wrote: >> >>> We have experienced another issue. >>> >>> On one mobile platform it was advertised that Float 32 texture is >>> supported. And after actually testing it (because you have to test >>> regardless of what is advertised by extension), it did "worked". >>> But there was a weird catch: writing float 32 pixel, and then reading >>> it, it would loose precision. So even it worked, it actually was changed. >>> Either due to some emulation and repacking to different formats there was >>> some issues and data gets modified, or by some other bug, where we >>> literally missing some bytes or actual values are modified. >>> >>> Here is actual code for testing this in our engine: >>> https://github.com/playcanvas/engine/blob/master/src >>> /graphics/device.js#L739-L795 >>> This was a surprise for us and did lead to some time figuring out, what >>> is actually a problem. We were trying to implement Variance Shadow Maps >>> with float32 textures, and some data got modified breaking the feature only >>> on some devices. >>> >>> This is of course not acceptable at all, and renders feature unusable in >>> many scenarios where precision of data should persist. >>> >> >> Does this behavior persist in WebGL 2.0 if you use EXT_color_buffer_float >> and explicitly render to an FP32 texture, using highp precision variables >> in your shaders? I'm not sure what the guarantees were in older OpenGL ES >> versions, but since ES 3.0 provides exact control over textures' internal >> formats, I would expect this round-trip to be guaranteed. >> >> >> >> >>> >>> Cheers, >>> Max >>> >>> On 22 March 2017 at 17:12, Florian B?sch wrote: >>> >>>> Having looked supporting different formats for rendering to and >>>> sampling from, I'd like to share my observations. >>>> >>>> *Extensions are claimed that are not supported* >>>> >>>> On iOS the implementation claims to support OES_texture_float_linear >>>> but this does not actually work and it defaults (silently) to nearest. >>>> >>>> >> Could you please submit a conformance test verifying this behavior? >> >> >> >>> >>>> *Float16Array still does not exist* >>>> >>>> It's still a major pain to deal with generating data to upload to >>>> Half-Float textures because despite repeated prodding on the ECMA-ML as >>>> well as here, we *still* don't have a Float16Array. >>>> >>> >> Can't help with this. Sorry. >> >> >> *Some implementations do not accept Uint16Array upload to half-float >>>> textures* >>>> >>>> Safari and iOS refuse to accept an array for texImage2D to upload to >>>> half-float textures. Even though it's now in the specification that this is >>>> permissible. We talked about this. It was agreed we would allow that. >>>> >>> >> I confirm that Safari on macOS is failing https://www.khronos.or >> g/registry/webgl/sdk/tests/conformance/extensions/oes-textur >> e-half-float.html . Please confirm that it's failing on iOS and file a >> bug on bugs.webkit.org. >> >> >> *Setting linear blending mode on textures that don't support it generates >>>> no error* >>>> >>>> The UA complains about an unrenderable texture when you draw sampling >>>> from it, so it knows that the blending mode isn't supported. But you can't >>>> get an error from it either at texParameter or draw*. This is extremely >>>> awkward, because apparently (see above) the linear extensions have no >>>> meaning whatsoever, so you have to actually draw to figure out if blending >>>> works and then readback the results. If you (the UA) already knows that >>>> linear doesn't work, please don't make developers integrate a unit test to >>>> figure it out? >>>> >>> >> Please file an issue about this on https://github.com/KhronosGroup/WebGL >> . The browser vendors can discuss making this change. >> >> >> *The color_buffer extensions have no meaning* >>>> >>>> Platforms (such as Chrome) that support drawing to floating point >>>> textures do not expose these extensions, leaving you no choice but to >>>> getExtension it and then promptly ignore anything you got and test if you >>>> can actually construct an FBO that is indicated as valid and draw to it and >>>> then read the drawn texture (trough another FBO because see blow). >>>> >>> >> This behavior is much clarified and simpler in WebGL 2.0. There's only >> one extension: EXT_color_buffer_float, and it provides a strong guarantee >> about renderability without adding a lot of feature detection code to the >> WebGL implementation itself and impacting startup time of all WebGL apps. >> Please try WebGL 2.0. If you see issues in this area in that version then >> please file bugs. >> >> >> *readPixels of floats may or may not work* >>>> >>>> Some platforms do not implement readPixels from a floating point >>>> texture. Some do. Because of that, you can't directly test some of the more >>>> interesting properties of floating point textures (such as blending, >>>> filtering, clamping, etc.) but you have to do it trough a proxy unsigned >>>> byte FBO because you can't rely on readPixels. >>>> >>> >> This should again be much clarified in WebGL 2.0 and there should be >> strong guarantees about readPixels' behavior there. >> >> >> *Some devices do not expose floating point textures even though they >>>> support them* >>>> >>>> For reasons that completely boggle me, the fairly new Samsung S7 (just >>>> a year old) which has perfectly fine and working support for a variety of >>>> floating point textures/operations do not expose that to WebGL (by some >>>> combination of unlucky ES config and whatnot). That's a fairly big problem. >>>> Because samsung devices are fairly popular, it means floating point support >>>> on mobiles is actually retrograde, mean reverting slowly back to somewhere >>>> anno 2012 or so. >>>> >>> >> We just tested Chrome Dev on a Samsung Galaxy S7 Edge and it passes the >> render-to-RGBA-texture portion of https://www.khronos.org/reg >> istry/webgl/sdk/tests/conformance/extensions/oes-texture-float.html . >> (RGB textures are not renderable.) It also seems to support >> EXT_color_buffer_float for WebGL 2.0. If you have a scenario on a newer >> device like this where render-to-FP-texture is not working at all then >> please file a bug. >> >> If you're trying to save memory, then rendering to R32F and RG32F >> textures is available as of WebGL 2.0. >> >> >> The only qualifier I can find for the situation is miserable and utterly >>>> broken. It's hurting WebGL. It should be addressed. It should have been >>>> addressed long ago, and most of these things came up in the past years at >>>> one point or another. I don't understand why they are not addressed. >>>> >>> >> WebGL 2.0 should solve many longstanding issues with rendering to >> floating-point textures. It's supported in Firefox on Android now and will >> be in Chrome 58 on Android. Please help us make sure that these issues are >> addressed in the most recent version, and we can work on backporting some >> of the fixes to WebGL 1.0 + extensions. >> >> -Ken >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Mar 24 14:24:12 2017 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 24 Mar 2017 22:24:12 +0100 Subject: [Public WebGL] The miserable state of affairs of floating point support In-Reply-To: References: Message-ID: On Fri, Mar 24, 2017 at 10:06 PM, Kenneth Russell wrote: > > In Chrome it looks like the WebGL 1.0 extension OES_texture_half_float > isn't allowing these textures to be renderable. This looks like an accident > and I've filed http://crbug.com/705083 about it. Sorry about that. > Ah if there but was a way to indicate the optional renderability of floating point textures... https://www.khronos.org/registry/webgl/extensions/EXT_color_buffer_half_float/ :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From din...@ Fri Mar 24 17:16:05 2017 From: din...@ (Dean Jackson) Date: Sat, 25 Mar 2017 11:16:05 +1100 Subject: [Public WebGL] The miserable state of affairs of floating point support In-Reply-To: References: Message-ID: <82E037A1-7968-4940-8F62-8FCE4E7AC36D@apple.com> > On 23 Mar 2017, at 4:12 am, Florian B?sch wrote: > > Extensions are claimed that are not supported > > On iOS the implementation claims to support OES_texture_float_linear but this does not actually work and it defaults (silently) to nearest. Oops. I've filed https://bugs.webkit.org/show_bug.cgi?id=170088 Dean -------------- next part -------------- An HTML attachment was scrubbed... URL: From khr...@ Sat Mar 25 05:18:42 2017 From: khr...@ (Mark Callow) Date: Sat, 25 Mar 2017 21:18:42 +0900 Subject: [Public WebGL] The miserable state of affairs of floating point support In-Reply-To: References: Message-ID: <276A7006-A88A-4E8C-A0F2-EA84C3E4E091@callow.im> > On Mar 24, 2017, at 14:02, Gregg Tavares wrote: > > this is never going to be fixed for WebGL1 as it would break too much content. The whole issue was WebGL shipped for > year with OES_texture_float and the ability to use them as a framebuffer attachments before Mark Callow pointed out that was wrong and that we needed EXT_color_float_buffer. So it was added but the original method (make floating point texture, attach, check for FRAMEBUFFER_COMPLETE) was left. This is missing Florian?s point which, I think, is that if all browsers supported these extensions WebGL 1.0 apps would have an easy way to tell if {half_,}float rendering is supported or not. That browsers may continue to allow float rendering without enabling an extension, does not negate the validity of his point. 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 pya...@ Sat Mar 25 05:25:47 2017 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sat, 25 Mar 2017 13:25:47 +0100 Subject: [Public WebGL] The miserable state of affairs of floating point support In-Reply-To: <276A7006-A88A-4E8C-A0F2-EA84C3E4E091@callow.im> References: <276A7006-A88A-4E8C-A0F2-EA84C3E4E091@callow.im> Message-ID: On Sat, Mar 25, 2017 at 1:18 PM, Mark Callow wrote: > This is missing Florian?s point which, I think, is that if all browsers > supported these extensions WebGL 1.0 apps would have an easy way to tell if > {half_,}float rendering is supported or not. That browsers may continue to > allow float rendering without enabling an extension, does not negate the > validity of his point. > Thank you, that's exactly what I mean. -------------- next part -------------- An HTML attachment was scrubbed... URL: From khr...@ Sat Mar 25 20:20:36 2017 From: khr...@ (Mark Callow) Date: Sun, 26 Mar 2017 12:20:36 +0900 Subject: [Public WebGL] The miserable state of affairs of floating point support In-Reply-To: References: Message-ID: <8CF6F815-2965-4805-ABDE-A70C0657FBC7@callow.im> > On Mar 23, 2017, at 18:08, Florian B?sch wrote: > > > readPixels of floats may or may not work > > Some platforms do not implement readPixels from a floating point texture. Some do. Because of that, you can't directly test some of the more interesting properties of floating point textures (such as blending, filtering, clamping, etc.) but you have to do it trough a proxy unsigned byte FBO because you can't rely on readPixels. > > This should again be much clarified in WebGL 2.0 and there should be strong guarantees about readPixels' behavior there. > > The specification of color-buffer-float clearly specifies that area, it states that: "The format and type combination RGBA and FLOAT becomes valid for reading from a floating-point rendering buffer.? As Florian points out, the WebGL 1.0 extensions specs do make strong guarantees. The issue is that some UAs, most notably Chrome, do not support those extensions, for reasons that I can?t recall and am not sure I ever understood fully. As a result they have completely unspecified behavior when it comes to floating-point rendering, leaving developers like Florian grasping for ways to figure out what those UAs are doing. With unspecified behavior there can be no conformance tests, so it is not surprising if things like failure to support RGBA, FLOAT readPixels fall through the cracks. 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: