From emm...@ Thu Oct 1 10:18:56 2015 From: emm...@ (Emmanuel Gil Peyrot) Date: Thu, 1 Oct 2015 18:18:56 +0100 Subject: [Public WebGL] Proposal for the WEBGL_debug extension In-Reply-To: References: <20150918143018.GA11808@localhost.cbg.collabora.co.uk> Message-ID: <20151001171856.GA4333@localhost.cbg.collabora.co.uk> On Wed, Sep 30, 2015 at 11:06:32PM -0700, Kenneth Russell wrote: > Could you describe in more detail how you've used your prototype > implementation of this extension and how it's improved your debugging > workflow? The main reason I started working on this extension was integration with existing GLES debugging tools, namely apitrace in my case. This allows seamless debugging of the WebGL application, the web browser, and the graphics driver, either while they are running or post-mortem, which can be very useful especially on embedded platforms where a full-blown debugger or even a JS console isn?t always an option. > > There are many simple JavaScript frameworks like webgl-debug.js ( > https://github.com/KhronosGroup/WebGLDeveloperTools ) that wrap the > WebGLRenderingContext, calling getError() after each call, and > throwing an exception if an error occurred, which can be caught in the > browser's devtools debugger. There are two big issues with this approach: - Only errors can be found that way, there is no possibility for the driver or browser to present performances issues, warnings about undefined behaviours allowed by the specification, nor for the application to tell the debugger about whatever it wants. - They reduce performances by making many asynchronous things synchronous, which can hide some race condition bugs (I have encountered that issue), and can?t usually be enabled/disabled on a per-case basis. > > -Ken -- Emmanuel Gil Peyrot Collabora Ltd. ----------------------------------------------------------- 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...@ Thu Oct 1 10:48:36 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Thu, 1 Oct 2015 19:48:36 +0200 Subject: [Public WebGL] Proposal for the WEBGL_debug extension In-Reply-To: <20151001171856.GA4333@localhost.cbg.collabora.co.uk> References: <20150918143018.GA11808@localhost.cbg.collabora.co.uk> <20151001171856.GA4333@localhost.cbg.collabora.co.uk> Message-ID: On Thu, Oct 1, 2015 at 7:18 PM, Emmanuel Gil Peyrot < emmanuel.peyrot...@> wrote: > The main reason I started working on this extension was integration > with existing GLES debugging tools, namely apitrace in my case. > Is it a correct statement to say that apitrace relies on KHR_debug to identify the stream of commands of interest to the programmer (because there's a lot of commands being executed by a browser), and therefore allows you to inspect just the commands your WebGL context emitted? Since you have experience in this field, could you comment on how vogl fits into that picture? Is KHR/WebGL_debug something that could interoperate with it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From emm...@ Thu Oct 1 11:19:37 2015 From: emm...@ (Emmanuel Gil Peyrot) Date: Thu, 1 Oct 2015 19:19:37 +0100 Subject: [Public WebGL] Proposal for the WEBGL_debug extension In-Reply-To: References: <20150918143018.GA11808@localhost.cbg.collabora.co.uk> <20151001171856.GA4333@localhost.cbg.collabora.co.uk> Message-ID: <20151001181937.GA5572@localhost.cbg.collabora.co.uk> On Thu, Oct 01, 2015 at 07:48:36PM +0200, Florian B?sch wrote: > On Thu, Oct 1, 2015 at 7:18 PM, Emmanuel Gil Peyrot < > emmanuel.peyrot...@> wrote: > > > The main reason I started working on this extension was integration > > with existing GLES debugging tools, namely apitrace in my case. > > > Is it a correct statement to say that apitrace relies on KHR_debug to > identify the stream of commands of interest to the programmer (because > there's a lot of commands being executed by a browser), and therefore > allows you to inspect just the commands your WebGL context emitted? No, since it runs externally to the browser, apitrace (or any such tool) doesn?t have any information about which GL calls are emitted by the WebGL application and which are emitted by the browser. It does have the information about the source of debug messages though, which can let you insert debug messages from the browser, application, or its libraries. What you can do with KHR_debug that you can?t do without though is grouping relevant calls together, ignore errors, warnings or notifications you don?t care about, name your objects so they are more easily spottable, etc. It could make sense to add WebGL support to apitrace, so it could debug JS calls instead of C calls, using traces that browsers or tools like webgl-debug.js would create, but this hasn?t been done yet. > > Since you have experience in this field, could you comment on how vogl fits > into that picture? Is KHR/WebGL_debug something that could interoperate > with it? I haven?t tried it yet, but VOGL targets mostly the same workflow as apitrace, and according to their change notes[0] they already support KHR_debug since 2014-03-21. [0] https://github.com/ValveSoftware/vogl/wiki/Change-Notes -- Emmanuel Gil Peyrot Collabora Ltd. ----------------------------------------------------------- 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...@ Thu Oct 1 11:38:10 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Thu, 1 Oct 2015 20:38:10 +0200 Subject: [Public WebGL] Proposal for the WEBGL_debug extension In-Reply-To: <20151001181937.GA5572@localhost.cbg.collabora.co.uk> References: <20150918143018.GA11808@localhost.cbg.collabora.co.uk> <20151001171856.GA4333@localhost.cbg.collabora.co.uk> <20151001181937.GA5572@localhost.cbg.collabora.co.uk> Message-ID: I think another interesting question would be how this could be made to work with angle and Direct3D related debugging tools. Does Direct3D offer comparable functionality to KHR_debug? -------------- next part -------------- An HTML attachment was scrubbed... URL: From khr...@ Thu Oct 1 14:37:32 2015 From: khr...@ (Mark Callow) Date: Thu, 1 Oct 2015 14:37:32 -0700 Subject: [Public WebGL] WEBKIT prefixes on extensions Message-ID: It has been reported that on Safari, anisotropy must be enabled via: WEBKIT_EXT_texture_filter_anisotropic (instead of EXT_texture_filter_anisotropic). Why? Does it mean it is not stable yet? I thought we decided long ago to not use vendor prefixes on extensions. Regards -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From emm...@ Fri Oct 2 04:14:39 2015 From: emm...@ (Emmanuel Gil Peyrot) Date: Fri, 2 Oct 2015 12:14:39 +0100 Subject: [Public WebGL] Proposal for the WEBGL_debug extension In-Reply-To: References: <20150918143018.GA11808@localhost.cbg.collabora.co.uk> <20151001171856.GA4333@localhost.cbg.collabora.co.uk> <20151001181937.GA5572@localhost.cbg.collabora.co.uk> Message-ID: <20151002111439.GA4324@localhost.cbg.collabora.co.uk> On Thu, Oct 01, 2015 at 08:38:10PM +0200, Florian B?sch wrote: > I think another interesting question would be how this could be made to > work with angle and Direct3D related debugging tools. Does Direct3D offer > comparable functionality to KHR_debug? I don?t know much about Direct3D, but if it has any performance/error reporting ANGLE can translate it for the GLES application. ANGLE is here considered as the driver, using KHR_debug it can provide useful information to the application, either what Direct3D is reporting, or when it is taking a slow path due to some difference between both APIs for example. WEBGL_debug then exposes that information to WebGL. -- Emmanuel Gil Peyrot Collabora Ltd. ----------------------------------------------------------- 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...@ Fri Oct 2 14:17:28 2015 From: kbr...@ (Kenneth Russell) Date: Fri, 2 Oct 2015 14:17:28 -0700 Subject: [Public WebGL] WEBKIT prefixes on extensions In-Reply-To: References: Message-ID: Confirmed. Looks like a bug in Safari. I'd suggest filing this on bugs.webkit.org and posting the bug ID here. -Ken On Thu, Oct 1, 2015 at 2:37 PM, Mark Callow wrote: > It has been reported that on Safari, anisotropy must be enabled via: > WEBKIT_EXT_texture_filter_anisotropic (instead of > EXT_texture_filter_anisotropic). Why? Does it mean it is not stable yet? I > thought we decided long ago to not use vendor prefixes on extensions. > > Regards > > -Mark > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From khr...@ Fri Oct 2 14:48:24 2015 From: khr...@ (Mark Callow) Date: Fri, 2 Oct 2015 14:48:24 -0700 Subject: [Public WebGL] WEBKIT prefixes on extensions In-Reply-To: References: Message-ID: <52BE6BE5-9D37-446A-9B60-39B846BC8554@callow.im> > On Oct 2, 2015, at 2:17 PM, Kenneth Russell wrote: > > > Confirmed. Looks like a bug in Safari. I'd suggest filing this on > bugs.webkit.org and posting the bug ID here. > > > On Thu, Oct 1, 2015 at 2:37 PM, Mark Callow wrote: >> It has been reported that on Safari, anisotropy must be enabled via: >> WEBKIT_EXT_texture_filter_anisotropic (instead of >> EXT_texture_filter_anisotropic). Why? Does it mean it is not stable yet? I >> thought we decided long ago to not use vendor prefixes on extensions. >> > Thanks for the confirmation. I?d appreciate it if someone who already has a webkit bug account would file the bug. I?m not working with WebKit and don?t want to create an account just to file this one bug. Regards -Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From kbr...@ Fri Oct 2 15:13:09 2015 From: kbr...@ (Kenneth Russell) Date: Fri, 2 Oct 2015 15:13:09 -0700 Subject: [Public WebGL] WEBKIT prefixes on extensions In-Reply-To: <52BE6BE5-9D37-446A-9B60-39B846BC8554@callow.im> References: <52BE6BE5-9D37-446A-9B60-39B846BC8554@callow.im> Message-ID: On Fri, Oct 2, 2015 at 2:48 PM, Mark Callow wrote: > >> On Oct 2, 2015, at 2:17 PM, Kenneth Russell wrote: >> >> >> Confirmed. Looks like a bug in Safari. I'd suggest filing this on >> bugs.webkit.org and posting the bug ID here. >> >> >> On Thu, Oct 1, 2015 at 2:37 PM, Mark Callow wrote: >>> It has been reported that on Safari, anisotropy must be enabled via: >>> WEBKIT_EXT_texture_filter_anisotropic (instead of >>> EXT_texture_filter_anisotropic). Why? Does it mean it is not stable yet? I >>> thought we decided long ago to not use vendor prefixes on extensions. >>> >> > > Thanks for the confirmation. I?d appreciate it if someone who already has a webkit bug account would file the bug. I?m not working with WebKit and don?t want to create an account just to file this one bug. Sure. Filed https://bugs.webkit.org/show_bug.cgi?id=149765 . -Ken > Regards > > -Mark > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From khr...@ Fri Oct 2 15:14:07 2015 From: khr...@ (Mark Callow) Date: Fri, 2 Oct 2015 15:14:07 -0700 Subject: [Public WebGL] WEBKIT prefixes on extensions In-Reply-To: References: <52BE6BE5-9D37-446A-9B60-39B846BC8554@callow.im> Message-ID: > On Oct 2, 2015, at 3:13 PM, Kenneth Russell wrote: > > On Fri, Oct 2, 2015 at 2:48 PM, Mark Callow wrote: >> >>> On Oct 2, 2015, at 2:17 PM, Kenneth Russell wrote: >>> >>> >>> Confirmed. Looks like a bug in Safari. I'd suggest filing this on >>> bugs.webkit.org and posting the bug ID here. >>> >>> >>> On Thu, Oct 1, 2015 at 2:37 PM, Mark Callow wrote: >>>> It has been reported that on Safari, anisotropy must be enabled via: >>>> WEBKIT_EXT_texture_filter_anisotropic (instead of >>>> EXT_texture_filter_anisotropic). Why? Does it mean it is not stable yet? I >>>> thought we decided long ago to not use vendor prefixes on extensions. >>>> >>> >> >> Thanks for the confirmation. I?d appreciate it if someone who already has a webkit bug account would file the bug. I?m not working with WebKit and don?t want to create an account just to file this one bug. > > Sure. Filed https://bugs.webkit.org/show_bug.cgi?id=149765 . > > -Ken > Thanks Ken. Regards -Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From pya...@ Fri Oct 2 21:58:37 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sat, 3 Oct 2015 06:58:37 +0200 Subject: [Public WebGL] WEBKIT prefixes on extensions In-Reply-To: References: Message-ID: On Thu, Oct 1, 2015 at 11:37 PM, Mark Callow wrote: > Why? Does it mean it is not stable yet? I thought we decided long ago to > not use vendor prefixes on extensions. > I believe Google has committed not to use prefixes and Mozilla wants to drop using them. I cannot recall Apple commenting on their use, so I wouldn't presume that they're committed as well. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Fri Oct 2 22:32:10 2015 From: kbr...@ (Kenneth Russell) Date: Fri, 2 Oct 2015 22:32:10 -0700 Subject: [Public WebGL] Propose moving EXT_disjoint_timer_query extension to community approved Message-ID: WebGL community, I would like to propose moving WebGL's wrapper for the EXT_disjoint_timer_query extension to community approved: https://www.khronos.org/registry/webgl/extensions/EXT_disjoint_timer_query/ Thanks to David Yen from the Chromium team, this extension is now implemented in Chromium behind the --enable-webgl-draft-extensions command line flag. With a final update to the conformance test [1] and a final change to the browser [2], there is now a fully spec compliant implementation of this extension. Comments in favor or against? Thanks, -Ken [1] https://github.com/KhronosGroup/WebGL/pull/1252 [2] https://codereview.chromium.org/1385793002/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Oct 2 22:43:39 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sat, 3 Oct 2015 07:43:39 +0200 Subject: [Public WebGL] Propose moving EXT_disjoint_timer_query extension to community approved In-Reply-To: References: Message-ID: I don't have a principal objection against moving to community approved. I do however have some concern that taking something out of draft where the public wasn't testing it, to community approved where it can't be changed or pulled back to draft has the potential to reveal bugs or specification deficiencies that're then harder to address. It's more a concern about the extension process after prefix avoidance, where we now lack a way to publicly expose draft extensions. On Sat, Oct 3, 2015 at 7:32 AM, Kenneth Russell wrote: > WebGL community, > > I would like to propose moving WebGL's wrapper for the > EXT_disjoint_timer_query extension to community approved: > > https://www.khronos.org/registry/webgl/extensions/EXT_disjoint_timer_query/ > > Thanks to David Yen from the Chromium team, this extension is now > implemented in Chromium behind the --enable-webgl-draft-extensions command > line flag. With a final update to the conformance test [1] and a final > change to the browser [2], there is now a fully spec compliant > implementation of this extension. > > Comments in favor or against? > > Thanks, > > -Ken > > [1] https://github.com/KhronosGroup/WebGL/pull/1252 > [2] https://codereview.chromium.org/1385793002/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Fri Oct 2 22:58:29 2015 From: kbr...@ (Kenneth Russell) Date: Fri, 2 Oct 2015 22:58:29 -0700 Subject: [Public WebGL] Propose moving EXT_disjoint_timer_query extension to community approved In-Reply-To: References: Message-ID: That's a fair point. For one thing, I'd neglected to widely announce the availability of the draft extension in Chromium. Some of the interested parties noticed the bug report get updated ( http://crbug.com/345227 ), but I'm not sure how many people have tried it. If interested people would please give it a try in Chrome's Dev Channel, your feedback on it would be appreciated. It should finally be possible to get fine-grained timing of GPU-side work in WebGL. On the more general topic, I think broader advertising of these draft extensions in browsers is what's needed. Until these extensions have been vetted, it seems to me that they shouldn't be exposed unconditionally, so almost inevitably, the feedback will have to come from interested developers who enable the extensions themselves and try them out. (Unless you're talking about adding another step to the process like "provisional", where it can be exposed unconditionally, with the caveat that it might be removed or changed in the future. I can see arguments both for and against adding a step like that.) -Ken On Fri, Oct 2, 2015 at 10:43 PM, Florian B?sch wrote: > I don't have a principal objection against moving to community approved. I > do however have some concern that taking something out of draft where the > public wasn't testing it, to community approved where it can't be changed > or pulled back to draft has the potential to reveal bugs or specification > deficiencies that're then harder to address. It's more a concern about the > extension process after prefix avoidance, where we now lack a way to > publicly expose draft extensions. > > On Sat, Oct 3, 2015 at 7:32 AM, Kenneth Russell wrote: > >> WebGL community, >> >> I would like to propose moving WebGL's wrapper for the >> EXT_disjoint_timer_query extension to community approved: >> >> >> https://www.khronos.org/registry/webgl/extensions/EXT_disjoint_timer_query/ >> >> Thanks to David Yen from the Chromium team, this extension is now >> implemented in Chromium behind the --enable-webgl-draft-extensions command >> line flag. With a final update to the conformance test [1] and a final >> change to the browser [2], there is now a fully spec compliant >> implementation of this extension. >> >> Comments in favor or against? >> >> Thanks, >> >> -Ken >> >> [1] https://github.com/KhronosGroup/WebGL/pull/1252 >> [2] https://codereview.chromium.org/1385793002/ >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sat Oct 3 05:22:49 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sat, 3 Oct 2015 14:22:49 +0200 Subject: [Public WebGL] Proposal for the WEBGL_debug extension In-Reply-To: <20151002111439.GA4324@localhost.cbg.collabora.co.uk> References: <20150918143018.GA11808@localhost.cbg.collabora.co.uk> <20151001171856.GA4333@localhost.cbg.collabora.co.uk> <20151001181937.GA5572@localhost.cbg.collabora.co.uk> <20151002111439.GA4324@localhost.cbg.collabora.co.uk> Message-ID: It might be prudent to check out how this kind of thing works in Direct3D land to see if the current extension is a sufficient match. It'd be a pitty if there's incompatibilities we didn't catch at this stage, and later needed to introduce WEBGL_debug_d3d or something. On Fri, Oct 2, 2015 at 1:14 PM, Emmanuel Gil Peyrot < emmanuel.peyrot...@> wrote: > On Thu, Oct 01, 2015 at 08:38:10PM +0200, Florian B?sch wrote: > > I think another interesting question would be how this could be made to > > work with angle and Direct3D related debugging tools. Does Direct3D offer > > comparable functionality to KHR_debug? > > I don?t know much about Direct3D, but if it has any performance/error > reporting ANGLE can translate it for the GLES application. ANGLE is > here considered as the driver, using KHR_debug it can provide useful > information to the application, either what Direct3D is reporting, or > when it is taking a slow path due to some difference between both APIs > for example. > > WEBGL_debug then exposes that information to WebGL. > > -- > Emmanuel Gil Peyrot > Collabora Ltd. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From baj...@ Sat Oct 3 21:39:08 2015 From: baj...@ (Brandon Jones) Date: Sun, 04 Oct 2015 04:39:08 +0000 Subject: [Public WebGL] WEBKIT prefixes on extensions In-Reply-To: References: Message-ID: Florian's right. The decision not to use prefixes was made at the browser level, it's not a Khronos policy. Nothing prevents Apple from using prefixed extensions if they choose. On Fri, Oct 2, 2015 at 9:59 PM Florian B?sch wrote: > On Thu, Oct 1, 2015 at 11:37 PM, Mark Callow wrote: > >> Why? Does it mean it is not stable yet? I thought we decided long ago to >> not use vendor prefixes on extensions. >> > > I believe Google has committed not to use prefixes and Mozilla wants to > drop using them. I cannot recall Apple commenting on their use, so I > wouldn't presume that they're committed as well. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Sun Oct 4 11:00:39 2015 From: jda...@ (John Davis) Date: Sun, 4 Oct 2015 14:00:39 -0400 Subject: [Public WebGL] webgl2 Message-ID: Any idea when we'll start seeing experimental webgl2 builds in chrome? -------------- next part -------------- An HTML attachment was scrubbed... URL: From baj...@ Sun Oct 4 14:53:19 2015 From: baj...@ (Brandon Jones) Date: Sun, 04 Oct 2015 21:53:19 +0000 Subject: [Public WebGL] webgl2 In-Reply-To: References: Message-ID: You can already turn on the experimental WebGL 2 implementation in Chrome (Canary recommended) with the command line "--enable-unsafe-es3-apis". The implementation is still missing some features, which is why we haven't added a more easily accessible flag to about:flags, but it should still be able to handle a decent amount of the new APIs correctly. Once we feel like the implementation is feature complete we'll make it easier to get to so we can get more developer feedback while we secure the API and fix bugs on the way to turning it on by default. On Sun, Oct 4, 2015 at 11:01 AM John Davis wrote: > Any idea when we'll start seeing experimental webgl2 builds in chrome? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From emm...@ Mon Oct 5 03:59:48 2015 From: emm...@ (Emmanuel Gil Peyrot) Date: Mon, 5 Oct 2015 11:59:48 +0100 Subject: [Public WebGL] Proposal for the WEBGL_debug extension In-Reply-To: References: <20150918143018.GA11808@localhost.cbg.collabora.co.uk> <20151001171856.GA4333@localhost.cbg.collabora.co.uk> <20151001181937.GA5572@localhost.cbg.collabora.co.uk> <20151002111439.GA4324@localhost.cbg.collabora.co.uk> <20151005103748.GA1372@localhost.cbg.collabora.co.uk> Message-ID: <20151005105948.GA1828@localhost.cbg.collabora.co.uk> On Mon, Oct 05, 2015 at 12:46:55PM +0200, Florian B?sch wrote: > maybe add a note to the extension spec that KHR_debug is intended to be > emulated on angle via the ID3d10/11InfoQueue functions. I could add that, but is it really the right place, in a specification, to tell about such implementation details? What should we do then when somebody else will implement WebGL on top of other APIs, say d3d12, Vulkan or Metal? Will we have to update the specification to tell them how to expose the feature? -- Emmanuel Gil Peyrot Collabora Ltd. ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Mon Oct 5 04:05:33 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Mon, 5 Oct 2015 13:05:33 +0200 Subject: [Public WebGL] Proposal for the WEBGL_debug extension In-Reply-To: <20151005105948.GA1828@localhost.cbg.collabora.co.uk> References: <20150918143018.GA11808@localhost.cbg.collabora.co.uk> <20151001171856.GA4333@localhost.cbg.collabora.co.uk> <20151001181937.GA5572@localhost.cbg.collabora.co.uk> <20151002111439.GA4324@localhost.cbg.collabora.co.uk> <20151005103748.GA1372@localhost.cbg.collabora.co.uk> <20151005105948.GA1828@localhost.cbg.collabora.co.uk> Message-ID: On Mon, Oct 5, 2015 at 12:59 PM, Emmanuel Gil Peyrot < emmanuel.peyrot...@> wrote: > I could add that, but is it really the right place, in a specification, > to tell about such implementation details? > I don't know. It's usually clear that a feature is intended to be emulated by Direct3D via angle, but in this case I'm not sure it is. Kenneth? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Mon Oct 5 14:30:47 2015 From: kbr...@ (Kenneth Russell) Date: Mon, 5 Oct 2015 14:30:47 -0700 Subject: [Public WebGL] Proposal for the WEBGL_debug extension In-Reply-To: References: <20150918143018.GA11808@localhost.cbg.collabora.co.uk> <20151001171856.GA4333@localhost.cbg.collabora.co.uk> <20151001181937.GA5572@localhost.cbg.collabora.co.uk> <20151002111439.GA4324@localhost.cbg.collabora.co.uk> <20151005103748.GA1372@localhost.cbg.collabora.co.uk> <20151005105948.GA1828@localhost.cbg.collabora.co.uk> Message-ID: WebGL core APIs and extensions are expected to work cross-browser and cross-platform. If there is something in the KHR_debug or WEBGL_debug extension that would preclude its being implemented in ANGLE, then that functionality should be adjusted or removed. If investigation is done into how this would be exposed on D3D, then non-normative text could be added to the extension spec describing it, but it shouldn't be normative text. -Ken On Mon, Oct 5, 2015 at 4:05 AM, Florian B?sch wrote: > On Mon, Oct 5, 2015 at 12:59 PM, Emmanuel Gil Peyrot < > emmanuel.peyrot...@> wrote: > >> I could add that, but is it really the right place, in a specification, >> to tell about such implementation details? >> > I don't know. It's usually clear that a feature is intended to be emulated > by Direct3D via angle, but in this case I'm not sure it is. Kenneth? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Mon Oct 5 19:00:19 2015 From: kbr...@ (Kenneth Russell) Date: Mon, 5 Oct 2015 19:00:19 -0700 Subject: [Public WebGL] WEBKIT prefixes on extensions In-Reply-To: References: Message-ID: Also please note that that bug was just marked fixed. :) -Ken On Sat, Oct 3, 2015 at 9:39 PM, Brandon Jones wrote: > Florian's right. The decision not to use prefixes was made at the browser > level, it's not a Khronos policy. Nothing prevents Apple from using > prefixed extensions if they choose. > > On Fri, Oct 2, 2015 at 9:59 PM Florian B?sch wrote: > >> On Thu, Oct 1, 2015 at 11:37 PM, Mark Callow wrote: >> >>> Why? Does it mean it is not stable yet? I thought we decided long ago to >>> not use vendor prefixes on extensions. >>> >> >> I believe Google has committed not to use prefixes and Mozilla wants to >> drop using them. I cannot recall Apple commenting on their use, so I >> wouldn't presume that they're committed as well. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From din...@ Wed Oct 7 15:04:43 2015 From: din...@ (Dean Jackson) Date: Thu, 8 Oct 2015 09:04:43 +1100 Subject: [Public WebGL] WEBKIT prefixes on extensions In-Reply-To: References: Message-ID: <8A077CF7-CCBB-42E5-81A8-392200E3F78B@apple.com> > On 4 Oct 2015, at 3:39 PM, Brandon Jones wrote: > > Florian's right. The decision not to use prefixes was made at the browser level, it's not a Khronos policy. Nothing prevents Apple from using prefixed extensions if they choose. While it is still a browser policy decision the WebGL WG, like the CSS WG, could come up with recommendations for shipping/making available non-final things. Unlike the CSS WG, I don't suggest getting too detailed. The question really comes down to "is it more harmful to release something that can possibly change behaviour in the future without a way to distinguish new vs old content, or to pollute the namespace with prefixed crap that might force other browsers to implement it?" Right now the wind is blowing in the direction of the former. However, I have a feeling as soon as something awesome gets adopted by one engine then gets changed after shipping, the wind will start to swirl. There isn't a great solution :( I'd be fine with a recommendation of no prefixes for WebGL. We've sort-of informally agreed to that when exposing the rendering context for WebGL2. We could do the same for extensions, but I'm already on the record as saying we should really avoid extensions as much as possible. And as Ken pointed out, I removed the prefix for this extension in WebKit. Dean > > On Fri, Oct 2, 2015 at 9:59 PM Florian B?sch > wrote: > On Thu, Oct 1, 2015 at 11:37 PM, Mark Callow > wrote: > Why? Does it mean it is not stable yet? I thought we decided long ago to not use vendor prefixes on extensions. > > I believe Google has committed not to use prefixes and Mozilla wants to drop using them. I cannot recall Apple commenting on their use, so I wouldn't presume that they're committed as well. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Mon Oct 12 17:13:09 2015 From: kbr...@ (Kenneth Russell) Date: Mon, 12 Oct 2015 17:13:09 -0700 Subject: [Public WebGL] Propose moving EXT_disjoint_timer_query extension to community approved In-Reply-To: References: Message-ID: I'd really like to move this extension forward so we can more easily enable testing of it in Chromium. Are there any specific objections? Thanks, -Ken On Fri, Oct 2, 2015 at 10:58 PM, Kenneth Russell wrote: > That's a fair point. For one thing, I'd neglected to widely announce the > availability of the draft extension in Chromium. Some of the interested > parties noticed the bug report get updated ( http://crbug.com/345227 ), > but I'm not sure how many people have tried it. If interested people would > please give it a try in Chrome's Dev Channel, your feedback on it would be > appreciated. It should finally be possible to get fine-grained timing of > GPU-side work in WebGL. > > On the more general topic, I think broader advertising of these draft > extensions in browsers is what's needed. Until these extensions have been > vetted, it seems to me that they shouldn't be exposed unconditionally, so > almost inevitably, the feedback will have to come from interested > developers who enable the extensions themselves and try them out. > > (Unless you're talking about adding another step to the process like > "provisional", where it can be exposed unconditionally, with the caveat > that it might be removed or changed in the future. I can see arguments both > for and against adding a step like that.) > > -Ken > > > > On Fri, Oct 2, 2015 at 10:43 PM, Florian B?sch wrote: > >> I don't have a principal objection against moving to community approved. >> I do however have some concern that taking something out of draft where the >> public wasn't testing it, to community approved where it can't be changed >> or pulled back to draft has the potential to reveal bugs or specification >> deficiencies that're then harder to address. It's more a concern about the >> extension process after prefix avoidance, where we now lack a way to >> publicly expose draft extensions. >> >> On Sat, Oct 3, 2015 at 7:32 AM, Kenneth Russell wrote: >> >>> WebGL community, >>> >>> I would like to propose moving WebGL's wrapper for the >>> EXT_disjoint_timer_query extension to community approved: >>> >>> >>> https://www.khronos.org/registry/webgl/extensions/EXT_disjoint_timer_query/ >>> >>> Thanks to David Yen from the Chromium team, this extension is now >>> implemented in Chromium behind the --enable-webgl-draft-extensions command >>> line flag. With a final update to the conformance test [1] and a final >>> change to the browser [2], there is now a fully spec compliant >>> implementation of this extension. >>> >>> Comments in favor or against? >>> >>> Thanks, >>> >>> -Ken >>> >>> [1] https://github.com/KhronosGroup/WebGL/pull/1252 >>> [2] https://codereview.chromium.org/1385793002/ >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmi...@ Tue Oct 13 04:28:14 2015 From: dmi...@ (Kirill Dmitrenko) Date: Tue, 13 Oct 2015 14:28:14 +0300 Subject: [Public WebGL] Propose moving EXT_disjoint_timer_query extension to community approved In-Reply-To: References: Message-ID: <21261444735694@webcorp01f.yandex-team.ru> We at Yandex.Maps API team support moving this extension to community approved. 13.10.2015, 03:14, "Kenneth Russell" : > I'd really like to move this extension forward so we can more easily enable testing of it in Chromium. Are there any specific objections? > > Thanks, > > -Ken > > On Fri, Oct 2, 2015 at 10:58 PM, Kenneth Russell wrote: >> That's a fair point. For one thing, I'd neglected to widely announce the availability of the draft extension in Chromium. Some of the interested parties noticed the bug report get updated ( http://crbug.com/345227 ), but I'm not sure how many people have tried it. If interested people would please give it a try in Chrome's Dev Channel, your feedback on it would be appreciated. It should finally be possible to get fine-grained timing of GPU-side work in WebGL. >> >> On the more general topic, I think broader advertising of these draft extensions in browsers is what's needed. Until these extensions have been vetted, it seems to me that they shouldn't be exposed unconditionally, so almost inevitably, the feedback will have to come from interested developers who enable the extensions themselves and try them out. >> >> (Unless you're talking about adding another step to the process like "provisional", where it can be exposed unconditionally, with the caveat that it might be removed or changed in the future. I can see arguments both for and against adding a step like that.) >> >> -Ken >> >> On Fri, Oct 2, 2015 at 10:43 PM, Florian B?sch wrote: >>> I don't have a principal objection against moving to community approved. I do however have some concern that taking something out of draft where the public wasn't testing it, to community approved where it can't be changed or pulled back to draft has the potential to reveal bugs or specification deficiencies that're then harder to address. It's more a concern about the extension process after prefix avoidance, where we now lack a way to publicly expose draft extensions. >>> >>> On Sat, Oct 3, 2015 at 7:32 AM, Kenneth Russell wrote: >>>> WebGL community, >>>> >>>> I would like to propose moving WebGL's wrapper for the EXT_disjoint_timer_query extension to community approved: >>>> >>>> https://www.khronos.org/registry/webgl/extensions/EXT_disjoint_timer_query/ >>>> >>>> Thanks to David Yen from the Chromium team, this extension is now implemented in Chromium behind the --enable-webgl-draft-extensions command line flag. With a final update to the conformance test [1] and a final change to the browser [2], there is now a fully spec compliant implementation of this extension. >>>> >>>> Comments in favor or against? >>>> >>>> Thanks, >>>> >>>> -Ken >>>> >>>> [1]?https://github.com/KhronosGroup/WebGL/pull/1252 >>>> [2]?https://codereview.chromium.org/1385793002/ -- Kirill Dmitrenko Yandex Maps Team ----------------------------------------------------------- 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...@ Sun Oct 18 04:02:12 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 18 Oct 2015 13:02:12 +0200 Subject: [Public WebGL] WebGL/ESSL version strings Message-ID: WebGL implementations report back the VERSION and SHADING_LANGUAGE_VERSION getParameter strings. *VERSION* It's my understanding there are only two valid values for the parameter VERSION: WebGL 1.0 and WebGL 2.0 at the time of this writing (afaik minor spec revision versions aren't reported). However, these are versions that are reported in the wild: - *WebGL 0.9* - *WebGL 0.91* - *WebGL 0.92* - *WebGL 0.93* - *WebGL 0.94* - *WebGL 0.95* - WebGL 1.0 *SHADING_LANGUAGE_VERSION* It's my Understanding that there are only two valid values for the parameter SHADING_LANGUAGE_VERSION: WebGL GLSL ES 1.0 and WebGL GLSL ES 2.0. However, these are values observed in the wild: - *WebGL GLSL ES 0.9* - *WebGL GLSL ES 0.91* - *WebGL GLSL ES 0.92* - *WebGL GLSL ES 0.93* - *WebGL GLSL ES 0.94* - *WebGL GLSL ES 0.95* - WebGL GLSL ES 1.0 *Request for clarification* I would like to inquire off the Khronos WebGL WG the following questions for clarification: - Is it correct that the only two valid versions to report here are 1.0 and 2.0? - If so (or not) should there be language in the specifications to clarify this? - Is it correct that official members to the Khronos WebGL WG are required to adhere to the standards set forth by the group and should not willfully deviate from the standard? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Sun Oct 18 15:39:28 2015 From: kbr...@ (Kenneth Russell) Date: Sun, 18 Oct 2015 15:39:28 -0700 Subject: [Public WebGL] WebGL/ESSL version strings In-Reply-To: References: Message-ID: On Sun, Oct 18, 2015 at 4:02 AM, Florian B?sch wrote: > WebGL implementations report back the VERSION and SHADING_LANGUAGE_VERSION > getParameter strings. > > *VERSION* > > It's my understanding there are only two valid values for the parameter > VERSION: WebGL 1.0 and WebGL 2.0 at the time of this writing (afaik minor > spec revision versions aren't reported). However, these are versions that > are reported in the wild: > > - *WebGL 0.9* > - *WebGL 0.91* > - *WebGL 0.92* > - *WebGL 0.93* > - *WebGL 0.94* > - *WebGL 0.95* > - WebGL 1.0 > > *SHADING_LANGUAGE_VERSION* > > It's my Understanding that there are only two valid values for the > parameter SHADING_LANGUAGE_VERSION: WebGL GLSL ES 1.0 and WebGL GLSL ES > 2.0. However, these are values observed in the wild: > > - *WebGL GLSL ES 0.9* > - *WebGL GLSL ES 0.91* > - *WebGL GLSL ES 0.92* > - *WebGL GLSL ES 0.93* > - *WebGL GLSL ES 0.94* > - *WebGL GLSL ES 0.95* > - WebGL GLSL ES 1.0 > > *Request for clarification* > > I would like to inquire off the Khronos WebGL WG the following questions > for clarification: > > - Is it correct that the only two valid versions to report here are > 1.0 and 2.0? > > Yes. > > - If so (or not) should there be language in the specifications to > clarify this? > > There's no need. The specification already says this. > > - Is it correct that official members to the Khronos WebGL WG are > required to adhere to the standards set forth by the group and should not > willfully deviate from the standard? > > Yes. I don't know which implementations are reporting these strings but they're not conformant. -Ken -------------- next part -------------- An HTML attachment was scrubbed... URL: From Fra...@ Sun Oct 18 17:11:18 2015 From: Fra...@ (Frank Olivier) Date: Mon, 19 Oct 2015 00:11:18 +0000 Subject: [Public WebGL] WebGL/ESSL version strings In-Reply-To: References: Message-ID: Internet Explorer and Microsoft Edge report these <1.0 version strings; the goal here was to enable feature support detection* as we update the renderer several times year. The goal has always been to use ?1.0? as soon as we had a fully conformant implementation, and to update devices so that we get to ?1.0? everywhere; we?ve received feedback from developers that they find the 0.01 increments useful. That said, if it is more useful to change to ?1.0? at this point, we could do that. *only for cases where no other feature support detection mechanism could be used. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Kenneth Russell Sent: Monday, October 19, 2015 7:39 AM To: Florian B?sch Cc: public webgl Subject: Re: [Public WebGL] WebGL/ESSL version strings On Sun, Oct 18, 2015 at 4:02 AM, Florian B?sch > wrote: WebGL implementations report back the VERSION and SHADING_LANGUAGE_VERSION getParameter strings. VERSION It's my understanding there are only two valid values for the parameter VERSION: WebGL 1.0 and WebGL 2.0 at the time of this writing (afaik minor spec revision versions aren't reported). However, these are versions that are reported in the wild: * WebGL 0.9 * WebGL 0.91 * WebGL 0.92 * WebGL 0.93 * WebGL 0.94 * WebGL 0.95 * WebGL 1.0 SHADING_LANGUAGE_VERSION It's my Understanding that there are only two valid values for the parameter SHADING_LANGUAGE_VERSION: WebGL GLSL ES 1.0 and WebGL GLSL ES 2.0. However, these are values observed in the wild: * WebGL GLSL ES 0.9 * WebGL GLSL ES 0.91 * WebGL GLSL ES 0.92 * WebGL GLSL ES 0.93 * WebGL GLSL ES 0.94 * WebGL GLSL ES 0.95 * WebGL GLSL ES 1.0 Request for clarification I would like to inquire off the Khronos WebGL WG the following questions for clarification: * Is it correct that the only two valid versions to report here are 1.0 and 2.0? Yes. * If so (or not) should there be language in the specifications to clarify this? There's no need. The specification already says this. * Is it correct that official members to the Khronos WebGL WG are required to adhere to the standards set forth by the group and should not willfully deviate from the standard? Yes. I don't know which implementations are reporting these strings but they're not conformant. -Ken -------------- next part -------------- An HTML attachment was scrubbed... URL: From khr...@ Sun Oct 18 20:58:44 2015 From: khr...@ (Mark Callow) Date: Mon, 19 Oct 2015 12:58:44 +0900 Subject: [Public WebGL] WebGL/ESSL version strings In-Reply-To: References: Message-ID: > On Oct 19, 2015, at 9:11 AM, Frank Olivier wrote: > > Internet Explorer and Microsoft Edge report these <1.0 version strings; the goal here was to enable feature support detection* as we update the renderer several times year. > > The goal has always been to use ?1.0? as soon as we had a fully conformant implementation, and to update devices so that we get to ?1.0? everywhere; we?ve received feedback from developers that they find the 0.01 increments useful. > > That said, if it is more useful to change to ?1.0? at this point, we could do that. > ? <> > > *only for cases where no other feature support detection mechanism could be used. > I think non-conformant implementations should provide only an ?experimental-webgl? context not a ?webgl? context. I can?t recall if we formally decided this, I think we did, and I do not know which is provided by IE and Edge at present. gl.VENDOR could be used to provide feature detection for ?experimental-webgl? contexts. I think gl.VERSION should be reserved for the official API version number, even if the implementation is not yet fully conformant to that version. > On Oct 18, 2015, at 8:02 PM, Florian B?sch wrote: > > (afaik minor spec revision versions aren't reported). Correct. gl.VERSION is for the API version not the spec version. Spec revisions do not change the API (except under exceptional circumstances). Regards -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From Fra...@ Mon Oct 19 02:00:10 2015 From: Fra...@ (Frank Olivier) Date: Mon, 19 Oct 2015 09:00:10 +0000 Subject: [Public WebGL] WebGL/ESSL version strings In-Reply-To: References: Message-ID: Internet Explorer and Microsoft Edge provide the ?experimental-webgl? context only; as soon as we had a fully conformant implementation we?ll provide ?webgl? as well. From: Mark Callow [mailto:khronos...@] Sent: Monday, October 19, 2015 12:59 PM To: Frank Olivier Cc: Kenneth Russell ; Florian B?sch ; public webgl Subject: Re: [Public WebGL] WebGL/ESSL version strings On Oct 19, 2015, at 9:11 AM, Frank Olivier > wrote: Internet Explorer and Microsoft Edge report these <1.0 version strings; the goal here was to enable feature support detection* as we update the renderer several times year. The goal has always been to use ?1.0? as soon as we had a fully conformant implementation, and to update devices so that we get to ?1.0? everywhere; we?ve received feedback from developers that they find the 0.01 increments useful. That said, if it is more useful to change to ?1.0? at this point, we could do that. *only for cases where no other feature support detection mechanism could be used. I think non-conformant implementations should provide only an ?experimental-webgl? context not a ?webgl? context. I can?t recall if we formally decided this, I think we did, and I do not know which is provided by IE and Edge at present. gl.VENDOR could be used to provide feature detection for ?experimental-webgl? contexts. I think gl.VERSION should be reserved for the official API version number, even if the implementation is not yet fully conformant to that version. On Oct 18, 2015, at 8:02 PM, Florian B?sch > wrote: (afaik minor spec revision versions aren't reported). Correct. gl.VERSION is for the API version not the spec version. Spec revisions do not change the API (except under exceptional circumstances). Regards -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Thu Oct 29 14:03:09 2015 From: jgi...@ (Jeff Gilbert) Date: Thu, 29 Oct 2015 14:03:09 -0700 Subject: [Public WebGL] Out-of-bounds ReadPixels and CopyTex*Image* behavior Message-ID: We standardized this to read zeros in WebGL 1. However, this is trickier in WebGL 2 because of PBOs and the new PACK_ pixelstore options. I propose that we change this (at least for WebGL 2) to "Out-of-bounds pixels are not written to the destination during reads from a framebuffer (ReadPixels or CopyTex*Image*), leaving the values in the destination buffer unchanged. Partially-out-of-bounds reads will only write in-bounds pixels to the destination buffer." This should be at easy or easier to implement, and be much more performant, since implementations can just restrict the size of their read and draw rects for these operations. I would really rather make out-of-bounds reads of this sort an INVALID_OPERATION, but a change to an error is more likely to be breaking in terms of existing content. While it's also a breaking change from OpenGL, I don't believe it is a porting concern, since porting can be fixed by changing its behavior to match what I outline above at the Emscripten (or other) level, though. ----------------------------------------------------------- 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 -----------------------------------------------------------