From jos...@ Tue Apr 4 17:23:30 2017 From: jos...@ (Joshua Groves) Date: Tue, 4 Apr 2017 18:23:30 -0600 Subject: [Public WebGL] The miserable state of affairs of floating point support In-Reply-To: References: Message-ID: Besides Float16Array, a related issue is the ability to efficiently create interleaved arrays without the use of a DataView or multiple TypedArrays that share an ArrayBuffer. I believe many people avoid the use of interleaved arrays in WebGL due to this complexity. It would be great if the "array of struct type" discussions could be revisited and other element types could be considered. On Fri, Mar 24, 2017 at 2:32 PM, Kenneth Russell wrote: > 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 pda...@ Tue Apr 11 07:16:28 2017 From: pda...@ (=?utf-8?Q?Patrick_D=C3=A4hne?=) Date: Tue, 11 Apr 2017 16:16:28 +0200 Subject: [Public WebGL] webgl-debug.js does not work with webgl2 contexts Message-ID: Hello WebGL community, I just realized that webgl-debug.js from the Khronos WebGL Developer Tools does not work with webgl2 contexts - it silently fails. Are there any plans to update webgl-debug.js to webgl2? Best regards, Patrick ----------------------------------------------------------- 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 Apr 12 14:55:38 2017 From: kbr...@ (Kenneth Russell) Date: Wed, 12 Apr 2017 14:55:38 -0700 Subject: [Public WebGL] webgl-debug.js does not work with webgl2 contexts In-Reply-To: References: Message-ID: Help's needed -- please file an issue on https://github.com/KhronosGroup/WebGLDeveloperTools and consider making a contribution. Thanks, -Ken On Tue, Apr 11, 2017 at 7:16 AM, Patrick D?hne wrote: > > Hello WebGL community, > > I just realized that webgl-debug.js from the Khronos WebGL Developer Tools > does not work with webgl2 contexts - it silently fails. Are there any plans > to update webgl-debug.js to webgl2? > > Best regards, > > Patrick > > > ----------------------------------------------------------- > 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 pda...@ Tue Apr 18 16:10:14 2017 From: pda...@ (=?utf-8?Q?Patrick_D=C3=A4hne?=) Date: Wed, 19 Apr 2017 01:10:14 +0200 Subject: [Public WebGL] webgl-debug.js does not work with webgl2 contexts In-Reply-To: References: Message-ID: Hello WebGL community, there is now full WebGL 2 support in webgl-debug.js. Thank you Ken for your support! Best regards, Patrick > Am 12.04.2017 um 23:55 schrieb Kenneth Russell : > > Help's needed -- please file an issue on https://github.com/KhronosGroup/WebGLDeveloperTools and consider making a contribution. > > Thanks, > > -Ken > > > On Tue, Apr 11, 2017 at 7:16 AM, Patrick D?hne wrote: > > Hello WebGL community, > > I just realized that webgl-debug.js from the Khronos WebGL Developer Tools does not work with webgl2 contexts - it silently fails. Are there any plans to update webgl-debug.js to webgl2? > > Best regards, > > Patrick ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Tue Apr 18 17:39:18 2017 From: kbr...@ (Kenneth Russell) Date: Tue, 18 Apr 2017 17:39:18 -0700 Subject: [Public WebGL] webgl-debug.js does not work with webgl2 contexts In-Reply-To: References: Message-ID: Thanks Patrick for adding this! Good to see the developer tools moving forward. -Ken On Tue, Apr 18, 2017 at 4:10 PM, Patrick D?hne wrote: > Hello WebGL community, > > there is now full WebGL 2 support in webgl-debug.js. Thank you Ken for > your support! > > Best regards, > > Patrick > > > > Am 12.04.2017 um 23:55 schrieb Kenneth Russell : > > > > Help's needed -- please file an issue on https://github.com/ > KhronosGroup/WebGLDeveloperTools and consider making a contribution. > > > > Thanks, > > > > -Ken > > > > > > On Tue, Apr 11, 2017 at 7:16 AM, Patrick D?hne > wrote: > > > > Hello WebGL community, > > > > I just realized that webgl-debug.js from the Khronos WebGL Developer > Tools does not work with webgl2 contexts - it silently fails. Are there any > plans to update webgl-debug.js to webgl2? > > > > Best regards, > > > > Patrick > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ib...@ Thu Apr 20 18:51:44 2017 From: ib...@ (Ib Green) Date: Thu, 20 Apr 2017 18:51:44 -0700 Subject: [Public WebGL] webgl-debug.js does not work with webgl2 contexts Message-ID: Hi Patrick, this is great news, thanks for doing this! As far as I can tell the update is only available on github, however we have been consuming this module through npm. Any chance you would be able to publish a new version on npm so that we can get access to the update that way? Thanks, Ib $ npm info webgl-debug { name: 'webgl-debug', time: { modified: '2016-05-20T11:15:28.040Z', created: '2016-05-20T11:02:35.367Z', '1.0.0': '2016-05-20T11:02:35.367Z', '1.0.1': '2016-05-20T11:10:02.920Z', '1.0.2': '2016-05-20T11:15:28.040Z' }, maintainers: [ 'vorg ' ], ... On Tue, Apr 18, 2017 at 4:10 PM, Patrick D?hne wrote: > > Hello WebGL community, > > there is now full WebGL 2 support in webgl-debug.js. Thank you Ken for > your support! > > Best regards, > > Patrick > > > > Am 12.04.2017 um 23:55 schrieb Kenneth Russell : > > > > Help's needed -- please file an issue on https://github.com/ > KhronosGroup/WebGLDeveloperTools and consider making a contribution. > > > > Thanks, > > > > -Ken > > > > > > On Tue, Apr 11, 2017 at 7:16 AM, Patrick D?hne > wrote: > > > > Hello WebGL community, > > > > I just realized that webgl-debug.js from the Khronos WebGL Developer > Tools does not work with webgl2 contexts - it silently fails. Are there any > plans to update webgl-debug.js to webgl2? > > > > Best regards, > > > > Patrick > > > ----------------------------------------------------------- > 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 pda...@ Fri Apr 21 04:19:27 2017 From: pda...@ (=?utf-8?Q?Patrick_D=C3=A4hne?=) Date: Fri, 21 Apr 2017 13:19:27 +0200 Subject: [Public WebGL] webgl-debug.js does not work with webgl2 contexts In-Reply-To: References: Message-ID: Hello Ib, sorry, as you already realized, the npm module is maintained neither by me nor Khronos, so there is nothing we can do. Hopefully the maintainer reacts to your issue report. Best regards, Patrick ----------------------------------------------------------- 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...@ Wed Apr 26 01:02:38 2017 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 26 Apr 2017 10:02:38 +0200 Subject: [Public WebGL] Some statistical oddities Message-ID: I was reviewing some statistics on WebGL Stats and came across some odd things. *Falling WebGL 1 support on Apple desktop machines in Chrome* WebGL 1 Support on OSX is faltering, but only on Chrome: http://webglstats.com/?platforms=000000000004000000 [image: Inline image 1] It's also in decline on MacOS: http://webglstats.com/?platforms=000000000000002000 [image: Inline image 3] Firefox doesn't have this issue OSX: http://webglstats.com/?platforms=000000008000000000 [image: Inline image 2] *WebGL 2 support level for a single UA on Windows seems low* Looking at the WebGL2 support levels I've noticed that for instance for Chrome on Windows it topped out at *69%* and has stayed that way for months; http://webglstats.com/?platforms=000002000000000000 [image: Inline image 4] The same is true for Firefox on Windows: http://webglstats.com/?platforms=000004000000000000 [image: Inline image 5] I'd be cool if UA vendors could enlighten us what's keeping WebGL2 support back there. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 22033 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 12498 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 23862 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 18455 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 25743 bytes Desc: not available URL: From cam...@ Wed Apr 26 02:28:30 2017 From: cam...@ (Cameron Yule) Date: Wed, 26 Apr 2017 10:28:30 +0100 Subject: [Public WebGL] Some statistical oddities In-Reply-To: References: Message-ID: Could the falling WebGL 1 support on Chrome on OS X be explained by GPU blacklisting? https://groups.google.com/a/chromium.org/d/topic/chromium-reviews/I6dL_9IAwiE/discussion On 26 April 2017 at 09:02, Florian B?sch wrote: > I was reviewing some statistics on WebGL Stats and > came across some odd things. > > *Falling WebGL 1 support on Apple desktop machines in Chrome* > > WebGL 1 Support on OSX is faltering, but only on Chrome: > http://webglstats.com/?platforms=000000000004000000 > > [image: Inline image 1] > > It's also in decline on MacOS: http://webglstats.com/? > platforms=000000000000002000 > > [image: Inline image 3] > > > Firefox doesn't have this issue OSX: http://webglstats.com/? > platforms=000000008000000000 > > [image: Inline image 2] > > > *WebGL 2 support level for a single UA on Windows seems low* > > Looking at the WebGL2 support levels I've noticed that for instance for > Chrome on Windows it topped out at *69%* and has stayed that way for > months; http://webglstats.com/?platforms=000002000000000000 > > [image: Inline image 4] > > The same is true for Firefox on Windows: http://webglstats.com/?platforms= > 000004000000000000 > > [image: Inline image 5] > > I'd be cool if UA vendors could enlighten us what's keeping WebGL2 support > back there. > > > -- +44(0)774 760 8776 https://cameronyule.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 23862 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 12498 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 18455 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 25743 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 22033 bytes Desc: not available URL: From pya...@ Thu Apr 27 23:38:43 2017 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 28 Apr 2017 06:38:43 +0000 Subject: [Public WebGL] POSSIBLE EMERGENCY: android chrome webgl 1 support collapsed to 50% for the 26th Message-ID: on webglstats there is a statistical unprecedented dip in daily data showing a collapse of webgl 1 to 50%. other platforms/UA show no anomalies, and visitor numbers are not out of the ordinary. it could be a problem of my site, i will analyze this issue later today. i thought an immediate headsup is warranted. it could be related to the april 25th android chrome release. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Apr 28 02:17:46 2017 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 28 Apr 2017 11:17:46 +0200 Subject: [Public WebGL] Re: POSSIBLE EMERGENCY: android chrome webgl 1 support collapsed to 50% for the 26th In-Reply-To: References: Message-ID: The daily data for the 27th shows a recovery of WebGL1 support to 64% for Chrome on Android, still very low compared to the previous watermark of 95%. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Fri Apr 28 15:50:18 2017 From: kbr...@ (Kenneth Russell) Date: Fri, 28 Apr 2017 15:50:18 -0700 Subject: [Public WebGL] Re: POSSIBLE EMERGENCY: android chrome webgl 1 support collapsed to 50% for the 26th In-Reply-To: References: Message-ID: Thanks for the heads up Florian. Chrome 58 was just promoted to Stable, so this may coincide with that release. I looked through https://cs.chromium.org/chromium/src/gpu/config/software_rendering_list.json and don't see any obvious changes that would have affected WebGL 1.0 support. On the other hand, some changes were made to that list in order to release WebGL 2.0 in Chrome 58. It's possible there is a side-effect. Looking through our internal histograms, I don't see an uptick in blacklisting of WebGL 1.0 support in Chrome 58, but it's possible I'm not querying the data correctly. Can we gather more data over a few days and see what happens? Do you have any more detailed information about the sort of phones (e.g. older low-end Android phones) that may be affected? Thanks, -Ken On Fri, Apr 28, 2017 at 2:17 AM, Florian B?sch wrote: > The daily data for the 27th shows a recovery of WebGL1 support to 64% for > Chrome on Android, still very low compared to the previous watermark of 95%. > -------------- next part -------------- An HTML attachment was scrubbed... URL: