From art...@ Thu Dec 1 03:15:11 2016 From: art...@ (Mr F) Date: Thu, 1 Dec 2016 14:15:11 +0300 Subject: [Public WebGL] Support precompiled shaders as extensions In-Reply-To: References: <0456a52b1474b03c6bbf402cba013a5b.squirrel@sjbaker.org> <9A74453A5B48464BA12E7CD59327A713@gmail.com> Message-ID: This is very cool, Jamie! On 30 November 2016 at 22:27, Jamie Madill wrote: > Good news, initial prototype for internally parallel compiling shaders has > landed for D3D/ANGLE. It should be available in tomorrow's Canary, and make > it's way to stable in the next few months (assuming no reverts :). > Benchmarking shows a 50% improvement in a loop that compiles a tiny shader > and draws with it once. > > Haven't had time to investigate exposing some version of the extension, > but that is something for future work. > > On Fri, Nov 25, 2016 at 7:35 AM, Mr F wrote: > >> From D3D11 perspective (ANGLE) it is possible to compile shaders by >> simply launching a separate fxc.exe process and checking for it to end. >> Loading its output is quite fast, and ID3D11Device class (which performs >> the loading) supports multithreading. I guess browser can spawn a spare >> process dedicated to that (can be shared by all tabs), as well as call fxc. >> >> On 25 November 2016 at 11:51, Florian B?sch wrote: >> >>> Interesting, but spawning a new GL context/process for each shader >>> compilation "thread" isn't really a nice way to do things, particularly not >>> on mobiles. >>> >>> On Fri, Nov 25, 2016 at 5:09 AM, Mark Callow wrote: >>> >>>> >>>> On 2016 Nov 25, at 0:38, Florian B?sch wrote: >>>> >>>> Sorry, I was confusing them with framebuffer objects which (at least in >>>> some implementations) you can't share. However it is usually the case that >>>> operations done on resources in one context need to be completely finished >>>> before any of their state can be shared with another context (i.e. you have >>>> to invoke a blocking call such as getting the compile status, or calling >>>> glFinish), I'm sure similar restrictions apply to D3D. >>>> >>>> >>>> In OpenGL {ES} I think you can call glFenceSync after the compile/link >>>> commands and in the thread on the other context you can check for >>>> completion with glClientWaitSync with a timeout of 0. WebGL 2 has sync >>>> objects too. >>>> >>>> Regards >>>> >>>> -Mark >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From max...@ Thu Dec 1 03:21:50 2016 From: max...@ (Maksims Mihejevs) Date: Thu, 1 Dec 2016 11:21:50 +0000 Subject: [Public WebGL] Support precompiled shaders as extensions In-Reply-To: References: <0456a52b1474b03c6bbf402cba013a5b.squirrel@sjbaker.org> <9A74453A5B48464BA12E7CD59327A713@gmail.com> Message-ID: Absolutely cool! Would be great to find out more and see how that affects large shaders that require good level of optimisations. On 1 December 2016 at 11:15, Mr F wrote: > This is very cool, Jamie! > > On 30 November 2016 at 22:27, Jamie Madill wrote: > >> Good news, initial prototype for internally parallel compiling shaders >> has landed for D3D/ANGLE. It should be available in tomorrow's Canary, and >> make it's way to stable in the next few months (assuming no reverts :). >> Benchmarking shows a 50% improvement in a loop that compiles a tiny shader >> and draws with it once. >> >> Haven't had time to investigate exposing some version of the extension, >> but that is something for future work. >> >> On Fri, Nov 25, 2016 at 7:35 AM, Mr F wrote: >> >>> From D3D11 perspective (ANGLE) it is possible to compile shaders by >>> simply launching a separate fxc.exe process and checking for it to end. >>> Loading its output is quite fast, and ID3D11Device class (which performs >>> the loading) supports multithreading. I guess browser can spawn a spare >>> process dedicated to that (can be shared by all tabs), as well as call fxc. >>> >>> On 25 November 2016 at 11:51, Florian B?sch wrote: >>> >>>> Interesting, but spawning a new GL context/process for each shader >>>> compilation "thread" isn't really a nice way to do things, particularly not >>>> on mobiles. >>>> >>>> On Fri, Nov 25, 2016 at 5:09 AM, Mark Callow wrote: >>>> >>>>> >>>>> On 2016 Nov 25, at 0:38, Florian B?sch wrote: >>>>> >>>>> Sorry, I was confusing them with framebuffer objects which (at least >>>>> in some implementations) you can't share. However it is usually the case >>>>> that operations done on resources in one context need to be completely >>>>> finished before any of their state can be shared with another context (i.e. >>>>> you have to invoke a blocking call such as getting the compile status, or >>>>> calling glFinish), I'm sure similar restrictions apply to D3D. >>>>> >>>>> >>>>> In OpenGL {ES} I think you can call glFenceSync after the compile/link >>>>> commands and in the thread on the other context you can check for >>>>> completion with glClientWaitSync with a timeout of 0. WebGL 2 has sync >>>>> objects too. >>>>> >>>>> Regards >>>>> >>>>> -Mark >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From art...@ Thu Dec 1 04:50:11 2016 From: art...@ (Mr F) Date: Thu, 1 Dec 2016 15:50:11 +0300 Subject: [Public WebGL] Resolve MSAA depth? In-Reply-To: References: Message-ID: OK, sorry for bothering - must be my mistake somewhere. Made it work while preparing the test case :) On 30 November 2016 at 23:03, Jamie Madill wrote: > Yes, a reproduction / test case would be awesome, thanks. > > On Tue, Nov 29, 2016 at 9:20 PM, Jeff Gilbert > wrote: > >> FWIW, the spec says pretty explicitly that BlitFramebuffer should be >> functional for depth->depth blitting, as long as the formats match, >> etc etc. >> >> GLES 3.0.5 p198: >> If the >> source formats are depth values, sample values are resolved in an >> implementation- >> dependent manner where the result will be between the minimum and maximum >> depth values in the pixel. >> >> On Tue, Nov 29, 2016 at 8:16 PM, Kenneth Russell wrote: >> > Could you make any test case available? Do you have any other platforms >> > (Mac, Linux) to test on? You could also try launching Chrome with the >> > command line argument --use-angle=gl to see the difference between >> ANGLE's >> > D3D11 and OpenGL backends. >> > >> > >> > On Tue, Nov 29, 2016 at 12:42 PM, Mr F wrote: >> >> >> >> I'll try to prepare a clean test case soon. I'm on the latest Chrome >> >> Canary/Win 7/GTX970. Both source and destination are 32F. What I mean >> by >> >> "blank" actually looks like a solid red color, which seems to be >> uniform >> >> 1,0,0, no matter how close/far I'm from any geometry.It's good to know >> that >> >> it is supposed to work - maybe just my mistake somewhere, although I >> tested >> >> it heavily. The source buffer is created and attached using >> >> >> >> renderbufferStorageMultisample(gl.RENDERBUFFER, 4, >> gl.DEPTH_COMPONENT32F, >> >> width, height) >> >> framebufferRenderbuffer(gl.FRAMEBUFFER, gl.DEPTH_ATTACHMENT, >> >> gl.RENDERBUFFER, msaaBuffer) >> >> >> >> and the destination created and attached to another framebufer with >> >> >> >> texImage2D(gl.TEXTURE_2D, 0, gl.DEPTH_COMPONENT32F, width, height, 0, >> >> gl.DEPTH_COMPONENT, gl.FLOAT, null) >> >> framebufferTexture2D(gl.FRAMEBUFFER, gl.DEPTH_ATTACHMENT, >> gl.TEXTURE_2D, >> >> tex, 0) >> >> >> >> The blit is performed like this: >> >> bindFramebuffer(gl.READ_FRAMEBUFFER, msaaFBO) >> >> bindFramebuffer(gl.DRAW_FRAMEBUFFER, resolveFBO) >> >> blitFramebuffer(0, 0, width, height, 0, 0, width, height, >> >> gl.COLOR_BUFFER_BIT | gl.DEPTH_BUFFER_BIT, gl.NEAREST) >> >> >> >> On 29 November 2016 at 17:51, Jamie Madill >> wrote: >> >>> >> >>> This generally should work. There are tests for this in dEQP's >> >>> dEQP-GLES3.functional.fbo.msaa and also in the WebGL 2-specific tests >> in >> >>> gles3/fbomultisample and I think also fboinvalidate/sub. >> >>> >> >>> Note some of these tests are marked as failing on Intel on pretty much >> >>> all platforms: >> >>> >> >>> https://cs.chromium.org/chromium/src/content/test/gpu/gpu_ >> tests/webgl2_conformance_expectations.py?q=webgl2_conform& >> sq=package:chromium&l=118 >> >>> >> >>> Mr F, what platform are you on, and which vendor? >> >>> >> >>> On Mon, Nov 28, 2016 at 10:34 PM, Kenneth Russell >> wrote: >> >>>> >> >>>> I'm pretty sure this should either work, or generate an OpenGL error. >> >>>> OpenGL ES 3.0.5 section 4.3.3 "Copying Pixels" says BlitFramebuffer >> >>>> generates INVALID_OPERATION if the mask includes DEPTH_BUFFER_BIT or >> >>>> STENCIL_BUFFER_BIT, and the source and destination depth and stencil >> buffer >> >>>> formats don't match. >> >>>> >> >>>> It looks like there are extensive tests of resolving multisampled >> depth >> >>>> buffers to single-sampled ones, but I'm not sure about resolving to >> a depth >> >>>> texture. Do you have a test case? What platform are you on (can you >> provide >> >>>> about:gpu if you're running Chrome)? >> >>>> >> >>>> -Ken >> >>>> >> >>>> >> >>>> >> >>>> On Sat, Nov 26, 2016 at 12:26 PM, Mr F >> wrote: >> >>>>> >> >>>>> The docs are a bit unclear on that. Is it possible to use >> >>>>> blitFramebuffer to get current MSAA depth buffer into a non-MSAA >> depth >> >>>>> texture? The color buffer is resolved nicely, however the depth is >> just >> >>>>> blank, and no error is generated - wondering if it's the expected >> behaviour. >> >>>>> Depth format is DEPTH_COMPONENT32F. >> >>>> >> >>>> >> >>> >> >> >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jav...@ Mon Dec 5 17:03:21 2016 From: jav...@ (Javi Agenjo) Date: Tue, 6 Dec 2016 02:03:21 +0100 Subject: [Public WebGL] Problem with a Chrome using DX9 instead of DX11 Message-ID: Sorry if this is not the right place to ask but I recently tested my webgl app in a computer with Windows 7 and a Geforce 1070 and was surprised that the draw buffers extension wasnt present. Then checking the chrome://gpu I discovered it was running with ANGLE in DX9 instead of DX11 (although I have DX11 installed). I also get this errors: [1244:5092:1206/235005:ERROR:angle_platform_impl.cc(33)] : ANGLE Display::initialize error 5: DXGI 1.2 required to present to HWNDs owned by another process. [1244:5092:1206/235005:ERROR:gl_surface_egl.cc(620)] : eglInitialize D3D11 failed with error EGL_NOT_INITIALIZED, trying next display type [4056:1188:1207/015832:ERROR:angle_platform_impl.cc(33)] : ANGLE Display::initialize error 5: DXGI 1.2 required to present to HWNDs owned by another process. [4056:1188:1207/015832:ERROR:gl_surface_egl.cc(620)] : eglInitialize D3D11 failed with error EGL_NOT_INITIALIZED, trying next display type Which looks like is trying to find DX11.1 but because I have a newer version this doesnt work. I ask here because I cant find anywhere info about this error. Why does ANGLE cant run in DX11? Many thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Mon Dec 5 19:13:04 2016 From: kbr...@ (Kenneth Russell) Date: Mon, 5 Dec 2016 19:13:04 -0800 Subject: [Public WebGL] Problem with a Chrome using DX9 instead of DX11 In-Reply-To: References: Message-ID: This would be better suited for webgl-dev-list since it's not a spec question, but: If you're running Windows 7 I think the issue is that you don't have the Platform Update installed per: https://msdn.microsoft.com/en-us/library/windows/desktop/jj863687(v=vs.85).aspx That's required on that OS in order for Chrome's multi-process rendering model to work with ANGLE's D3D11 backend. -Ken On Mon, Dec 5, 2016 at 5:03 PM, Javi Agenjo wrote: > Sorry if this is not the right place to ask but I recently tested my webgl > app in a computer with Windows 7 and a Geforce 1070 and was surprised that > the draw buffers extension wasnt present. > > Then checking the chrome://gpu I discovered it was running with ANGLE in > DX9 instead of DX11 (although I have DX11 installed). > > I also get this errors: > > [1244:5092:1206/235005:ERROR:angle_platform_impl.cc(33)] : ANGLE > Display::initialize error 5: DXGI 1.2 required to present to HWNDs owned by > another process. > [1244:5092:1206/235005:ERROR:gl_surface_egl.cc(620)] : eglInitialize > D3D11 failed with error EGL_NOT_INITIALIZED, trying next display type > [4056:1188:1207/015832:ERROR:angle_platform_impl.cc(33)] : ANGLE > Display::initialize error 5: DXGI 1.2 required to present to HWNDs owned by > another process. > [4056:1188:1207/015832:ERROR:gl_surface_egl.cc(620)] : eglInitialize > D3D11 failed with error EGL_NOT_INITIALIZED, trying next display type > > Which looks like is trying to find DX11.1 but because I have a newer > version this doesnt work. > > I ask here because I cant find anywhere info about this error. > > Why does ANGLE cant run in DX11? > > Many thanks. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Mon Dec 12 10:51:52 2016 From: kbr...@ (Kenneth Russell) Date: Mon, 12 Dec 2016 10:51:52 -0800 Subject: [Public WebGL] Promote ASTC extension to community approved now ? In-Reply-To: References: Message-ID: Apologies for the delay but David's excellent test has now been verified and merged in https://github.com/KhronosGroup/WebGL/pull/2172 . It would be great to promote this extension to community approved now. Any objections or other comments? -Ken On Tue, Nov 22, 2016 at 4:52 PM, Kenneth Russell wrote: > Thank you David for this excellent contribution! > > We'll verify it and merge as soon as possible -- by next Monday the > latest, due to the US holidays. If there are certain formats that aren't > working well on many GPU types, we should probably file bugs against the > various GPU vendors and temporarily disable testing just those formats, so > the rest of the tests pass 100% (thereby acting as regression tests). > > -Ken > > > > On Tue, Nov 22, 2016 at 8:48 AM, David Peicho wrote: > >> We have worked on the conformance tests, and the pull request is now >> available (https://github.com/KhronosGroup/WebGL/pull/2172). >> >> When the flag --enable-webgl-draft-extensions is activated, the >> extension is accessible and the texture uploading works with LDR/HDR >> encoded ASTC. >> >> However, on an Intel Core i7-6700HQ and with a 16x16 red/green test >> image, only few compression formats were working well >> (COMPRESSED_RGBA_ASTC_4x4_KHR, COMPRESSED_RGBA_ASTC_5x4_KHRs and >> COMPRESSED_RGBA_ASTC_5x5_KHR), others giving strange decoding result. >> >> David, >> Sketchfab >> >> On Fri, Nov 11, 2016 at 12:19 AM, Kenneth Russell wrote: >> >>> Sorry, clarification: the tests are under sdk/tests/conformance/extensions/ >>> in the Github repository. >>> >>> -Ken >>> >>> >>> On Thu, Nov 10, 2016 at 2:52 PM, Kenneth Russell wrote: >>> >>>> Could someone please provide a conformance test for this extension? We >>>> don't have an ASTC pipeline conveniently in house. >>>> >>>> The existing compressed texture extension tests in >>>> https://github.com/KhronosGroup/WebGL under conformance/extensions/ >>>> should be a good starting point. Chrome already has this extension >>>> implemented behind the --enable-webgl-draft-extensions flag. We're >>>> basically waiting for a test to be able to validate the implementation and >>>> give a thumbs up. >>>> >>>> Thanks, >>>> >>>> -Ken >>>> >>>> >>>> On Thu, Nov 10, 2016 at 2:30 PM, Christophe Riccio < >>>> christophe.riccio...@> wrote: >>>> >>>>> There quite a few Android http://opengles.gpuinfo.org/gl >>>>> es_listreports.php?extension=GL_KHR_texture_compression_astc_ldr. and >>>>> iOS (with PowerVR 6XT chips) mobile devices with ASTC support. >>>>> >>>>> But yes, I don't believe there is any web browser exposing ASTC. I >>>>> think that would be a great first step. >>>>> >>>>> On Thu, Nov 10, 2016 at 11:29 AM, Florian B?sch >>>>> wrote: >>>>> >>>>>> I did not record any device/webgl implementation exposing the ASTC >>>>>> extension (expected for draft extensions). The Samsung S7 lists astc >>>>>> support (though it seems to be spread across 3 extensions and one that >>>>>> isn't in the ES registry). Desktop linux driver for nvidia does not expose >>>>>> astc. iOS does not have astc. >>>>>> >>>>>> Since draft extensions are not exposed by default, I can't quantify >>>>>> what the current implementation status across platforms and UA vendors is. >>>>>> Could the UA vendors (apple, google, microsoft, mozilla) respectively >>>>>> comment on: >>>>>> >>>>>> 1. What their implementation status is (and across which >>>>>> platforms) >>>>>> 2. How well supported ASTC currently is on devices they see (by >>>>>> usage) >>>>>> 3. If the spec is final >>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Mon Dec 12 14:27:58 2016 From: jgi...@ (Jeff Gilbert) Date: Mon, 12 Dec 2016 12:27:58 -1000 Subject: [Public WebGL] Promote ASTC extension to community approved now ? In-Reply-To: References: Message-ID: No objections here. I actually thought it went CA already. On Mon, Dec 12, 2016 at 8:51 AM, Kenneth Russell wrote: > Apologies for the delay but David's excellent test has now been verified and > merged in https://github.com/KhronosGroup/WebGL/pull/2172 . > > It would be great to promote this extension to community approved now. Any > objections or other comments? > > -Ken > > > > On Tue, Nov 22, 2016 at 4:52 PM, Kenneth Russell wrote: >> >> Thank you David for this excellent contribution! >> >> We'll verify it and merge as soon as possible -- by next Monday the >> latest, due to the US holidays. If there are certain formats that aren't >> working well on many GPU types, we should probably file bugs against the >> various GPU vendors and temporarily disable testing just those formats, so >> the rest of the tests pass 100% (thereby acting as regression tests). >> >> -Ken >> >> >> >> On Tue, Nov 22, 2016 at 8:48 AM, David Peicho wrote: >>> >>> We have worked on the conformance tests, and the pull request is now >>> available (https://github.com/KhronosGroup/WebGL/pull/2172). >>> >>> When the flag --enable-webgl-draft-extensions is activated, the extension >>> is accessible and the texture uploading works with LDR/HDR encoded ASTC. >>> >>> However, on an Intel Core i7-6700HQ and with a 16x16 red/green test >>> image, only few compression formats were working well >>> (COMPRESSED_RGBA_ASTC_4x4_KHR, COMPRESSED_RGBA_ASTC_5x4_KHRs and >>> COMPRESSED_RGBA_ASTC_5x5_KHR), others giving strange decoding result. >>> >>> David, >>> Sketchfab >>> >>> On Fri, Nov 11, 2016 at 12:19 AM, Kenneth Russell wrote: >>>> >>>> Sorry, clarification: the tests are under >>>> sdk/tests/conformance/extensions/ in the Github repository. >>>> >>>> -Ken >>>> >>>> >>>> On Thu, Nov 10, 2016 at 2:52 PM, Kenneth Russell wrote: >>>>> >>>>> Could someone please provide a conformance test for this extension? We >>>>> don't have an ASTC pipeline conveniently in house. >>>>> >>>>> The existing compressed texture extension tests in >>>>> https://github.com/KhronosGroup/WebGL under conformance/extensions/ should >>>>> be a good starting point. Chrome already has this extension implemented >>>>> behind the --enable-webgl-draft-extensions flag. We're basically waiting for >>>>> a test to be able to validate the implementation and give a thumbs up. >>>>> >>>>> Thanks, >>>>> >>>>> -Ken >>>>> >>>>> >>>>> On Thu, Nov 10, 2016 at 2:30 PM, Christophe Riccio >>>>> wrote: >>>>>> >>>>>> There quite a few Android >>>>>> http://opengles.gpuinfo.org/gles_listreports.php?extension=GL_KHR_texture_compression_astc_ldr. >>>>>> and iOS (with PowerVR 6XT chips) mobile devices with ASTC support. >>>>>> >>>>>> But yes, I don't believe there is any web browser exposing ASTC. I >>>>>> think that would be a great first step. >>>>>> >>>>>> On Thu, Nov 10, 2016 at 11:29 AM, Florian B?sch >>>>>> wrote: >>>>>>> >>>>>>> I did not record any device/webgl implementation exposing the ASTC >>>>>>> extension (expected for draft extensions). The Samsung S7 lists astc support >>>>>>> (though it seems to be spread across 3 extensions and one that isn't in the >>>>>>> ES registry). Desktop linux driver for nvidia does not expose astc. iOS does >>>>>>> not have astc. >>>>>>> >>>>>>> Since draft extensions are not exposed by default, I can't quantify >>>>>>> what the current implementation status across platforms and UA vendors is. >>>>>>> Could the UA vendors (apple, google, microsoft, mozilla) respectively >>>>>>> comment on: >>>>>>> >>>>>>> What their implementation status is (and across which platforms) >>>>>>> How well supported ASTC currently is on devices they see (by usage) >>>>>>> If the spec is final >>>>>> >>>>>> >>>>> >>>> >>> >> > ----------------------------------------------------------- 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 Dec 12 17:01:50 2016 From: kbr...@ (Kenneth Russell) Date: Mon, 12 Dec 2016 17:01:50 -0800 Subject: [Public WebGL] Promote ASTC extension to community approved now ? In-Reply-To: References: Message-ID: Great. https://github.com/KhronosGroup/WebGL/pull/2204 uploaded. On Mon, Dec 12, 2016 at 2:27 PM, Jeff Gilbert wrote: > No objections here. > I actually thought it went CA already. > > On Mon, Dec 12, 2016 at 8:51 AM, Kenneth Russell wrote: > > Apologies for the delay but David's excellent test has now been verified > and > > merged in https://github.com/KhronosGroup/WebGL/pull/2172 . > > > > It would be great to promote this extension to community approved now. > Any > > objections or other comments? > > > > -Ken > > > > > > > > On Tue, Nov 22, 2016 at 4:52 PM, Kenneth Russell wrote: > >> > >> Thank you David for this excellent contribution! > >> > >> We'll verify it and merge as soon as possible -- by next Monday the > >> latest, due to the US holidays. If there are certain formats that aren't > >> working well on many GPU types, we should probably file bugs against the > >> various GPU vendors and temporarily disable testing just those formats, > so > >> the rest of the tests pass 100% (thereby acting as regression tests). > >> > >> -Ken > >> > >> > >> > >> On Tue, Nov 22, 2016 at 8:48 AM, David Peicho > wrote: > >>> > >>> We have worked on the conformance tests, and the pull request is now > >>> available (https://github.com/KhronosGroup/WebGL/pull/2172). > >>> > >>> When the flag --enable-webgl-draft-extensions is activated, the > extension > >>> is accessible and the texture uploading works with LDR/HDR encoded > ASTC. > >>> > >>> However, on an Intel Core i7-6700HQ and with a 16x16 red/green test > >>> image, only few compression formats were working well > >>> (COMPRESSED_RGBA_ASTC_4x4_KHR, COMPRESSED_RGBA_ASTC_5x4_KHRs and > >>> COMPRESSED_RGBA_ASTC_5x5_KHR), others giving strange decoding result. > >>> > >>> David, > >>> Sketchfab > >>> > >>> On Fri, Nov 11, 2016 at 12:19 AM, Kenneth Russell > wrote: > >>>> > >>>> Sorry, clarification: the tests are under > >>>> sdk/tests/conformance/extensions/ in the Github repository. > >>>> > >>>> -Ken > >>>> > >>>> > >>>> On Thu, Nov 10, 2016 at 2:52 PM, Kenneth Russell > wrote: > >>>>> > >>>>> Could someone please provide a conformance test for this extension? > We > >>>>> don't have an ASTC pipeline conveniently in house. > >>>>> > >>>>> The existing compressed texture extension tests in > >>>>> https://github.com/KhronosGroup/WebGL under conformance/extensions/ > should > >>>>> be a good starting point. Chrome already has this extension > implemented > >>>>> behind the --enable-webgl-draft-extensions flag. We're basically > waiting for > >>>>> a test to be able to validate the implementation and give a thumbs > up. > >>>>> > >>>>> Thanks, > >>>>> > >>>>> -Ken > >>>>> > >>>>> > >>>>> On Thu, Nov 10, 2016 at 2:30 PM, Christophe Riccio > >>>>> wrote: > >>>>>> > >>>>>> There quite a few Android > >>>>>> http://opengles.gpuinfo.org/gles_listreports.php? > extension=GL_KHR_texture_compression_astc_ldr. > >>>>>> and iOS (with PowerVR 6XT chips) mobile devices with ASTC support. > >>>>>> > >>>>>> But yes, I don't believe there is any web browser exposing ASTC. I > >>>>>> think that would be a great first step. > >>>>>> > >>>>>> On Thu, Nov 10, 2016 at 11:29 AM, Florian B?sch > >>>>>> wrote: > >>>>>>> > >>>>>>> I did not record any device/webgl implementation exposing the ASTC > >>>>>>> extension (expected for draft extensions). The Samsung S7 lists > astc support > >>>>>>> (though it seems to be spread across 3 extensions and one that > isn't in the > >>>>>>> ES registry). Desktop linux driver for nvidia does not expose > astc. iOS does > >>>>>>> not have astc. > >>>>>>> > >>>>>>> Since draft extensions are not exposed by default, I can't quantify > >>>>>>> what the current implementation status across platforms and UA > vendors is. > >>>>>>> Could the UA vendors (apple, google, microsoft, mozilla) > respectively > >>>>>>> comment on: > >>>>>>> > >>>>>>> What their implementation status is (and across which platforms) > >>>>>>> How well supported ASTC currently is on devices they see (by usage) > >>>>>>> If the spec is final > >>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Fri Dec 30 11:11:14 2016 From: jda...@ (John Davis) Date: Fri, 30 Dec 2016 19:11:14 +0000 Subject: [Public WebGL] V2 Message-ID: Webgl2 dead? -------------- next part -------------- An HTML attachment was scrubbed... URL: From max...@ Sat Dec 31 09:05:08 2016 From: max...@ (Maksims Mihejevs) Date: Sat, 31 Dec 2016 17:05:08 +0000 Subject: [Public WebGL] V2 In-Reply-To: References: Message-ID: WebGL 2.0 is being actively developed, and is about to be born in major browsers. On 30 Dec 2016 7:13 p.m., "John Davis" wrote: > Webgl2 dead? -------------- next part -------------- An HTML attachment was scrubbed... URL: