From khr...@ Thu Mar 1 09:03:05 2018 From: khr...@ (Gregg Tavares) Date: Fri, 2 Mar 2018 02:03:05 +0900 Subject: [Public WebGL] Is WebGL2 Effectively Dead? Message-ID: Sorry for the controversial title but.... I just recently tried the latest version of the Safari Technology Preview. I enabled WebGL2 and tried a few very simple (spinning cube level) demos only to be very disappointed they didn't remotely work. Shaders of version 300 es are not supported which is kind of a non-starter. It's been over a year since Chrome and Firefox shipped WebGL2. Given that Apple now has this public tech preview and given there's effectively no WebGL2 support in it it's made me wonder if Apple has decided to never ship WebGL2 and concentrate only on WebGPU. Looking at webkit.org there is nearly zero public work happening on WebGL2 in Webkit and the WebGL2RenderingContext code is pretty sparse https://trac.webkit.org/search?q=WebGL2 https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/html/canvas/WebGL2RenderingContext.cpp I know that in general Apple doesn't announce what they are going to ship and when but it sure would be nice to at least know if they've decided they will likely never ship WebGL2 on which case devs will know iOS will never support WebGL2 and a large percentage of Safari using Mac users won't get WebGL2 either which would be helpful in making decisions about what to target. As it is, given the WebGL2 option appeared in the Safari Technology Preview a long time ago it seemed like an indication WebGL2 was going to happen but looking at the current signals it appears Apple is not going to ship WebGL2 ever. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Thu Mar 1 12:41:49 2018 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Thu, 1 Mar 2018 21:41:49 +0100 Subject: [Public WebGL] Is WebGL2 Effectively Dead? In-Reply-To: References: Message-ID: I too am disappointed with the state of WebGL2 support. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsc...@ Fri Mar 2 00:51:05 2018 From: jsc...@ (Johannes Schmid) Date: Fri, 2 Mar 2018 09:51:05 +0100 Subject: [Public WebGL] Is WebGL2 Effectively Dead? In-Reply-To: References: Message-ID: This would be very disappointing, please make it happen Apple (and Microsoft). People and companies working on 3D web solutions, like Esri, are counting on it. Joe On 01.03.2018 18:03, Gregg Tavares wrote: > Sorry for the controversial title but.... > > I just recently tried the latest version of the Safari Technology > Preview. I enabled WebGL2 and tried a few very simple (spinning cube > level) demos only to be very disappointed they didn't remotely work. > Shaders of version 300 es are not supported which is kind of a non-starter. > > It's been over a year since Chrome and Firefox shipped WebGL2. Given > that Apple now has this public tech preview and given there's > effectively no WebGL2 support in it it's made me wonder if Apple has > decided to never ship WebGL2 and concentrate only on WebGPU. > > Looking at webkit.org > > there is nearly zero public work happening on WebGL2 in Webkit and the > WebGL2RenderingContext code is pretty sparse > > https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.webkit.org_search-3Fq-3DWebGL2&d=DwICaQ&c=n6-cguzQvX_tUIrZOS_4Og&r=auoQGNsmLnZrqg32kllpVy1sEhZuGa0MskBkSeTAPWA&m=2tzvFvORBGX75RynBcYlSzB4nBsO5f8183Ayua2qQEc&s=xwfE28RPX8TKIEABeg6TmxcjM3tjEE-MTCFP9zzr-M4&e= > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.webkit.org_browser_webkit_trunk_Source_WebCore_html_canvas_WebGL2RenderingContext.cpp&d=DwICaQ&c=n6-cguzQvX_tUIrZOS_4Og&r=auoQGNsmLnZrqg32kllpVy1sEhZuGa0MskBkSeTAPWA&m=2tzvFvORBGX75RynBcYlSzB4nBsO5f8183Ayua2qQEc&s=QSTqv9zeaRg0ukzVNLH2EG6slIDVXW6XsmYJBMilIo4&e= > > > I know that in general Apple doesn't announce what they are going to > ship and when but it sure would be nice to at least know if they've > decided they will likely never ship WebGL2 on which case devs will know > iOS will never support WebGL2 and a large percentage of Safari using Mac > users won't get WebGL2 either which would be helpful in making decisions > about what to target. > > As it is, given the WebGL2 option appeared in the Safari Technology > Preview a long time ago it seemed like an indication WebGL2 was going to > happen but looking at the current signals it appears Apple is not going > to ship WebGL2 ever. > > ----------------------------------------------------------- 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 ale...@ Fri Mar 2 03:42:44 2018 From: ale...@ (Aleksandar Rodic) Date: Fri, 02 Mar 2018 11:42:44 +0000 Subject: [Public WebGL] Is WebGL2 Effectively Dead? In-Reply-To: References: Message-ID: Is there anything that we as a community can do to encourage Apple to make progress on WebGL2? On Fri, Mar 2, 2018 at 8:51 AM Johannes Schmid wrote: > > This would be very disappointing, please make it happen Apple (and > Microsoft). People and companies working on 3D web solutions, like Esri, > are counting on it. > > Joe > > > On 01.03.2018 18:03, Gregg Tavares wrote: > > Sorry for the controversial title but.... > > > > I just recently tried the latest version of the Safari Technology > > Preview. I enabled WebGL2 and tried a few very simple (spinning cube > > level) demos only to be very disappointed they didn't remotely work. > > Shaders of version 300 es are not supported which is kind of a > non-starter. > > > > It's been over a year since Chrome and Firefox shipped WebGL2. Given > > that Apple now has this public tech preview and given there's > > effectively no WebGL2 support in it it's made me wonder if Apple has > > decided to never ship WebGL2 and concentrate only on WebGPU. > > > > Looking at webkit.org > > < > https://urldefense.proofpoint.com/v2/url?u=http-3A__webkit.org&d=DwMFaQ&c=n6-cguzQvX_tUIrZOS_4Og&r=Ux-IP6GGs0zR9QFItJFFvA&m=i88vsSqVW7FGNHGWvOqt6P_hzIKb7KJ5Z_FY9IPT25c&s=vnzPhzhXdWLnTIb7vymdUtBica2PXHwUfw1RNVTreqc&e= > > > > there is nearly zero public work happening on WebGL2 in Webkit and the > > WebGL2RenderingContext code is pretty sparse > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.webkit.org_search-3Fq-3DWebGL2&d=DwICaQ&c=n6-cguzQvX_tUIrZOS_4Og&r=auoQGNsmLnZrqg32kllpVy1sEhZuGa0MskBkSeTAPWA&m=2tzvFvORBGX75RynBcYlSzB4nBsO5f8183Ayua2qQEc&s=xwfE28RPX8TKIEABeg6TmxcjM3tjEE-MTCFP9zzr-M4&e= > > < > https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.webkit.org_search-3Fq-3DWebGL2&d=DwMFaQ&c=n6-cguzQvX_tUIrZOS_4Og&r=Ux-IP6GGs0zR9QFItJFFvA&m=i88vsSqVW7FGNHGWvOqt6P_hzIKb7KJ5Z_FY9IPT25c&s=Ot27LRTH5hp2cJHKZs0Le90jLzwJQ1qqQ4q9M0_bOLI&e= > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.webkit.org_browser_webkit_trunk_Source_WebCore_html_canvas_WebGL2RenderingContext.cpp&d=DwICaQ&c=n6-cguzQvX_tUIrZOS_4Og&r=auoQGNsmLnZrqg32kllpVy1sEhZuGa0MskBkSeTAPWA&m=2tzvFvORBGX75RynBcYlSzB4nBsO5f8183Ayua2qQEc&s=QSTqv9zeaRg0ukzVNLH2EG6slIDVXW6XsmYJBMilIo4&e= > > < > https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.webkit.org_browser_webkit_trunk_Source_WebCore_html_canvas_WebGL2RenderingContext.cpp&d=DwMFaQ&c=n6-cguzQvX_tUIrZOS_4Og&r=Ux-IP6GGs0zR9QFItJFFvA&m=i88vsSqVW7FGNHGWvOqt6P_hzIKb7KJ5Z_FY9IPT25c&s=3QsrTilLhI-5V2GJsvh93gl1cRzLF-RvWEYB66YNHzM&e= > > > > > > I know that in general Apple doesn't announce what they are going to > > ship and when but it sure would be nice to at least know if they've > > decided they will likely never ship WebGL2 on which case devs will know > > iOS will never support WebGL2 and a large percentage of Safari using Mac > > users won't get WebGL2 either which would be helpful in making decisions > > about what to target. > > > > As it is, given the WebGL2 option appeared in the Safari Technology > > Preview a long time ago it seemed like an indication WebGL2 was going to > > happen but looking at the current signals it appears Apple is not going > > to ship WebGL2 ever. > > > > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Mon Mar 5 18:04:22 2018 From: kbr...@ (Ken Russell) Date: Mon, 5 Mar 2018 18:04:22 -0800 Subject: [Public WebGL] Is WebGL2 Effectively Dead? In-Reply-To: References: Message-ID: WebGL 2.0 is still alive and kicking. There has been steady ongoing work to shift the majority of the WebGL 2.0 implementation into the ANGLE library. It now contains a context creation option for WebGL 2.0 compatibility, above and beyond support for ES 3.0. This mode is now the default in Chrome on Windows and the Chrome team plans to use it on more platforms ? hopefully all. Another recent piece of news is that ANGLE now works on macOS, providing solid EGL, OpenGL ES 2.0, and ES 3.0 implementations on that platform. At this point, basically all that's needed to support WebGL 2.0 in Safari is to compile in ANGLE, and delegate all of the JavaScript function calls to ANGLE. -Ken On Thu, Mar 1, 2018 at 9:03 AM, Gregg Tavares wrote: > Sorry for the controversial title but.... > > I just recently tried the latest version of the Safari Technology Preview. > I enabled WebGL2 and tried a few very simple (spinning cube level) demos > only to be very disappointed they didn't remotely work. Shaders of version > 300 es are not supported which is kind of a non-starter. > > It's been over a year since Chrome and Firefox shipped WebGL2. Given that > Apple now has this public tech preview and given there's effectively no > WebGL2 support in it it's made me wonder if Apple has decided to never ship > WebGL2 and concentrate only on WebGPU. > > Looking at webkit.org there is nearly zero public work happening on > WebGL2 in Webkit and the WebGL2RenderingContext code is pretty sparse > > https://trac.webkit.org/search?q=WebGL2 > > https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/html/canvas/ > WebGL2RenderingContext.cpp > > I know that in general Apple doesn't announce what they are going to ship > and when but it sure would be nice to at least know if they've decided they > will likely never ship WebGL2 on which case devs will know iOS will never > support WebGL2 and a large percentage of Safari using Mac users won't get > WebGL2 either which would be helpful in making decisions about what to > target. > > As it is, given the WebGL2 option appeared in the Safari Technology > Preview a long time ago it seemed like an indication WebGL2 was going to > happen but looking at the current signals it appears Apple is not going to > ship WebGL2 ever. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From art...@ Tue Mar 6 09:02:46 2018 From: art...@ (Mr F) Date: Tue, 6 Mar 2018 17:02:46 +0000 Subject: [Public WebGL] Is WebGL2 Effectively Dead? In-Reply-To: References: Message-ID: By the way, found it a bit sad that WebGL 2 doesn't work on Chrome on out of the box Win 7. I know Win 7 is pretty old, but there is no problem in Firefox, only in Chrome. Seems Chrome requires some DX11.1 features for its multi-process approach, yet WebGL 2 itself doesn't require more than standard DX11. On 6 March 2018 at 02:04, Ken Russell wrote: > WebGL 2.0 is still alive and kicking. There has been steady ongoing work > to shift the majority of the WebGL 2.0 implementation into the ANGLE > library. It now contains a context creation option for WebGL 2.0 > compatibility, above and beyond support for ES 3.0. This mode is now the > default in Chrome on Windows and the Chrome team plans to use it on more > platforms ? hopefully all. > > Another recent piece of news is that ANGLE now works on macOS, providing > solid EGL, OpenGL ES 2.0, and ES 3.0 implementations on that platform. > > At this point, basically all that's needed to support WebGL 2.0 in Safari > is to compile in ANGLE, and delegate all of the JavaScript function calls > to ANGLE. > > -Ken > > > > On Thu, Mar 1, 2018 at 9:03 AM, Gregg Tavares > wrote: > >> Sorry for the controversial title but.... >> >> I just recently tried the latest version of the Safari Technology >> Preview. I enabled WebGL2 and tried a few very simple (spinning cube level) >> demos only to be very disappointed they didn't remotely work. Shaders of >> version 300 es are not supported which is kind of a non-starter. >> >> It's been over a year since Chrome and Firefox shipped WebGL2. Given that >> Apple now has this public tech preview and given there's effectively no >> WebGL2 support in it it's made me wonder if Apple has decided to never ship >> WebGL2 and concentrate only on WebGPU. >> >> Looking at webkit.org there is nearly zero public work happening on >> WebGL2 in Webkit and the WebGL2RenderingContext code is pretty sparse >> >> https://trac.webkit.org/search?q=WebGL2 >> >> https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/ >> html/canvas/WebGL2RenderingContext.cpp >> >> I know that in general Apple doesn't announce what they are going to ship >> and when but it sure would be nice to at least know if they've decided they >> will likely never ship WebGL2 on which case devs will know iOS will never >> support WebGL2 and a large percentage of Safari using Mac users won't get >> WebGL2 either which would be helpful in making decisions about what to >> target. >> >> As it is, given the WebGL2 option appeared in the Safari Technology >> Preview a long time ago it seemed like an indication WebGL2 was going to >> happen but looking at the current signals it appears Apple is not going to >> ship WebGL2 ever. >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From geo...@ Tue Mar 6 09:21:46 2018 From: geo...@ (Geoff Lang) Date: Tue, 06 Mar 2018 17:21:46 +0000 Subject: [Public WebGL] Is WebGL2 Effectively Dead? In-Reply-To: References: Message-ID: We require the "Windows 7 Platform Update (KB2670838)" which adds DXGI 1.2 in order to initialize D3D11 at all on Windows 7. It's the only way to use D3D11 with Chrome's multi-process architecture. On Tue, Mar 6, 2018 at 12:03 PM Mr F wrote: > By the way, found it a bit sad that WebGL 2 doesn't work on Chrome on out > of the box Win 7. I know Win 7 is pretty old, but there is no problem in > Firefox, only in Chrome. Seems Chrome requires some DX11.1 features for its > multi-process approach, yet WebGL 2 itself doesn't require more than > standard DX11. > > On 6 March 2018 at 02:04, Ken Russell wrote: > >> WebGL 2.0 is still alive and kicking. There has been steady ongoing work >> to shift the majority of the WebGL 2.0 implementation into the ANGLE >> library. It now contains a context creation option for WebGL 2.0 >> compatibility, above and beyond support for ES 3.0. This mode is now the >> default in Chrome on Windows and the Chrome team plans to use it on more >> platforms ? hopefully all. >> >> Another recent piece of news is that ANGLE now works on macOS, providing >> solid EGL, OpenGL ES 2.0, and ES 3.0 implementations on that platform. >> >> At this point, basically all that's needed to support WebGL 2.0 in Safari >> is to compile in ANGLE, and delegate all of the JavaScript function calls >> to ANGLE. >> >> -Ken >> >> >> >> On Thu, Mar 1, 2018 at 9:03 AM, Gregg Tavares >> wrote: >> >>> Sorry for the controversial title but.... >>> >>> I just recently tried the latest version of the Safari Technology >>> Preview. I enabled WebGL2 and tried a few very simple (spinning cube level) >>> demos only to be very disappointed they didn't remotely work. Shaders of >>> version 300 es are not supported which is kind of a non-starter. >>> >>> It's been over a year since Chrome and Firefox shipped WebGL2. Given >>> that Apple now has this public tech preview and given there's effectively >>> no WebGL2 support in it it's made me wonder if Apple has decided to never >>> ship WebGL2 and concentrate only on WebGPU. >>> >>> Looking at webkit.org there is nearly zero public work happening on >>> WebGL2 in Webkit and the WebGL2RenderingContext code is pretty sparse >>> >>> https://trac.webkit.org/search?q=WebGL2 >>> >>> >>> https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/html/canvas/WebGL2RenderingContext.cpp >>> >>> I know that in general Apple doesn't announce what they are going to >>> ship and when but it sure would be nice to at least know if they've decided >>> they will likely never ship WebGL2 on which case devs will know iOS will >>> never support WebGL2 and a large percentage of Safari using Mac users won't >>> get WebGL2 either which would be helpful in making decisions about what to >>> target. >>> >>> As it is, given the WebGL2 option appeared in the Safari Technology >>> Preview a long time ago it seemed like an indication WebGL2 was going to >>> happen but looking at the current signals it appears Apple is not going to >>> ship WebGL2 ever. >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Mar 7 01:46:17 2018 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 7 Mar 2018 10:46:17 +0100 Subject: [Public WebGL] Is WebGL2 Effectively Dead? In-Reply-To: References: Message-ID: Some platforms that have a disproportional big impact on the unavailability of WebGL2 are: - Windows: 70% support on browsers that support WebGL2 (because desktops make 30% of visitors and windows makes 80% of desktops) - Android: 65% support on browsers that support WebLG2 (because smartphones make 65% of visitors and Android makes 66% of smartphones) The primary problem with these platforms isn't that WebGL isn't implemented by most browsers (IE+Edge only hold about 15% of desktop browsers, and legacy android browsers hold some 25%). It's that for some reason or other those WebGL 2 capable browsers do not expose WebGL 2 on some devices. In both cases support is slowly increasing at a rate between 1-3%/month (a little less on windows, a bit more on android). At these rates it can be expected for WebGL2 to reach WebGL1 levels of support (98%): - Windows: June 2019 to September 2020 - Android: February 2019 to August 2019 Although this is based on biased data, I don't think the bias is terribly relevant when talking about the end-state of near 100% support (i.e. it doesn't matter if you estimate support to be low and increasing quickly, or high and increasing slowly, you'll both reach 100% at about the same time). On Tue, Mar 6, 2018 at 6:21 PM, Geoff Lang wrote: > We require the "Windows 7 Platform Update (KB2670838)" which adds DXGI 1.2 > in order to initialize D3D11 at all on Windows 7. It's the only way to use > D3D11 with Chrome's multi-process architecture. > > On Tue, Mar 6, 2018 at 12:03 PM Mr F wrote: > >> By the way, found it a bit sad that WebGL 2 doesn't work on Chrome on out >> of the box Win 7. I know Win 7 is pretty old, but there is no problem in >> Firefox, only in Chrome. Seems Chrome requires some DX11.1 features for its >> multi-process approach, yet WebGL 2 itself doesn't require more than >> standard DX11. >> >> On 6 March 2018 at 02:04, Ken Russell wrote: >> >>> WebGL 2.0 is still alive and kicking. There has been steady ongoing work >>> to shift the majority of the WebGL 2.0 implementation into the ANGLE >>> library. It now contains a context creation option for WebGL 2.0 >>> compatibility, above and beyond support for ES 3.0. This mode is now the >>> default in Chrome on Windows and the Chrome team plans to use it on more >>> platforms ? hopefully all. >>> >>> Another recent piece of news is that ANGLE now works on macOS, providing >>> solid EGL, OpenGL ES 2.0, and ES 3.0 implementations on that platform. >>> >>> At this point, basically all that's needed to support WebGL 2.0 in >>> Safari is to compile in ANGLE, and delegate all of the JavaScript function >>> calls to ANGLE. >>> >>> -Ken >>> >>> >>> >>> On Thu, Mar 1, 2018 at 9:03 AM, Gregg Tavares >>> wrote: >>> >>>> Sorry for the controversial title but.... >>>> >>>> I just recently tried the latest version of the Safari Technology >>>> Preview. I enabled WebGL2 and tried a few very simple (spinning cube level) >>>> demos only to be very disappointed they didn't remotely work. Shaders of >>>> version 300 es are not supported which is kind of a non-starter. >>>> >>>> It's been over a year since Chrome and Firefox shipped WebGL2. Given >>>> that Apple now has this public tech preview and given there's effectively >>>> no WebGL2 support in it it's made me wonder if Apple has decided to never >>>> ship WebGL2 and concentrate only on WebGPU. >>>> >>>> Looking at webkit.org there is nearly zero public work happening on >>>> WebGL2 in Webkit and the WebGL2RenderingContext code is pretty sparse >>>> >>>> https://trac.webkit.org/search?q=WebGL2 >>>> >>>> https://trac.webkit.org/browser/webkit/trunk/Source/ >>>> WebCore/html/canvas/WebGL2RenderingContext.cpp >>>> >>>> I know that in general Apple doesn't announce what they are going to >>>> ship and when but it sure would be nice to at least know if they've decided >>>> they will likely never ship WebGL2 on which case devs will know iOS will >>>> never support WebGL2 and a large percentage of Safari using Mac users won't >>>> get WebGL2 either which would be helpful in making decisions about what to >>>> target. >>>> >>>> As it is, given the WebGL2 option appeared in the Safari Technology >>>> Preview a long time ago it seemed like an indication WebGL2 was going to >>>> happen but looking at the current signals it appears Apple is not going to >>>> ship WebGL2 ever. >>>> >>>> >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Thu Mar 8 02:21:48 2018 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Thu, 8 Mar 2018 11:21:48 +0100 Subject: [Public WebGL] Is WebGL2 Effectively Dead? In-Reply-To: References: Message-ID: On Wed, Mar 7, 2018 at 7:42 PM, Nicolas Capens wrote: > It's not a mystery. 36% of mobile devices > running > Android don't support OpenGL ES 3.0. > Since most people replace their mobile every 2 years or so, it would be interesting to know why more than a third of handsets more than 6 years after the introduction of a new standard (7 if you count the first draft, 8 if you count first planning phase), are not compatible with that industrywide standard. > Similarly, the desktop and laptop GPU market has been dominated by > integrated GPUs for the last decade, and a large chunk of them have issues > that require blacklisting WebGL 2 support. > Similarly it would be interesting to know why Intel is selling garbage hardware en-masse (and continues to do so). Surely getting the kinks out of its hardware before production/shipping should be a reasonable expectation. Let alone do it at least once in more than 10 years... They're not helping anybodies bottom line by shipping bugged garbage hardware (not their own, and not anybody who writes applications for them). Need I remind anybody of the fact that this is not acceptable? Imagine if you will if there was 3 or 4 different brands of CPUs, each of which required application developers to write a different application for them, and each generation of each brand shipping with different bugs necessitating each application developer to tailor their application best they can around the bugs of those CPUs and if they can't, ruefully inform users of said hardware (of which they have no idea which they have) that for reasons beyond their control their application will not function with their hardware. Imagine if the google play store, ios app-store, windows store etc. needed to check for each application for each cpu if it actually could give you that application. Imagine the frustration that users would have trying to obtain any application. Why exactly is it this should be acceptable for GPUs? What do you expect to gain from screwing things up this badly that writing applications for GPUs is basically an exercise in futility, in the year 2018?! Surely you must realize that there's something very, very wrong here. > In both cases support is slowly increasing at a rate between 1-3%/month (a >> little less on windows, a bit more on android). At these rates it can be >> expected for WebGL2 to reach WebGL1 levels of support (98%): >> >> - Windows: June 2019 to September 2020 >> - Android: February 2019 to August 2019 >> >> That would actually be phenomenally soon. Since the issue is GPU > hardware, and the prevalence of each generation follows an S-curve, we're > going to have a long tail before ~98% of support is reached. > I'm aware that it's an S-curve, I'm just hoping that the part that takes us most of the way is reasonably flat. > That said, SwiftShader > has recently reached the milestone of passing the dEQP test suite for > OpenGL ES 3.0, running entirely on the CPU, and we're making quick progress > on WebGL 2 conformance. So for the needs of casual games and educational > content we could have broad support much sooner. > As nice as that is technically, and congratulations on that achievement, for application developers it's very near useless. Spanning a performance gap of nearly 100:1 between high end desktops and low-end (but functioning) mobile GPUs is already pretty challenging. Spanning a performance gap of 1000000:1 or thereabouts is just about futile. -------------- next part -------------- An HTML attachment was scrubbed... URL: From khr...@ Thu Mar 8 16:41:55 2018 From: khr...@ (Mark Callow) Date: Fri, 9 Mar 2018 09:41:55 +0900 Subject: [Public WebGL] Is WebGL2 Effectively Dead? In-Reply-To: References: Message-ID: <222FB090-8562-458F-AC05-312005D0529E@callow.im> > On Mar 8, 2018, at 19:21, Florian B?sch wrote: > > On Wed, Mar 7, 2018 at 7:42 PM, Nicolas Capens > wrote: > It's not a mystery. 36% of mobile devices running Android don't support OpenGL ES 3.0. > > Since most people replace their mobile every 2 years or so, it would be interesting to know why more than a third of handsets more than 6 years after the introduction of a new standard (7 if you count the first draft, 8 if you count first planning phase), are not compatible with that industrywide standard. I don?t. But on the other hand the Android mobile I purchased just over 5 years ago supports OpenGL ES 3.0. > > > Similarly, the desktop and laptop GPU market has been dominated by integrated GPUs for the last decade, and a large chunk of them have issues that require blacklisting WebGL 2 support. > > Similarly it would be interesting to know why Intel is selling garbage hardware en-masse (and continues to do so). ? rest of rant deleted for brevity ... I don?t know anything about why WebGL apparently needs to be blacklisted on a large chunk of integrated GPUs. I do know that Intel has been regularly making successful OpenGL and Vulkan CTS (Conformance Test) submissions for several years now. I also know that on the laptop I purchased 3 years ago with Intel HD 5000 graphics I could use OpenGL 4.3 out of the box in Windows and both it and Vulkan in Linux without issues. Since the days of the GMA950(?) the quality of Intel's drivers has greatly increased. I think ?continues to do so? (sell "garbage hardware?) is not a true reflection of the current state. My only complaint about Intel is that their Windows team refuses to support Vulkan on quite a few devices that are clearly capable of it, c/f the HD 5000. 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: 528 bytes Desc: Message signed with OpenPGP URL: From pya...@ Thu Mar 8 23:58:14 2018 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 9 Mar 2018 08:58:14 +0100 Subject: [Public WebGL] Is WebGL2 Effectively Dead? In-Reply-To: <222FB090-8562-458F-AC05-312005D0529E@callow.im> References: <222FB090-8562-458F-AC05-312005D0529E@callow.im> Message-ID: On Fri, Mar 9, 2018 at 1:41 AM, Mark Callow wrote: > I don?t know anything about why WebGL apparently needs to be blacklisted > on a large chunk of integrated GPUs. > It's because of the myriad of exotic bugs that exist, that are corner cases until your software runs into them. Since WebGL has an extensive conformance test suite, and since we set a high bar of expectation of "things working" on the web, it means that for exotic bugs which you might not exercise in your application (but somebody does), you'll get it blacklisted. It's not an unreasonable approach to dealing with things that are fundamentally broken. The question though is why a 14-16 year old trimmed down standard is the only thing that you can even remotely describe as universally working. There's some parallels with that to x86, but unlike x86 new machine features (and by that I mean machines over a decade old) are inaccessible to that standard. That's a pretty bad thing for application developers and GPU makers, because GPU makers pour all that money into developing fancier machines, and application developers are desperate to use new machine features, but use of these features is largely relegated to the margins for more than a decade. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Mar 9 00:03:10 2018 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 9 Mar 2018 09:03:10 +0100 Subject: [Public WebGL] Is WebGL2 Effectively Dead? In-Reply-To: References: <222FB090-8562-458F-AC05-312005D0529E@callow.im> Message-ID: The way I see it is, we're basically on the brink of failing to deliver on hardware accelerated rendering. The most popularly sold "GPUs" today are slow, unreliable, bugridden and feature poor. While the platforms that offer more see declining sales year to year. Before long we'll find there's no modern hardware left to rely on and we've jumped back 10-20 years in hardware development. On Fri, Mar 9, 2018 at 8:58 AM, Florian B?sch wrote: > On Fri, Mar 9, 2018 at 1:41 AM, Mark Callow wrote: > >> I don?t know anything about why WebGL apparently needs to be blacklisted >> on a large chunk of integrated GPUs. >> > It's because of the myriad of exotic bugs that exist, that are corner > cases until your software runs into them. Since WebGL has an extensive > conformance test suite, and since we set a high bar of expectation of > "things working" on the web, it means that for exotic bugs which you might > not exercise in your application (but somebody does), you'll get it > blacklisted. It's not an unreasonable approach to dealing with things that > are fundamentally broken. > > The question though is why a 14-16 year old trimmed down standard is the > only thing that you can even remotely describe as universally working. > There's some parallels with that to x86, but unlike x86 new machine > features (and by that I mean machines over a decade old) are inaccessible > to that standard. That's a pretty bad thing for application developers and > GPU makers, because GPU makers pour all that money into developing fancier > machines, and application developers are desperate to use new machine > features, but use of these features is largely relegated to the margins for > more than a decade. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From khr...@ Sun Mar 11 00:38:51 2018 From: khr...@ (Mark Callow) Date: Sun, 11 Mar 2018 17:38:51 +0900 Subject: [Public WebGL] Is WebGL2 Effectively Dead? In-Reply-To: References: <222FB090-8562-458F-AC05-312005D0529E@callow.im> Message-ID: <4197800C-F40E-4EFB-9D09-8A921319C7C1@callow.im> > On Mar 9, 2018, at 16:58, Florian B?sch wrote: > > It's because of the myriad of exotic bugs that exist, that are corner cases until your software runs into them. Since WebGL has an extensive conformance test suite, and since we set a high bar of expectation of "things working" on the web, it means that for exotic bugs which you might not exercise in your application (but somebody does), you'll get it blacklisted. It's not an unreasonable approach to dealing with things that are fundamentally broken. As well the OpenGL conformance test submissions I mentioned, Intel has also been heavily involved in improving the WebGL conformance tests and making sure their GPUs pass them. So with respect to at least Intel?s integrated GPUs, I think you are talking ancient history. BtW I have no connection whatsoever with Intel beyond knowing a couple of people who work there. 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: 528 bytes Desc: Message signed with OpenPGP URL: From pya...@ Sun Mar 11 01:38:29 2018 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 11 Mar 2018 10:38:29 +0100 Subject: [Public WebGL] Is WebGL2 Effectively Dead? In-Reply-To: <4197800C-F40E-4EFB-9D09-8A921319C7C1@callow.im> References: <222FB090-8562-458F-AC05-312005D0529E@callow.im> <4197800C-F40E-4EFB-9D09-8A921319C7C1@callow.im> Message-ID: On Sun, Mar 11, 2018 at 9:38 AM, Mark Callow wrote: > > Intel has also been *heavily* involved in improving the WebGL conformance > tests and making sure their GPUs pass them. > I'm aware that they're at least trying to improve the stuff they newly release. The problem is though that you can buy brand-new machines with integrated GPUs half a decade old and they aren't going back, recalling stocks of defective product or upgrading it to something that's not bugged. It takes forever and ever to get the bad chipsets out of circulation that way. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sun Mar 11 01:40:02 2018 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 11 Mar 2018 10:40:02 +0100 Subject: [Public WebGL] Is WebGL2 Effectively Dead? In-Reply-To: References: <222FB090-8562-458F-AC05-312005D0529E@callow.im> <4197800C-F40E-4EFB-9D09-8A921319C7C1@callow.im> Message-ID: Mind many of these stocks that aren't selling well anymore in first-world economies, are now being offloaded to developing economies at bargain prices, creating a newly minted population of hardware acceleration disadvantaged in those economies. On Sun, Mar 11, 2018 at 10:38 AM, Florian B?sch wrote: > On Sun, Mar 11, 2018 at 9:38 AM, Mark Callow wrote: >> >> Intel has also been *heavily* involved in improving the WebGL >> conformance tests and making sure their GPUs pass them. >> > > I'm aware that they're at least trying to improve the stuff they newly > release. The problem is though that you can buy brand-new machines with > integrated GPUs half a decade old and they aren't going back, recalling > stocks of defective product or upgrading it to something that's not bugged. > It takes forever and ever to get the bad chipsets out of circulation that > way. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsh...@ Tue Mar 20 12:25:01 2018 From: tsh...@ (Tarek Sherif) Date: Tue, 20 Mar 2018 15:25:01 -0400 Subject: [Public WebGL] EXT_disjoint_timer_query disabled Message-ID: Hi all, I noticed in Chrome 65 and Firefox 59 today that EXT_disjoint_timer_query is disabled. In chrome://gpu on both Linux and Mac I found the rather cryptic message: "Don't expose disjoint_timer_query extensions to WebGL: 808744" with a link to a private Chromium ticket. I enabled WebGL draft extensions in chrome://flags, but that didn't change anything. I'm guessing there's a security issue involved, but I'm curious if this is change is being treated as permanent, or if there's some hope of seeing the extension re-enabled later. Losing EXT_disjoint_timer_query would be a substantial blow to WebGL as a platform. If it has to be disabled for general use, could it at least be hidden behind a flag so it could still be used for local development? Tarek Sherif http://tareksherif.net/ https://www.biodigital.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue Mar 20 12:45:25 2018 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Tue, 20 Mar 2018 20:45:25 +0100 Subject: [Public WebGL] EXT_disjoint_timer_query disabled In-Reply-To: References: Message-ID: It's a disgrace that we have to fight nail, tooth and claw to retain any kind of ability to measure the performance we can attain with our own code. On Tue, Mar 20, 2018 at 8:25 PM, Tarek Sherif wrote: > Hi all, > > I noticed in Chrome 65 and Firefox 59 today that EXT_disjoint_timer_query > is disabled. In chrome://gpu on both Linux and Mac I found the rather > cryptic message: "Don't expose disjoint_timer_query extensions to WebGL: > 808744" with a link to a private Chromium ticket. I enabled WebGL draft > extensions in chrome://flags, but that didn't change anything. > > I'm guessing there's a security issue involved, but I'm curious if this is > change is being treated as permanent, or if there's some hope of seeing the > extension re-enabled later. Losing EXT_disjoint_timer_query would be a > substantial blow to WebGL as a platform. If it has to be disabled for > general use, could it at least be hidden behind a flag so it could still be > used for local development? > > Tarek Sherif > http://tareksherif.net/ > https://www.biodigital.com/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Tue Mar 20 13:31:23 2018 From: jgi...@ (Jeff Gilbert) Date: Tue, 20 Mar 2018 13:31:23 -0700 Subject: [Public WebGL] EXT_disjoint_timer_query disabled In-Reply-To: References: Message-ID: You can re-enable it for local development in Firefox by setting webgl.enable-privileged-extensions:true. On Tue, Mar 20, 2018 at 12:45 PM, Florian B?sch wrote: > It's a disgrace that we have to fight nail, tooth and claw to retain any > kind of ability to measure the performance we can attain with our own code. > > On Tue, Mar 20, 2018 at 8:25 PM, Tarek Sherif wrote: >> >> Hi all, >> >> I noticed in Chrome 65 and Firefox 59 today that EXT_disjoint_timer_query >> is disabled. In chrome://gpu on both Linux and Mac I found the rather >> cryptic message: "Don't expose disjoint_timer_query extensions to WebGL: >> 808744" with a link to a private Chromium ticket. I enabled WebGL draft >> extensions in chrome://flags, but that didn't change anything. >> >> I'm guessing there's a security issue involved, but I'm curious if this is >> change is being treated as permanent, or if there's some hope of seeing the >> extension re-enabled later. Losing EXT_disjoint_timer_query would be a >> substantial blow to WebGL as a platform. If it has to be disabled for >> general use, could it at least be hidden behind a flag so it could still be >> used for local development? >> >> Tarek Sherif >> http://tareksherif.net/ >> https://www.biodigital.com/ >> > ----------------------------------------------------------- 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 Mar 20 13:39:19 2018 From: kbr...@ (Ken Russell) Date: Tue, 20 Mar 2018 20:39:19 +0000 Subject: [Public WebGL] EXT_disjoint_timer_query disabled In-Reply-To: References: Message-ID: A high-priority issue recently came in which necessitated disabling this extension temporarily. More details will be forthcoming, but we can't share them yet. In Chrome we don't yet have a way to re-enable this extension easily (aside from --ignore-gpu-blacklist ) but we'll work on adding one in http://crbug.com/823863 . -Ken On Tue, Mar 20, 2018 at 1:32 PM Jeff Gilbert wrote: > > You can re-enable it for local development in Firefox by setting > webgl.enable-privileged-extensions:true. > > On Tue, Mar 20, 2018 at 12:45 PM, Florian B?sch wrote: > > It's a disgrace that we have to fight nail, tooth and claw to retain any > > kind of ability to measure the performance we can attain with our own > code. > > > > On Tue, Mar 20, 2018 at 8:25 PM, Tarek Sherif wrote: > >> > >> Hi all, > >> > >> I noticed in Chrome 65 and Firefox 59 today that > EXT_disjoint_timer_query > >> is disabled. In chrome://gpu on both Linux and Mac I found the rather > >> cryptic message: "Don't expose disjoint_timer_query extensions to WebGL: > >> 808744" with a link to a private Chromium ticket. I enabled WebGL draft > >> extensions in chrome://flags, but that didn't change anything. > >> > >> I'm guessing there's a security issue involved, but I'm curious if this > is > >> change is being treated as permanent, or if there's some hope of seeing > the > >> extension re-enabled later. Losing EXT_disjoint_timer_query would be a > >> substantial blow to WebGL as a platform. If it has to be disabled for > >> general use, could it at least be hidden behind a flag so it could > still be > >> used for local development? > >> > >> Tarek Sherif > >> http://tareksherif.net/ > >> https://www.biodigital.com/ > >> > > > > ----------------------------------------------------------- > 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 tsh...@ Tue Mar 20 15:38:55 2018 From: tsh...@ (Tarek Sherif) Date: Tue, 20 Mar 2018 18:38:55 -0400 Subject: [Public WebGL] EXT_disjoint_timer_query disabled In-Reply-To: References: Message-ID: Thanks, Jeff. That will do for my current needs. Ken, --ignore-gpu-blacklist doesn't seem to help. Tarek Sherif http://tareksherif.net/ https://www.biodigital.com/ On Tue, Mar 20, 2018 at 4:39 PM, Ken Russell wrote: > A high-priority issue recently came in which necessitated disabling this > extension temporarily. More details will be forthcoming, but we can't share > them yet. > > In Chrome we don't yet have a way to re-enable this extension easily > (aside from --ignore-gpu-blacklist ) but we'll work on adding one in > http://crbug.com/823863 . > > -Ken > > > > On Tue, Mar 20, 2018 at 1:32 PM Jeff Gilbert wrote: > >> >> You can re-enable it for local development in Firefox by setting >> webgl.enable-privileged-extensions:true. >> >> On Tue, Mar 20, 2018 at 12:45 PM, Florian B?sch wrote: >> > It's a disgrace that we have to fight nail, tooth and claw to retain any >> > kind of ability to measure the performance we can attain with our own >> code. >> > >> > On Tue, Mar 20, 2018 at 8:25 PM, Tarek Sherif >> wrote: >> >> >> >> Hi all, >> >> >> >> I noticed in Chrome 65 and Firefox 59 today that >> EXT_disjoint_timer_query >> >> is disabled. In chrome://gpu on both Linux and Mac I found the rather >> >> cryptic message: "Don't expose disjoint_timer_query extensions to >> WebGL: >> >> 808744" with a link to a private Chromium ticket. I enabled WebGL draft >> >> extensions in chrome://flags, but that didn't change anything. >> >> >> >> I'm guessing there's a security issue involved, but I'm curious if >> this is >> >> change is being treated as permanent, or if there's some hope of >> seeing the >> >> extension re-enabled later. Losing EXT_disjoint_timer_query would be a >> >> substantial blow to WebGL as a platform. If it has to be disabled for >> >> general use, could it at least be hidden behind a flag so it could >> still be >> >> used for local development? >> >> >> >> Tarek Sherif >> >> http://tareksherif.net/ >> >> https://www.biodigital.com/ >> >> >> > >> >> ----------------------------------------------------------- >> 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 tsh...@ Thu Mar 22 05:50:27 2018 From: tsh...@ (Tarek Sherif) Date: Thu, 22 Mar 2018 08:50:27 -0400 Subject: [Public WebGL] EXT_disjoint_timer_query disabled In-Reply-To: References: Message-ID: Jeff, Ken, since you said it's temporary, any sense of a timeline for when we can expect to see it working again? Tarek Sherif http://tareksherif.net/ https://www.biodigital.com/ On Tue, Mar 20, 2018 at 6:38 PM, Tarek Sherif wrote: > Thanks, Jeff. That will do for my current needs. > > Ken, --ignore-gpu-blacklist doesn't seem to help. > > Tarek Sherif > http://tareksherif.net/ > https://www.biodigital.com/ > > > On Tue, Mar 20, 2018 at 4:39 PM, Ken Russell wrote: > >> A high-priority issue recently came in which necessitated disabling this >> extension temporarily. More details will be forthcoming, but we can't share >> them yet. >> >> In Chrome we don't yet have a way to re-enable this extension easily >> (aside from --ignore-gpu-blacklist ) but we'll work on adding one in >> http://crbug.com/823863 . >> >> -Ken >> >> >> >> On Tue, Mar 20, 2018 at 1:32 PM Jeff Gilbert >> wrote: >> >>> >>> You can re-enable it for local development in Firefox by setting >>> webgl.enable-privileged-extensions:true. >>> >>> On Tue, Mar 20, 2018 at 12:45 PM, Florian B?sch >>> wrote: >>> > It's a disgrace that we have to fight nail, tooth and claw to retain >>> any >>> > kind of ability to measure the performance we can attain with our own >>> code. >>> > >>> > On Tue, Mar 20, 2018 at 8:25 PM, Tarek Sherif >>> wrote: >>> >> >>> >> Hi all, >>> >> >>> >> I noticed in Chrome 65 and Firefox 59 today that >>> EXT_disjoint_timer_query >>> >> is disabled. In chrome://gpu on both Linux and Mac I found the rather >>> >> cryptic message: "Don't expose disjoint_timer_query extensions to >>> WebGL: >>> >> 808744" with a link to a private Chromium ticket. I enabled WebGL >>> draft >>> >> extensions in chrome://flags, but that didn't change anything. >>> >> >>> >> I'm guessing there's a security issue involved, but I'm curious if >>> this is >>> >> change is being treated as permanent, or if there's some hope of >>> seeing the >>> >> extension re-enabled later. Losing EXT_disjoint_timer_query would be a >>> >> substantial blow to WebGL as a platform. If it has to be disabled for >>> >> general use, could it at least be hidden behind a flag so it could >>> still be >>> >> used for local development? >>> >> >>> >> Tarek Sherif >>> >> http://tareksherif.net/ >>> >> https://www.biodigital.com/ >>> >> >>> > >>> >>> ----------------------------------------------------------- >>> 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...@ Sat Mar 24 05:05:20 2018 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sat, 24 Mar 2018 13:05:20 +0100 Subject: [Public WebGL] EXT_disjoint_timer_query disabled In-Reply-To: References: Message-ID: On Thu, Mar 22, 2018 at 1:50 PM, Tarek Sherif wrote: > when we can expect to see it working again? > When can we expect to see it working again? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Mon Mar 26 12:41:02 2018 From: jgi...@ (Jeff Gilbert) Date: Mon, 26 Mar 2018 12:41:02 -0700 Subject: [Public WebGL] EXT_disjoint_timer_query disabled In-Reply-To: References: Message-ID: That's TBD but we're looking into it. On Sat, Mar 24, 2018 at 5:05 AM, Florian B?sch wrote: > On Thu, Mar 22, 2018 at 1:50 PM, Tarek Sherif wrote: >> >> when we can expect to see it working again? > > > When can we expect to see it working again? ----------------------------------------------------------- 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 -----------------------------------------------------------