From baj...@ Mon Apr 11 15:55:23 2016 From: baj...@ (Brandon Jones) Date: Mon, 11 Apr 2016 22:55:23 +0000 Subject: [Public WebGL] Propose moving EXT_color_buffer_float to community approved In-Reply-To: <580CAB29-2E84-4AEF-A75D-805D40A29AF3@callow.im> References: <580CAB29-2E84-4AEF-A75D-805D40A29AF3@callow.im> Message-ID: Slow to respond to this one, but I'm supportive of moving it to community approved as well. On Mon, Mar 28, 2016 at 6:10 PM Mark Callow wrote: > > On Mar 29, 2016, at 8:02 AM, Kenneth Russell wrote: > > Any other comments? Hoping for feedback from Mark Callow and Jeff Gilbert > as well. > > > I have no objections. I?ll be happy to see the extension enabled by > default. > > Regards > > > -Mark > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmi...@ Wed Apr 13 07:45:20 2016 From: dmi...@ (Kirill Dmitrenko) Date: Wed, 13 Apr 2016 17:45:20 +0300 Subject: [Public WebGL] ImageBitmap as TexImageSource Message-ID: <199011460558720@webcorp02e.yandex-team.ru> Hi guys! Let's add ImageBitmap as TexImageSource to WebGL and WebGL 2 specs. Later one actually mentions ImageBitmap, but doesn't explicitly define it as TexImageSource. And it already works in Chrome (for WebGL at least, but it seems there still are some issues with blocking). -- 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 jun...@ Wed Apr 13 12:05:14 2016 From: jun...@ (Justin Novosad) Date: Wed, 13 Apr 2016 15:05:14 -0400 Subject: [Public WebGL] ImageBitmap as TexImageSource In-Reply-To: <199011460558720@webcorp02e.yandex-team.ru> References: <199011460558720@webcorp02e.yandex-team.ru> Message-ID: This has already been done: https://github.com/KhronosGroup/WebGL/pull/1424 typedef (ImageBitmap or ImageData or HTMLImageElement or HTMLCanvasElement or HTMLVideoElement) TexImageSource; On Wed, Apr 13, 2016 at 10:45 AM, Kirill Dmitrenko wrote: > > Hi guys! > > Let's add ImageBitmap as TexImageSource to WebGL and WebGL 2 specs. Later > one actually mentions ImageBitmap, but doesn't explicitly define it as > TexImageSource. And it already works in Chrome (for WebGL at least, but it > seems there still are some issues with blocking). > > -- > 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 > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Wed Apr 13 16:08:47 2016 From: kbr...@ (Kenneth Russell) Date: Wed, 13 Apr 2016 16:08:47 -0700 Subject: [Public WebGL] ImageBitmap as TexImageSource In-Reply-To: References: <199011460558720@webcorp02e.yandex-team.ru> Message-ID: Justin's correct. ImageBitmap support is added in the editors' drafts of the WebGL 1.0 and 2.0 specs: https://www.khronos.org/registry/webgl/specs/latest/1.0/ https://www.khronos.org/registry/webgl/specs/latest/2.0/ -Ken On Wed, Apr 13, 2016 at 12:05 PM, Justin Novosad wrote: > This has already been done: > https://github.com/KhronosGroup/WebGL/pull/1424 > > typedef (ImageBitmap or > ImageData or > HTMLImageElement or > HTMLCanvasElement or > HTMLVideoElement) TexImageSource; > > > On Wed, Apr 13, 2016 at 10:45 AM, Kirill Dmitrenko > wrote: > >> >> Hi guys! >> >> Let's add ImageBitmap as TexImageSource to WebGL and WebGL 2 specs. Later >> one actually mentions ImageBitmap, but doesn't explicitly define it as >> TexImageSource. And it already works in Chrome (for WebGL at least, but it >> seems there still are some issues with blocking). >> >> -- >> 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 >> ----------------------------------------------------------- >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Wed Apr 13 22:39:01 2016 From: kbr...@ (Kenneth Russell) Date: Wed, 13 Apr 2016 22:39:01 -0700 Subject: [Public WebGL] Propose moving EXT_color_buffer_float to community approved In-Reply-To: References: <580CAB29-2E84-4AEF-A75D-805D40A29AF3@callow.im> Message-ID: Thanks all for your feedback. It's been moved to community approved. -Ken On Mon, Apr 11, 2016 at 3:55 PM, Brandon Jones wrote: > Slow to respond to this one, but I'm supportive of moving it to community > approved as well. > > On Mon, Mar 28, 2016 at 6:10 PM Mark Callow wrote: > >> >> On Mar 29, 2016, at 8:02 AM, Kenneth Russell wrote: >> >> Any other comments? Hoping for feedback from Mark Callow and Jeff Gilbert >> as well. >> >> >> I have no objections. I?ll be happy to see the extension enabled by >> default. >> >> Regards >> >> >> -Mark >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Wed Apr 13 22:47:02 2016 From: kbr...@ (Kenneth Russell) Date: Wed, 13 Apr 2016 22:47:02 -0700 Subject: [Public WebGL] WEBGL_subscribe_uniform extension In-Reply-To: References: <149461459196318@webcorp01d.yandex-team.ru> Message-ID: WEBGL_subscribe_uniform has been moved to rejected status. -Ken On Mon, Mar 28, 2016 at 2:52 PM, Kenneth Russell wrote: > Apologies for the long delay revisiting this topic. > > At this point I agree with rejecting this extension. It was always > difficult to understand how it would be used effectively by applications, > since the values the GPU saw would be a frame or two ahead of the CPU-side > code. Additionally, nobody's working on the code any more. The most > profitable thing to do at this point is to work on reducing the latency of > all WebGL implementations, rather than working around the latency of > specific ones. > > Any other comments? > > -Ken > > > > On Mon, Mar 28, 2016 at 1:18 PM, Kirill Dmitrenko > wrote: > >> I support. More over, I think, the problem is more general and does >> affect not only WebGL, but the whole platform. Thus more general solution >> has to be introduced. Like a function to request current state of user >> input devices (as, if understand correctly, done in gamepad API). >> >> 28.03.2016, 20:04, "Florian B?sch" : >> >> I suggest to move the WEBGL_subscribe_uniform extension to rejected, for >> the following reasons: >> >> 1. Asynchronous Time Warp (ATW, >> https://developer.oculus.com/blog/asynchronous-timewarp-on-oculus-rift/) >> is the preferred method to ensure most up to date HMD input -> display >> transform. This removes the main motivation for this extension. >> 2. No further input has been provided on this extension in 16 months >> 3. No evaluation beyond the initial prototype has occured for 22 >> fmonths >> 4. The extension no longer has a champion since 16 months >> 5. No other champion has come forward in the last 16 months >> 6. The issues around the extension formulation have not been >> addressed for 20 months. >> >> Repeated calls for a new maintainer the extension have gone unanswered >> with the last occurring over 12 months ago. >> >> I would also like to state on record that I think it's poor form to >> introduce an extension to the registry without the necessary commitment to >> see it trough to its conclusion. I strongly disapprove of this sort of >> registry littering with garbage. >> >> >> >> -- >> Kirill Dmitrenko >> Yandex Maps Team >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmi...@ Thu Apr 14 05:59:28 2016 From: dmi...@ (Kirill Dmitrenko) Date: Thu, 14 Apr 2016 15:59:28 +0300 Subject: [Public WebGL] ImageBitmap as TexImageSource In-Reply-To: References: <199011460558720@webcorp02e.yandex-team.ru> Message-ID: <373551460638768@webcorp02f.yandex-team.ru> An HTML attachment was scrubbed... URL: From khr...@ Thu Apr 21 04:18:14 2016 From: khr...@ (Gregg Tavares) Date: Thu, 21 Apr 2016 20:18:14 +0900 Subject: [Public WebGL] Queries in WebGL 2.0 Message-ID: I didn't follow any public discussion of this feature but ... I'm already seeing people posting bad code which will just keep propagating forever Example from SO var query = gl.createQuery(); gl.beginQuery(gl.ANY_SAMPLES_PASSED, query);// ... draw a small quad at the specified 3d position ... gl.endQuery(gl.ANY_SAMPLES_PASSED);// some time later, typically a few frames later (after a fraction of a second) gl.getQueryParameter(query, gl.QUERY_RESULT); Shouldn't the spec require correct behavior? Basically you have to call gl.getQueryParameter(query, gl.QUERY_RESULT_AVAILABLE) and it has to return true or gl.getQueryParameter(query, gl.QUERY_RESULT); should generate INVALID_OPERATION I suppose that doesn't really fix the issue because people can just put gl.getQueryParameter(query, gl.QUERY_RESULT_AVAILABLE) // ignore result and pray gl.getQueryParameter(query, gl.QUERY_RESULT) If WebGL 2 is supposed to be an API that works everywhere shouldn't the API at least try to help people not write code that won't actually work everywhere? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmi...@ Thu Apr 21 08:15:25 2016 From: dmi...@ (Kirill Dmitrenko) Date: Thu, 21 Apr 2016 18:15:25 +0300 Subject: [Public WebGL] Queries in WebGL 2.0 In-Reply-To: References: Message-ID: <44681461251725@webcorp02h.yandex-team.ru> I think using ES6 Promise would be most reliable way to stop people using aforementioned snippet: gl.getQueryParameter(query, gl.QUERY_RESULT).then((result) => /* ... */); But it may be too big of a change and, if I understand correctly, can introduce some problems with coming WebAssembly. 21.04.2016, 15:31, "Gregg Tavares" : > I didn't follow any public discussion of this feature but ... I'm already seeing people posting bad code which will just keep propagating forever > > Example from SO > > var query = gl.createQuery(); gl.beginQuery(gl.ANY_SAMPLES_PASSED, query); // ... draw a small quad at the specified 3d position ... gl.endQuery(gl.ANY_SAMPLES_PASSED); // some time later, typically a few frames later (after a fraction of a second) gl.getQueryParameter(query, gl.QUERY_RESULT); > > Shouldn't the spec require correct behavior? Basically you have to call > > ? ? ?gl.getQueryParameter(query, gl.QUERY_RESULT_AVAILABLE) > > and it has to return true or > > ? ? ?gl.getQueryParameter(query, gl.QUERY_RESULT); > > should generate INVALID_OPERATION > > I suppose that doesn't really fix the issue because people can just put > > ? ? ?gl.getQueryParameter(query, gl.QUERY_RESULT_AVAILABLE) ? // ignore result and pray > ? ? ?gl.getQueryParameter(query, gl.QUERY_RESULT) > > If WebGL 2 is supposed to be an API that works everywhere shouldn't the API at least try to help people not write code that won't actually work everywhere? -- 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 jgi...@ Thu Apr 21 09:23:16 2016 From: jgi...@ (Jeff Gilbert) Date: Thu, 21 Apr 2016 09:23:16 -0700 Subject: [Public WebGL] Queries in WebGL 2.0 In-Reply-To: <44681461251725@webcorp02h.yandex-team.ru> References: <44681461251725@webcorp02h.yandex-team.ru> Message-ID: This is akin to using a framebuffer without checking if it's complete. I don't think we should handhold this at the spec level. I think it could be useful to add a browser pref to add a (longer) delay to query availability. On Thu, Apr 21, 2016 at 8:15 AM, Kirill Dmitrenko wrote: > > I think using ES6 Promise would be most reliable way to stop people using aforementioned snippet: > > gl.getQueryParameter(query, gl.QUERY_RESULT).then((result) => /* ... */); > > But it may be too big of a change and, if I understand correctly, can introduce some problems with coming WebAssembly. > > 21.04.2016, 15:31, "Gregg Tavares" : >> I didn't follow any public discussion of this feature but ... I'm already seeing people posting bad code which will just keep propagating forever >> >> Example from SO >> >> var query = gl.createQuery(); gl.beginQuery(gl.ANY_SAMPLES_PASSED, query); // ... draw a small quad at the specified 3d position ... gl.endQuery(gl.ANY_SAMPLES_PASSED); // some time later, typically a few frames later (after a fraction of a second) gl.getQueryParameter(query, gl.QUERY_RESULT); >> >> Shouldn't the spec require correct behavior? Basically you have to call >> >> gl.getQueryParameter(query, gl.QUERY_RESULT_AVAILABLE) >> >> and it has to return true or >> >> gl.getQueryParameter(query, gl.QUERY_RESULT); >> >> should generate INVALID_OPERATION >> >> I suppose that doesn't really fix the issue because people can just put >> >> gl.getQueryParameter(query, gl.QUERY_RESULT_AVAILABLE) // ignore result and pray >> gl.getQueryParameter(query, gl.QUERY_RESULT) >> >> If WebGL 2 is supposed to be an API that works everywhere shouldn't the API at least try to help people not write code that won't actually work everywhere? > > > -- > 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 > ----------------------------------------------------------- > ----------------------------------------------------------- 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 kgi...@ Thu Apr 21 10:19:09 2016 From: kgi...@ (kgi...@) Date: Thu, 21 Apr 2016 10:19:09 -0700 Subject: [Public WebGL] Queries in WebGL 2.0 In-Reply-To: References: <44681461251725@webcorp02h.yandex-team.ru> Message-ID: <4AA35ECB-0AC6-4523-ABE3-E10200A67685@mozilla.com> On OpenGL ES, checking if the query result is available is optional, and only needed to determine if getting the query result will cause a pipeline stall. In some cases, you have no choice but to stall the pipeline because without the query information, you can not correctly render the next frame. Is this intended to differ in WebGL? Cheers, - Kearwood "Kip" Gilbert > On Apr 21, 2016, at 9:23 AM, Jeff Gilbert wrote: > > > This is akin to using a framebuffer without checking if it's complete. > I don't think we should handhold this at the spec level. > > I think it could be useful to add a browser pref to add a (longer) > delay to query availability. > >> On Thu, Apr 21, 2016 at 8:15 AM, Kirill Dmitrenko wrote: >> >> I think using ES6 Promise would be most reliable way to stop people using aforementioned snippet: >> >> gl.getQueryParameter(query, gl.QUERY_RESULT).then((result) => /* ... */); >> >> But it may be too big of a change and, if I understand correctly, can introduce some problems with coming WebAssembly. >> >> 21.04.2016, 15:31, "Gregg Tavares" : >>> I didn't follow any public discussion of this feature but ... I'm already seeing people posting bad code which will just keep propagating forever >>> >>> Example from SO >>> >>> var query = gl.createQuery(); gl.beginQuery(gl.ANY_SAMPLES_PASSED, query); // ... draw a small quad at the specified 3d position ... gl.endQuery(gl.ANY_SAMPLES_PASSED); // some time later, typically a few frames later (after a fraction of a second) gl.getQueryParameter(query, gl.QUERY_RESULT); >>> >>> Shouldn't the spec require correct behavior? Basically you have to call >>> >>> gl.getQueryParameter(query, gl.QUERY_RESULT_AVAILABLE) >>> >>> and it has to return true or >>> >>> gl.getQueryParameter(query, gl.QUERY_RESULT); >>> >>> should generate INVALID_OPERATION >>> >>> I suppose that doesn't really fix the issue because people can just put >>> >>> gl.getQueryParameter(query, gl.QUERY_RESULT_AVAILABLE) // ignore result and pray >>> gl.getQueryParameter(query, gl.QUERY_RESULT) >>> >>> If WebGL 2 is supposed to be an API that works everywhere shouldn't the API at least try to help people not write code that won't actually work everywhere? >> >> >> -- >> 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 >> ----------------------------------------------------------- > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From jgi...@ Thu Apr 21 13:03:40 2016 From: jgi...@ (Jeff Gilbert) Date: Thu, 21 Apr 2016 13:03:40 -0700 Subject: [Public WebGL] Queries in WebGL 2.0 In-Reply-To: <4AA35ECB-0AC6-4523-ABE3-E10200A67685@mozilla.com> References: <44681461251725@webcorp02h.yandex-team.ru> <4AA35ECB-0AC6-4523-ABE3-E10200A67685@mozilla.com> Message-ID: kgilbert is absolutely correct, and this is how all specs are written to date. We actually need to add language to our specs to detail what happens when the query is not allowed to be available yet. Presumably this is INVALID_OP, but it's not currently detailed. Rules-as-written, same-frame QUERY_RESULT queries would spin the browser forever. :) On Thu, Apr 21, 2016 at 10:19 AM, wrote: > On OpenGL ES, checking if the query result is available is optional, and only needed to determine if getting the query result will cause a pipeline stall. In some cases, you have no choice but to stall the pipeline because without the query information, you can not correctly render the next frame. > > Is this intended to differ in WebGL? > > Cheers, > - Kearwood "Kip" Gilbert > >> On Apr 21, 2016, at 9:23 AM, Jeff Gilbert wrote: >> >> >> This is akin to using a framebuffer without checking if it's complete. >> I don't think we should handhold this at the spec level. >> >> I think it could be useful to add a browser pref to add a (longer) >> delay to query availability. >> >>> On Thu, Apr 21, 2016 at 8:15 AM, Kirill Dmitrenko wrote: >>> >>> I think using ES6 Promise would be most reliable way to stop people using aforementioned snippet: >>> >>> gl.getQueryParameter(query, gl.QUERY_RESULT).then((result) => /* ... */); >>> >>> But it may be too big of a change and, if I understand correctly, can introduce some problems with coming WebAssembly. >>> >>> 21.04.2016, 15:31, "Gregg Tavares" : >>>> I didn't follow any public discussion of this feature but ... I'm already seeing people posting bad code which will just keep propagating forever >>>> >>>> Example from SO >>>> >>>> var query = gl.createQuery(); gl.beginQuery(gl.ANY_SAMPLES_PASSED, query); // ... draw a small quad at the specified 3d position ... gl.endQuery(gl.ANY_SAMPLES_PASSED); // some time later, typically a few frames later (after a fraction of a second) gl.getQueryParameter(query, gl.QUERY_RESULT); >>>> >>>> Shouldn't the spec require correct behavior? Basically you have to call >>>> >>>> gl.getQueryParameter(query, gl.QUERY_RESULT_AVAILABLE) >>>> >>>> and it has to return true or >>>> >>>> gl.getQueryParameter(query, gl.QUERY_RESULT); >>>> >>>> should generate INVALID_OPERATION >>>> >>>> I suppose that doesn't really fix the issue because people can just put >>>> >>>> gl.getQueryParameter(query, gl.QUERY_RESULT_AVAILABLE) // ignore result and pray >>>> gl.getQueryParameter(query, gl.QUERY_RESULT) >>>> >>>> If WebGL 2 is supposed to be an API that works everywhere shouldn't the API at least try to help people not write code that won't actually work everywhere? >>> >>> >>> -- >>> 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 >>> ----------------------------------------------------------- >> >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> unsubscribe public_webgl >> ----------------------------------------------------------- >> ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Thu Apr 21 13:24:44 2016 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Thu, 21 Apr 2016 22:24:44 +0200 Subject: [Public WebGL] Queries in WebGL 2.0 In-Reply-To: References: <44681461251725@webcorp02h.yandex-team.ru> <4AA35ECB-0AC6-4523-ABE3-E10200A67685@mozilla.com> Message-ID: Generating a pipeline-stall to wait for a query is actually valid code. For instance, the result of an occlusion query would be quite useless a few frames later. On Thu, Apr 21, 2016 at 10:03 PM, Jeff Gilbert wrote: > > kgilbert is absolutely correct, and this is how all specs are written to > date. > > We actually need to add language to our specs to detail what happens > when the query is not allowed to be available yet. Presumably this is > INVALID_OP, but it's not currently detailed. Rules-as-written, > same-frame QUERY_RESULT queries would spin the browser forever. :) > > On Thu, Apr 21, 2016 at 10:19 AM, wrote: > > On OpenGL ES, checking if the query result is available is optional, and > only needed to determine if getting the query result will cause a pipeline > stall. In some cases, you have no choice but to stall the pipeline because > without the query information, you can not correctly render the next frame. > > > > Is this intended to differ in WebGL? > > > > Cheers, > > - Kearwood "Kip" Gilbert > > > >> On Apr 21, 2016, at 9:23 AM, Jeff Gilbert wrote: > >> > >> > >> This is akin to using a framebuffer without checking if it's complete. > >> I don't think we should handhold this at the spec level. > >> > >> I think it could be useful to add a browser pref to add a (longer) > >> delay to query availability. > >> > >>> On Thu, Apr 21, 2016 at 8:15 AM, Kirill Dmitrenko < > dmikis...@> wrote: > >>> > >>> I think using ES6 Promise would be most reliable way to stop people > using aforementioned snippet: > >>> > >>> gl.getQueryParameter(query, gl.QUERY_RESULT).then((result) => /* ... > */); > >>> > >>> But it may be too big of a change and, if I understand correctly, can > introduce some problems with coming WebAssembly. > >>> > >>> 21.04.2016, 15:31, "Gregg Tavares" : > >>>> I didn't follow any public discussion of this feature but ... I'm > already seeing people posting bad code which will just keep propagating > forever > >>>> > >>>> Example from SO > >>>> > >>>> var query = gl.createQuery(); gl.beginQuery(gl.ANY_SAMPLES_PASSED, > query); // ... draw a small quad at the specified 3d position ... > gl.endQuery(gl.ANY_SAMPLES_PASSED); // some time later, typically a few > frames later (after a fraction of a second) gl.getQueryParameter(query, > gl.QUERY_RESULT); > >>>> > >>>> Shouldn't the spec require correct behavior? Basically you have to > call > >>>> > >>>> gl.getQueryParameter(query, gl.QUERY_RESULT_AVAILABLE) > >>>> > >>>> and it has to return true or > >>>> > >>>> gl.getQueryParameter(query, gl.QUERY_RESULT); > >>>> > >>>> should generate INVALID_OPERATION > >>>> > >>>> I suppose that doesn't really fix the issue because people can just > put > >>>> > >>>> gl.getQueryParameter(query, gl.QUERY_RESULT_AVAILABLE) // > ignore result and pray > >>>> gl.getQueryParameter(query, gl.QUERY_RESULT) > >>>> > >>>> If WebGL 2 is supposed to be an API that works everywhere shouldn't > the API at least try to help people not write code that won't actually work > everywhere? > >>> > >>> > >>> -- > >>> 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 > >>> ----------------------------------------------------------- > >> > >> ----------------------------------------------------------- > >> You are currently subscribed to public_webgl...@ > >> To unsubscribe, send an email to majordomo...@ with > >> the following command in the body of your email: > >> unsubscribe public_webgl > >> ----------------------------------------------------------- > >> > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Thu Apr 21 18:17:38 2016 From: kbr...@ (Kenneth Russell) Date: Thu, 21 Apr 2016 18:17:38 -0700 Subject: [Public WebGL] Queries in WebGL 2.0 In-Reply-To: References: <44681461251725@webcorp02h.yandex-team.ru> <4AA35ECB-0AC6-4523-ABE3-E10200A67685@mozilla.com> Message-ID: WebGL deliberately changes the semantics of queries' results to prevent client code from stalling the pipeline. Code needs to be adjusted to anticipate that queries' results will not be made available in the current frame, but instead in subsequent frames. This was a deliberate design decision that Gregg helped inform. Tests have been written for it and adjusted for the difference in behavior compared to ES 3.0. See https://www.khronos.org/registry/webgl/specs/latest/2.0/#5.23 for more details. -Ken On Thu, Apr 21, 2016 at 1:24 PM, Florian B?sch wrote: > Generating a pipeline-stall to wait for a query is actually valid code. > For instance, the result of an occlusion query would be quite useless a few > frames later. > > On Thu, Apr 21, 2016 at 10:03 PM, Jeff Gilbert > wrote: > >> >> kgilbert is absolutely correct, and this is how all specs are written to >> date. >> >> We actually need to add language to our specs to detail what happens >> when the query is not allowed to be available yet. Presumably this is >> INVALID_OP, but it's not currently detailed. Rules-as-written, >> same-frame QUERY_RESULT queries would spin the browser forever. :) >> >> On Thu, Apr 21, 2016 at 10:19 AM, wrote: >> > On OpenGL ES, checking if the query result is available is optional, >> and only needed to determine if getting the query result will cause a >> pipeline stall. In some cases, you have no choice but to stall the >> pipeline because without the query information, you can not correctly >> render the next frame. >> > >> > Is this intended to differ in WebGL? >> > >> > Cheers, >> > - Kearwood "Kip" Gilbert >> > >> >> On Apr 21, 2016, at 9:23 AM, Jeff Gilbert >> wrote: >> >> >> >> >> >> This is akin to using a framebuffer without checking if it's complete. >> >> I don't think we should handhold this at the spec level. >> >> >> >> I think it could be useful to add a browser pref to add a (longer) >> >> delay to query availability. >> >> >> >>> On Thu, Apr 21, 2016 at 8:15 AM, Kirill Dmitrenko < >> dmikis...@> wrote: >> >>> >> >>> I think using ES6 Promise would be most reliable way to stop people >> using aforementioned snippet: >> >>> >> >>> gl.getQueryParameter(query, gl.QUERY_RESULT).then((result) => /* ... >> */); >> >>> >> >>> But it may be too big of a change and, if I understand correctly, can >> introduce some problems with coming WebAssembly. >> >>> >> >>> 21.04.2016, 15:31, "Gregg Tavares" : >> >>>> I didn't follow any public discussion of this feature but ... I'm >> already seeing people posting bad code which will just keep propagating >> forever >> >>>> >> >>>> Example from SO >> >>>> >> >>>> var query = gl.createQuery(); gl.beginQuery(gl.ANY_SAMPLES_PASSED, >> query); // ... draw a small quad at the specified 3d position ... >> gl.endQuery(gl.ANY_SAMPLES_PASSED); // some time later, typically a few >> frames later (after a fraction of a second) gl.getQueryParameter(query, >> gl.QUERY_RESULT); >> >>>> >> >>>> Shouldn't the spec require correct behavior? Basically you have to >> call >> >>>> >> >>>> gl.getQueryParameter(query, gl.QUERY_RESULT_AVAILABLE) >> >>>> >> >>>> and it has to return true or >> >>>> >> >>>> gl.getQueryParameter(query, gl.QUERY_RESULT); >> >>>> >> >>>> should generate INVALID_OPERATION >> >>>> >> >>>> I suppose that doesn't really fix the issue because people can just >> put >> >>>> >> >>>> gl.getQueryParameter(query, gl.QUERY_RESULT_AVAILABLE) // >> ignore result and pray >> >>>> gl.getQueryParameter(query, gl.QUERY_RESULT) >> >>>> >> >>>> If WebGL 2 is supposed to be an API that works everywhere shouldn't >> the API at least try to help people not write code that won't actually work >> everywhere? >> >>> >> >>> >> >>> -- >> >>> 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 >> >>> ----------------------------------------------------------- >> >> >> >> ----------------------------------------------------------- >> >> You are currently subscribed to public_webgl...@ >> >> To unsubscribe, send an email to majordomo...@ with >> >> the following command in the body of your email: >> >> unsubscribe public_webgl >> >> ----------------------------------------------------------- >> >> >> >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> unsubscribe public_webgl >> ----------------------------------------------------------- >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Thu Apr 21 19:16:11 2016 From: jgi...@ (Jeff Gilbert) Date: Thu, 21 Apr 2016 19:16:11 -0700 Subject: [Public WebGL] Queries in WebGL 2.0 In-Reply-To: References: <44681461251725@webcorp02h.yandex-team.ru> <4AA35ECB-0AC6-4523-ABE3-E10200A67685@mozilla.com> Message-ID: Well, sort of. We still allow pipeline stalls with this entrypoint, just not within a single JS 'frame'. Also the spec doesn't detail how a not-yet-available request fails. I suppose I can add this. On Thu, Apr 21, 2016 at 6:17 PM, Kenneth Russell wrote: > WebGL deliberately changes the semantics of queries' results to prevent > client code from stalling the pipeline. Code needs to be adjusted to > anticipate that queries' results will not be made available in the current > frame, but instead in subsequent frames. This was a deliberate design > decision that Gregg helped inform. Tests have been written for it and > adjusted for the difference in behavior compared to ES 3.0. See > https://www.khronos.org/registry/webgl/specs/latest/2.0/#5.23 for more > details. > > -Ken > > > On Thu, Apr 21, 2016 at 1:24 PM, Florian B?sch wrote: >> >> Generating a pipeline-stall to wait for a query is actually valid code. >> For instance, the result of an occlusion query would be quite useless a few >> frames later. >> >> On Thu, Apr 21, 2016 at 10:03 PM, Jeff Gilbert >> wrote: >>> >>> >>> kgilbert is absolutely correct, and this is how all specs are written to >>> date. >>> >>> We actually need to add language to our specs to detail what happens >>> when the query is not allowed to be available yet. Presumably this is >>> INVALID_OP, but it's not currently detailed. Rules-as-written, >>> same-frame QUERY_RESULT queries would spin the browser forever. :) >>> >>> On Thu, Apr 21, 2016 at 10:19 AM, wrote: >>> > On OpenGL ES, checking if the query result is available is optional, >>> > and only needed to determine if getting the query result will cause a >>> > pipeline stall. In some cases, you have no choice but to stall the pipeline >>> > because without the query information, you can not correctly render the next >>> > frame. >>> > >>> > Is this intended to differ in WebGL? >>> > >>> > Cheers, >>> > - Kearwood "Kip" Gilbert >>> > >>> >> On Apr 21, 2016, at 9:23 AM, Jeff Gilbert >>> >> wrote: >>> >> >>> >> >>> >> This is akin to using a framebuffer without checking if it's complete. >>> >> I don't think we should handhold this at the spec level. >>> >> >>> >> I think it could be useful to add a browser pref to add a (longer) >>> >> delay to query availability. >>> >> >>> >>> On Thu, Apr 21, 2016 at 8:15 AM, Kirill Dmitrenko >>> >>> wrote: >>> >>> >>> >>> I think using ES6 Promise would be most reliable way to stop people >>> >>> using aforementioned snippet: >>> >>> >>> >>> gl.getQueryParameter(query, gl.QUERY_RESULT).then((result) => /* ... >>> >>> */); >>> >>> >>> >>> But it may be too big of a change and, if I understand correctly, can >>> >>> introduce some problems with coming WebAssembly. >>> >>> >>> >>> 21.04.2016, 15:31, "Gregg Tavares" : >>> >>>> I didn't follow any public discussion of this feature but ... I'm >>> >>>> already seeing people posting bad code which will just keep propagating >>> >>>> forever >>> >>>> >>> >>>> Example from SO >>> >>>> >>> >>>> var query = gl.createQuery(); gl.beginQuery(gl.ANY_SAMPLES_PASSED, >>> >>>> query); // ... draw a small quad at the specified 3d position ... >>> >>>> gl.endQuery(gl.ANY_SAMPLES_PASSED); // some time later, typically a few >>> >>>> frames later (after a fraction of a second) gl.getQueryParameter(query, >>> >>>> gl.QUERY_RESULT); >>> >>>> >>> >>>> Shouldn't the spec require correct behavior? Basically you have to >>> >>>> call >>> >>>> >>> >>>> gl.getQueryParameter(query, gl.QUERY_RESULT_AVAILABLE) >>> >>>> >>> >>>> and it has to return true or >>> >>>> >>> >>>> gl.getQueryParameter(query, gl.QUERY_RESULT); >>> >>>> >>> >>>> should generate INVALID_OPERATION >>> >>>> >>> >>>> I suppose that doesn't really fix the issue because people can just >>> >>>> put >>> >>>> >>> >>>> gl.getQueryParameter(query, gl.QUERY_RESULT_AVAILABLE) // >>> >>>> ignore result and pray >>> >>>> gl.getQueryParameter(query, gl.QUERY_RESULT) >>> >>>> >>> >>>> If WebGL 2 is supposed to be an API that works everywhere shouldn't >>> >>>> the API at least try to help people not write code that won't actually work >>> >>>> everywhere? >>> >>> >>> >>> >>> >>> -- >>> >>> 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 >>> >>> ----------------------------------------------------------- >>> >> >>> >> ----------------------------------------------------------- >>> >> You are currently subscribed to public_webgl...@ >>> >> To unsubscribe, send an email to majordomo...@ with >>> >> the following command in the body of your email: >>> >> unsubscribe public_webgl >>> >> ----------------------------------------------------------- >>> >> >>> >>> ----------------------------------------------------------- >>> You are currently subscribed to public_webgl...@ >>> To unsubscribe, send an email to majordomo...@ with >>> the following command in the body of your email: >>> unsubscribe public_webgl >>> ----------------------------------------------------------- >>> >> > ----------------------------------------------------------- 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 dmi...@ Sat Apr 23 05:57:54 2016 From: dmi...@ (Kirill Dmitrenko) Date: Sat, 23 Apr 2016 15:57:54 +0300 Subject: [Public WebGL] Queries in WebGL 2.0 In-Reply-To: References: <44681461251725@webcorp02h.yandex-team.ru> Message-ID: <343531461416274@webcorp02f.yandex-team.ru> I don't think that is like the framebuffer completeness. WIth FBOs a developer have a reliable way to make it complete without checking it's status, whereas with queries there is no such way: one *need* to check available or one's code won't be reliable. Also, nobody commented on my suggestion to use promises to eliminate availability checking and force developers to obtain a query result properly. Why not make WebGL 2 a bit more JS-ish? Or are there design concerns prohibiting using promises? 21.04.2016, 19:23, "Jeff Gilbert" : > This is akin to using a framebuffer without checking if it's complete. > I don't think we should handhold this at the spec level. > > I think it could be useful to add a browser pref to add a (longer) > delay to query availability. > > On Thu, Apr 21, 2016 at 8:15 AM, Kirill Dmitrenko wrote: >> ?I think using ES6 Promise would be most reliable way to stop people using aforementioned snippet: >> >> ?gl.getQueryParameter(query, gl.QUERY_RESULT).then((result) => /* ... */); >> >> ?But it may be too big of a change and, if I understand correctly, can introduce some problems with coming WebAssembly. >> >> ?21.04.2016, 15:31, "Gregg Tavares" : >>> ?I didn't follow any public discussion of this feature but ... I'm already seeing people posting bad code which will just keep propagating forever >>> >>> ?Example from SO >>> >>> ?var query = gl.createQuery(); gl.beginQuery(gl.ANY_SAMPLES_PASSED, query); // ... draw a small quad at the specified 3d position ... gl.endQuery(gl.ANY_SAMPLES_PASSED); // some time later, typically a few frames later (after a fraction of a second) gl.getQueryParameter(query, gl.QUERY_RESULT); >>> >>> ?Shouldn't the spec require correct behavior? Basically you have to call >>> >>> ??????gl.getQueryParameter(query, gl.QUERY_RESULT_AVAILABLE) >>> >>> ?and it has to return true or >>> >>> ??????gl.getQueryParameter(query, gl.QUERY_RESULT); >>> >>> ?should generate INVALID_OPERATION >>> >>> ?I suppose that doesn't really fix the issue because people can just put >>> >>> ??????gl.getQueryParameter(query, gl.QUERY_RESULT_AVAILABLE) // ignore result and pray >>> ??????gl.getQueryParameter(query, gl.QUERY_RESULT) >>> >>> ?If WebGL 2 is supposed to be an API that works everywhere shouldn't the API at least try to help people not write code that won't actually work everywhere? >> >> ?-- >> ?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 >> ?----------------------------------------------------------- -- 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 kbr...@ Sat Apr 23 14:47:01 2016 From: kbr...@ (Kenneth Russell) Date: Sat, 23 Apr 2016 14:47:01 -0700 Subject: [Public WebGL] Queries in WebGL 2.0 In-Reply-To: <343531461416274@webcorp02f.yandex-team.ru> References: <44681461251725@webcorp02h.yandex-team.ru> <343531461416274@webcorp02f.yandex-team.ru> Message-ID: On Sat, Apr 23, 2016 at 5:57 AM, Kirill Dmitrenko wrote: > > I don't think that is like the framebuffer completeness. WIth FBOs a > developer have a reliable way to make it complete without checking it's > status, whereas with queries there is no such way: one *need* to check > available or one's code won't be reliable. > > Also, nobody commented on my suggestion to use promises to eliminate > availability checking and force developers to obtain a query result > properly. Why not make WebGL 2 a bit more JS-ish? Or are there design > concerns prohibiting using promises? > The expectation is that some applications may allocate ~1000 query objects per frame for things like timer queries. It was decided a while back that WebGL would stick to the C-like API to reduce the number of allocated objects and the number of promises the browser would need to track and later call. -Ken > > 21.04.2016, 19:23, "Jeff Gilbert" : > > This is akin to using a framebuffer without checking if it's complete. > > I don't think we should handhold this at the spec level. > > > > I think it could be useful to add a browser pref to add a (longer) > > delay to query availability. > > > > On Thu, Apr 21, 2016 at 8:15 AM, Kirill Dmitrenko > wrote: > >> I think using ES6 Promise would be most reliable way to stop people > using aforementioned snippet: > >> > >> gl.getQueryParameter(query, gl.QUERY_RESULT).then((result) => /* ... > */); > >> > >> But it may be too big of a change and, if I understand correctly, can > introduce some problems with coming WebAssembly. > >> > >> 21.04.2016, 15:31, "Gregg Tavares" : > >>> I didn't follow any public discussion of this feature but ... I'm > already seeing people posting bad code which will just keep propagating > forever > >>> > >>> Example from SO > >>> > >>> var query = gl.createQuery(); gl.beginQuery(gl.ANY_SAMPLES_PASSED, > query); // ... draw a small quad at the specified 3d position ... > gl.endQuery(gl.ANY_SAMPLES_PASSED); // some time later, typically a few > frames later (after a fraction of a second) gl.getQueryParameter(query, > gl.QUERY_RESULT); > >>> > >>> Shouldn't the spec require correct behavior? Basically you have to > call > >>> > >>> gl.getQueryParameter(query, gl.QUERY_RESULT_AVAILABLE) > >>> > >>> and it has to return true or > >>> > >>> gl.getQueryParameter(query, gl.QUERY_RESULT); > >>> > >>> should generate INVALID_OPERATION > >>> > >>> I suppose that doesn't really fix the issue because people can just > put > >>> > >>> gl.getQueryParameter(query, gl.QUERY_RESULT_AVAILABLE) // ignore > result and pray > >>> gl.getQueryParameter(query, gl.QUERY_RESULT) > >>> > >>> If WebGL 2 is supposed to be an API that works everywhere shouldn't > the API at least try to help people not write code that won't actually work > everywhere? > >> > >> -- > >> 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 > >> ----------------------------------------------------------- > > -- > 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 > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From juj...@ Wed Apr 27 06:08:37 2016 From: juj...@ (juj j) Date: Wed, 27 Apr 2016 16:08:37 +0300 Subject: [Public WebGL] Queries in WebGL 2.0 In-Reply-To: References: <44681461251725@webcorp02h.yandex-team.ru> <343531461416274@webcorp02f.yandex-team.ru> Message-ID: Hey, happy to see the agreement to C-like API here. Just wanted to comp that vote from the Emscripten side of the fence that WebGL remaining C-like is extremely critical for Unity3D and Unreal Engine 4 and other cross-compiled native GL codebases. Adding JS'y features would be fine, as long as they play nice with native code that targets GLES -> WebGL compilation. In a related note, when profiling causes of temporary JS object garbage and GC pressure in Unity/UE4, the WebGL API entry points currently are among the highest sources of per-frame trashers. This has been discussed a bit in https://bugzilla.mozilla.org/show_bug.cgi?id=973810. It would be very nice to have an allocation-free variant of the API, which would also improve performance. I presume nobody would be opposed to this kind of idea? 2016-04-24 0:47 GMT+03:00 Kenneth Russell : > On Sat, Apr 23, 2016 at 5:57 AM, Kirill Dmitrenko > wrote: > >> >> I don't think that is like the framebuffer completeness. WIth FBOs a >> developer have a reliable way to make it complete without checking it's >> status, whereas with queries there is no such way: one *need* to check >> available or one's code won't be reliable. >> >> Also, nobody commented on my suggestion to use promises to eliminate >> availability checking and force developers to obtain a query result >> properly. Why not make WebGL 2 a bit more JS-ish? Or are there design >> concerns prohibiting using promises? >> > > The expectation is that some applications may allocate ~1000 query objects > per frame for things like timer queries. It was decided a while back that > WebGL would stick to the C-like API to reduce the number of allocated > objects and the number of promises the browser would need to track and > later call. > > -Ken > > > > >> >> 21.04.2016, 19:23, "Jeff Gilbert" : >> > This is akin to using a framebuffer without checking if it's complete. >> > I don't think we should handhold this at the spec level. >> > >> > I think it could be useful to add a browser pref to add a (longer) >> > delay to query availability. >> > >> > On Thu, Apr 21, 2016 at 8:15 AM, Kirill Dmitrenko < >> dmikis...@> wrote: >> >> I think using ES6 Promise would be most reliable way to stop people >> using aforementioned snippet: >> >> >> >> gl.getQueryParameter(query, gl.QUERY_RESULT).then((result) => /* ... >> */); >> >> >> >> But it may be too big of a change and, if I understand correctly, can >> introduce some problems with coming WebAssembly. >> >> >> >> 21.04.2016, 15:31, "Gregg Tavares" : >> >>> I didn't follow any public discussion of this feature but ... I'm >> already seeing people posting bad code which will just keep propagating >> forever >> >>> >> >>> Example from SO >> >>> >> >>> var query = gl.createQuery(); gl.beginQuery(gl.ANY_SAMPLES_PASSED, >> query); // ... draw a small quad at the specified 3d position ... >> gl.endQuery(gl.ANY_SAMPLES_PASSED); // some time later, typically a few >> frames later (after a fraction of a second) gl.getQueryParameter(query, >> gl.QUERY_RESULT); >> >>> >> >>> Shouldn't the spec require correct behavior? Basically you have to >> call >> >>> >> >>> gl.getQueryParameter(query, gl.QUERY_RESULT_AVAILABLE) >> >>> >> >>> and it has to return true or >> >>> >> >>> gl.getQueryParameter(query, gl.QUERY_RESULT); >> >>> >> >>> should generate INVALID_OPERATION >> >>> >> >>> I suppose that doesn't really fix the issue because people can just >> put >> >>> >> >>> gl.getQueryParameter(query, gl.QUERY_RESULT_AVAILABLE) // >> ignore result and pray >> >>> gl.getQueryParameter(query, gl.QUERY_RESULT) >> >>> >> >>> If WebGL 2 is supposed to be an API that works everywhere shouldn't >> the API at least try to help people not write code that won't actually work >> everywhere? >> >> >> >> -- >> >> 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 >> >> ----------------------------------------------------------- >> >> -- >> 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 >> ----------------------------------------------------------- >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Apr 27 07:12:08 2016 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 27 Apr 2016 16:12:08 +0200 Subject: [Public WebGL] Queries in WebGL 2.0 In-Reply-To: References: <44681461251725@webcorp02h.yandex-team.ru> <343531461416274@webcorp02f.yandex-team.ru> Message-ID: On Wed, Apr 27, 2016 at 3:08 PM, juj j wrote: > > It would be very nice to have an allocation-free variant of the API > +1 the WebGL API should be zero GC (assuming no create/delete/forget trashing is done by the application itself), I'd consider it a bug if it isn't. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmi...@ Wed Apr 27 08:17:43 2016 From: dmi...@ (Kirill Dmitrenko) Date: Wed, 27 Apr 2016 18:17:43 +0300 Subject: [Public WebGL] Queries in WebGL 2.0 In-Reply-To: References: <44681461251725@webcorp02h.yandex-team.ru> <343531461416274@webcorp02f.yandex-team.ru> Message-ID: <8381461770263@webcorp02e.yandex-team.ru> An HTML attachment was scrubbed... URL: From juj...@ Thu Apr 28 02:30:55 2016 From: juj...@ (juj j) Date: Thu, 28 Apr 2016 12:30:55 +0300 Subject: [Public WebGL] Queries in WebGL 2.0 In-Reply-To: <8381461770263@webcorp02e.yandex-team.ru> References: <44681461251725@webcorp02h.yandex-team.ru> <343531461416274@webcorp02f.yandex-team.ru> <8381461770263@webcorp02e.yandex-team.ru> Message-ID: I am not super well versed in knowledge of GC operation in browsers, though my understanding is that long-lived JS objects don't cause much GC pressure. Even though WebGL does have the high level WebGLBuffer, WebGLTexture, WebGLShader etc. objects, at least in Emscripten compiled GL code, these objects are generally not created and deleted at high frequency at all. If one needs, say, dynamic textures, one might create and reuse them from a custom maintained pool. From the high level interface objects, the WebGLUniformLocation type is the most painful, since there can be hundreds of these per program, and we need to maintain a big table of int<->WebGLUniformLocation assignment mappings for them, though these mappings are also very persistent across application frames. The large amount of per-frame GC pressure comes from the functions that take in a BufferDataSource or ArrayBufferView WebIDL parameters. In WebGL 1 these are buffer{Sub}Data, compressedTex{Sub}Image2D, readPixels, tex{Sub}Image2D, uniform{1,2,3,4}{i,f}v, uniformMatrix{2,3,4}fv and vertexAttrib{1,2,3,4}fv. The GC pressure is because one needs to prepare a suitable typed array view that is of correct size. In Emscripten we represent memory as a linear heap, so we don't have such typed arrays ready that would be long-lived in memory, but need to create them on demand. Some of these functions are called with very high frequency, often multiple times per each draw, uniform{1,2,3,4}{i,f}v and uniformMatrix{2,3,4}fv being the most common, followed by bufferSubData and texSubImage2D. This would create thousands of temporary JS typed array view allocations per frame, so we create these kind of pooling hacks for the most commonly sized small views: https://github.com/kripken/emscripten/blob/incoming/src/library_gl.js#L71 and https://github.com/kripken/emscripten/blob/incoming/src/library_gl.js#L2669. This scheme alleviates the problem, but trades it for some lost performance, since we need to copy the data over, as shown in the second link. For compiled GL code case, if each of these functions that took in an array buffer (view) would have a variant that additionally takes in offset and length, that would lift all of this shuffling altogether, since we could just point the array buffer view parameter to the asm.js HEAP and provide the subrange in the heap in the function call. In any case, did not mean to derail this topic, except to voice that we definitely value having the 1:1 C-like mapping wherever possible, since that ensures there's as little performance and features lost in the runtime GLES->WebGL translation layer as possible, compared to native. In my opinion, having JS'y APIs (in addition) is ok, as long as that API is suitable for functioning as a compilation target as well, or if there is an additional C-like API in parallel. 2016-04-27 18:17 GMT+03:00 Kirill Dmitrenko : > I'm not defending my point (completely agree with you guys). But WebGL API > might already create a considerable pressure on GC due to the fact that > every GL entity is wrapped in it's own JS object, doesn't it? > > 27.04.2016, 17:12, "Florian B?sch" : > > On Wed, Apr 27, 2016 at 3:08 PM, juj j wrote: > > It would be very nice to have an allocation-free variant of the API > > +1 the WebGL API should be zero GC (assuming no create/delete/forget > trashing is done by the application itself), I'd consider it a bug if it > isn't. > > > > -- > Kirill Dmitrenko > Yandex Maps Team > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Thu Apr 28 02:38:34 2016 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Thu, 28 Apr 2016 11:38:34 +0200 Subject: [Public WebGL] Queries in WebGL 2.0 In-Reply-To: References: <44681461251725@webcorp02h.yandex-team.ru> <343531461416274@webcorp02f.yandex-team.ru> <8381461770263@webcorp02e.yandex-team.ru> Message-ID: > For compiled GL code case, if each of these functions that took in an array buffer (view) would have a variant that additionally takes in offset and length I don't think that the semantic of taking in a view object is going to change. However, if you had an ArrayBufferView that you can shift in offset and length as in: view.shift(offset, length); bufferSubData(view); That'd solve the object allocation issue. The view allocation stuff has been a longstanding and unresolved issue of emscripten. On Thu, Apr 28, 2016 at 11:30 AM, juj j wrote: > I am not super well versed in knowledge of GC operation in browsers, > though my understanding is that long-lived JS objects don't cause much GC > pressure. Even though WebGL does have the high level WebGLBuffer, > WebGLTexture, WebGLShader etc. objects, at least in Emscripten compiled GL > code, these objects are generally not created and deleted at high frequency > at all. If one needs, say, dynamic textures, one might create and reuse > them from a custom maintained pool. From the high level interface objects, > the WebGLUniformLocation type is the most painful, since there can be > hundreds of these per program, and we need to maintain a big table of > int<->WebGLUniformLocation assignment mappings for them, though these > mappings are also very persistent across application frames. > > The large amount of per-frame GC pressure comes from the functions that > take in a BufferDataSource or ArrayBufferView WebIDL parameters. In WebGL 1 > these are buffer{Sub}Data, compressedTex{Sub}Image2D, readPixels, > tex{Sub}Image2D, uniform{1,2,3,4}{i,f}v, uniformMatrix{2,3,4}fv and > vertexAttrib{1,2,3,4}fv. The GC pressure is because one needs to prepare a > suitable typed array view that is of correct size. In Emscripten we > represent memory as a linear heap, so we don't have such typed arrays ready > that would be long-lived in memory, but need to create them on demand. Some > of these functions are called with very high frequency, often multiple > times per each draw, uniform{1,2,3,4}{i,f}v and uniformMatrix{2,3,4}fv > being the most common, followed by bufferSubData and texSubImage2D. This > would create thousands of temporary JS typed array view allocations per > frame, so we create these kind of pooling hacks for the most commonly sized > small views: > https://github.com/kripken/emscripten/blob/incoming/src/library_gl.js#L71 > and > https://github.com/kripken/emscripten/blob/incoming/src/library_gl.js#L2669. > This scheme alleviates the problem, but trades it for some lost > performance, since we need to copy the data over, as shown in the second > link. > > For compiled GL code case, if each of these functions that took in an > array buffer (view) would have a variant that additionally takes in offset > and length, that would lift all of this shuffling altogether, since we > could just point the array buffer view parameter to the asm.js HEAP and > provide the subrange in the heap in the function call. > > In any case, did not mean to derail this topic, except to voice that we > definitely value having the 1:1 C-like mapping wherever possible, since > that ensures there's as little performance and features lost in the runtime > GLES->WebGL translation layer as possible, compared to native. In my > opinion, having JS'y APIs (in addition) is ok, as long as that API is > suitable for functioning as a compilation target as well, or if there is an > additional C-like API in parallel. > > > 2016-04-27 18:17 GMT+03:00 Kirill Dmitrenko : > >> I'm not defending my point (completely agree with you guys). But WebGL >> API might already create a considerable pressure on GC due to the fact that >> every GL entity is wrapped in it's own JS object, doesn't it? >> >> 27.04.2016, 17:12, "Florian B?sch" : >> >> On Wed, Apr 27, 2016 at 3:08 PM, juj j wrote: >> >> It would be very nice to have an allocation-free variant of the API >> >> +1 the WebGL API should be zero GC (assuming no create/delete/forget >> trashing is done by the application itself), I'd consider it a bug if it >> isn't. >> >> >> >> -- >> Kirill Dmitrenko >> Yandex Maps Team >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: