From pub...@ Thu May 2 14:41:26 2019 From: pub...@ (Ken Russell (...@...)) Date: Thu, 2 May 2019 14:41:26 -0700 Subject: [Public WebGL] Uses of WEBGL_debug_renderer_info Message-ID: Dear WebGL community, There have been some recent discussions about the exposure of the WEBGL_debug_renderer_info extension, as it relates to user privacy and fingerprinting. If you build a WebGL application that queries this extension, could you please reply (either on-list, or directly to me) and indicate what information you infer, directly or indirectly, from it? Could the WebGL API provide this information via a different mechanism? Thanks, -Ken -------------- next part -------------- An HTML attachment was scrubbed... URL: From pub...@ Fri May 3 03:52:02 2019 From: pub...@ (Ashley Gullen (...@...)) Date: Fri, 3 May 2019 11:52:02 +0100 Subject: [Public WebGL] Uses of WEBGL_debug_renderer_info In-Reply-To: References: Message-ID: We build a HTML5 game engine and have used the unmasked renderer for: - identifying GPUs affected by driver bugs, and working around it (e.g. "Mali" on Android) - analytics on the unmasked renderer to identify the impact of such bugs and help us decide how to respond - identifying which GPU is really in use on dual-GPU systems - displaying it to the user as a diagnostic (also for them to identify which GPU is in use) On Thu, 2 May 2019 at 22:42, Ken Russell (kbr...@) < public_webgl...@> wrote: > Dear WebGL community, > > There have been some recent discussions about the exposure of the > WEBGL_debug_renderer_info extension, as it relates to user privacy and > fingerprinting. > > If you build a WebGL application that queries this extension, could you > please reply (either on-list, or directly to me) and indicate what > information you infer, directly or indirectly, from it? Could the WebGL API > provide this information via a different mechanism? > > Thanks, > > -Ken > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pub...@ Fri May 3 04:30:09 2019 From: pub...@ (=?UTF-8?Q?Jukka_Jyl=C3=A4nki?= (...@...)) Date: Fri, 3 May 2019 14:30:09 +0300 Subject: [Public WebGL] Uses of WEBGL_debug_renderer_info In-Reply-To: References: Message-ID: In addition to using exact GPU info for what Ashley mentions, we are also using exact GPU info+device+OS+browser to use as an additional bit of info to identify weak fillrate systems for whether to use "SD" or "HD" rendering (i.e. whether to render to 1:1 CSS pixels, or 1:1 with device pixels/retina resolution). pe 3. toukok. 2019 klo 13.53 Ashley Gullen (ashley...@) (public_webgl...@) kirjoitti: > > We build a HTML5 game engine and have used the unmasked renderer for: > - identifying GPUs affected by driver bugs, and working around it (e.g. "Mali" on Android) > - analytics on the unmasked renderer to identify the impact of such bugs and help us decide how to respond > - identifying which GPU is really in use on dual-GPU systems > - displaying it to the user as a diagnostic (also for them to identify which GPU is in use) > > > On Thu, 2 May 2019 at 22:42, Ken Russell (kbr...@) wrote: >> >> Dear WebGL community, >> >> There have been some recent discussions about the exposure of the WEBGL_debug_renderer_info extension, as it relates to user privacy and fingerprinting. >> >> If you build a WebGL application that queries this extension, could you please reply (either on-list, or directly to me) and indicate what information you infer, directly or indirectly, from it? Could the WebGL API provide this information via a different mechanism? >> >> Thanks, >> >> -Ken >> ----------------------------------------------------------- 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 pub...@ Fri May 3 06:18:44 2019 From: pub...@ (=?UTF-8?Q?Paul_Cheyrou=2DLagr=C3=A8ze?= (...@...)) Date: Fri, 3 May 2019 15:18:44 +0200 Subject: [Public WebGL] Uses of WEBGL_debug_renderer_info In-Reply-To: References: Message-ID: It's very useful for us; here are our two main use cases: 1) We use it very extensively to report user GPU in our automatic error reporting tools. When we need to reproduce shader bugs it's invaluable. We found many shader bugs directly linked to specific GPU vendors/renderers. >From visual artifact to compilation errors all tied to very specific vendor/renderer (Intel branching error, PowerVR glsl compiler not supporting vec4 arrays as function parameter, implicit cast fails in some cases on Mali, etc...). And Compiler Error messages are not enough "Internal compiler error: Too many vertex shader constants" (Adreno/android4.x.x favorite) 2) We also use it to warn users when they are switched to "software webgl acceleration " (Due to too many GPU crashes and Chrome reverting to SwiftShader) e.g. "if ( gl.getParameter(debugInfo.UNMASKED_RENDERER_WEBGL) === 'Google SwiftShader' )". Otherwise users might think the Sketchfab render is very slow, using their laptop batteries, and pushing laptop fan to the max where just restarting/reloading chrome fixes it. Thanks, -Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From pub...@ Fri May 3 07:56:27 2019 From: pub...@ (Evan Nowak (...@...)) Date: Fri, 3 May 2019 09:56:27 -0500 Subject: [Public WebGL] Uses of WEBGL_debug_renderer_info In-Reply-To: References: Message-ID: At Onshape we use WEBGL_debug_renderer_info for a few purposes: 1. To work around driver-specific interactions with our system. More often than not this involves disabling a feature of our renderer that is exhibiting poor performance on a particular platform/GPU combination. If possible, we will try to find an alternative solution that performs well on all platforms, but this is not always feasible. 2. To inform users when they may be experiencing reduced performance due to the use of an integrated GPU over a discrete one. We have seen a significant number of users complain about rendering performance only to discover later that they have a more powerful, discrete GPU going unused. We try to shorten this pain period by detecting systems that may have a discrete GPU alongside an integrated one, and notify the user when degraded rendering performance is detected. We are looking forward to a wider implementation of the ?powerPreference? option so the guesswork of which GPU is running will be avoided. 3. To collect statistics about the hardware makeup of our user base. This is helpful in understanding the spectrum of performance capabilities amongst our users. On Thu, May 2, 2019 at 4:42 PM Ken Russell (kbr...@) < public_webgl...@> wrote: > Dear WebGL community, > > There have been some recent discussions about the exposure of the > WEBGL_debug_renderer_info extension, as it relates to user privacy and > fingerprinting. > > If you build a WebGL application that queries this extension, could you > please reply (either on-list, or directly to me) and indicate what > information you infer, directly or indirectly, from it? Could the WebGL API > provide this information via a different mechanism? > > Thanks, > > -Ken > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pub...@ Fri May 3 12:50:42 2019 From: pub...@ (Jasper St. Pierre (...@...)) Date: Fri, 3 May 2019 19:50:42 +0000 Subject: [Public WebGL] Uses of WEBGL_debug_renderer_info In-Reply-To: References: , Message-ID: Hi, I use it to detect and work around known bugs in drivers, like Apple not supporting row-major matrices ( https://bugs.chromium.org/p/angleproject/issues/detail?id=2273 ), as well as providing better error messages to users (e.g. "Google SwiftShader"). The immediate impact if this extension was removed would be that all Apple devices would fail to render. ________________________________ From: "Jasper St. Pierre (jstpierre...@)" behalf of Evan Nowak (enowak...@) Sent: Friday, May 3, 2019 7:56:27 AM To: Public WebGL Subject: Re: [Public WebGL] Uses of WEBGL_debug_renderer_info At Onshape we use WEBGL_debug_renderer_info for a few purposes: 1. To work around driver-specific interactions with our system. More often than not this involves disabling a feature of our renderer that is exhibiting poor performance on a particular platform/GPU combination. If possible, we will try to find an alternative solution that performs well on all platforms, but this is not always feasible. 2. To inform users when they may be experiencing reduced performance due to the use of an integrated GPU over a discrete one. We have seen a significant number of users complain about rendering performance only to discover later that they have a more powerful, discrete GPU going unused. We try to shorten this pain period by detecting systems that may have a discrete GPU alongside an integrated one, and notify the user when degraded rendering performance is detected. We are looking forward to a wider implementation of the ?powerPreference? option so the guesswork of which GPU is running will be avoided. 3. To collect statistics about the hardware makeup of our user base. This is helpful in understanding the spectrum of performance capabilities amongst our users. On Thu, May 2, 2019 at 4:42 PM Ken Russell (kbr...@) > wrote: Dear WebGL community, There have been some recent discussions about the exposure of the WEBGL_debug_renderer_info extension, as it relates to user privacy and fingerprinting. If you build a WebGL application that queries this extension, could you please reply (either on-list, or directly to me) and indicate what information you infer, directly or indirectly, from it? Could the WebGL API provide this information via a different mechanism? Thanks, -Ken -------------- next part -------------- An HTML attachment was scrubbed... URL: From pub...@ Mon May 6 18:16:00 2019 From: pub...@ (Ken Russell (...@...)) Date: Mon, 6 May 2019 18:16:00 -0700 Subject: [Public WebGL] Uses of WEBGL_debug_renderer_info In-Reply-To: References: Message-ID: Thank you Ashley, Jukka, Paul, Evan, Jasper and others who replied off-list to this request. This is all very useful information and will help guide decisions going forward. If anyone else has more feedback, please do share it. To be clear: there's no agreement or plan among WebGL implementers to remove the WEBGL_debug_renderer_info extension wholesale from all browsers. In the design of coming Web graphics APIs (WebGPU specifically) there are some open questions about how much detail the browser should provide about the underlying GPU. I think that these pieces of feedback argue strongly for providing as much detail to the applications (and, therefore, the web page) as possible. -Ken On Fri, May 3, 2019 at 12:51 PM Jasper St. Pierre (jstpierre...@) < public_webgl...@> wrote: > Hi, > > > I use it to detect and work around known bugs in drivers, like Apple not > supporting row-major matrices ( > https://bugs.chromium.org/p/angleproject/issues/detail?id=2273 ), as well > as providing better error messages to users (e.g. "Google SwiftShader"). > The immediate impact if this extension was removed would be that all Apple > devices would fail to render. > > > ------------------------------ > *From:* owners-public_webgl...@ > on behalf of Evan Nowak (enowak...@) > *Sent:* Friday, May 3, 2019 7:56:27 AM > *To:* Public WebGL > *Subject:* Re: [Public WebGL] Uses of WEBGL_debug_renderer_info > > > At Onshape we use WEBGL_debug_renderer_info for a few purposes: > 1. To work around driver-specific interactions with our system. More > often than not this involves disabling a feature of our renderer that is > exhibiting poor performance on a particular platform/GPU combination. If > possible, we will try to find an alternative solution that performs well on > all platforms, but this is not always feasible. > 2. To inform users when they may be experiencing reduced performance due > to the use of an integrated GPU over a discrete one. We have seen a > significant number of users complain about rendering performance only to > discover later that they have a more powerful, discrete GPU going unused. > We try to shorten this pain period by detecting systems that may have a > discrete GPU alongside an integrated one, and notify the user when degraded > rendering performance is detected. We are looking forward to a wider > implementation of the ?powerPreference? option so the guesswork of which > GPU is running will be avoided. > 3. To collect statistics about the hardware makeup of our user base. This > is helpful in understanding the spectrum of performance capabilities > amongst our users. > > > > > On Thu, May 2, 2019 at 4:42 PM Ken Russell (kbr...@) < > public_webgl...@> wrote: > > Dear WebGL community, > > There have been some recent discussions about the exposure of the > WEBGL_debug_renderer_info extension, as it relates to user privacy and > fingerprinting. > > If you build a WebGL application that queries this extension, could you > please reply (either on-list, or directly to me) and indicate what > information you infer, directly or indirectly, from it? Could the WebGL API > provide this information via a different mechanism? > > Thanks, > > -Ken > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pub...@ Tue May 7 22:40:31 2019 From: pub...@ (Ken Russell (...@...)) Date: Tue, 7 May 2019 22:40:31 -0700 Subject: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved In-Reply-To: References: <6h3BiRju7dWPGuP15Wgavg04jqoNgcsaRjDr-HP_D_SQUQfY_DBtNAkJ7uI27SPHXHOkv9iRdF39tDwSYntzIF_YrsQiFhB6YFDGdR6geOg=@pm.me> <5F447A42ADFAFD499D69CF330DF2E5C16064696C@SHSMSX101.ccr.corp.intel.com> <5F447A42ADFAFD499D69CF330DF2E5C160646A54@SHSMSX101.ccr.corp.intel.com> <5F447A42ADFAFD499D69CF330DF2E5C1606477B6@SHSMSX101.ccr.corp.intel.com> <5F447A42ADFAFD499D69CF330DF2E5C160647D0F@SHSMSX101.ccr.corp.intel.com> Message-ID: Jie Chen from Intel just landed a fix in Chrome dramatically improving the performance of querying COMPLETION_STATUS_KHR under http://crbug.com/881152 . The fix will be in tomorrow's Canary on Windows and macOS. This should address the last major gap with this extension. We would like to enable it by default by promoting it to community approved; any further comments? -Ken *From: *Ken Russell *Date: *Fri, Apr 26, 2019 at 3:40 PM *To: *Public WebGL Thanks for the report and the clear test case. There was an existing bug > about this, so the new one was duplicated into it, and some hints about > implementing it were added to the preexisting bug. > > > On Fri, Apr 26, 2019 at 5:56 AM Takahiro Aoyagi (taoyagi...@) < > public_webgl...@> wrote: > >> Hi Chen, >> >> Opened a bug. Thanks. >> >> https://bugs.chromium.org/p/chromium/issues/detail?id=957001 >> >> Takahiro >> >> >> On Fri, Apr 26, 2019 at 8:03 PM Chen, Jie A (jie.a.chen...@) < >> public_webgl...@> wrote: >> >>> Hi Takahiro, >>> >>> The current implementation of COMPLETION_STATUS_KHR query in >>> chromium incurs an expensive round-trip to the GPU thread. This may >>> contribute to the wait time in your case. I am trying to optimize this. >>> Could you please file a bug to chromium? I would look into it once I?ve >>> done the optimization. >>> >>> >>> >>> *From:* owners-public_webgl...@ [mailto: >>> owners-public_webgl...@] *On Behalf Of *Takahiro Aoyagi ( >>> taoyagi...@) >>> *Sent:* Friday, April 26, 2019 6:20 PM >>> *To:* Public WebGL >>> *Subject:* Re: [Public WebGL] Propose promoting >>> KHR_parallel_shader_compile to community approved >>> >>> >>> >>> Hi all, >>> >>> >>> >>> I'm working on Three.js + KHR_parallel_shader_compile extension support >>> with Fernando. >>> >>> >>> >>> https://github.com/mrdoob/three.js/issues/16321#issuecomment-486436086 >>> >>> >>> >>> I'm testing with Canary. But the behavior seems weird to me. >>> gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) seems to wait >>> for compile+link completion. I don't think it should wait for that, it >>> should just do polling and returning true/false quickly instead. >>> >>> >>> >>> I made a simple test to reproduce. >>> >>> >>> >>> >>> https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html >>> >>> >>> >>> Code snippet. >>> >>> >>> >>> const ext = gl.getExtension('KHR_parallel_shader_compile'); >>> >>> >>> >>> gl.compileShader(vertexShader); >>> gl.compileShader(fragmentShader); >>> gl.attachShader(program, vertexShader); >>> gl.attachShader(program, fragmentShader); >>> gl.linkProgram(program); >>> >>> const startTime = performance.now(); >>> const status = useExtension >>> ? gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) >>> : gl.getProgramParameter(program, gl.LINK_STATUS); >>> const endTime = performance.now(); >>> >>> const elapsedTime = endTime - startTime; >>> >>> >>> >>> On my platform, both gl.LINK_STATUS and ext.COMPLETION_STATUS_KHR take >>> so long time about 15ms. I can accept this number for gl.LINK_STATUS >>> because it waits for compile+link completion. But 15ms for >>> ext.COMPLETION_STATUS_KHR looks weird to me. It shouldn't wait for the >>> compile+link completion but should do just polling and quickly returning >>> true/false instead. So I guess the number should be 1ms or less. >>> >>> >>> >>> Let me know if I'm missing something. Or could it be a Canary bug? >>> >>> >>> >>> My platform. >>> >>> >>> >>> OS: Windows10 >>> >>> Browser: Chrome Canary. >>> >>> Browser boot option: --use-cmd-decoder=passthrough >>> --enable-webgl-draft-extensions >>> >>> >>> >>> >>> >>> Thanks >>> >>> >>> >>> Takahiro >>> >>> >>> >>> >>> >>> On Fri, Apr 26, 2019 at 10:15 AM Chen, Jie A (jie.a.chen...@) < >>> public_webgl...@> wrote: >>> >>> Basically, for ANGLE?s GL backend, it?s simply a wrapper for the >>> existing GL implementations. In this sense glCompileShader() is still >>> implementation specific. Essentially ANGLE just calls glCompileShader and >>> check GL_COMPILE_STATUS. >>> >>> >>> >>> *From:* owners-public_webgl...@ [mailto: >>> owners-public_webgl...@] *On Behalf Of *Jasper St. Pierre ( >>> jstpierre...@) >>> *Sent:* Friday, April 26, 2019 1:18 AM >>> *To:* Public WebGL >>> *Subject:* RE: [Public WebGL] Propose promoting >>> KHR_parallel_shader_compile to community approved >>> >>> >>> >>> Thank you, that?s important information to know. Changing my shader >>> compilation pipeline to wait for shader completion status is a lot more >>> difficult, but based on some initial tests, it?s more expensive than not >>> doing it ? the latency of getShaderParameter is too high. >>> >>> >>> >>> That said, in a lot of GL implementations, glCompileShader() is >>> practically a no-op, and will only do an AST parse when >>> glGetShaderParameter/InfoLog() is called (which is basically only for >>> debugging / error checking). glLinkProgram() does full compilation of all >>> programs, as full-PSO optimization is important. I don?t know how common >>> this is, but multiple GL implementations I have seen do it. It might make >>> sense for ANGLE to adopt this model as well. >>> >>> >>> >>> *From:* owners-public_webgl...@ >>> *On Behalf Of *Chen, Jie A (jie.a.chen...@) >>> *Sent:* Wednesday, April 24, 2019 6:48 PM >>> *To:* Public WebGL >>> *Subject:* RE: [Public WebGL] Propose promoting >>> KHR_parallel_shader_compile to community approved >>> >>> >>> >>> Absolutely. Ideally there would be no stall for linkProgram. I tried, >>> but it?s too difficult to achieve this in ANGLE. >>> >>> >>> >>> *From:* owners-public_webgl...@ [ >>> mailto:owners-public_webgl...@ ] >>> *On Behalf Of *Jeff Gilbert (jgilbert...@) >>> *Sent:* Thursday, April 25, 2019 9:33 AM >>> *To:* Public WebGL >>> *Subject:* Re: [Public WebGL] Propose promoting >>> KHR_parallel_shader_compile to community approved >>> >>> >>> >>> Possibly, but in the long run, I expect implementations to support >>> no-stall linkProgram invocations. >>> >>> >>> >>> On Wed, Apr 24, 2019 at 6:27 PM Chen, Jie A (jie.a.chen...@) < >>> public_webgl...@> wrote: >>> >>> linkProgram may stall on compileShader. To avoid the stall, you?d better >>> make sure the COMPLETION_STATUS_KHR statuses of the attached shaders are >>> all True before calling linkProgram. In this sense, the first workflow has >>> less chance running into stall. >>> >>> >>> >>> *From:* owners-public_webgl...@ [mailto: >>> owners-public_webgl...@] *On Behalf Of *Fernando Serrano Garc?a >>> (fserrano...@) >>> *Sent:* Wednesday, April 24, 2019 9:38 PM >>> *To:* Public WebGL >>> *Subject:* Re: [Public WebGL] Propose promoting >>> KHR_parallel_shader_compile to community approved >>> >>> >>> >>> Regarding the optimal proposed workflow (grouping shaders and programs >>> separately) of: >>> >>> for (const x of shaders) >>> gl.compileShader(x); >>> for (const x of programs) >>> gl.linkProgram(x); >>> >>> >>> >>> versus something more on the way that we currently have in many engines >>> as threejs: >>> >>> for (const x of material) >>> >>> gl.compileShader(fs); >>> >>> gl.compileShader(vs); >>> gl.linkProgram(x); >>> >>> >>> >>> Do you think is more or less accurate the following graph for 4 >>> materials and enabling this extension with 2 and 4 parallel threads? >>> >>> >>> >>> [image: Screen Shot 2019-04-24 at 15.35.47.png] >>> >>> >>> >>> On Wed, Apr 24, 2019 at 2:40 PM Fernando Serrano Garc?a < >>> fserrano...@> wrote: >>> >>> fwiw three.js introduced a "debug" parameter (false by default) to >>> determine if there will be a status check and call all the get* (currently >>> in dev): >>> >>> - >>> https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLShader.js#L21-L26 >>> >>> - >>> https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLProgram.js#L608 >>> >>> >>> >>> so currently calling `new WebGLShader()` won't be blocking with any >>> `get*` function and it could be used as is to compile all of them in a loop >>> with or without the extension. >>> >>> the problem comes from the WebGLProgram as it should just queue itself >>> before trying to link any program and wait until all the shader compile >>> calls finish, then do all the link, and wait for it asynchronously before >>> start using these programs. >>> >>> I have opened an issue on the three.js repo to keep track of the >>> implementation and we have booked some time this week to take a look at it, >>> feedback is welcome :) https://github.com/mrdoob/three.js/issues/16321 >>> >>> >>> >>> On Tue, Apr 16, 2019 at 11:55 PM Ken Russell (kbr...@) < >>> public_webgl...@> wrote: >>> >>> On Tue, Apr 16, 2019 at 2:24 PM Tarek Sherif (tsherif...@) < >>> public_webgl...@> wrote: >>> >>> Yes, I've read both specs. I think this language in the WebGL version is >>> confusing: "When this extension is enabled: Shader compilation and program >>> linking may be performed in a separate CPU thread." And neither indicates >>> which functions are expected to cause stalls. As written, this extension >>> requires more than most that people know implementation details. >>> >>> >>> >>> All previous operations against the program - looking up uniform >>> locations, drawing with it, etc. - will cause stalls. The application >>> *must* be updated to query the program's COMPLETION_STATUS_KHR status, and >>> skip *all* operations against the program until it's no longer pending. >>> >>> >>> >>> I guess we'll just change the WebGL version of this extension spec to be >>> much more explicit about this. >>> >>> >>> >>> >>> >>> Essentially, all previous code which checked for the completion of >>> compilation of shaders / linking of programs can be updated with a small >>> wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. >>> >>> >>> >>> This is not true because the most common way this is done will cause >>> stalls that sabotage the parallelism, e.g.: >>> >>> https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLShader.js#L21-L36 >>> >>> >>> https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLProgram.js#L586-L631 >>> >>> >>> >>> The check for COMPLETION_STATUS_KHR has to wrap *all* queries and uses >>> of the program object, and they must be skipped until COMPLETION_STATUS_KHR >>> returns true. Yes, all applications will have to be updated to take >>> advantage of this extension, but if they do, the benefits will be >>> significant. >>> >>> >>> >>> -Ken >>> >>> >>> >>> >>> >>> *Tarek Sherif* >>> >>> Senior Software Engineer, Visualization | Uber >>> >>> http://vis.gl/ >>> >>> >>> >>> >>> >>> >>> >>> On Tue, Apr 16, 2019 at 4:18 PM Ken Russell (kbr...@) < >>> public_webgl...@> wrote: >>> >>> Please review the Overview in the underlying OpenGL ES spec: >>> >>> >>> https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt >>> >>> >>> >>> >>> It describes that the extension uses one or more separate CPU threads >>> for shader compilation. If you still think we should rewrite the >>> introduction to the WebGL extension, we can do that too. >>> >>> >>> >>> Essentially, all previous code which checked for the completion of >>> compilation of shaders / linking of programs can be updated with a small >>> wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. >>> >>> >>> >>> -Ken >>> >>> >>> >>> >>> >>> >>> >>> On Tue, Apr 16, 2019 at 1:36 AM Tarek Sherif (tsherif...@) < >>> public_webgl...@> wrote: >>> >>> This is all extremely interesting, and documentation of these best >>> practices should probably be more publicly available (perhaps through a >>> non-normative note in the spec). I'm thinking the language in the extension >>> spec could be made more clear about what it's actual purpose is. It >>> currently gives the impression that enabling it is what allows for parallel >>> compilation and that this should save time, but given what Jeff and Kai >>> have said, it sounds like the purpose is to avoid CPU stalls, and that it >>> might even take longer in wall time since you're only checking once a >>> frame. Maybe some background information could be added along the lines of >>> "Normally applications must wait on get*Parameter or a draw call for >>> program linking to complete, this extension provides a mechanism for >>> querying completion status without stalling..." >>> >>> >>> >>> *Tarek Sherif* >>> >>> Senior Software Engineer, Visualization | Uber >>> >>> http://vis.gl/ >>> >>> >>> >>> >>> >>> >>> >>> >>> On Mon, Apr 15, 2019 at 11:23 PM Kai Ninomiya (kainino...@) < >>> public_webgl...@> wrote: >>> >>> >>> >>> >>> >>> On Mon, Apr 15, 2019 at 7:18 PM Tarek Sherif (tareksherif...@) < >>> public_webgl...@> wrote: >>> >>> I don't see anything in the OpenGL extension spec about what functions >>> cause stalls. Is that implementation-specific? Having an idea what to >>> expect is important for two reasons: >>> >>> 1. To make it clear that drawing will still work if >>> getProgramParameter(COMPLETION_STATUS_KHR) hasn't returned true yet >>> (i.e. the stall on a draw call) >>> >>> >>> >>> Generally, OpenGL extensions are not allowed to break existing >>> API/existing content. (In OpenGL, all extensions are always enabled; >>> there's no requestExtension.) Hence, even if you enable the extension, it >>> won't change the way your application works, and therefore the draw call >>> must still cause a stall in order to be able to use the program. >>> >>> >>> >>> 2. Almost all WebGL code I've looked at handles compilation in a way >>> similar to the following: >>> >>> gl.compileShader(vertexShader); >>> if (!gl.getShaderParameter(vertexShader, gl.COMPILE_STATUS)) //... >>> >>> gl.compileShader(fragmentShader); >>> >>> if (!gl.getShaderParameter(fragmentShader, gl.COMPILE_STATUS)) //... >>> >>> //... >>> >>> gl.linkProgram(program); >>> if (!gl.getProgramParameter(program, gl.LINK_STATUS)) //... >>> >>> I think it would be worth it to make clear that this pattern would >>> sabotage the parallel compile. >>> >>> >>> >>> I seem to remember (not sure if this is still true) that this pattern >>> also sabotages the shader compiler cache in ANGLE, because ANGLE doesn't >>> cache the COMPILE_STATUS (or was it the compile info string?). So it forces >>> the compiler to recompile just to give you the status. >>> >>> >>> >>> Tarek Sherif >>> >>> http://tareksherif.net/ >>> >>> >>> >>> >>> >>> >>> >>> >>> ??????? Original Message ??????? >>> >>> On Monday, April 15, 2019 9:00 PM, Ken Russell (kbr...@) < >>> public_webgl...@> wrote: >>> >>> >>> >>> The WebGL extension (which is basically just a wrapper) refers to the >>> underlying OpenGL / OpenGL ES extension >>> https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt >>> , >>> where this is documented. Is that sufficient? It would be better to avoid >>> duplicating a large amount of spec text from the underlying extension. >>> However, we can add some non-normative text if that would help. >>> >>> >>> >>> -Ken >>> >>> >>> >>> >>> >>> >>> >>> On Sat, Apr 13, 2019 at 3:51 AM Tarek Sherif (tareksherif...@) < >>> public_webgl...@> wrote: >>> >>> IIRC, all 3 of those functions still force a wait for the {shader to >>> finish compiling, program to finish linking} just as they did before. The >>> new semantics are only visible via the new COMPLETION_STATUS_KHR check. >>> >>> That should work perfectly for us. Can we add some language to the spec >>> about which functions cause stalls? I feel like as written, it will be easy >>> for people to use the extension incorrectly. >>> >>> >>> >>> Tarek Sherif >>> >>> http://tareksherif.net/ >>> >>> >>> >>> >>> >>> >>> >>> >>> ??????? Original Message ??????? >>> >>> On Friday, April 12, 2019 4:10 PM, Kai Ninomiya (kainino...@) < >>> public_webgl...@> wrote: >>> >>> >>> >>> Oh yes, useProgram probably won't stall. But getUniformLocation and the >>> others will stall, as will draw calls. >>> >>> >>> >>> getProgramParameter(COMPLETION_STATUS_KHR) should get faster at some >>> point; see http://crbug.com/881152 >>> which >>> Ken linked. >>> >>> >>> >>> On Fri, Apr 12, 2019 at 12:39 PM Jasper St. Pierre (jstpierre...@) >>> wrote: >>> >>> Thank you! Trying this out in my own WebGL 2 app, I see quite a >>> reduction in shader compilation time, shaving 400ms on load time on a >>> moderately complex scene. The getProgramParameter(COMPLETION_STATUS_KHR) >>> query still takes 1ms (which I believe is being tracked), but that is still >>> better from the 4ms I see in getUniformBlockIndex (my previous sync point). >>> >>> >>> >>> AFAIK, useProgram should not cause a stall, but in order to set my >>> texture samplers to bind to different units, I need to do a >>> getUniformLocation on my sampler uniform, which causes a compilation stall. >>> Same thing with getUniformBlockIndex. Do make sure that anything that might >>> query into reflection about the program (e.g. getVertexAttributeIndex, >>> getUniformLocation, getUniformBlockIndex) happens after >>> COMPLETION_STATUS_KHR returns true, since that?s another way to >>> accidentally stall on compilation completing. >>> >>> >>> >>> >>> >>> *From:* owners-public_webgl...@ >>> *On Behalf Of *Kai Ninomiya (kainino...@) >>> >>> *Sent:* Friday, April 12, 2019 10:25 AM >>> >>> *To:* Public WebGL >>> >>> *Subject:* Re: [Public WebGL] Propose promoting >>> KHR_parallel_shader_compile to community approved >>> >>> >>> >>> >>> >>> IIRC, all 3 of those functions still force a wait for the {shader to >>> finish compiling, program to finish linking} just as they did before. The >>> new semantics are only visible via the new COMPLETION_STATUS_KHR check. >>> >>> >>> >>> On Fri, Apr 12, 2019 at 10:05 AM Tarek Sherif (tsherif...@) < >>> public_webgl...@> wrote: >>> >>> Very excited about this extension, but I'm concerned about how it would >>> work in our use case. Our flagship visualization library, deck.gl >>> , >>> often shares the gl context with a separate base map rendering application >>> so that it can properly interleave visualization layers with the base map. >>> Enabling this extension seems to change the behaviour of existing WebGL >>> functions in a way that I don't believe other extensions do. My worry is >>> how our enabling KHR_parallel_shader_compile would affect applications we >>> share contexts with, i.e what happens if the typical synchronous >>> compilation logic is used after KHR_parallel_shader_compile is enabled? >>> Specifically: >>> >>> - What happens if getShaderParameter(shader, COMPILE_STATUS) is >>> called before compilation is complete? >>> - What happens if getProgramParameter(program, LINK_STATUS) is >>> called before linking is complete? >>> - What happens if useProgram is called before linking is complete? >>> >>> Thanks, >>> >>> >>> >>> >>> >>> Tarek Sherif >>> >>> Senior Software Engineer, Visualization | Uber >>> >>> http://vis.gl/ >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> *Tarek Sherif* >>> >>> Senior Software Engineer, Visualization | Uber >>> >>> http://vis.gl/ >>> >>> >>> >>> >>> >>> >>> On Fri, Apr 12, 2019 at 12:16 PM David Catuhe ( >>> David.Catuhe...@) wrote: >>> >>> Wonderful! >>> >>> >>> >>> >>> >>> *From:* owners-public_webgl...@ >>> *On Behalf Of *Ken Russell (kbr...@) >>> >>> *Sent:* Wednesday, April 10, 2019 2:56 PM >>> >>> *To:* Public WebGL >>> >>> *Subject:* Re: [Public WebGL] Propose promoting >>> KHR_parallel_shader_compile to community approved >>> >>> >>> >>> >>> >>> If your code works correctly now when enabling draft WebGL extensions in >>> Chrome, then no changes are needed. There won't be any changes to the >>> extension when it's taken out of draft status; it'll just be available by >>> default. >>> >>> >>> >>> -Ken >>> >>> >>> >>> >>> >>> On Wed, Apr 10, 2019 at 12:36 PM David Catuhe ( >>> David.Catuhe...@) wrote: >>> >>> We do have support for the extension in Babylon.js. How can we test this >>> change? >>> ------------------------------ >>> >>> >>> >>> *From:* owners-public_webgl...@ >>> on behalf of Ken Russell (kbr...@) >>> *Sent:* Wednesday, April 10, 2019 12:00:25 PM >>> *To:* public >>> *Subject:* [Public WebGL] Propose promoting KHR_parallel_shader_compile >>> to community approved >>> >>> >>> >>> WebGL community, >>> >>> >>> >>> Jie Chen from Intel has principally developed and implemented a WebGL >>> wrapper for the KHR_parallel_shader_compile extension. This allows shader >>> compilation and program linking to occur fully in parallel to the rest of >>> the WebGL application. Some small application changes are needed to take >>> full advantage of the extension, but it is otherwise fully backward >>> compatible. Jie has even emulated this extension on platforms which don't >>> support it natively. >>> >>> >>> >>> This extension solves a longstanding user complaint with WebGL, namely >>> long shader compile times on Windows. Compiles and links occur not only >>> asynchronously, but also in parallel, so there is a net speedup when using >>> this extension. Users who have tried out the draft extension are pleased >>> with the results and would like to see it made widely available. >>> >>> >>> >>> I propose promoting this extension to community approved in >>> https://github.com/KhronosGroup/WebGL/pull/2855 >>> >>> . Any comments? >>> >>> >>> >>> -Ken >>> >>> >>> >>> >>> >>> >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 82548 bytes Desc: not available URL: From pub...@ Wed May 8 11:35:39 2019 From: pub...@ (=?UTF-8?Q?Florian_B=C3=B6sch?= (...@...)) Date: Wed, 8 May 2019 20:35:39 +0200 Subject: [Public WebGL] Uses of WEBGL_debug_renderer_info In-Reply-To: References: Message-ID: http://codeflow.org/entries/2016/feb/10/webgl_debug_renderer_info-extension-survey-results/ On Tue, May 7, 2019 at 3:17 AM Ken Russell (kbr...@) < public_webgl...@> wrote: > Thank you Ashley, Jukka, Paul, Evan, Jasper and others who replied > off-list to this request. This is all very useful information and will help > guide decisions going forward. If anyone else has more feedback, please do > share it. > > To be clear: there's no agreement or plan among WebGL implementers to > remove the WEBGL_debug_renderer_info extension wholesale from all browsers. > In the design of coming Web graphics APIs (WebGPU specifically) there are > some open questions about how much detail the browser should provide about > the underlying GPU. I think that these pieces of feedback argue strongly > for providing as much detail to the applications (and, therefore, the web > page) as possible. > > -Ken > > > On Fri, May 3, 2019 at 12:51 PM Jasper St. Pierre (jstpierre...@) < > public_webgl...@> wrote: > >> Hi, >> >> >> I use it to detect and work around known bugs in drivers, like Apple not >> supporting row-major matrices ( >> https://bugs.chromium.org/p/angleproject/issues/detail?id=2273 ), as >> well as providing better error messages to users (e.g. "Google >> SwiftShader"). The immediate impact if this extension was removed would be >> that all Apple devices would fail to render. >> >> >> ------------------------------ >> *From:* owners-public_webgl...@ >> on behalf of Evan Nowak (enowak...@) >> *Sent:* Friday, May 3, 2019 7:56:27 AM >> *To:* Public WebGL >> *Subject:* Re: [Public WebGL] Uses of WEBGL_debug_renderer_info >> >> >> At Onshape we use WEBGL_debug_renderer_info for a few purposes: >> 1. To work around driver-specific interactions with our system. More >> often than not this involves disabling a feature of our renderer that is >> exhibiting poor performance on a particular platform/GPU combination. If >> possible, we will try to find an alternative solution that performs well on >> all platforms, but this is not always feasible. >> 2. To inform users when they may be experiencing reduced performance due >> to the use of an integrated GPU over a discrete one. We have seen a >> significant number of users complain about rendering performance only to >> discover later that they have a more powerful, discrete GPU going unused. >> We try to shorten this pain period by detecting systems that may have a >> discrete GPU alongside an integrated one, and notify the user when degraded >> rendering performance is detected. We are looking forward to a wider >> implementation of the ?powerPreference? option so the guesswork of which >> GPU is running will be avoided. >> 3. To collect statistics about the hardware makeup of our user base. >> This is helpful in understanding the spectrum of performance capabilities >> amongst our users. >> >> >> >> >> On Thu, May 2, 2019 at 4:42 PM Ken Russell (kbr...@) < >> public_webgl...@> wrote: >> >> Dear WebGL community, >> >> There have been some recent discussions about the exposure of the >> WEBGL_debug_renderer_info extension, as it relates to user privacy and >> fingerprinting. >> >> If you build a WebGL application that queries this extension, could you >> please reply (either on-list, or directly to me) and indicate what >> information you infer, directly or indirectly, from it? Could the WebGL API >> provide this information via a different mechanism? >> >> Thanks, >> >> -Ken >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From pub...@ Fri May 10 00:21:44 2019 From: pub...@ (Takahiro Aoyagi (...@...)) Date: Fri, 10 May 2019 16:21:44 +0900 Subject: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved In-Reply-To: References: <6h3BiRju7dWPGuP15Wgavg04jqoNgcsaRjDr-HP_D_SQUQfY_DBtNAkJ7uI27SPHXHOkv9iRdF39tDwSYntzIF_YrsQiFhB6YFDGdR6geOg=@pm.me> <5F447A42ADFAFD499D69CF330DF2E5C16064696C@SHSMSX101.ccr.corp.intel.com> <5F447A42ADFAFD499D69CF330DF2E5C160646A54@SHSMSX101.ccr.corp.intel.com> <5F447A42ADFAFD499D69CF330DF2E5C1606477B6@SHSMSX101.ccr.corp.intel.com> <5F447A42ADFAFD499D69CF330DF2E5C160647D0F@SHSMSX101.ccr.corp.intel.com> Message-ID: Confirmed COMPLETION_STATUS_KHR is very fast like 0.01ms on my test https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html Nice work! Thanks Virus-free. www.avg.com <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Wed, May 8, 2019 at 2:41 PM Ken Russell (kbr...@) < public_webgl...@> wrote: > Jie Chen from Intel just landed a fix in Chrome dramatically improving the > performance of querying COMPLETION_STATUS_KHR under > http://crbug.com/881152 . The fix will be in tomorrow's Canary on Windows > and macOS. > > This should address the last major gap with this extension. We would like > to enable it by default by promoting it to community approved; any further > comments? > > -Ken > > > > *From: *Ken Russell > *Date: *Fri, Apr 26, 2019 at 3:40 PM > *To: *Public WebGL > > Thanks for the report and the clear test case. There was an existing bug >> about this, so the new one was duplicated into it, and some hints about >> implementing it were added to the preexisting bug. >> >> >> On Fri, Apr 26, 2019 at 5:56 AM Takahiro Aoyagi (taoyagi...@) < >> public_webgl...@> wrote: >> >>> Hi Chen, >>> >>> Opened a bug. Thanks. >>> >>> https://bugs.chromium.org/p/chromium/issues/detail?id=957001 >>> >>> Takahiro >>> >>> >>> On Fri, Apr 26, 2019 at 8:03 PM Chen, Jie A (jie.a.chen...@) < >>> public_webgl...@> wrote: >>> >>>> Hi Takahiro, >>>> >>>> The current implementation of COMPLETION_STATUS_KHR query in >>>> chromium incurs an expensive round-trip to the GPU thread. This may >>>> contribute to the wait time in your case. I am trying to optimize this. >>>> Could you please file a bug to chromium? I would look into it once I?ve >>>> done the optimization. >>>> >>>> >>>> >>>> *From:* owners-public_webgl...@ [mailto: >>>> owners-public_webgl...@] *On Behalf Of *Takahiro Aoyagi ( >>>> taoyagi...@) >>>> *Sent:* Friday, April 26, 2019 6:20 PM >>>> *To:* Public WebGL >>>> *Subject:* Re: [Public WebGL] Propose promoting >>>> KHR_parallel_shader_compile to community approved >>>> >>>> >>>> >>>> Hi all, >>>> >>>> >>>> >>>> I'm working on Three.js + KHR_parallel_shader_compile extension support >>>> with Fernando. >>>> >>>> >>>> >>>> https://github.com/mrdoob/three.js/issues/16321#issuecomment-486436086 >>>> >>>> >>>> >>>> I'm testing with Canary. But the behavior seems weird to me. >>>> gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) seems to wait >>>> for compile+link completion. I don't think it should wait for that, it >>>> should just do polling and returning true/false quickly instead. >>>> >>>> >>>> >>>> I made a simple test to reproduce. >>>> >>>> >>>> >>>> >>>> https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html >>>> >>>> >>>> >>>> Code snippet. >>>> >>>> >>>> >>>> const ext = gl.getExtension('KHR_parallel_shader_compile'); >>>> >>>> >>>> >>>> gl.compileShader(vertexShader); >>>> gl.compileShader(fragmentShader); >>>> gl.attachShader(program, vertexShader); >>>> gl.attachShader(program, fragmentShader); >>>> gl.linkProgram(program); >>>> >>>> const startTime = performance.now(); >>>> const status = useExtension >>>> ? gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) >>>> : gl.getProgramParameter(program, gl.LINK_STATUS); >>>> const endTime = performance.now(); >>>> >>>> const elapsedTime = endTime - startTime; >>>> >>>> >>>> >>>> On my platform, both gl.LINK_STATUS and ext.COMPLETION_STATUS_KHR take >>>> so long time about 15ms. I can accept this number for gl.LINK_STATUS >>>> because it waits for compile+link completion. But 15ms for >>>> ext.COMPLETION_STATUS_KHR looks weird to me. It shouldn't wait for the >>>> compile+link completion but should do just polling and quickly returning >>>> true/false instead. So I guess the number should be 1ms or less. >>>> >>>> >>>> >>>> Let me know if I'm missing something. Or could it be a Canary bug? >>>> >>>> >>>> >>>> My platform. >>>> >>>> >>>> >>>> OS: Windows10 >>>> >>>> Browser: Chrome Canary. >>>> >>>> Browser boot option: --use-cmd-decoder=passthrough >>>> --enable-webgl-draft-extensions >>>> >>>> >>>> >>>> >>>> >>>> Thanks >>>> >>>> >>>> >>>> Takahiro >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Apr 26, 2019 at 10:15 AM Chen, Jie A (jie.a.chen...@) < >>>> public_webgl...@> wrote: >>>> >>>> Basically, for ANGLE?s GL backend, it?s simply a wrapper for the >>>> existing GL implementations. In this sense glCompileShader() is still >>>> implementation specific. Essentially ANGLE just calls glCompileShader and >>>> check GL_COMPILE_STATUS. >>>> >>>> >>>> >>>> *From:* owners-public_webgl...@ [mailto: >>>> owners-public_webgl...@] *On Behalf Of *Jasper St. Pierre ( >>>> jstpierre...@) >>>> *Sent:* Friday, April 26, 2019 1:18 AM >>>> *To:* Public WebGL >>>> *Subject:* RE: [Public WebGL] Propose promoting >>>> KHR_parallel_shader_compile to community approved >>>> >>>> >>>> >>>> Thank you, that?s important information to know. Changing my shader >>>> compilation pipeline to wait for shader completion status is a lot more >>>> difficult, but based on some initial tests, it?s more expensive than not >>>> doing it ? the latency of getShaderParameter is too high. >>>> >>>> >>>> >>>> That said, in a lot of GL implementations, glCompileShader() is >>>> practically a no-op, and will only do an AST parse when >>>> glGetShaderParameter/InfoLog() is called (which is basically only for >>>> debugging / error checking). glLinkProgram() does full compilation of all >>>> programs, as full-PSO optimization is important. I don?t know how common >>>> this is, but multiple GL implementations I have seen do it. It might make >>>> sense for ANGLE to adopt this model as well. >>>> >>>> >>>> >>>> *From:* owners-public_webgl...@ < >>>> owners-public_webgl...@> *On Behalf Of *Chen, Jie A ( >>>> jie.a.chen...@) >>>> *Sent:* Wednesday, April 24, 2019 6:48 PM >>>> *To:* Public WebGL >>>> *Subject:* RE: [Public WebGL] Propose promoting >>>> KHR_parallel_shader_compile to community approved >>>> >>>> >>>> >>>> Absolutely. Ideally there would be no stall for linkProgram. I tried, >>>> but it?s too difficult to achieve this in ANGLE. >>>> >>>> >>>> >>>> *From:* owners-public_webgl...@ [ >>>> mailto:owners-public_webgl...@ >>>> ] *On Behalf Of *Jeff Gilbert ( >>>> jgilbert...@) >>>> *Sent:* Thursday, April 25, 2019 9:33 AM >>>> *To:* Public WebGL >>>> *Subject:* Re: [Public WebGL] Propose promoting >>>> KHR_parallel_shader_compile to community approved >>>> >>>> >>>> >>>> Possibly, but in the long run, I expect implementations to support >>>> no-stall linkProgram invocations. >>>> >>>> >>>> >>>> On Wed, Apr 24, 2019 at 6:27 PM Chen, Jie A (jie.a.chen...@) < >>>> public_webgl...@> wrote: >>>> >>>> linkProgram may stall on compileShader. To avoid the stall, you?d >>>> better make sure the COMPLETION_STATUS_KHR statuses of the attached shaders >>>> are all True before calling linkProgram. In this sense, the first workflow >>>> has less chance running into stall. >>>> >>>> >>>> >>>> *From:* owners-public_webgl...@ [mailto: >>>> owners-public_webgl...@] *On Behalf Of *Fernando Serrano >>>> Garc?a (fserrano...@) >>>> *Sent:* Wednesday, April 24, 2019 9:38 PM >>>> *To:* Public WebGL >>>> *Subject:* Re: [Public WebGL] Propose promoting >>>> KHR_parallel_shader_compile to community approved >>>> >>>> >>>> >>>> Regarding the optimal proposed workflow (grouping shaders and programs >>>> separately) of: >>>> >>>> for (const x of shaders) >>>> gl.compileShader(x); >>>> for (const x of programs) >>>> gl.linkProgram(x); >>>> >>>> >>>> >>>> versus something more on the way that we currently have in many engines >>>> as threejs: >>>> >>>> for (const x of material) >>>> >>>> gl.compileShader(fs); >>>> >>>> gl.compileShader(vs); >>>> gl.linkProgram(x); >>>> >>>> >>>> >>>> Do you think is more or less accurate the following graph for 4 >>>> materials and enabling this extension with 2 and 4 parallel threads? >>>> >>>> >>>> >>>> [image: Screen Shot 2019-04-24 at 15.35.47.png] >>>> >>>> >>>> >>>> On Wed, Apr 24, 2019 at 2:40 PM Fernando Serrano Garc?a < >>>> fserrano...@> wrote: >>>> >>>> fwiw three.js introduced a "debug" parameter (false by default) to >>>> determine if there will be a status check and call all the get* (currently >>>> in dev): >>>> >>>> - >>>> https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLShader.js#L21-L26 >>>> >>>> - >>>> https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLProgram.js#L608 >>>> >>>> >>>> >>>> so currently calling `new WebGLShader()` won't be blocking with any >>>> `get*` function and it could be used as is to compile all of them in a loop >>>> with or without the extension. >>>> >>>> the problem comes from the WebGLProgram as it should just queue itself >>>> before trying to link any program and wait until all the shader compile >>>> calls finish, then do all the link, and wait for it asynchronously before >>>> start using these programs. >>>> >>>> I have opened an issue on the three.js repo to keep track of the >>>> implementation and we have booked some time this week to take a look at it, >>>> feedback is welcome :) https://github.com/mrdoob/three.js/issues/16321 >>>> >>>> >>>> >>>> On Tue, Apr 16, 2019 at 11:55 PM Ken Russell (kbr...@) < >>>> public_webgl...@> wrote: >>>> >>>> On Tue, Apr 16, 2019 at 2:24 PM Tarek Sherif (tsherif...@) < >>>> public_webgl...@> wrote: >>>> >>>> Yes, I've read both specs. I think this language in the WebGL version >>>> is confusing: "When this extension is enabled: Shader compilation and >>>> program linking may be performed in a separate CPU thread." And neither >>>> indicates which functions are expected to cause stalls. As written, this >>>> extension requires more than most that people know implementation details. >>>> >>>> >>>> >>>> All previous operations against the program - looking up uniform >>>> locations, drawing with it, etc. - will cause stalls. The application >>>> *must* be updated to query the program's COMPLETION_STATUS_KHR status, and >>>> skip *all* operations against the program until it's no longer pending. >>>> >>>> >>>> >>>> I guess we'll just change the WebGL version of this extension spec to >>>> be much more explicit about this. >>>> >>>> >>>> >>>> >>>> >>>> Essentially, all previous code which checked for the completion of >>>> compilation of shaders / linking of programs can be updated with a small >>>> wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. >>>> >>>> >>>> >>>> This is not true because the most common way this is done will cause >>>> stalls that sabotage the parallelism, e.g.: >>>> >>>> https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLShader.js#L21-L36 >>>> >>>> >>>> https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLProgram.js#L586-L631 >>>> >>>> >>>> >>>> The check for COMPLETION_STATUS_KHR has to wrap *all* queries and uses >>>> of the program object, and they must be skipped until COMPLETION_STATUS_KHR >>>> returns true. Yes, all applications will have to be updated to take >>>> advantage of this extension, but if they do, the benefits will be >>>> significant. >>>> >>>> >>>> >>>> -Ken >>>> >>>> >>>> >>>> >>>> >>>> *Tarek Sherif* >>>> >>>> Senior Software Engineer, Visualization | Uber >>>> >>>> http://vis.gl/ >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Tue, Apr 16, 2019 at 4:18 PM Ken Russell (kbr...@) < >>>> public_webgl...@> wrote: >>>> >>>> Please review the Overview in the underlying OpenGL ES spec: >>>> >>>> >>>> https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt >>>> >>>> >>>> >>>> >>>> It describes that the extension uses one or more separate CPU threads >>>> for shader compilation. If you still think we should rewrite the >>>> introduction to the WebGL extension, we can do that too. >>>> >>>> >>>> >>>> Essentially, all previous code which checked for the completion of >>>> compilation of shaders / linking of programs can be updated with a small >>>> wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. >>>> >>>> >>>> >>>> -Ken >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Tue, Apr 16, 2019 at 1:36 AM Tarek Sherif (tsherif...@) < >>>> public_webgl...@> wrote: >>>> >>>> This is all extremely interesting, and documentation of these best >>>> practices should probably be more publicly available (perhaps through a >>>> non-normative note in the spec). I'm thinking the language in the extension >>>> spec could be made more clear about what it's actual purpose is. It >>>> currently gives the impression that enabling it is what allows for parallel >>>> compilation and that this should save time, but given what Jeff and Kai >>>> have said, it sounds like the purpose is to avoid CPU stalls, and that it >>>> might even take longer in wall time since you're only checking once a >>>> frame. Maybe some background information could be added along the lines of >>>> "Normally applications must wait on get*Parameter or a draw call for >>>> program linking to complete, this extension provides a mechanism for >>>> querying completion status without stalling..." >>>> >>>> >>>> >>>> *Tarek Sherif* >>>> >>>> Senior Software Engineer, Visualization | Uber >>>> >>>> http://vis.gl/ >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Mon, Apr 15, 2019 at 11:23 PM Kai Ninomiya (kainino...@) < >>>> public_webgl...@> wrote: >>>> >>>> >>>> >>>> >>>> >>>> On Mon, Apr 15, 2019 at 7:18 PM Tarek Sherif (tareksherif...@) < >>>> public_webgl...@> wrote: >>>> >>>> I don't see anything in the OpenGL extension spec about what functions >>>> cause stalls. Is that implementation-specific? Having an idea what to >>>> expect is important for two reasons: >>>> >>>> 1. To make it clear that drawing will still work if >>>> getProgramParameter(COMPLETION_STATUS_KHR) hasn't returned true yet >>>> (i.e. the stall on a draw call) >>>> >>>> >>>> >>>> Generally, OpenGL extensions are not allowed to break existing >>>> API/existing content. (In OpenGL, all extensions are always enabled; >>>> there's no requestExtension.) Hence, even if you enable the extension, it >>>> won't change the way your application works, and therefore the draw call >>>> must still cause a stall in order to be able to use the program. >>>> >>>> >>>> >>>> 2. Almost all WebGL code I've looked at handles compilation in a way >>>> similar to the following: >>>> >>>> gl.compileShader(vertexShader); >>>> if (!gl.getShaderParameter(vertexShader, gl.COMPILE_STATUS)) //... >>>> >>>> gl.compileShader(fragmentShader); >>>> >>>> if (!gl.getShaderParameter(fragmentShader, gl.COMPILE_STATUS)) //... >>>> >>>> //... >>>> >>>> gl.linkProgram(program); >>>> if (!gl.getProgramParameter(program, gl.LINK_STATUS)) //... >>>> >>>> I think it would be worth it to make clear that this pattern would >>>> sabotage the parallel compile. >>>> >>>> >>>> >>>> I seem to remember (not sure if this is still true) that this pattern >>>> also sabotages the shader compiler cache in ANGLE, because ANGLE doesn't >>>> cache the COMPILE_STATUS (or was it the compile info string?). So it forces >>>> the compiler to recompile just to give you the status. >>>> >>>> >>>> >>>> Tarek Sherif >>>> >>>> http://tareksherif.net/ >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> ??????? Original Message ??????? >>>> >>>> On Monday, April 15, 2019 9:00 PM, Ken Russell (kbr...@) < >>>> public_webgl...@> wrote: >>>> >>>> >>>> >>>> The WebGL extension (which is basically just a wrapper) refers to the >>>> underlying OpenGL / OpenGL ES extension >>>> https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt >>>> , >>>> where this is documented. Is that sufficient? It would be better to avoid >>>> duplicating a large amount of spec text from the underlying extension. >>>> However, we can add some non-normative text if that would help. >>>> >>>> >>>> >>>> -Ken >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Sat, Apr 13, 2019 at 3:51 AM Tarek Sherif (tareksherif...@) < >>>> public_webgl...@> wrote: >>>> >>>> IIRC, all 3 of those functions still force a wait for the {shader to >>>> finish compiling, program to finish linking} just as they did before. The >>>> new semantics are only visible via the new COMPLETION_STATUS_KHR check. >>>> >>>> That should work perfectly for us. Can we add some language to the spec >>>> about which functions cause stalls? I feel like as written, it will be easy >>>> for people to use the extension incorrectly. >>>> >>>> >>>> >>>> Tarek Sherif >>>> >>>> http://tareksherif.net/ >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> ??????? Original Message ??????? >>>> >>>> On Friday, April 12, 2019 4:10 PM, Kai Ninomiya (kainino...@) < >>>> public_webgl...@> wrote: >>>> >>>> >>>> >>>> Oh yes, useProgram probably won't stall. But getUniformLocation and the >>>> others will stall, as will draw calls. >>>> >>>> >>>> >>>> getProgramParameter(COMPLETION_STATUS_KHR) should get faster at some >>>> point; see http://crbug.com/881152 >>>> which >>>> Ken linked. >>>> >>>> >>>> >>>> On Fri, Apr 12, 2019 at 12:39 PM Jasper St. Pierre ( >>>> jstpierre...@) wrote: >>>> >>>> Thank you! Trying this out in my own WebGL 2 app, I see quite a >>>> reduction in shader compilation time, shaving 400ms on load time on a >>>> moderately complex scene. The getProgramParameter(COMPLETION_STATUS_KHR) >>>> query still takes 1ms (which I believe is being tracked), but that is still >>>> better from the 4ms I see in getUniformBlockIndex (my previous sync point). >>>> >>>> >>>> >>>> AFAIK, useProgram should not cause a stall, but in order to set my >>>> texture samplers to bind to different units, I need to do a >>>> getUniformLocation on my sampler uniform, which causes a compilation stall. >>>> Same thing with getUniformBlockIndex. Do make sure that anything that might >>>> query into reflection about the program (e.g. getVertexAttributeIndex, >>>> getUniformLocation, getUniformBlockIndex) happens after >>>> COMPLETION_STATUS_KHR returns true, since that?s another way to >>>> accidentally stall on compilation completing. >>>> >>>> >>>> >>>> >>>> >>>> *From:* owners-public_webgl...@ < >>>> owners-public_webgl...@> *On Behalf Of *Kai Ninomiya ( >>>> kainino...@) >>>> >>>> *Sent:* Friday, April 12, 2019 10:25 AM >>>> >>>> *To:* Public WebGL >>>> >>>> *Subject:* Re: [Public WebGL] Propose promoting >>>> KHR_parallel_shader_compile to community approved >>>> >>>> >>>> >>>> >>>> >>>> IIRC, all 3 of those functions still force a wait for the {shader to >>>> finish compiling, program to finish linking} just as they did before. The >>>> new semantics are only visible via the new COMPLETION_STATUS_KHR check. >>>> >>>> >>>> >>>> On Fri, Apr 12, 2019 at 10:05 AM Tarek Sherif (tsherif...@) < >>>> public_webgl...@> wrote: >>>> >>>> Very excited about this extension, but I'm concerned about how it would >>>> work in our use case. Our flagship visualization library, deck.gl >>>> , >>>> often shares the gl context with a separate base map rendering application >>>> so that it can properly interleave visualization layers with the base map. >>>> Enabling this extension seems to change the behaviour of existing WebGL >>>> functions in a way that I don't believe other extensions do. My worry is >>>> how our enabling KHR_parallel_shader_compile would affect applications we >>>> share contexts with, i.e what happens if the typical synchronous >>>> compilation logic is used after KHR_parallel_shader_compile is enabled? >>>> Specifically: >>>> >>>> - What happens if getShaderParameter(shader, COMPILE_STATUS) is >>>> called before compilation is complete? >>>> - What happens if getProgramParameter(program, LINK_STATUS) is >>>> called before linking is complete? >>>> - What happens if useProgram is called before linking is complete? >>>> >>>> Thanks, >>>> >>>> >>>> >>>> >>>> >>>> Tarek Sherif >>>> >>>> Senior Software Engineer, Visualization | Uber >>>> >>>> http://vis.gl/ >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> *Tarek Sherif* >>>> >>>> Senior Software Engineer, Visualization | Uber >>>> >>>> http://vis.gl/ >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Apr 12, 2019 at 12:16 PM David Catuhe ( >>>> David.Catuhe...@) wrote: >>>> >>>> Wonderful! >>>> >>>> >>>> >>>> >>>> >>>> *From:* owners-public_webgl...@ < >>>> owners-public_webgl...@> *On Behalf Of *Ken Russell ( >>>> kbr...@) >>>> >>>> *Sent:* Wednesday, April 10, 2019 2:56 PM >>>> >>>> *To:* Public WebGL >>>> >>>> *Subject:* Re: [Public WebGL] Propose promoting >>>> KHR_parallel_shader_compile to community approved >>>> >>>> >>>> >>>> >>>> >>>> If your code works correctly now when enabling draft WebGL extensions >>>> in Chrome, then no changes are needed. There won't be any changes to the >>>> extension when it's taken out of draft status; it'll just be available by >>>> default. >>>> >>>> >>>> >>>> -Ken >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Apr 10, 2019 at 12:36 PM David Catuhe ( >>>> David.Catuhe...@) wrote: >>>> >>>> We do have support for the extension in Babylon.js. How can we test >>>> this change? >>>> ------------------------------ >>>> >>>> >>>> >>>> *From:* owners-public_webgl...@ < >>>> owners-public_webgl...@> on behalf of Ken Russell ( >>>> kbr...@) >>>> *Sent:* Wednesday, April 10, 2019 12:00:25 PM >>>> *To:* public >>>> *Subject:* [Public WebGL] Propose promoting >>>> KHR_parallel_shader_compile to community approved >>>> >>>> >>>> >>>> WebGL community, >>>> >>>> >>>> >>>> Jie Chen from Intel has principally developed and implemented a WebGL >>>> wrapper for the KHR_parallel_shader_compile extension. This allows shader >>>> compilation and program linking to occur fully in parallel to the rest of >>>> the WebGL application. Some small application changes are needed to take >>>> full advantage of the extension, but it is otherwise fully backward >>>> compatible. Jie has even emulated this extension on platforms which don't >>>> support it natively. >>>> >>>> >>>> >>>> This extension solves a longstanding user complaint with WebGL, namely >>>> long shader compile times on Windows. Compiles and links occur not only >>>> asynchronously, but also in parallel, so there is a net speedup when using >>>> this extension. Users who have tried out the draft extension are pleased >>>> with the results and would like to see it made widely available. >>>> >>>> >>>> >>>> I propose promoting this extension to community approved in >>>> https://github.com/KhronosGroup/WebGL/pull/2855 >>>> >>>> . Any comments? >>>> >>>> >>>> >>>> -Ken >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Virus-free. www.avg.com <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 82548 bytes Desc: not available URL: From pub...@ Fri May 10 10:26:53 2019 From: pub...@ (Jasper St. Pierre (...@...)) Date: Fri, 10 May 2019 17:26:53 +0000 Subject: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved In-Reply-To: References: Message-ID: Hello again. My app is now showing that getProgramParameter is completing quick, but it is spending a lot of time in useProgram. I am checking for COMPLETION_STATUS_KHR on the GL program beforehand and it is returning true. I?m guessing there?s some additional expensive work that still needs to happen at useProgram time. Is this a bug? Any ways to debug or avoid this? I?m unsure if there will be an easy repro. Again, profiler screenshot attached. From: owners-public_webgl...@ On Behalf Of Takahiro Aoyagi (taoyagi...@) Sent: Friday, May 10, 2019 12:22 AM To: Public WebGL Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Confirmed COMPLETION_STATUS_KHR is very fast like 0.01ms on my test https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html Nice work! Thanks [https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png] Virus-free. www.avg.com On Wed, May 8, 2019 at 2:41 PM Ken Russell (kbr...@) > wrote: Jie Chen from Intel just landed a fix in Chrome dramatically improving the performance of querying COMPLETION_STATUS_KHR under http://crbug.com/881152 . The fix will be in tomorrow's Canary on Windows and macOS. This should address the last major gap with this extension. We would like to enable it by default by promoting it to community approved; any further comments? -Ken From: Ken Russell > Date: Fri, Apr 26, 2019 at 3:40 PM To: Public WebGL Thanks for the report and the clear test case. There was an existing bug about this, so the new one was duplicated into it, and some hints about implementing it were added to the preexisting bug. On Fri, Apr 26, 2019 at 5:56 AM Takahiro Aoyagi (taoyagi...@) > wrote: Hi Chen, Opened a bug. Thanks. https://bugs.chromium.org/p/chromium/issues/detail?id=957001 Takahiro On Fri, Apr 26, 2019 at 8:03 PM Chen, Jie A (jie.a.chen...@) > wrote: Hi Takahiro, The current implementation of COMPLETION_STATUS_KHR query in chromium incurs an expensive round-trip to the GPU thread. This may contribute to the wait time in your case. I am trying to optimize this. Could you please file a bug to chromium? I would look into it once I?ve done the optimization. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Takahiro Aoyagi (taoyagi...@) Sent: Friday, April 26, 2019 6:20 PM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Hi all, I'm working on Three.js + KHR_parallel_shader_compile extension support with Fernando. https://github.com/mrdoob/three.js/issues/16321#issuecomment-486436086 I'm testing with Canary. But the behavior seems weird to me. gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) seems to wait for compile+link completion. I don't think it should wait for that, it should just do polling and returning true/false quickly instead. I made a simple test to reproduce. https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html Code snippet. const ext = gl.getExtension('KHR_parallel_shader_compile'); gl.compileShader(vertexShader); gl.compileShader(fragmentShader); gl.attachShader(program, vertexShader); gl.attachShader(program, fragmentShader); gl.linkProgram(program); const startTime = performance.now(); const status = useExtension ? gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) : gl.getProgramParameter(program, gl.LINK_STATUS); const endTime = performance.now(); const elapsedTime = endTime - startTime; On my platform, both gl.LINK_STATUS and ext.COMPLETION_STATUS_KHR take so long time about 15ms. I can accept this number for gl.LINK_STATUS because it waits for compile+link completion. But 15ms for ext.COMPLETION_STATUS_KHR looks weird to me. It shouldn't wait for the compile+link completion but should do just polling and quickly returning true/false instead. So I guess the number should be 1ms or less. Let me know if I'm missing something. Or could it be a Canary bug? My platform. OS: Windows10 Browser: Chrome Canary. Browser boot option: --use-cmd-decoder=passthrough --enable-webgl-draft-extensions Thanks Takahiro On Fri, Apr 26, 2019 at 10:15 AM Chen, Jie A (jie.a.chen...@) > wrote: Basically, for ANGLE?s GL backend, it?s simply a wrapper for the existing GL implementations. In this sense glCompileShader() is still implementation specific. Essentially ANGLE just calls glCompileShader and check GL_COMPILE_STATUS. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Jasper St. Pierre (jstpierre...@) Sent: Friday, April 26, 2019 1:18 AM To: Public WebGL > Subject: RE: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Thank you, that?s important information to know. Changing my shader compilation pipeline to wait for shader completion status is a lot more difficult, but based on some initial tests, it?s more expensive than not doing it ? the latency of getShaderParameter is too high. That said, in a lot of GL implementations, glCompileShader() is practically a no-op, and will only do an AST parse when glGetShaderParameter/InfoLog() is called (which is basically only for debugging / error checking). glLinkProgram() does full compilation of all programs, as full-PSO optimization is important. I don?t know how common this is, but multiple GL implementations I have seen do it. It might make sense for ANGLE to adopt this model as well. From: owners-public_webgl...@ > On Behalf Of Chen, Jie A (jie.a.chen...@) Sent: Wednesday, April 24, 2019 6:48 PM To: Public WebGL > Subject: RE: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Absolutely. Ideally there would be no stall for linkProgram. I tried, but it?s too difficult to achieve this in ANGLE. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Jeff Gilbert (jgilbert...@) Sent: Thursday, April 25, 2019 9:33 AM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Possibly, but in the long run, I expect implementations to support no-stall linkProgram invocations. On Wed, Apr 24, 2019 at 6:27 PM Chen, Jie A (jie.a.chen...@) > wrote: linkProgram may stall on compileShader. To avoid the stall, you?d better make sure the COMPLETION_STATUS_KHR statuses of the attached shaders are all True before calling linkProgram. In this sense, the first workflow has less chance running into stall. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Fernando Serrano Garc?a (fserrano...@) Sent: Wednesday, April 24, 2019 9:38 PM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Regarding the optimal proposed workflow (grouping shaders and programs separately) of: for (const x of shaders) gl.compileShader(x); for (const x of programs) gl.linkProgram(x); versus something more on the way that we currently have in many engines as threejs: for (const x of material) gl.compileShader(fs); gl.compileShader(vs); gl.linkProgram(x); Do you think is more or less accurate the following graph for 4 materials and enabling this extension with 2 and 4 parallel threads? [Screen Shot 2019-04-24 at 15.35.47.png] On Wed, Apr 24, 2019 at 2:40 PM Fernando Serrano Garc?a > wrote: fwiw three.js introduced a "debug" parameter (false by default) to determine if there will be a status check and call all the get* (currently in dev): - https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLShader.js#L21-L26 - https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLProgram.js#L608 so currently calling `new WebGLShader()` won't be blocking with any `get*` function and it could be used as is to compile all of them in a loop with or without the extension. the problem comes from the WebGLProgram as it should just queue itself before trying to link any program and wait until all the shader compile calls finish, then do all the link, and wait for it asynchronously before start using these programs. I have opened an issue on the three.js repo to keep track of the implementation and we have booked some time this week to take a look at it, feedback is welcome :) https://github.com/mrdoob/three.js/issues/16321 On Tue, Apr 16, 2019 at 11:55 PM Ken Russell (kbr...@) > wrote: On Tue, Apr 16, 2019 at 2:24 PM Tarek Sherif (tsherif...@) > wrote: Yes, I've read both specs. I think this language in the WebGL version is confusing: "When this extension is enabled: Shader compilation and program linking may be performed in a separate CPU thread." And neither indicates which functions are expected to cause stalls. As written, this extension requires more than most that people know implementation details. All previous operations against the program - looking up uniform locations, drawing with it, etc. - will cause stalls. The application *must* be updated to query the program's COMPLETION_STATUS_KHR status, and skip *all* operations against the program until it's no longer pending. I guess we'll just change the WebGL version of this extension spec to be much more explicit about this. Essentially, all previous code which checked for the completion of compilation of shaders / linking of programs can be updated with a small wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. This is not true because the most common way this is done will cause stalls that sabotage the parallelism, e.g.: https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLShader.js#L21-L36 https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLProgram.js#L586-L631 The check for COMPLETION_STATUS_KHR has to wrap *all* queries and uses of the program object, and they must be skipped until COMPLETION_STATUS_KHR returns true. Yes, all applications will have to be updated to take advantage of this extension, but if they do, the benefits will be significant. -Ken Tarek Sherif Senior Software Engineer, Visualization | Uber http://vis.gl/ On Tue, Apr 16, 2019 at 4:18 PM Ken Russell (kbr...@) > wrote: Please review the Overview in the underlying OpenGL ES spec: https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt It describes that the extension uses one or more separate CPU threads for shader compilation. If you still think we should rewrite the introduction to the WebGL extension, we can do that too. Essentially, all previous code which checked for the completion of compilation of shaders / linking of programs can be updated with a small wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. -Ken On Tue, Apr 16, 2019 at 1:36 AM Tarek Sherif (tsherif...@) > wrote: This is all extremely interesting, and documentation of these best practices should probably be more publicly available (perhaps through a non-normative note in the spec). I'm thinking the language in the extension spec could be made more clear about what it's actual purpose is. It currently gives the impression that enabling it is what allows for parallel compilation and that this should save time, but given what Jeff and Kai have said, it sounds like the purpose is to avoid CPU stalls, and that it might even take longer in wall time since you're only checking once a frame. Maybe some background information could be added along the lines of "Normally applications must wait on get*Parameter or a draw call for program linking to complete, this extension provides a mechanism for querying completion status without stalling..." Tarek Sherif Senior Software Engineer, Visualization | Uber http://vis.gl/ On Mon, Apr 15, 2019 at 11:23 PM Kai Ninomiya (kainino...@) > wrote: On Mon, Apr 15, 2019 at 7:18 PM Tarek Sherif (tareksherif...@) > wrote: I don't see anything in the OpenGL extension spec about what functions cause stalls. Is that implementation-specific? Having an idea what to expect is important for two reasons: 1. To make it clear that drawing will still work if getProgramParameter(COMPLETION_STATUS_KHR) hasn't returned true yet (i.e. the stall on a draw call) Generally, OpenGL extensions are not allowed to break existing API/existing content. (In OpenGL, all extensions are always enabled; there's no requestExtension.) Hence, even if you enable the extension, it won't change the way your application works, and therefore the draw call must still cause a stall in order to be able to use the program. 2. Almost all WebGL code I've looked at handles compilation in a way similar to the following: gl.compileShader(vertexShader); if (!gl.getShaderParameter(vertexShader, gl.COMPILE_STATUS)) //... gl.compileShader(fragmentShader); if (!gl.getShaderParameter(fragmentShader, gl.COMPILE_STATUS)) //... //... gl.linkProgram(program); if (!gl.getProgramParameter(program, gl.LINK_STATUS)) //... I think it would be worth it to make clear that this pattern would sabotage the parallel compile. I seem to remember (not sure if this is still true) that this pattern also sabotages the shader compiler cache in ANGLE, because ANGLE doesn't cache the COMPILE_STATUS (or was it the compile info string?). So it forces the compiler to recompile just to give you the status. Tarek Sherif http://tareksherif.net/ ??????? Original Message ??????? On Monday, April 15, 2019 9:00 PM, Ken Russell (kbr...@) > wrote: The WebGL extension (which is basically just a wrapper) refers to the underlying OpenGL / OpenGL ES extension https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt, where this is documented. Is that sufficient? It would be better to avoid duplicating a large amount of spec text from the underlying extension. However, we can add some non-normative text if that would help. -Ken On Sat, Apr 13, 2019 at 3:51 AM Tarek Sherif (tareksherif...@) > wrote: IIRC, all 3 of those functions still force a wait for the {shader to finish compiling, program to finish linking} just as they did before. The new semantics are only visible via the new COMPLETION_STATUS_KHR check. That should work perfectly for us. Can we add some language to the spec about which functions cause stalls? I feel like as written, it will be easy for people to use the extension incorrectly. Tarek Sherif http://tareksherif.net/ ??????? Original Message ??????? On Friday, April 12, 2019 4:10 PM, Kai Ninomiya (kainino...@) > wrote: Oh yes, useProgram probably won't stall. But getUniformLocation and the others will stall, as will draw calls. getProgramParameter(COMPLETION_STATUS_KHR) should get faster at some point; see http://crbug.com/881152 which Ken linked. On Fri, Apr 12, 2019 at 12:39 PM Jasper St. Pierre (jstpierre...@) > wrote: Thank you! Trying this out in my own WebGL 2 app, I see quite a reduction in shader compilation time, shaving 400ms on load time on a moderately complex scene. The getProgramParameter(COMPLETION_STATUS_KHR) query still takes 1ms (which I believe is being tracked), but that is still better from the 4ms I see in getUniformBlockIndex (my previous sync point). AFAIK, useProgram should not cause a stall, but in order to set my texture samplers to bind to different units, I need to do a getUniformLocation on my sampler uniform, which causes a compilation stall. Same thing with getUniformBlockIndex. Do make sure that anything that might query into reflection about the program (e.g. getVertexAttributeIndex, getUniformLocation, getUniformBlockIndex) happens after COMPLETION_STATUS_KHR returns true, since that?s another way to accidentally stall on compilation completing. From: owners-public_webgl...@ > On Behalf Of Kai Ninomiya (kainino...@) Sent: Friday, April 12, 2019 10:25 AM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved IIRC, all 3 of those functions still force a wait for the {shader to finish compiling, program to finish linking} just as they did before. The new semantics are only visible via the new COMPLETION_STATUS_KHR check. On Fri, Apr 12, 2019 at 10:05 AM Tarek Sherif (tsherif...@) > wrote: Very excited about this extension, but I'm concerned about how it would work in our use case. Our flagship visualization library, deck.gl, often shares the gl context with a separate base map rendering application so that it can properly interleave visualization layers with the base map. Enabling this extension seems to change the behaviour of existing WebGL functions in a way that I don't believe other extensions do. My worry is how our enabling KHR_parallel_shader_compile would affect applications we share contexts with, i.e what happens if the typical synchronous compilation logic is used after KHR_parallel_shader_compile is enabled? Specifically: * What happens if getShaderParameter(shader, COMPILE_STATUS) is called before compilation is complete? * What happens if getProgramParameter(program, LINK_STATUS) is called before linking is complete? * What happens if useProgram is called before linking is complete? Thanks, Tarek Sherif Senior Software Engineer, Visualization | Uber http://vis.gl/ Tarek Sherif Senior Software Engineer, Visualization | Uber http://vis.gl/ On Fri, Apr 12, 2019 at 12:16 PM David Catuhe (David.Catuhe...@) > wrote: Wonderful! From: owners-public_webgl...@ > On Behalf Of Ken Russell (kbr...@) Sent: Wednesday, April 10, 2019 2:56 PM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved If your code works correctly now when enabling draft WebGL extensions in Chrome, then no changes are needed. There won't be any changes to the extension when it's taken out of draft status; it'll just be available by default. -Ken On Wed, Apr 10, 2019 at 12:36 PM David Catuhe (David.Catuhe...@) > wrote: We do have support for the extension in Babylon.js. How can we test this change? ________________________________ From: owners-public_webgl...@ > on behalf of Ken Russell (kbr...@) > Sent: Wednesday, April 10, 2019 12:00:25 PM To: public Subject: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved WebGL community, Jie Chen from Intel has principally developed and implemented a WebGL wrapper for the KHR_parallel_shader_compile extension. This allows shader compilation and program linking to occur fully in parallel to the rest of the WebGL application. Some small application changes are needed to take full advantage of the extension, but it is otherwise fully backward compatible. Jie has even emulated this extension on platforms which don't support it natively. This extension solves a longstanding user complaint with WebGL, namely long shader compile times on Windows. Compiles and links occur not only asynchronously, but also in parallel, so there is a net speedup when using this extension. Users who have tried out the draft extension are pleased with the results and would like to see it made widely available. I propose promoting this extension to community approved in https://github.com/KhronosGroup/WebGL/pull/2855 . Any comments? -Ken [https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png] Virus-free. www.avg.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 82548 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: chrome_up0AJZj96D.png Type: image/png Size: 85289 bytes Desc: chrome_up0AJZj96D.png URL: From pub...@ Fri May 10 10:45:27 2019 From: pub...@ (Ken Russell (...@...)) Date: Fri, 10 May 2019 10:45:27 -0700 Subject: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved In-Reply-To: References: Message-ID: Hmm. The only reason I can think of that that would happen is if you're running on Windows, and ANGLE has to dynamically recompile the program behind the scenes in order to handle some OpenGL ES state change. I'm not 100% sure which changes require this dynamic recompilation; the ANGLE developers would know best. https://groups.google.com//forum/#!forum/angleproject might be helpful. We'd really need some test case to make progress on this. Can you provide one? -Ken On Fri, May 10, 2019 at 10:28 AM Jasper St. Pierre (jstpierre...@) < public_webgl...@> wrote: > Hello again. My app is now showing that getProgramParameter is completing > quick, but it is spending a lot of time in useProgram. I am checking for > COMPLETION_STATUS_KHR on the GL program beforehand and it is returning > true. I?m guessing there?s some additional expensive work that still needs > to happen at useProgram time. Is this a bug? Any ways to debug or avoid > this? I?m unsure if there will be an easy repro. > > > > Again, profiler screenshot attached. > > > > *From:* owners-public_webgl...@ *On > Behalf Of *Takahiro Aoyagi (taoyagi...@) > *Sent:* Friday, May 10, 2019 12:22 AM > *To:* Public WebGL > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Confirmed COMPLETION_STATUS_KHR is very fast like 0.01ms on my test > > > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html > > > > Nice work! > > > > Thanks > > > > [image: > https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png] > > > Virus-free. www.avg.com > > > > > On Wed, May 8, 2019 at 2:41 PM Ken Russell (kbr...@) < > public_webgl...@> wrote: > > Jie Chen from Intel just landed a fix in Chrome dramatically improving the > performance of querying COMPLETION_STATUS_KHR under > http://crbug.com/881152 . The fix will be in tomorrow's Canary on Windows > and macOS. > > > > This should address the last major gap with this extension. We would like > to enable it by default by promoting it to community approved; any further > comments? > > > > -Ken > > > > > > > > *From: *Ken Russell > *Date: *Fri, Apr 26, 2019 at 3:40 PM > *To: *Public WebGL > > Thanks for the report and the clear test case. There was an existing bug > about this, so the new one was duplicated into it, and some hints about > implementing it were added to the preexisting bug. > > > > > > On Fri, Apr 26, 2019 at 5:56 AM Takahiro Aoyagi (taoyagi...@) < > public_webgl...@> wrote: > > Hi Chen, > > > > Opened a bug. Thanks. > > > > https://bugs.chromium.org/p/chromium/issues/detail?id=957001 > > > > Takahiro > > > > > > On Fri, Apr 26, 2019 at 8:03 PM Chen, Jie A (jie.a.chen...@) < > public_webgl...@> wrote: > > Hi Takahiro, > > The current implementation of COMPLETION_STATUS_KHR query in chromium > incurs an expensive round-trip to the GPU thread. This may contribute to > the wait time in your case. I am trying to optimize this. Could you please > file a bug to chromium? I would look into it once I?ve done the > optimization. > > > > *From:* owners-public_webgl...@ [mailto: > owners-public_webgl...@] *On Behalf Of *Takahiro Aoyagi ( > taoyagi...@) > *Sent:* Friday, April 26, 2019 6:20 PM > *To:* Public WebGL > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Hi all, > > > > I'm working on Three.js + KHR_parallel_shader_compile extension support > with Fernando. > > > > https://github.com/mrdoob/three.js/issues/16321#issuecomment-486436086 > > > > I'm testing with Canary. But the behavior seems weird to me. > gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) seems to wait > for compile+link completion. I don't think it should wait for that, it > should just do polling and returning true/false quickly instead. > > > > I made a simple test to reproduce. > > > > > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html > > > > Code snippet. > > > > const ext = gl.getExtension('KHR_parallel_shader_compile'); > > > > gl.compileShader(vertexShader); > gl.compileShader(fragmentShader); > gl.attachShader(program, vertexShader); > gl.attachShader(program, fragmentShader); > gl.linkProgram(program); > > const startTime = performance.now(); > const status = useExtension > ? gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) > : gl.getProgramParameter(program, gl.LINK_STATUS); > const endTime = performance.now(); > > const elapsedTime = endTime - startTime; > > > > On my platform, both gl.LINK_STATUS and ext.COMPLETION_STATUS_KHR take so > long time about 15ms. I can accept this number for gl.LINK_STATUS because > it waits for compile+link completion. But 15ms for > ext.COMPLETION_STATUS_KHR looks weird to me. It shouldn't wait for the > compile+link completion but should do just polling and quickly returning > true/false instead. So I guess the number should be 1ms or less. > > > > Let me know if I'm missing something. Or could it be a Canary bug? > > > > My platform. > > > > OS: Windows10 > > Browser: Chrome Canary. > > Browser boot option: --use-cmd-decoder=passthrough > --enable-webgl-draft-extensions > > > > > > Thanks > > > > Takahiro > > > > > > On Fri, Apr 26, 2019 at 10:15 AM Chen, Jie A (jie.a.chen...@) < > public_webgl...@> wrote: > > Basically, for ANGLE?s GL backend, it?s simply a wrapper for the existing > GL implementations. In this sense glCompileShader() is still implementation > specific. Essentially ANGLE just calls glCompileShader and check > GL_COMPILE_STATUS. > > > > *From:* owners-public_webgl...@ [mailto: > owners-public_webgl...@] *On Behalf Of *Jasper St. Pierre ( > jstpierre...@) > *Sent:* Friday, April 26, 2019 1:18 AM > *To:* Public WebGL > *Subject:* RE: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Thank you, that?s important information to know. Changing my shader > compilation pipeline to wait for shader completion status is a lot more > difficult, but based on some initial tests, it?s more expensive than not > doing it ? the latency of getShaderParameter is too high. > > > > That said, in a lot of GL implementations, glCompileShader() is > practically a no-op, and will only do an AST parse when > glGetShaderParameter/InfoLog() is called (which is basically only for > debugging / error checking). glLinkProgram() does full compilation of all > programs, as full-PSO optimization is important. I don?t know how common > this is, but multiple GL implementations I have seen do it. It might make > sense for ANGLE to adopt this model as well. > > > > *From:* owners-public_webgl...@ *On > Behalf Of *Chen, Jie A (jie.a.chen...@) > *Sent:* Wednesday, April 24, 2019 6:48 PM > *To:* Public WebGL > *Subject:* RE: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Absolutely. Ideally there would be no stall for linkProgram. I tried, but > it?s too difficult to achieve this in ANGLE. > > > > *From:* owners-public_webgl...@ [ > mailto:owners-public_webgl...@ ] *On > Behalf Of *Jeff Gilbert (jgilbert...@) > *Sent:* Thursday, April 25, 2019 9:33 AM > *To:* Public WebGL > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Possibly, but in the long run, I expect implementations to support > no-stall linkProgram invocations. > > > > On Wed, Apr 24, 2019 at 6:27 PM Chen, Jie A (jie.a.chen...@) < > public_webgl...@> wrote: > > linkProgram may stall on compileShader. To avoid the stall, you?d better > make sure the COMPLETION_STATUS_KHR statuses of the attached shaders are > all True before calling linkProgram. In this sense, the first workflow has > less chance running into stall. > > > > *From:* owners-public_webgl...@ [mailto: > owners-public_webgl...@] *On Behalf Of *Fernando Serrano Garc?a ( > fserrano...@) > *Sent:* Wednesday, April 24, 2019 9:38 PM > *To:* Public WebGL > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Regarding the optimal proposed workflow (grouping shaders and programs > separately) of: > > for (const x of shaders) > gl.compileShader(x); > for (const x of programs) > gl.linkProgram(x); > > > > versus something more on the way that we currently have in many engines as > threejs: > > for (const x of material) > > gl.compileShader(fs); > > gl.compileShader(vs); > gl.linkProgram(x); > > > > Do you think is more or less accurate the following graph for 4 materials > and enabling this extension with 2 and 4 parallel threads? > > > > [image: Screen Shot 2019-04-24 at 15.35.47.png] > > > > On Wed, Apr 24, 2019 at 2:40 PM Fernando Serrano Garc?a < > fserrano...@> wrote: > > fwiw three.js introduced a "debug" parameter (false by default) to > determine if there will be a status check and call all the get* (currently > in dev): > > - > https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLShader.js#L21-L26 > > - > https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLProgram.js#L608 > > > > so currently calling `new WebGLShader()` won't be blocking with any `get*` > function and it could be used as is to compile all of them in a loop with > or without the extension. > > the problem comes from the WebGLProgram as it should just queue itself > before trying to link any program and wait until all the shader compile > calls finish, then do all the link, and wait for it asynchronously before > start using these programs. > > I have opened an issue on the three.js repo to keep track of the > implementation and we have booked some time this week to take a look at it, > feedback is welcome :) https://github.com/mrdoob/three.js/issues/16321 > > > > On Tue, Apr 16, 2019 at 11:55 PM Ken Russell (kbr...@) < > public_webgl...@> wrote: > > On Tue, Apr 16, 2019 at 2:24 PM Tarek Sherif (tsherif...@) < > public_webgl...@> wrote: > > Yes, I've read both specs. I think this language in the WebGL version is > confusing: "When this extension is enabled: Shader compilation and program > linking may be performed in a separate CPU thread." And neither indicates > which functions are expected to cause stalls. As written, this extension > requires more than most that people know implementation details. > > > > All previous operations against the program - looking up uniform > locations, drawing with it, etc. - will cause stalls. The application > *must* be updated to query the program's COMPLETION_STATUS_KHR status, and > skip *all* operations against the program until it's no longer pending. > > > > I guess we'll just change the WebGL version of this extension spec to be > much more explicit about this. > > > > > > Essentially, all previous code which checked for the completion of > compilation of shaders / linking of programs can be updated with a small > wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. > > > > This is not true because the most common way this is done will cause > stalls that sabotage the parallelism, e.g.: > > https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLShader.js#L21-L36 > > > https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLProgram.js#L586-L631 > > > > The check for COMPLETION_STATUS_KHR has to wrap *all* queries and uses of > the program object, and they must be skipped until COMPLETION_STATUS_KHR > returns true. Yes, all applications will have to be updated to take > advantage of this extension, but if they do, the benefits will be > significant. > > > > -Ken > > > > > > *Tarek Sherif* > > Senior Software Engineer, Visualization | Uber > > http://vis.gl/ > > > > > > > > On Tue, Apr 16, 2019 at 4:18 PM Ken Russell (kbr...@) < > public_webgl...@> wrote: > > Please review the Overview in the underlying OpenGL ES spec: > > > https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt > > > > > It describes that the extension uses one or more separate CPU threads for > shader compilation. If you still think we should rewrite the introduction > to the WebGL extension, we can do that too. > > > > Essentially, all previous code which checked for the completion of > compilation of shaders / linking of programs can be updated with a small > wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. > > > > -Ken > > > > > > > > On Tue, Apr 16, 2019 at 1:36 AM Tarek Sherif (tsherif...@) < > public_webgl...@> wrote: > > This is all extremely interesting, and documentation of these best > practices should probably be more publicly available (perhaps through a > non-normative note in the spec). I'm thinking the language in the extension > spec could be made more clear about what it's actual purpose is. It > currently gives the impression that enabling it is what allows for parallel > compilation and that this should save time, but given what Jeff and Kai > have said, it sounds like the purpose is to avoid CPU stalls, and that it > might even take longer in wall time since you're only checking once a > frame. Maybe some background information could be added along the lines of > "Normally applications must wait on get*Parameter or a draw call for > program linking to complete, this extension provides a mechanism for > querying completion status without stalling..." > > > > *Tarek Sherif* > > Senior Software Engineer, Visualization | Uber > > http://vis.gl/ > > > > > > > > > On Mon, Apr 15, 2019 at 11:23 PM Kai Ninomiya (kainino...@) < > public_webgl...@> wrote: > > > > > > On Mon, Apr 15, 2019 at 7:18 PM Tarek Sherif (tareksherif...@) < > public_webgl...@> wrote: > > I don't see anything in the OpenGL extension spec about what functions > cause stalls. Is that implementation-specific? Having an idea what to > expect is important for two reasons: > > 1. To make it clear that drawing will still work if > getProgramParameter(COMPLETION_STATUS_KHR) hasn't returned true yet (i.e. > the stall on a draw call) > > > > Generally, OpenGL extensions are not allowed to break existing > API/existing content. (In OpenGL, all extensions are always enabled; > there's no requestExtension.) Hence, even if you enable the extension, it > won't change the way your application works, and therefore the draw call > must still cause a stall in order to be able to use the program. > > > > 2. Almost all WebGL code I've looked at handles compilation in a way > similar to the following: > > gl.compileShader(vertexShader); > if (!gl.getShaderParameter(vertexShader, gl.COMPILE_STATUS)) //... > > gl.compileShader(fragmentShader); > > if (!gl.getShaderParameter(fragmentShader, gl.COMPILE_STATUS)) //... > > //... > > gl.linkProgram(program); > if (!gl.getProgramParameter(program, gl.LINK_STATUS)) //... > > I think it would be worth it to make clear that this pattern would > sabotage the parallel compile. > > > > I seem to remember (not sure if this is still true) that this pattern also > sabotages the shader compiler cache in ANGLE, because ANGLE doesn't cache > the COMPILE_STATUS (or was it the compile info string?). So it forces the > compiler to recompile just to give you the status. > > > > Tarek Sherif > > http://tareksherif.net/ > > > > > > > > > ??????? Original Message ??????? > > On Monday, April 15, 2019 9:00 PM, Ken Russell (kbr...@) < > public_webgl...@> wrote: > > > > The WebGL extension (which is basically just a wrapper) refers to the > underlying OpenGL / OpenGL ES extension > https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt > , > where this is documented. Is that sufficient? It would be better to avoid > duplicating a large amount of spec text from the underlying extension. > However, we can add some non-normative text if that would help. > > > > -Ken > > > > > > > > On Sat, Apr 13, 2019 at 3:51 AM Tarek Sherif (tareksherif...@) < > public_webgl...@> wrote: > > IIRC, all 3 of those functions still force a wait for the {shader to > finish compiling, program to finish linking} just as they did before. The > new semantics are only visible via the new COMPLETION_STATUS_KHR check. > > That should work perfectly for us. Can we add some language to the spec > about which functions cause stalls? I feel like as written, it will be easy > for people to use the extension incorrectly. > > > > Tarek Sherif > > http://tareksherif.net/ > > > > > > > > > ??????? Original Message ??????? > > On Friday, April 12, 2019 4:10 PM, Kai Ninomiya (kainino...@) < > public_webgl...@> wrote: > > > > Oh yes, useProgram probably won't stall. But getUniformLocation and the > others will stall, as will draw calls. > > > > getProgramParameter(COMPLETION_STATUS_KHR) should get faster at some > point; see http://crbug.com/881152 > which > Ken linked. > > > > On Fri, Apr 12, 2019 at 12:39 PM Jasper St. Pierre (jstpierre...@) > wrote: > > Thank you! Trying this out in my own WebGL 2 app, I see quite a reduction > in shader compilation time, shaving 400ms on load time on a moderately > complex scene. The getProgramParameter(COMPLETION_STATUS_KHR) query still > takes 1ms (which I believe is being tracked), but that is still better from > the 4ms I see in getUniformBlockIndex (my previous sync point). > > > > AFAIK, useProgram should not cause a stall, but in order to set my texture > samplers to bind to different units, I need to do a getUniformLocation on > my sampler uniform, which causes a compilation stall. Same thing with > getUniformBlockIndex. Do make sure that anything that might query into > reflection about the program (e.g. getVertexAttributeIndex, > getUniformLocation, getUniformBlockIndex) happens after > COMPLETION_STATUS_KHR returns true, since that?s another way to > accidentally stall on compilation completing. > > > > > > *From:* owners-public_webgl...@ *On > Behalf Of *Kai Ninomiya (kainino...@) > > *Sent:* Friday, April 12, 2019 10:25 AM > > *To:* Public WebGL > > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > > > IIRC, all 3 of those functions still force a wait for the {shader to > finish compiling, program to finish linking} just as they did before. The > new semantics are only visible via the new COMPLETION_STATUS_KHR check. > > > > On Fri, Apr 12, 2019 at 10:05 AM Tarek Sherif (tsherif...@) < > public_webgl...@> wrote: > > Very excited about this extension, but I'm concerned about how it would > work in our use case. Our flagship visualization library, deck.gl > , > often shares the gl context with a separate base map rendering application > so that it can properly interleave visualization layers with the base map. > Enabling this extension seems to change the behaviour of existing WebGL > functions in a way that I don't believe other extensions do. My worry is > how our enabling KHR_parallel_shader_compile would affect applications we > share contexts with, i.e what happens if the typical synchronous > compilation logic is used after KHR_parallel_shader_compile is enabled? > Specifically: > > - What happens if getShaderParameter(shader, COMPILE_STATUS) is called > before compilation is complete? > - What happens if getProgramParameter(program, LINK_STATUS) is called > before linking is complete? > - What happens if useProgram is called before linking is complete? > > Thanks, > > > > > > Tarek Sherif > > Senior Software Engineer, Visualization | Uber > > http://vis.gl/ > > > > > > > > > > > *Tarek Sherif* > > Senior Software Engineer, Visualization | Uber > > http://vis.gl/ > > > > > > > On Fri, Apr 12, 2019 at 12:16 PM David Catuhe (David.Catuhe...@) > wrote: > > Wonderful! > > > > > > *From:* owners-public_webgl...@ *On > Behalf Of *Ken Russell (kbr...@) > > *Sent:* Wednesday, April 10, 2019 2:56 PM > > *To:* Public WebGL > > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > > > If your code works correctly now when enabling draft WebGL extensions in > Chrome, then no changes are needed. There won't be any changes to the > extension when it's taken out of draft status; it'll just be available by > default. > > > > -Ken > > > > > > On Wed, Apr 10, 2019 at 12:36 PM David Catuhe (David.Catuhe...@) > wrote: > > We do have support for the extension in Babylon.js. How can we test this > change? > ------------------------------ > > > > *From:* owners-public_webgl...@ > on behalf of Ken Russell (kbr...@) > *Sent:* Wednesday, April 10, 2019 12:00:25 PM > *To:* public > *Subject:* [Public WebGL] Propose promoting KHR_parallel_shader_compile > to community approved > > > > WebGL community, > > > > Jie Chen from Intel has principally developed and implemented a WebGL > wrapper for the KHR_parallel_shader_compile extension. This allows shader > compilation and program linking to occur fully in parallel to the rest of > the WebGL application. Some small application changes are needed to take > full advantage of the extension, but it is otherwise fully backward > compatible. Jie has even emulated this extension on platforms which don't > support it natively. > > > > This extension solves a longstanding user complaint with WebGL, namely > long shader compile times on Windows. Compiles and links occur not only > asynchronously, but also in parallel, so there is a net speedup when using > this extension. Users who have tried out the draft extension are pleased > with the results and would like to see it made widely available. > > > > I propose promoting this extension to community approved in > https://github.com/KhronosGroup/WebGL/pull/2855 > > . Any comments? > > > > -Ken > > > > > > > > > > [image: > https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png] > > > Virus-free. www.avg.com > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 82548 bytes Desc: not available URL: From pub...@ Fri May 10 10:50:20 2019 From: pub...@ (Takahiro Aoyagi (...@...)) Date: Sat, 11 May 2019 02:50:20 +0900 Subject: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved In-Reply-To: References: Message-ID: I made simple tests to check the CPU elapsed time of gl.getProgramParameter() and gl.useProgram() after checking COMPLETION_STATUS_KHR is true. Both are fast here on my Windows10 Chrome Canary. https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime6.html https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime7.html Takahiro Virus-free. www.avg.com <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Sat, May 11, 2019 at 2:46 AM Ken Russell (kbr...@) < public_webgl...@> wrote: > Hmm. The only reason I can think of that that would happen is if you're > running on Windows, and ANGLE has to dynamically recompile the program > behind the scenes in order to handle some OpenGL ES state change. I'm not > 100% sure which changes require this dynamic recompilation; the ANGLE > developers would know best. > https://groups.google.com//forum/#!forum/angleproject might be helpful. > > We'd really need some test case to make progress on this. Can you provide > one? > > -Ken > > > On Fri, May 10, 2019 at 10:28 AM Jasper St. Pierre (jstpierre...@) > wrote: > >> Hello again. My app is now showing that getProgramParameter is completing >> quick, but it is spending a lot of time in useProgram. I am checking for >> COMPLETION_STATUS_KHR on the GL program beforehand and it is returning >> true. I?m guessing there?s some additional expensive work that still needs >> to happen at useProgram time. Is this a bug? Any ways to debug or avoid >> this? I?m unsure if there will be an easy repro. >> >> >> >> Again, profiler screenshot attached. >> >> >> >> *From:* owners-public_webgl...@ >> *On Behalf Of *Takahiro Aoyagi (taoyagi...@) >> *Sent:* Friday, May 10, 2019 12:22 AM >> *To:* Public WebGL >> *Subject:* Re: [Public WebGL] Propose promoting >> KHR_parallel_shader_compile to community approved >> >> >> >> Confirmed COMPLETION_STATUS_KHR is very fast like 0.01ms on my test >> >> >> https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html >> >> >> >> Nice work! >> >> >> >> Thanks >> >> >> >> [image: >> https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png] >> >> >> Virus-free. www.avg.com >> >> >> >> >> On Wed, May 8, 2019 at 2:41 PM Ken Russell (kbr...@) < >> public_webgl...@> wrote: >> >> Jie Chen from Intel just landed a fix in Chrome dramatically improving >> the performance of querying COMPLETION_STATUS_KHR under >> http://crbug.com/881152 . The fix will be in tomorrow's Canary on >> Windows and macOS. >> >> >> >> This should address the last major gap with this extension. We would like >> to enable it by default by promoting it to community approved; any further >> comments? >> >> >> >> -Ken >> >> >> >> >> >> >> >> *From: *Ken Russell >> *Date: *Fri, Apr 26, 2019 at 3:40 PM >> *To: *Public WebGL >> >> Thanks for the report and the clear test case. There was an existing bug >> about this, so the new one was duplicated into it, and some hints about >> implementing it were added to the preexisting bug. >> >> >> >> >> >> On Fri, Apr 26, 2019 at 5:56 AM Takahiro Aoyagi (taoyagi...@) < >> public_webgl...@> wrote: >> >> Hi Chen, >> >> >> >> Opened a bug. Thanks. >> >> >> >> https://bugs.chromium.org/p/chromium/issues/detail?id=957001 >> >> >> >> Takahiro >> >> >> >> >> >> On Fri, Apr 26, 2019 at 8:03 PM Chen, Jie A (jie.a.chen...@) < >> public_webgl...@> wrote: >> >> Hi Takahiro, >> >> The current implementation of COMPLETION_STATUS_KHR query in >> chromium incurs an expensive round-trip to the GPU thread. This may >> contribute to the wait time in your case. I am trying to optimize this. >> Could you please file a bug to chromium? I would look into it once I?ve >> done the optimization. >> >> >> >> *From:* owners-public_webgl...@ [mailto: >> owners-public_webgl...@] *On Behalf Of *Takahiro Aoyagi ( >> taoyagi...@) >> *Sent:* Friday, April 26, 2019 6:20 PM >> *To:* Public WebGL >> *Subject:* Re: [Public WebGL] Propose promoting >> KHR_parallel_shader_compile to community approved >> >> >> >> Hi all, >> >> >> >> I'm working on Three.js + KHR_parallel_shader_compile extension support >> with Fernando. >> >> >> >> https://github.com/mrdoob/three.js/issues/16321#issuecomment-486436086 >> >> >> >> I'm testing with Canary. But the behavior seems weird to me. >> gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) seems to wait >> for compile+link completion. I don't think it should wait for that, it >> should just do polling and returning true/false quickly instead. >> >> >> >> I made a simple test to reproduce. >> >> >> >> >> https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html >> >> >> >> Code snippet. >> >> >> >> const ext = gl.getExtension('KHR_parallel_shader_compile'); >> >> >> >> gl.compileShader(vertexShader); >> gl.compileShader(fragmentShader); >> gl.attachShader(program, vertexShader); >> gl.attachShader(program, fragmentShader); >> gl.linkProgram(program); >> >> const startTime = performance.now(); >> const status = useExtension >> ? gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) >> : gl.getProgramParameter(program, gl.LINK_STATUS); >> const endTime = performance.now(); >> >> const elapsedTime = endTime - startTime; >> >> >> >> On my platform, both gl.LINK_STATUS and ext.COMPLETION_STATUS_KHR take so >> long time about 15ms. I can accept this number for gl.LINK_STATUS because >> it waits for compile+link completion. But 15ms for >> ext.COMPLETION_STATUS_KHR looks weird to me. It shouldn't wait for the >> compile+link completion but should do just polling and quickly returning >> true/false instead. So I guess the number should be 1ms or less. >> >> >> >> Let me know if I'm missing something. Or could it be a Canary bug? >> >> >> >> My platform. >> >> >> >> OS: Windows10 >> >> Browser: Chrome Canary. >> >> Browser boot option: --use-cmd-decoder=passthrough >> --enable-webgl-draft-extensions >> >> >> >> >> >> Thanks >> >> >> >> Takahiro >> >> >> >> >> >> On Fri, Apr 26, 2019 at 10:15 AM Chen, Jie A (jie.a.chen...@) < >> public_webgl...@> wrote: >> >> Basically, for ANGLE?s GL backend, it?s simply a wrapper for the existing >> GL implementations. In this sense glCompileShader() is still implementation >> specific. Essentially ANGLE just calls glCompileShader and check >> GL_COMPILE_STATUS. >> >> >> >> *From:* owners-public_webgl...@ [mailto: >> owners-public_webgl...@] *On Behalf Of *Jasper St. Pierre ( >> jstpierre...@) >> *Sent:* Friday, April 26, 2019 1:18 AM >> *To:* Public WebGL >> *Subject:* RE: [Public WebGL] Propose promoting >> KHR_parallel_shader_compile to community approved >> >> >> >> Thank you, that?s important information to know. Changing my shader >> compilation pipeline to wait for shader completion status is a lot more >> difficult, but based on some initial tests, it?s more expensive than not >> doing it ? the latency of getShaderParameter is too high. >> >> >> >> That said, in a lot of GL implementations, glCompileShader() is >> practically a no-op, and will only do an AST parse when >> glGetShaderParameter/InfoLog() is called (which is basically only for >> debugging / error checking). glLinkProgram() does full compilation of all >> programs, as full-PSO optimization is important. I don?t know how common >> this is, but multiple GL implementations I have seen do it. It might make >> sense for ANGLE to adopt this model as well. >> >> >> >> *From:* owners-public_webgl...@ >> *On Behalf Of *Chen, Jie A (jie.a.chen...@) >> *Sent:* Wednesday, April 24, 2019 6:48 PM >> *To:* Public WebGL >> *Subject:* RE: [Public WebGL] Propose promoting >> KHR_parallel_shader_compile to community approved >> >> >> >> Absolutely. Ideally there would be no stall for linkProgram. I tried, but >> it?s too difficult to achieve this in ANGLE. >> >> >> >> *From:* owners-public_webgl...@ [ >> mailto:owners-public_webgl...@ ] >> *On Behalf Of *Jeff Gilbert (jgilbert...@) >> *Sent:* Thursday, April 25, 2019 9:33 AM >> *To:* Public WebGL >> *Subject:* Re: [Public WebGL] Propose promoting >> KHR_parallel_shader_compile to community approved >> >> >> >> Possibly, but in the long run, I expect implementations to support >> no-stall linkProgram invocations. >> >> >> >> On Wed, Apr 24, 2019 at 6:27 PM Chen, Jie A (jie.a.chen...@) < >> public_webgl...@> wrote: >> >> linkProgram may stall on compileShader. To avoid the stall, you?d better >> make sure the COMPLETION_STATUS_KHR statuses of the attached shaders are >> all True before calling linkProgram. In this sense, the first workflow has >> less chance running into stall. >> >> >> >> *From:* owners-public_webgl...@ [mailto: >> owners-public_webgl...@] *On Behalf Of *Fernando Serrano Garc?a ( >> fserrano...@) >> *Sent:* Wednesday, April 24, 2019 9:38 PM >> *To:* Public WebGL >> *Subject:* Re: [Public WebGL] Propose promoting >> KHR_parallel_shader_compile to community approved >> >> >> >> Regarding the optimal proposed workflow (grouping shaders and programs >> separately) of: >> >> for (const x of shaders) >> gl.compileShader(x); >> for (const x of programs) >> gl.linkProgram(x); >> >> >> >> versus something more on the way that we currently have in many engines >> as threejs: >> >> for (const x of material) >> >> gl.compileShader(fs); >> >> gl.compileShader(vs); >> gl.linkProgram(x); >> >> >> >> Do you think is more or less accurate the following graph for 4 materials >> and enabling this extension with 2 and 4 parallel threads? >> >> >> >> [image: Screen Shot 2019-04-24 at 15.35.47.png] >> >> >> >> On Wed, Apr 24, 2019 at 2:40 PM Fernando Serrano Garc?a < >> fserrano...@> wrote: >> >> fwiw three.js introduced a "debug" parameter (false by default) to >> determine if there will be a status check and call all the get* (currently >> in dev): >> >> - >> https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLShader.js#L21-L26 >> >> - >> https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLProgram.js#L608 >> >> >> >> so currently calling `new WebGLShader()` won't be blocking with any >> `get*` function and it could be used as is to compile all of them in a loop >> with or without the extension. >> >> the problem comes from the WebGLProgram as it should just queue itself >> before trying to link any program and wait until all the shader compile >> calls finish, then do all the link, and wait for it asynchronously before >> start using these programs. >> >> I have opened an issue on the three.js repo to keep track of the >> implementation and we have booked some time this week to take a look at it, >> feedback is welcome :) https://github.com/mrdoob/three.js/issues/16321 >> >> >> >> On Tue, Apr 16, 2019 at 11:55 PM Ken Russell (kbr...@) < >> public_webgl...@> wrote: >> >> On Tue, Apr 16, 2019 at 2:24 PM Tarek Sherif (tsherif...@) < >> public_webgl...@> wrote: >> >> Yes, I've read both specs. I think this language in the WebGL version is >> confusing: "When this extension is enabled: Shader compilation and program >> linking may be performed in a separate CPU thread." And neither indicates >> which functions are expected to cause stalls. As written, this extension >> requires more than most that people know implementation details. >> >> >> >> All previous operations against the program - looking up uniform >> locations, drawing with it, etc. - will cause stalls. The application >> *must* be updated to query the program's COMPLETION_STATUS_KHR status, and >> skip *all* operations against the program until it's no longer pending. >> >> >> >> I guess we'll just change the WebGL version of this extension spec to be >> much more explicit about this. >> >> >> >> >> >> Essentially, all previous code which checked for the completion of >> compilation of shaders / linking of programs can be updated with a small >> wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. >> >> >> >> This is not true because the most common way this is done will cause >> stalls that sabotage the parallelism, e.g.: >> >> https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLShader.js#L21-L36 >> >> >> https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLProgram.js#L586-L631 >> >> >> >> The check for COMPLETION_STATUS_KHR has to wrap *all* queries and uses of >> the program object, and they must be skipped until COMPLETION_STATUS_KHR >> returns true. Yes, all applications will have to be updated to take >> advantage of this extension, but if they do, the benefits will be >> significant. >> >> >> >> -Ken >> >> >> >> >> >> *Tarek Sherif* >> >> Senior Software Engineer, Visualization | Uber >> >> http://vis.gl/ >> >> >> >> >> >> >> >> On Tue, Apr 16, 2019 at 4:18 PM Ken Russell (kbr...@) < >> public_webgl...@> wrote: >> >> Please review the Overview in the underlying OpenGL ES spec: >> >> >> https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt >> >> >> >> >> It describes that the extension uses one or more separate CPU threads for >> shader compilation. If you still think we should rewrite the introduction >> to the WebGL extension, we can do that too. >> >> >> >> Essentially, all previous code which checked for the completion of >> compilation of shaders / linking of programs can be updated with a small >> wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. >> >> >> >> -Ken >> >> >> >> >> >> >> >> On Tue, Apr 16, 2019 at 1:36 AM Tarek Sherif (tsherif...@) < >> public_webgl...@> wrote: >> >> This is all extremely interesting, and documentation of these best >> practices should probably be more publicly available (perhaps through a >> non-normative note in the spec). I'm thinking the language in the extension >> spec could be made more clear about what it's actual purpose is. It >> currently gives the impression that enabling it is what allows for parallel >> compilation and that this should save time, but given what Jeff and Kai >> have said, it sounds like the purpose is to avoid CPU stalls, and that it >> might even take longer in wall time since you're only checking once a >> frame. Maybe some background information could be added along the lines of >> "Normally applications must wait on get*Parameter or a draw call for >> program linking to complete, this extension provides a mechanism for >> querying completion status without stalling..." >> >> >> >> *Tarek Sherif* >> >> Senior Software Engineer, Visualization | Uber >> >> http://vis.gl/ >> >> >> >> >> >> >> >> >> On Mon, Apr 15, 2019 at 11:23 PM Kai Ninomiya (kainino...@) < >> public_webgl...@> wrote: >> >> >> >> >> >> On Mon, Apr 15, 2019 at 7:18 PM Tarek Sherif (tareksherif...@) < >> public_webgl...@> wrote: >> >> I don't see anything in the OpenGL extension spec about what functions >> cause stalls. Is that implementation-specific? Having an idea what to >> expect is important for two reasons: >> >> 1. To make it clear that drawing will still work if >> getProgramParameter(COMPLETION_STATUS_KHR) hasn't returned true yet >> (i.e. the stall on a draw call) >> >> >> >> Generally, OpenGL extensions are not allowed to break existing >> API/existing content. (In OpenGL, all extensions are always enabled; >> there's no requestExtension.) Hence, even if you enable the extension, it >> won't change the way your application works, and therefore the draw call >> must still cause a stall in order to be able to use the program. >> >> >> >> 2. Almost all WebGL code I've looked at handles compilation in a way >> similar to the following: >> >> gl.compileShader(vertexShader); >> if (!gl.getShaderParameter(vertexShader, gl.COMPILE_STATUS)) //... >> >> gl.compileShader(fragmentShader); >> >> if (!gl.getShaderParameter(fragmentShader, gl.COMPILE_STATUS)) //... >> >> //... >> >> gl.linkProgram(program); >> if (!gl.getProgramParameter(program, gl.LINK_STATUS)) //... >> >> I think it would be worth it to make clear that this pattern would >> sabotage the parallel compile. >> >> >> >> I seem to remember (not sure if this is still true) that this pattern >> also sabotages the shader compiler cache in ANGLE, because ANGLE doesn't >> cache the COMPILE_STATUS (or was it the compile info string?). So it forces >> the compiler to recompile just to give you the status. >> >> >> >> Tarek Sherif >> >> http://tareksherif.net/ >> >> >> >> >> >> >> >> >> ??????? Original Message ??????? >> >> On Monday, April 15, 2019 9:00 PM, Ken Russell (kbr...@) < >> public_webgl...@> wrote: >> >> >> >> The WebGL extension (which is basically just a wrapper) refers to the >> underlying OpenGL / OpenGL ES extension >> https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt >> , >> where this is documented. Is that sufficient? It would be better to avoid >> duplicating a large amount of spec text from the underlying extension. >> However, we can add some non-normative text if that would help. >> >> >> >> -Ken >> >> >> >> >> >> >> >> On Sat, Apr 13, 2019 at 3:51 AM Tarek Sherif (tareksherif...@) < >> public_webgl...@> wrote: >> >> IIRC, all 3 of those functions still force a wait for the {shader to >> finish compiling, program to finish linking} just as they did before. The >> new semantics are only visible via the new COMPLETION_STATUS_KHR check. >> >> That should work perfectly for us. Can we add some language to the spec >> about which functions cause stalls? I feel like as written, it will be easy >> for people to use the extension incorrectly. >> >> >> >> Tarek Sherif >> >> http://tareksherif.net/ >> >> >> >> >> >> >> >> >> ??????? Original Message ??????? >> >> On Friday, April 12, 2019 4:10 PM, Kai Ninomiya (kainino...@) < >> public_webgl...@> wrote: >> >> >> >> Oh yes, useProgram probably won't stall. But getUniformLocation and the >> others will stall, as will draw calls. >> >> >> >> getProgramParameter(COMPLETION_STATUS_KHR) should get faster at some >> point; see http://crbug.com/881152 >> which >> Ken linked. >> >> >> >> On Fri, Apr 12, 2019 at 12:39 PM Jasper St. Pierre (jstpierre...@) >> wrote: >> >> Thank you! Trying this out in my own WebGL 2 app, I see quite a reduction >> in shader compilation time, shaving 400ms on load time on a moderately >> complex scene. The getProgramParameter(COMPLETION_STATUS_KHR) query still >> takes 1ms (which I believe is being tracked), but that is still better from >> the 4ms I see in getUniformBlockIndex (my previous sync point). >> >> >> >> AFAIK, useProgram should not cause a stall, but in order to set my >> texture samplers to bind to different units, I need to do a >> getUniformLocation on my sampler uniform, which causes a compilation stall. >> Same thing with getUniformBlockIndex. Do make sure that anything that might >> query into reflection about the program (e.g. getVertexAttributeIndex, >> getUniformLocation, getUniformBlockIndex) happens after >> COMPLETION_STATUS_KHR returns true, since that?s another way to >> accidentally stall on compilation completing. >> >> >> >> >> >> *From:* owners-public_webgl...@ >> *On Behalf Of *Kai Ninomiya (kainino...@) >> >> *Sent:* Friday, April 12, 2019 10:25 AM >> >> *To:* Public WebGL >> >> *Subject:* Re: [Public WebGL] Propose promoting >> KHR_parallel_shader_compile to community approved >> >> >> >> >> >> IIRC, all 3 of those functions still force a wait for the {shader to >> finish compiling, program to finish linking} just as they did before. The >> new semantics are only visible via the new COMPLETION_STATUS_KHR check. >> >> >> >> On Fri, Apr 12, 2019 at 10:05 AM Tarek Sherif (tsherif...@) < >> public_webgl...@> wrote: >> >> Very excited about this extension, but I'm concerned about how it would >> work in our use case. Our flagship visualization library, deck.gl >> , >> often shares the gl context with a separate base map rendering application >> so that it can properly interleave visualization layers with the base map. >> Enabling this extension seems to change the behaviour of existing WebGL >> functions in a way that I don't believe other extensions do. My worry is >> how our enabling KHR_parallel_shader_compile would affect applications we >> share contexts with, i.e what happens if the typical synchronous >> compilation logic is used after KHR_parallel_shader_compile is enabled? >> Specifically: >> >> - What happens if getShaderParameter(shader, COMPILE_STATUS) is >> called before compilation is complete? >> - What happens if getProgramParameter(program, LINK_STATUS) is called >> before linking is complete? >> - What happens if useProgram is called before linking is complete? >> >> Thanks, >> >> >> >> >> >> Tarek Sherif >> >> Senior Software Engineer, Visualization | Uber >> >> http://vis.gl/ >> >> >> >> >> >> >> >> >> >> >> *Tarek Sherif* >> >> Senior Software Engineer, Visualization | Uber >> >> http://vis.gl/ >> >> >> >> >> >> >> On Fri, Apr 12, 2019 at 12:16 PM David Catuhe (David.Catuhe...@) >> wrote: >> >> Wonderful! >> >> >> >> >> >> *From:* owners-public_webgl...@ >> *On Behalf Of *Ken Russell (kbr...@) >> >> *Sent:* Wednesday, April 10, 2019 2:56 PM >> >> *To:* Public WebGL >> >> *Subject:* Re: [Public WebGL] Propose promoting >> KHR_parallel_shader_compile to community approved >> >> >> >> >> >> If your code works correctly now when enabling draft WebGL extensions in >> Chrome, then no changes are needed. There won't be any changes to the >> extension when it's taken out of draft status; it'll just be available by >> default. >> >> >> >> -Ken >> >> >> >> >> >> On Wed, Apr 10, 2019 at 12:36 PM David Catuhe (David.Catuhe...@) >> wrote: >> >> We do have support for the extension in Babylon.js. How can we test this >> change? >> ------------------------------ >> >> >> >> *From:* owners-public_webgl...@ >> on behalf of Ken Russell (kbr...@) >> *Sent:* Wednesday, April 10, 2019 12:00:25 PM >> *To:* public >> *Subject:* [Public WebGL] Propose promoting KHR_parallel_shader_compile >> to community approved >> >> >> >> WebGL community, >> >> >> >> Jie Chen from Intel has principally developed and implemented a WebGL >> wrapper for the KHR_parallel_shader_compile extension. This allows shader >> compilation and program linking to occur fully in parallel to the rest of >> the WebGL application. Some small application changes are needed to take >> full advantage of the extension, but it is otherwise fully backward >> compatible. Jie has even emulated this extension on platforms which don't >> support it natively. >> >> >> >> This extension solves a longstanding user complaint with WebGL, namely >> long shader compile times on Windows. Compiles and links occur not only >> asynchronously, but also in parallel, so there is a net speedup when using >> this extension. Users who have tried out the draft extension are pleased >> with the results and would like to see it made widely available. >> >> >> >> I propose promoting this extension to community approved in >> https://github.com/KhronosGroup/WebGL/pull/2855 >> >> . Any comments? >> >> >> >> -Ken >> >> >> >> >> >> >> >> >> >> [image: >> https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png] >> >> >> Virus-free. www.avg.com >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 82548 bytes Desc: not available URL: From pub...@ Fri May 10 10:56:36 2019 From: pub...@ (Jasper St. Pierre (...@...)) Date: Fri, 10 May 2019 17:56:36 +0000 Subject: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved In-Reply-To: References: Message-ID: I can give you a manual test case in my app, but not an automatic one. 1. Navigate to https://noclip.website/#mkwii/beginner_course 2. Wait for the full scene to load. 3. On the left, the button under the file picker should be labeled ?Render Hacks?. Open that panel and toggle Enable Vertex Colors or Enable Textures. This causes all the shaders in the scene to recompile. 4. There should be a bit of CPU time spent that, when analyzed in the Profiler, is useProgram-related. I should not be using any GLES states that would necessitate a dynamic shader recompile, but if I am, is there a way to get a debug callback or log message when this happens? I will try to ask the ANGLE mailing list later today. Thank you. From: owners-public_webgl...@ On Behalf Of Ken Russell (kbr...@) Sent: Friday, May 10, 2019 10:45 AM To: Public WebGL Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Hmm. The only reason I can think of that that would happen is if you're running on Windows, and ANGLE has to dynamically recompile the program behind the scenes in order to handle some OpenGL ES state change. I'm not 100% sure which changes require this dynamic recompilation; the ANGLE developers would know best. https://groups.google.com//forum/#!forum/angleproject might be helpful. We'd really need some test case to make progress on this. Can you provide one? -Ken On Fri, May 10, 2019 at 10:28 AM Jasper St. Pierre (jstpierre...@) > wrote: Hello again. My app is now showing that getProgramParameter is completing quick, but it is spending a lot of time in useProgram. I am checking for COMPLETION_STATUS_KHR on the GL program beforehand and it is returning true. I?m guessing there?s some additional expensive work that still needs to happen at useProgram time. Is this a bug? Any ways to debug or avoid this? I?m unsure if there will be an easy repro. Again, profiler screenshot attached. From: owners-public_webgl...@ > On Behalf Of Takahiro Aoyagi (taoyagi...@) Sent: Friday, May 10, 2019 12:22 AM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Confirmed COMPLETION_STATUS_KHR is very fast like 0.01ms on my test https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html Nice work! Thanks [https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png] Virus-free. www.avg.com On Wed, May 8, 2019 at 2:41 PM Ken Russell (kbr...@) > wrote: Jie Chen from Intel just landed a fix in Chrome dramatically improving the performance of querying COMPLETION_STATUS_KHR under http://crbug.com/881152 . The fix will be in tomorrow's Canary on Windows and macOS. This should address the last major gap with this extension. We would like to enable it by default by promoting it to community approved; any further comments? -Ken From: Ken Russell > Date: Fri, Apr 26, 2019 at 3:40 PM To: Public WebGL Thanks for the report and the clear test case. There was an existing bug about this, so the new one was duplicated into it, and some hints about implementing it were added to the preexisting bug. On Fri, Apr 26, 2019 at 5:56 AM Takahiro Aoyagi (taoyagi...@) > wrote: Hi Chen, Opened a bug. Thanks. https://bugs.chromium.org/p/chromium/issues/detail?id=957001 Takahiro On Fri, Apr 26, 2019 at 8:03 PM Chen, Jie A (jie.a.chen...@) > wrote: Hi Takahiro, The current implementation of COMPLETION_STATUS_KHR query in chromium incurs an expensive round-trip to the GPU thread. This may contribute to the wait time in your case. I am trying to optimize this. Could you please file a bug to chromium? I would look into it once I?ve done the optimization. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Takahiro Aoyagi (taoyagi...@) Sent: Friday, April 26, 2019 6:20 PM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Hi all, I'm working on Three.js + KHR_parallel_shader_compile extension support with Fernando. https://github.com/mrdoob/three.js/issues/16321#issuecomment-486436086 I'm testing with Canary. But the behavior seems weird to me. gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) seems to wait for compile+link completion. I don't think it should wait for that, it should just do polling and returning true/false quickly instead. I made a simple test to reproduce. https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html Code snippet. const ext = gl.getExtension('KHR_parallel_shader_compile'); gl.compileShader(vertexShader); gl.compileShader(fragmentShader); gl.attachShader(program, vertexShader); gl.attachShader(program, fragmentShader); gl.linkProgram(program); const startTime = performance.now(); const status = useExtension ? gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) : gl.getProgramParameter(program, gl.LINK_STATUS); const endTime = performance.now(); const elapsedTime = endTime - startTime; On my platform, both gl.LINK_STATUS and ext.COMPLETION_STATUS_KHR take so long time about 15ms. I can accept this number for gl.LINK_STATUS because it waits for compile+link completion. But 15ms for ext.COMPLETION_STATUS_KHR looks weird to me. It shouldn't wait for the compile+link completion but should do just polling and quickly returning true/false instead. So I guess the number should be 1ms or less. Let me know if I'm missing something. Or could it be a Canary bug? My platform. OS: Windows10 Browser: Chrome Canary. Browser boot option: --use-cmd-decoder=passthrough --enable-webgl-draft-extensions Thanks Takahiro On Fri, Apr 26, 2019 at 10:15 AM Chen, Jie A (jie.a.chen...@) > wrote: Basically, for ANGLE?s GL backend, it?s simply a wrapper for the existing GL implementations. In this sense glCompileShader() is still implementation specific. Essentially ANGLE just calls glCompileShader and check GL_COMPILE_STATUS. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Jasper St. Pierre (jstpierre...@) Sent: Friday, April 26, 2019 1:18 AM To: Public WebGL > Subject: RE: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Thank you, that?s important information to know. Changing my shader compilation pipeline to wait for shader completion status is a lot more difficult, but based on some initial tests, it?s more expensive than not doing it ? the latency of getShaderParameter is too high. That said, in a lot of GL implementations, glCompileShader() is practically a no-op, and will only do an AST parse when glGetShaderParameter/InfoLog() is called (which is basically only for debugging / error checking). glLinkProgram() does full compilation of all programs, as full-PSO optimization is important. I don?t know how common this is, but multiple GL implementations I have seen do it. It might make sense for ANGLE to adopt this model as well. From: owners-public_webgl...@ > On Behalf Of Chen, Jie A (jie.a.chen...@) Sent: Wednesday, April 24, 2019 6:48 PM To: Public WebGL > Subject: RE: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Absolutely. Ideally there would be no stall for linkProgram. I tried, but it?s too difficult to achieve this in ANGLE. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Jeff Gilbert (jgilbert...@) Sent: Thursday, April 25, 2019 9:33 AM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Possibly, but in the long run, I expect implementations to support no-stall linkProgram invocations. On Wed, Apr 24, 2019 at 6:27 PM Chen, Jie A (jie.a.chen...@) > wrote: linkProgram may stall on compileShader. To avoid the stall, you?d better make sure the COMPLETION_STATUS_KHR statuses of the attached shaders are all True before calling linkProgram. In this sense, the first workflow has less chance running into stall. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Fernando Serrano Garc?a (fserrano...@) Sent: Wednesday, April 24, 2019 9:38 PM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Regarding the optimal proposed workflow (grouping shaders and programs separately) of: for (const x of shaders) gl.compileShader(x); for (const x of programs) gl.linkProgram(x); versus something more on the way that we currently have in many engines as threejs: for (const x of material) gl.compileShader(fs); gl.compileShader(vs); gl.linkProgram(x); Do you think is more or less accurate the following graph for 4 materials and enabling this extension with 2 and 4 parallel threads? [Screen Shot 2019-04-24 at 15.35.47.png] On Wed, Apr 24, 2019 at 2:40 PM Fernando Serrano Garc?a > wrote: fwiw three.js introduced a "debug" parameter (false by default) to determine if there will be a status check and call all the get* (currently in dev): - https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLShader.js#L21-L26 - https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLProgram.js#L608 so currently calling `new WebGLShader()` won't be blocking with any `get*` function and it could be used as is to compile all of them in a loop with or without the extension. the problem comes from the WebGLProgram as it should just queue itself before trying to link any program and wait until all the shader compile calls finish, then do all the link, and wait for it asynchronously before start using these programs. I have opened an issue on the three.js repo to keep track of the implementation and we have booked some time this week to take a look at it, feedback is welcome :) https://github.com/mrdoob/three.js/issues/16321 On Tue, Apr 16, 2019 at 11:55 PM Ken Russell (kbr...@) > wrote: On Tue, Apr 16, 2019 at 2:24 PM Tarek Sherif (tsherif...@) > wrote: Yes, I've read both specs. I think this language in the WebGL version is confusing: "When this extension is enabled: Shader compilation and program linking may be performed in a separate CPU thread." And neither indicates which functions are expected to cause stalls. As written, this extension requires more than most that people know implementation details. All previous operations against the program - looking up uniform locations, drawing with it, etc. - will cause stalls. The application *must* be updated to query the program's COMPLETION_STATUS_KHR status, and skip *all* operations against the program until it's no longer pending. I guess we'll just change the WebGL version of this extension spec to be much more explicit about this. Essentially, all previous code which checked for the completion of compilation of shaders / linking of programs can be updated with a small wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. This is not true because the most common way this is done will cause stalls that sabotage the parallelism, e.g.: https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLShader.js#L21-L36 https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLProgram.js#L586-L631 The check for COMPLETION_STATUS_KHR has to wrap *all* queries and uses of the program object, and they must be skipped until COMPLETION_STATUS_KHR returns true. Yes, all applications will have to be updated to take advantage of this extension, but if they do, the benefits will be significant. -Ken Tarek Sherif Senior Software Engineer, Visualization | Uber http://vis.gl/ On Tue, Apr 16, 2019 at 4:18 PM Ken Russell (kbr...@) > wrote: Please review the Overview in the underlying OpenGL ES spec: https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt It describes that the extension uses one or more separate CPU threads for shader compilation. If you still think we should rewrite the introduction to the WebGL extension, we can do that too. Essentially, all previous code which checked for the completion of compilation of shaders / linking of programs can be updated with a small wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. -Ken On Tue, Apr 16, 2019 at 1:36 AM Tarek Sherif (tsherif...@) > wrote: This is all extremely interesting, and documentation of these best practices should probably be more publicly available (perhaps through a non-normative note in the spec). I'm thinking the language in the extension spec could be made more clear about what it's actual purpose is. It currently gives the impression that enabling it is what allows for parallel compilation and that this should save time, but given what Jeff and Kai have said, it sounds like the purpose is to avoid CPU stalls, and that it might even take longer in wall time since you're only checking once a frame. Maybe some background information could be added along the lines of "Normally applications must wait on get*Parameter or a draw call for program linking to complete, this extension provides a mechanism for querying completion status without stalling..." Tarek Sherif Senior Software Engineer, Visualization | Uber http://vis.gl/ On Mon, Apr 15, 2019 at 11:23 PM Kai Ninomiya (kainino...@) > wrote: On Mon, Apr 15, 2019 at 7:18 PM Tarek Sherif (tareksherif...@) > wrote: I don't see anything in the OpenGL extension spec about what functions cause stalls. Is that implementation-specific? Having an idea what to expect is important for two reasons: 1. To make it clear that drawing will still work if getProgramParameter(COMPLETION_STATUS_KHR) hasn't returned true yet (i.e. the stall on a draw call) Generally, OpenGL extensions are not allowed to break existing API/existing content. (In OpenGL, all extensions are always enabled; there's no requestExtension.) Hence, even if you enable the extension, it won't change the way your application works, and therefore the draw call must still cause a stall in order to be able to use the program. 2. Almost all WebGL code I've looked at handles compilation in a way similar to the following: gl.compileShader(vertexShader); if (!gl.getShaderParameter(vertexShader, gl.COMPILE_STATUS)) //... gl.compileShader(fragmentShader); if (!gl.getShaderParameter(fragmentShader, gl.COMPILE_STATUS)) //... //... gl.linkProgram(program); if (!gl.getProgramParameter(program, gl.LINK_STATUS)) //... I think it would be worth it to make clear that this pattern would sabotage the parallel compile. I seem to remember (not sure if this is still true) that this pattern also sabotages the shader compiler cache in ANGLE, because ANGLE doesn't cache the COMPILE_STATUS (or was it the compile info string?). So it forces the compiler to recompile just to give you the status. Tarek Sherif http://tareksherif.net/ ??????? Original Message ??????? On Monday, April 15, 2019 9:00 PM, Ken Russell (kbr...@) > wrote: The WebGL extension (which is basically just a wrapper) refers to the underlying OpenGL / OpenGL ES extension https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt, where this is documented. Is that sufficient? It would be better to avoid duplicating a large amount of spec text from the underlying extension. However, we can add some non-normative text if that would help. -Ken On Sat, Apr 13, 2019 at 3:51 AM Tarek Sherif (tareksherif...@) > wrote: IIRC, all 3 of those functions still force a wait for the {shader to finish compiling, program to finish linking} just as they did before. The new semantics are only visible via the new COMPLETION_STATUS_KHR check. That should work perfectly for us. Can we add some language to the spec about which functions cause stalls? I feel like as written, it will be easy for people to use the extension incorrectly. Tarek Sherif http://tareksherif.net/ ??????? Original Message ??????? On Friday, April 12, 2019 4:10 PM, Kai Ninomiya (kainino...@) > wrote: Oh yes, useProgram probably won't stall. But getUniformLocation and the others will stall, as will draw calls. getProgramParameter(COMPLETION_STATUS_KHR) should get faster at some point; see http://crbug.com/881152 which Ken linked. On Fri, Apr 12, 2019 at 12:39 PM Jasper St. Pierre (jstpierre...@) > wrote: Thank you! Trying this out in my own WebGL 2 app, I see quite a reduction in shader compilation time, shaving 400ms on load time on a moderately complex scene. The getProgramParameter(COMPLETION_STATUS_KHR) query still takes 1ms (which I believe is being tracked), but that is still better from the 4ms I see in getUniformBlockIndex (my previous sync point). AFAIK, useProgram should not cause a stall, but in order to set my texture samplers to bind to different units, I need to do a getUniformLocation on my sampler uniform, which causes a compilation stall. Same thing with getUniformBlockIndex. Do make sure that anything that might query into reflection about the program (e.g. getVertexAttributeIndex, getUniformLocation, getUniformBlockIndex) happens after COMPLETION_STATUS_KHR returns true, since that?s another way to accidentally stall on compilation completing. From: owners-public_webgl...@ > On Behalf Of Kai Ninomiya (kainino...@) Sent: Friday, April 12, 2019 10:25 AM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved IIRC, all 3 of those functions still force a wait for the {shader to finish compiling, program to finish linking} just as they did before. The new semantics are only visible via the new COMPLETION_STATUS_KHR check. On Fri, Apr 12, 2019 at 10:05 AM Tarek Sherif (tsherif...@) > wrote: Very excited about this extension, but I'm concerned about how it would work in our use case. Our flagship visualization library, deck.gl, often shares the gl context with a separate base map rendering application so that it can properly interleave visualization layers with the base map. Enabling this extension seems to change the behaviour of existing WebGL functions in a way that I don't believe other extensions do. My worry is how our enabling KHR_parallel_shader_compile would affect applications we share contexts with, i.e what happens if the typical synchronous compilation logic is used after KHR_parallel_shader_compile is enabled? Specifically: * What happens if getShaderParameter(shader, COMPILE_STATUS) is called before compilation is complete? * What happens if getProgramParameter(program, LINK_STATUS) is called before linking is complete? * What happens if useProgram is called before linking is complete? Thanks, Tarek Sherif Senior Software Engineer, Visualization | Uber http://vis.gl/ Tarek Sherif Senior Software Engineer, Visualization | Uber http://vis.gl/ On Fri, Apr 12, 2019 at 12:16 PM David Catuhe (David.Catuhe...@) > wrote: Wonderful! From: owners-public_webgl...@ > On Behalf Of Ken Russell (kbr...@) Sent: Wednesday, April 10, 2019 2:56 PM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved If your code works correctly now when enabling draft WebGL extensions in Chrome, then no changes are needed. There won't be any changes to the extension when it's taken out of draft status; it'll just be available by default. -Ken On Wed, Apr 10, 2019 at 12:36 PM David Catuhe (David.Catuhe...@) > wrote: We do have support for the extension in Babylon.js. How can we test this change? ________________________________ From: owners-public_webgl...@ > on behalf of Ken Russell (kbr...@) > Sent: Wednesday, April 10, 2019 12:00:25 PM To: public Subject: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved WebGL community, Jie Chen from Intel has principally developed and implemented a WebGL wrapper for the KHR_parallel_shader_compile extension. This allows shader compilation and program linking to occur fully in parallel to the rest of the WebGL application. Some small application changes are needed to take full advantage of the extension, but it is otherwise fully backward compatible. Jie has even emulated this extension on platforms which don't support it natively. This extension solves a longstanding user complaint with WebGL, namely long shader compile times on Windows. Compiles and links occur not only asynchronously, but also in parallel, so there is a net speedup when using this extension. Users who have tried out the draft extension are pleased with the results and would like to see it made widely available. I propose promoting this extension to community approved in https://github.com/KhronosGroup/WebGL/pull/2855 . Any comments? -Ken [https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png] Virus-free. www.avg.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 82548 bytes Desc: image001.png URL: From pub...@ Fri May 10 13:39:39 2019 From: pub...@ (Ken Russell (...@...)) Date: Fri, 10 May 2019 13:39:39 -0700 Subject: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved In-Reply-To: References: Message-ID: Thanks for posting to the ANGLE alias. Let's continue this discussion there, as I strongly suspect this particular problem is caused by dynamic shader recompilation. *From: *Jasper St. Pierre (jstpierre...@) *Date: *Fri, May 10, 2019 at 10:57 AM *To: *Public WebGL I can give you a manual test case in my app, but not an automatic one. > > > > 1. Navigate to https://noclip.website/#mkwii/beginner_course > 2. Wait for the full scene to load. > 3. On the left, the button under the file picker should be labeled > ?Render Hacks?. Open that panel and toggle Enable Vertex Colors or Enable > Textures. This causes all the shaders in the scene to recompile. > 4. There should be a bit of CPU time spent that, when analyzed in the > Profiler, is useProgram-related. I should not be using any GLES states that > would necessitate a dynamic shader recompile, but if I am, is there a way > to get a debug callback or log message when this happens? > > > > I will try to ask the ANGLE mailing list later today. Thank you. > > > > *From:* owners-public_webgl...@ *On > Behalf Of *Ken Russell (kbr...@) > *Sent:* Friday, May 10, 2019 10:45 AM > *To:* Public WebGL > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Hmm. The only reason I can think of that that would happen is if you're > running on Windows, and ANGLE has to dynamically recompile the program > behind the scenes in order to handle some OpenGL ES state change. I'm not > 100% sure which changes require this dynamic recompilation; the ANGLE > developers would know best. > https://groups.google.com//forum/#!forum/angleproject > might be helpful. > > > > We'd really need some test case to make progress on this. Can you provide > one? > > > > -Ken > > > > > > On Fri, May 10, 2019 at 10:28 AM Jasper St. Pierre (jstpierre...@) > wrote: > > Hello again. My app is now showing that getProgramParameter is completing > quick, but it is spending a lot of time in useProgram. I am checking for > COMPLETION_STATUS_KHR on the GL program beforehand and it is returning > true. I?m guessing there?s some additional expensive work that still needs > to happen at useProgram time. Is this a bug? Any ways to debug or avoid > this? I?m unsure if there will be an easy repro. > > > > Again, profiler screenshot attached. > > > > *From:* owners-public_webgl...@ *On > Behalf Of *Takahiro Aoyagi (taoyagi...@) > *Sent:* Friday, May 10, 2019 12:22 AM > *To:* Public WebGL > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Confirmed COMPLETION_STATUS_KHR is very fast like 0.01ms on my test > > > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html > > > > Nice work! > > > > Thanks > > > > [image: > https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png] > > > Virus-free. www.avg.com > > > > > On Wed, May 8, 2019 at 2:41 PM Ken Russell (kbr...@) < > public_webgl...@> wrote: > > Jie Chen from Intel just landed a fix in Chrome dramatically improving the > performance of querying COMPLETION_STATUS_KHR under > http://crbug.com/881152 . The fix will be in tomorrow's Canary on Windows > and macOS. > > > > This should address the last major gap with this extension. We would like > to enable it by default by promoting it to community approved; any further > comments? > > > > -Ken > > > > > > > > *From: *Ken Russell > *Date: *Fri, Apr 26, 2019 at 3:40 PM > *To: *Public WebGL > > Thanks for the report and the clear test case. There was an existing bug > about this, so the new one was duplicated into it, and some hints about > implementing it were added to the preexisting bug. > > > > > > On Fri, Apr 26, 2019 at 5:56 AM Takahiro Aoyagi (taoyagi...@) < > public_webgl...@> wrote: > > Hi Chen, > > > > Opened a bug. Thanks. > > > > https://bugs.chromium.org/p/chromium/issues/detail?id=957001 > > > > Takahiro > > > > > > On Fri, Apr 26, 2019 at 8:03 PM Chen, Jie A (jie.a.chen...@) < > public_webgl...@> wrote: > > Hi Takahiro, > > The current implementation of COMPLETION_STATUS_KHR query in chromium > incurs an expensive round-trip to the GPU thread. This may contribute to > the wait time in your case. I am trying to optimize this. Could you please > file a bug to chromium? I would look into it once I?ve done the > optimization. > > > > *From:* owners-public_webgl...@ [mailto: > owners-public_webgl...@] *On Behalf Of *Takahiro Aoyagi ( > taoyagi...@) > *Sent:* Friday, April 26, 2019 6:20 PM > *To:* Public WebGL > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Hi all, > > > > I'm working on Three.js + KHR_parallel_shader_compile extension support > with Fernando. > > > > https://github.com/mrdoob/three.js/issues/16321#issuecomment-486436086 > > > > I'm testing with Canary. But the behavior seems weird to me. > gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) seems to wait > for compile+link completion. I don't think it should wait for that, it > should just do polling and returning true/false quickly instead. > > > > I made a simple test to reproduce. > > > > > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html > > > > Code snippet. > > > > const ext = gl.getExtension('KHR_parallel_shader_compile'); > > > > gl.compileShader(vertexShader); > gl.compileShader(fragmentShader); > gl.attachShader(program, vertexShader); > gl.attachShader(program, fragmentShader); > gl.linkProgram(program); > > const startTime = performance.now(); > const status = useExtension > ? gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) > : gl.getProgramParameter(program, gl.LINK_STATUS); > const endTime = performance.now(); > > const elapsedTime = endTime - startTime; > > > > On my platform, both gl.LINK_STATUS and ext.COMPLETION_STATUS_KHR take so > long time about 15ms. I can accept this number for gl.LINK_STATUS because > it waits for compile+link completion. But 15ms for > ext.COMPLETION_STATUS_KHR looks weird to me. It shouldn't wait for the > compile+link completion but should do just polling and quickly returning > true/false instead. So I guess the number should be 1ms or less. > > > > Let me know if I'm missing something. Or could it be a Canary bug? > > > > My platform. > > > > OS: Windows10 > > Browser: Chrome Canary. > > Browser boot option: --use-cmd-decoder=passthrough > --enable-webgl-draft-extensions > > > > > > Thanks > > > > Takahiro > > > > > > On Fri, Apr 26, 2019 at 10:15 AM Chen, Jie A (jie.a.chen...@) < > public_webgl...@> wrote: > > Basically, for ANGLE?s GL backend, it?s simply a wrapper for the existing > GL implementations. In this sense glCompileShader() is still implementation > specific. Essentially ANGLE just calls glCompileShader and check > GL_COMPILE_STATUS. > > > > *From:* owners-public_webgl...@ [mailto: > owners-public_webgl...@] *On Behalf Of *Jasper St. Pierre ( > jstpierre...@) > *Sent:* Friday, April 26, 2019 1:18 AM > *To:* Public WebGL > *Subject:* RE: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Thank you, that?s important information to know. Changing my shader > compilation pipeline to wait for shader completion status is a lot more > difficult, but based on some initial tests, it?s more expensive than not > doing it ? the latency of getShaderParameter is too high. > > > > That said, in a lot of GL implementations, glCompileShader() is > practically a no-op, and will only do an AST parse when > glGetShaderParameter/InfoLog() is called (which is basically only for > debugging / error checking). glLinkProgram() does full compilation of all > programs, as full-PSO optimization is important. I don?t know how common > this is, but multiple GL implementations I have seen do it. It might make > sense for ANGLE to adopt this model as well. > > > > *From:* owners-public_webgl...@ *On > Behalf Of *Chen, Jie A (jie.a.chen...@) > *Sent:* Wednesday, April 24, 2019 6:48 PM > *To:* Public WebGL > *Subject:* RE: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Absolutely. Ideally there would be no stall for linkProgram. I tried, but > it?s too difficult to achieve this in ANGLE. > > > > *From:* owners-public_webgl...@ [ > mailto:owners-public_webgl...@ ] *On > Behalf Of *Jeff Gilbert (jgilbert...@) > *Sent:* Thursday, April 25, 2019 9:33 AM > *To:* Public WebGL > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Possibly, but in the long run, I expect implementations to support > no-stall linkProgram invocations. > > > > On Wed, Apr 24, 2019 at 6:27 PM Chen, Jie A (jie.a.chen...@) < > public_webgl...@> wrote: > > linkProgram may stall on compileShader. To avoid the stall, you?d better > make sure the COMPLETION_STATUS_KHR statuses of the attached shaders are > all True before calling linkProgram. In this sense, the first workflow has > less chance running into stall. > > > > *From:* owners-public_webgl...@ [mailto: > owners-public_webgl...@] *On Behalf Of *Fernando Serrano Garc?a ( > fserrano...@) > *Sent:* Wednesday, April 24, 2019 9:38 PM > *To:* Public WebGL > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Regarding the optimal proposed workflow (grouping shaders and programs > separately) of: > > for (const x of shaders) > gl.compileShader(x); > for (const x of programs) > gl.linkProgram(x); > > > > versus something more on the way that we currently have in many engines as > threejs: > > for (const x of material) > > gl.compileShader(fs); > > gl.compileShader(vs); > gl.linkProgram(x); > > > > Do you think is more or less accurate the following graph for 4 materials > and enabling this extension with 2 and 4 parallel threads? > > > > [image: Screen Shot 2019-04-24 at 15.35.47.png] > > > > On Wed, Apr 24, 2019 at 2:40 PM Fernando Serrano Garc?a < > fserrano...@> wrote: > > fwiw three.js introduced a "debug" parameter (false by default) to > determine if there will be a status check and call all the get* (currently > in dev): > > - > https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLShader.js#L21-L26 > > - > https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLProgram.js#L608 > > > > so currently calling `new WebGLShader()` won't be blocking with any `get*` > function and it could be used as is to compile all of them in a loop with > or without the extension. > > the problem comes from the WebGLProgram as it should just queue itself > before trying to link any program and wait until all the shader compile > calls finish, then do all the link, and wait for it asynchronously before > start using these programs. > > I have opened an issue on the three.js repo to keep track of the > implementation and we have booked some time this week to take a look at it, > feedback is welcome :) https://github.com/mrdoob/three.js/issues/16321 > > > > On Tue, Apr 16, 2019 at 11:55 PM Ken Russell (kbr...@) < > public_webgl...@> wrote: > > On Tue, Apr 16, 2019 at 2:24 PM Tarek Sherif (tsherif...@) < > public_webgl...@> wrote: > > Yes, I've read both specs. I think this language in the WebGL version is > confusing: "When this extension is enabled: Shader compilation and program > linking may be performed in a separate CPU thread." And neither indicates > which functions are expected to cause stalls. As written, this extension > requires more than most that people know implementation details. > > > > All previous operations against the program - looking up uniform > locations, drawing with it, etc. - will cause stalls. The application > *must* be updated to query the program's COMPLETION_STATUS_KHR status, and > skip *all* operations against the program until it's no longer pending. > > > > I guess we'll just change the WebGL version of this extension spec to be > much more explicit about this. > > > > > > Essentially, all previous code which checked for the completion of > compilation of shaders / linking of programs can be updated with a small > wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. > > > > This is not true because the most common way this is done will cause > stalls that sabotage the parallelism, e.g.: > > https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLShader.js#L21-L36 > > > https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLProgram.js#L586-L631 > > > > The check for COMPLETION_STATUS_KHR has to wrap *all* queries and uses of > the program object, and they must be skipped until COMPLETION_STATUS_KHR > returns true. Yes, all applications will have to be updated to take > advantage of this extension, but if they do, the benefits will be > significant. > > > > -Ken > > > > > > *Tarek Sherif* > > Senior Software Engineer, Visualization | Uber > > http://vis.gl/ > > > > > > > > On Tue, Apr 16, 2019 at 4:18 PM Ken Russell (kbr...@) < > public_webgl...@> wrote: > > Please review the Overview in the underlying OpenGL ES spec: > > > https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt > > > > > It describes that the extension uses one or more separate CPU threads for > shader compilation. If you still think we should rewrite the introduction > to the WebGL extension, we can do that too. > > > > Essentially, all previous code which checked for the completion of > compilation of shaders / linking of programs can be updated with a small > wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. > > > > -Ken > > > > > > > > On Tue, Apr 16, 2019 at 1:36 AM Tarek Sherif (tsherif...@) < > public_webgl...@> wrote: > > This is all extremely interesting, and documentation of these best > practices should probably be more publicly available (perhaps through a > non-normative note in the spec). I'm thinking the language in the extension > spec could be made more clear about what it's actual purpose is. It > currently gives the impression that enabling it is what allows for parallel > compilation and that this should save time, but given what Jeff and Kai > have said, it sounds like the purpose is to avoid CPU stalls, and that it > might even take longer in wall time since you're only checking once a > frame. Maybe some background information could be added along the lines of > "Normally applications must wait on get*Parameter or a draw call for > program linking to complete, this extension provides a mechanism for > querying completion status without stalling..." > > > > *Tarek Sherif* > > Senior Software Engineer, Visualization | Uber > > http://vis.gl/ > > > > > > > > > On Mon, Apr 15, 2019 at 11:23 PM Kai Ninomiya (kainino...@) < > public_webgl...@> wrote: > > > > > > On Mon, Apr 15, 2019 at 7:18 PM Tarek Sherif (tareksherif...@) < > public_webgl...@> wrote: > > I don't see anything in the OpenGL extension spec about what functions > cause stalls. Is that implementation-specific? Having an idea what to > expect is important for two reasons: > > 1. To make it clear that drawing will still work if > getProgramParameter(COMPLETION_STATUS_KHR) hasn't returned true yet (i.e. > the stall on a draw call) > > > > Generally, OpenGL extensions are not allowed to break existing > API/existing content. (In OpenGL, all extensions are always enabled; > there's no requestExtension.) Hence, even if you enable the extension, it > won't change the way your application works, and therefore the draw call > must still cause a stall in order to be able to use the program. > > > > 2. Almost all WebGL code I've looked at handles compilation in a way > similar to the following: > > gl.compileShader(vertexShader); > if (!gl.getShaderParameter(vertexShader, gl.COMPILE_STATUS)) //... > > gl.compileShader(fragmentShader); > > if (!gl.getShaderParameter(fragmentShader, gl.COMPILE_STATUS)) //... > > //... > > gl.linkProgram(program); > if (!gl.getProgramParameter(program, gl.LINK_STATUS)) //... > > I think it would be worth it to make clear that this pattern would > sabotage the parallel compile. > > > > I seem to remember (not sure if this is still true) that this pattern also > sabotages the shader compiler cache in ANGLE, because ANGLE doesn't cache > the COMPILE_STATUS (or was it the compile info string?). So it forces the > compiler to recompile just to give you the status. > > > > Tarek Sherif > > http://tareksherif.net/ > > > > > > > > > ??????? Original Message ??????? > > On Monday, April 15, 2019 9:00 PM, Ken Russell (kbr...@) < > public_webgl...@> wrote: > > > > The WebGL extension (which is basically just a wrapper) refers to the > underlying OpenGL / OpenGL ES extension > https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt > , > where this is documented. Is that sufficient? It would be better to avoid > duplicating a large amount of spec text from the underlying extension. > However, we can add some non-normative text if that would help. > > > > -Ken > > > > > > > > On Sat, Apr 13, 2019 at 3:51 AM Tarek Sherif (tareksherif...@) < > public_webgl...@> wrote: > > IIRC, all 3 of those functions still force a wait for the {shader to > finish compiling, program to finish linking} just as they did before. The > new semantics are only visible via the new COMPLETION_STATUS_KHR check. > > That should work perfectly for us. Can we add some language to the spec > about which functions cause stalls? I feel like as written, it will be easy > for people to use the extension incorrectly. > > > > Tarek Sherif > > http://tareksherif.net/ > > > > > > > > > ??????? Original Message ??????? > > On Friday, April 12, 2019 4:10 PM, Kai Ninomiya (kainino...@) < > public_webgl...@> wrote: > > > > Oh yes, useProgram probably won't stall. But getUniformLocation and the > others will stall, as will draw calls. > > > > getProgramParameter(COMPLETION_STATUS_KHR) should get faster at some > point; see http://crbug.com/881152 > which > Ken linked. > > > > On Fri, Apr 12, 2019 at 12:39 PM Jasper St. Pierre (jstpierre...@) > wrote: > > Thank you! Trying this out in my own WebGL 2 app, I see quite a reduction > in shader compilation time, shaving 400ms on load time on a moderately > complex scene. The getProgramParameter(COMPLETION_STATUS_KHR) query still > takes 1ms (which I believe is being tracked), but that is still better from > the 4ms I see in getUniformBlockIndex (my previous sync point). > > > > AFAIK, useProgram should not cause a stall, but in order to set my texture > samplers to bind to different units, I need to do a getUniformLocation on > my sampler uniform, which causes a compilation stall. Same thing with > getUniformBlockIndex. Do make sure that anything that might query into > reflection about the program (e.g. getVertexAttributeIndex, > getUniformLocation, getUniformBlockIndex) happens after > COMPLETION_STATUS_KHR returns true, since that?s another way to > accidentally stall on compilation completing. > > > > > > *From:* owners-public_webgl...@ *On > Behalf Of *Kai Ninomiya (kainino...@) > > *Sent:* Friday, April 12, 2019 10:25 AM > > *To:* Public WebGL > > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > > > IIRC, all 3 of those functions still force a wait for the {shader to > finish compiling, program to finish linking} just as they did before. The > new semantics are only visible via the new COMPLETION_STATUS_KHR check. > > > > On Fri, Apr 12, 2019 at 10:05 AM Tarek Sherif (tsherif...@) < > public_webgl...@> wrote: > > Very excited about this extension, but I'm concerned about how it would > work in our use case. Our flagship visualization library, deck.gl > , > often shares the gl context with a separate base map rendering application > so that it can properly interleave visualization layers with the base map. > Enabling this extension seems to change the behaviour of existing WebGL > functions in a way that I don't believe other extensions do. My worry is > how our enabling KHR_parallel_shader_compile would affect applications we > share contexts with, i.e what happens if the typical synchronous > compilation logic is used after KHR_parallel_shader_compile is enabled? > Specifically: > > - What happens if getShaderParameter(shader, COMPILE_STATUS) is called > before compilation is complete? > - What happens if getProgramParameter(program, LINK_STATUS) is called > before linking is complete? > - What happens if useProgram is called before linking is complete? > > Thanks, > > > > > > Tarek Sherif > > Senior Software Engineer, Visualization | Uber > > http://vis.gl/ > > > > > > > > > > > *Tarek Sherif* > > Senior Software Engineer, Visualization | Uber > > http://vis.gl/ > > > > > > > On Fri, Apr 12, 2019 at 12:16 PM David Catuhe (David.Catuhe...@) > wrote: > > Wonderful! > > > > > > *From:* owners-public_webgl...@ *On > Behalf Of *Ken Russell (kbr...@) > > *Sent:* Wednesday, April 10, 2019 2:56 PM > > *To:* Public WebGL > > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > > > If your code works correctly now when enabling draft WebGL extensions in > Chrome, then no changes are needed. There won't be any changes to the > extension when it's taken out of draft status; it'll just be available by > default. > > > > -Ken > > > > > > On Wed, Apr 10, 2019 at 12:36 PM David Catuhe (David.Catuhe...@) > wrote: > > We do have support for the extension in Babylon.js. How can we test this > change? > ------------------------------ > > > > *From:* owners-public_webgl...@ > on behalf of Ken Russell (kbr...@) > *Sent:* Wednesday, April 10, 2019 12:00:25 PM > *To:* public > *Subject:* [Public WebGL] Propose promoting KHR_parallel_shader_compile > to community approved > > > > WebGL community, > > > > Jie Chen from Intel has principally developed and implemented a WebGL > wrapper for the KHR_parallel_shader_compile extension. This allows shader > compilation and program linking to occur fully in parallel to the rest of > the WebGL application. Some small application changes are needed to take > full advantage of the extension, but it is otherwise fully backward > compatible. Jie has even emulated this extension on platforms which don't > support it natively. > > > > This extension solves a longstanding user complaint with WebGL, namely > long shader compile times on Windows. Compiles and links occur not only > asynchronously, but also in parallel, so there is a net speedup when using > this extension. Users who have tried out the draft extension are pleased > with the results and would like to see it made widely available. > > > > I propose promoting this extension to community approved in > https://github.com/KhronosGroup/WebGL/pull/2855 > > . Any comments? > > > > -Ken > > > > > > > > > > [image: > https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png] > > > Virus-free. www.avg.com > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 82548 bytes Desc: not available URL: From pub...@ Fri May 10 13:39:59 2019 From: pub...@ (Ken Russell (...@...)) Date: Fri, 10 May 2019 13:39:59 -0700 Subject: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved In-Reply-To: References: Message-ID: Super. Thank you Takahiro for testing and confirming! *From: *Takahiro Aoyagi (taoyagi...@) *Date: *Fri, May 10, 2019 at 10:51 AM *To: *Public WebGL I made simple tests to check the CPU elapsed time of > gl.getProgramParameter() and gl.useProgram() after checking > COMPLETION_STATUS_KHR is true. Both are fast here on my Windows10 Chrome > Canary. > > > > > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime6.html > > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime7.html > > Takahiro > > > Virus-free. > www.avg.com > > <#m_-3047211929259580689_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > On Sat, May 11, 2019 at 2:46 AM Ken Russell (kbr...@) < > public_webgl...@> wrote: > >> Hmm. The only reason I can think of that that would happen is if you're >> running on Windows, and ANGLE has to dynamically recompile the program >> behind the scenes in order to handle some OpenGL ES state change. I'm not >> 100% sure which changes require this dynamic recompilation; the ANGLE >> developers would know best. >> https://groups.google.com//forum/#!forum/angleproject might be helpful. >> >> We'd really need some test case to make progress on this. Can you provide >> one? >> >> -Ken >> >> >> On Fri, May 10, 2019 at 10:28 AM Jasper St. Pierre (jstpierre...@) >> wrote: >> >>> Hello again. My app is now showing that getProgramParameter is >>> completing quick, but it is spending a lot of time in useProgram. I am >>> checking for COMPLETION_STATUS_KHR on the GL program beforehand and it is >>> returning true. I?m guessing there?s some additional expensive work that >>> still needs to happen at useProgram time. Is this a bug? Any ways to debug >>> or avoid this? I?m unsure if there will be an easy repro. >>> >>> >>> >>> Again, profiler screenshot attached. >>> >>> >>> >>> *From:* owners-public_webgl...@ >>> *On Behalf Of *Takahiro Aoyagi (taoyagi...@) >>> *Sent:* Friday, May 10, 2019 12:22 AM >>> *To:* Public WebGL >>> *Subject:* Re: [Public WebGL] Propose promoting >>> KHR_parallel_shader_compile to community approved >>> >>> >>> >>> Confirmed COMPLETION_STATUS_KHR is very fast like 0.01ms on my test >>> >>> >>> https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html >>> >>> >>> >>> Nice work! >>> >>> >>> >>> Thanks >>> >>> >>> >>> [image: >>> https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png] >>> >>> >>> Virus-free. www.avg.com >>> >>> >>> >>> >>> On Wed, May 8, 2019 at 2:41 PM Ken Russell (kbr...@) < >>> public_webgl...@> wrote: >>> >>> Jie Chen from Intel just landed a fix in Chrome dramatically improving >>> the performance of querying COMPLETION_STATUS_KHR under >>> http://crbug.com/881152 . The fix will be in tomorrow's Canary on >>> Windows and macOS. >>> >>> >>> >>> This should address the last major gap with this extension. We would >>> like to enable it by default by promoting it to community approved; any >>> further comments? >>> >>> >>> >>> -Ken >>> >>> >>> >>> >>> >>> >>> >>> *From: *Ken Russell >>> *Date: *Fri, Apr 26, 2019 at 3:40 PM >>> *To: *Public WebGL >>> >>> Thanks for the report and the clear test case. There was an existing bug >>> about this, so the new one was duplicated into it, and some hints about >>> implementing it were added to the preexisting bug. >>> >>> >>> >>> >>> >>> On Fri, Apr 26, 2019 at 5:56 AM Takahiro Aoyagi (taoyagi...@) < >>> public_webgl...@> wrote: >>> >>> Hi Chen, >>> >>> >>> >>> Opened a bug. Thanks. >>> >>> >>> >>> https://bugs.chromium.org/p/chromium/issues/detail?id=957001 >>> >>> >>> >>> Takahiro >>> >>> >>> >>> >>> >>> On Fri, Apr 26, 2019 at 8:03 PM Chen, Jie A (jie.a.chen...@) < >>> public_webgl...@> wrote: >>> >>> Hi Takahiro, >>> >>> The current implementation of COMPLETION_STATUS_KHR query in >>> chromium incurs an expensive round-trip to the GPU thread. This may >>> contribute to the wait time in your case. I am trying to optimize this. >>> Could you please file a bug to chromium? I would look into it once I?ve >>> done the optimization. >>> >>> >>> >>> *From:* owners-public_webgl...@ [mailto: >>> owners-public_webgl...@] *On Behalf Of *Takahiro Aoyagi ( >>> taoyagi...@) >>> *Sent:* Friday, April 26, 2019 6:20 PM >>> *To:* Public WebGL >>> *Subject:* Re: [Public WebGL] Propose promoting >>> KHR_parallel_shader_compile to community approved >>> >>> >>> >>> Hi all, >>> >>> >>> >>> I'm working on Three.js + KHR_parallel_shader_compile extension support >>> with Fernando. >>> >>> >>> >>> https://github.com/mrdoob/three.js/issues/16321#issuecomment-486436086 >>> >>> >>> >>> I'm testing with Canary. But the behavior seems weird to me. >>> gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) seems to wait >>> for compile+link completion. I don't think it should wait for that, it >>> should just do polling and returning true/false quickly instead. >>> >>> >>> >>> I made a simple test to reproduce. >>> >>> >>> >>> >>> https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html >>> >>> >>> >>> Code snippet. >>> >>> >>> >>> const ext = gl.getExtension('KHR_parallel_shader_compile'); >>> >>> >>> >>> gl.compileShader(vertexShader); >>> gl.compileShader(fragmentShader); >>> gl.attachShader(program, vertexShader); >>> gl.attachShader(program, fragmentShader); >>> gl.linkProgram(program); >>> >>> const startTime = performance.now(); >>> const status = useExtension >>> ? gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) >>> : gl.getProgramParameter(program, gl.LINK_STATUS); >>> const endTime = performance.now(); >>> >>> const elapsedTime = endTime - startTime; >>> >>> >>> >>> On my platform, both gl.LINK_STATUS and ext.COMPLETION_STATUS_KHR take >>> so long time about 15ms. I can accept this number for gl.LINK_STATUS >>> because it waits for compile+link completion. But 15ms for >>> ext.COMPLETION_STATUS_KHR looks weird to me. It shouldn't wait for the >>> compile+link completion but should do just polling and quickly returning >>> true/false instead. So I guess the number should be 1ms or less. >>> >>> >>> >>> Let me know if I'm missing something. Or could it be a Canary bug? >>> >>> >>> >>> My platform. >>> >>> >>> >>> OS: Windows10 >>> >>> Browser: Chrome Canary. >>> >>> Browser boot option: --use-cmd-decoder=passthrough >>> --enable-webgl-draft-extensions >>> >>> >>> >>> >>> >>> Thanks >>> >>> >>> >>> Takahiro >>> >>> >>> >>> >>> >>> On Fri, Apr 26, 2019 at 10:15 AM Chen, Jie A (jie.a.chen...@) < >>> public_webgl...@> wrote: >>> >>> Basically, for ANGLE?s GL backend, it?s simply a wrapper for the >>> existing GL implementations. In this sense glCompileShader() is still >>> implementation specific. Essentially ANGLE just calls glCompileShader and >>> check GL_COMPILE_STATUS. >>> >>> >>> >>> *From:* owners-public_webgl...@ [mailto: >>> owners-public_webgl...@] *On Behalf Of *Jasper St. Pierre ( >>> jstpierre...@) >>> *Sent:* Friday, April 26, 2019 1:18 AM >>> *To:* Public WebGL >>> *Subject:* RE: [Public WebGL] Propose promoting >>> KHR_parallel_shader_compile to community approved >>> >>> >>> >>> Thank you, that?s important information to know. Changing my shader >>> compilation pipeline to wait for shader completion status is a lot more >>> difficult, but based on some initial tests, it?s more expensive than not >>> doing it ? the latency of getShaderParameter is too high. >>> >>> >>> >>> That said, in a lot of GL implementations, glCompileShader() is >>> practically a no-op, and will only do an AST parse when >>> glGetShaderParameter/InfoLog() is called (which is basically only for >>> debugging / error checking). glLinkProgram() does full compilation of all >>> programs, as full-PSO optimization is important. I don?t know how common >>> this is, but multiple GL implementations I have seen do it. It might make >>> sense for ANGLE to adopt this model as well. >>> >>> >>> >>> *From:* owners-public_webgl...@ >>> *On Behalf Of *Chen, Jie A (jie.a.chen...@) >>> *Sent:* Wednesday, April 24, 2019 6:48 PM >>> *To:* Public WebGL >>> *Subject:* RE: [Public WebGL] Propose promoting >>> KHR_parallel_shader_compile to community approved >>> >>> >>> >>> Absolutely. Ideally there would be no stall for linkProgram. I tried, >>> but it?s too difficult to achieve this in ANGLE. >>> >>> >>> >>> *From:* owners-public_webgl...@ [ >>> mailto:owners-public_webgl...@ ] >>> *On Behalf Of *Jeff Gilbert (jgilbert...@) >>> *Sent:* Thursday, April 25, 2019 9:33 AM >>> *To:* Public WebGL >>> *Subject:* Re: [Public WebGL] Propose promoting >>> KHR_parallel_shader_compile to community approved >>> >>> >>> >>> Possibly, but in the long run, I expect implementations to support >>> no-stall linkProgram invocations. >>> >>> >>> >>> On Wed, Apr 24, 2019 at 6:27 PM Chen, Jie A (jie.a.chen...@) < >>> public_webgl...@> wrote: >>> >>> linkProgram may stall on compileShader. To avoid the stall, you?d better >>> make sure the COMPLETION_STATUS_KHR statuses of the attached shaders are >>> all True before calling linkProgram. In this sense, the first workflow has >>> less chance running into stall. >>> >>> >>> >>> *From:* owners-public_webgl...@ [mailto: >>> owners-public_webgl...@] *On Behalf Of *Fernando Serrano Garc?a >>> (fserrano...@) >>> *Sent:* Wednesday, April 24, 2019 9:38 PM >>> *To:* Public WebGL >>> *Subject:* Re: [Public WebGL] Propose promoting >>> KHR_parallel_shader_compile to community approved >>> >>> >>> >>> Regarding the optimal proposed workflow (grouping shaders and programs >>> separately) of: >>> >>> for (const x of shaders) >>> gl.compileShader(x); >>> for (const x of programs) >>> gl.linkProgram(x); >>> >>> >>> >>> versus something more on the way that we currently have in many engines >>> as threejs: >>> >>> for (const x of material) >>> >>> gl.compileShader(fs); >>> >>> gl.compileShader(vs); >>> gl.linkProgram(x); >>> >>> >>> >>> Do you think is more or less accurate the following graph for 4 >>> materials and enabling this extension with 2 and 4 parallel threads? >>> >>> >>> >>> [image: Screen Shot 2019-04-24 at 15.35.47.png] >>> >>> >>> >>> On Wed, Apr 24, 2019 at 2:40 PM Fernando Serrano Garc?a < >>> fserrano...@> wrote: >>> >>> fwiw three.js introduced a "debug" parameter (false by default) to >>> determine if there will be a status check and call all the get* (currently >>> in dev): >>> >>> - >>> https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLShader.js#L21-L26 >>> >>> - >>> https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLProgram.js#L608 >>> >>> >>> >>> so currently calling `new WebGLShader()` won't be blocking with any >>> `get*` function and it could be used as is to compile all of them in a loop >>> with or without the extension. >>> >>> the problem comes from the WebGLProgram as it should just queue itself >>> before trying to link any program and wait until all the shader compile >>> calls finish, then do all the link, and wait for it asynchronously before >>> start using these programs. >>> >>> I have opened an issue on the three.js repo to keep track of the >>> implementation and we have booked some time this week to take a look at it, >>> feedback is welcome :) https://github.com/mrdoob/three.js/issues/16321 >>> >>> >>> >>> On Tue, Apr 16, 2019 at 11:55 PM Ken Russell (kbr...@) < >>> public_webgl...@> wrote: >>> >>> On Tue, Apr 16, 2019 at 2:24 PM Tarek Sherif (tsherif...@) < >>> public_webgl...@> wrote: >>> >>> Yes, I've read both specs. I think this language in the WebGL version is >>> confusing: "When this extension is enabled: Shader compilation and program >>> linking may be performed in a separate CPU thread." And neither indicates >>> which functions are expected to cause stalls. As written, this extension >>> requires more than most that people know implementation details. >>> >>> >>> >>> All previous operations against the program - looking up uniform >>> locations, drawing with it, etc. - will cause stalls. The application >>> *must* be updated to query the program's COMPLETION_STATUS_KHR status, and >>> skip *all* operations against the program until it's no longer pending. >>> >>> >>> >>> I guess we'll just change the WebGL version of this extension spec to be >>> much more explicit about this. >>> >>> >>> >>> >>> >>> Essentially, all previous code which checked for the completion of >>> compilation of shaders / linking of programs can be updated with a small >>> wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. >>> >>> >>> >>> This is not true because the most common way this is done will cause >>> stalls that sabotage the parallelism, e.g.: >>> >>> https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLShader.js#L21-L36 >>> >>> >>> https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLProgram.js#L586-L631 >>> >>> >>> >>> The check for COMPLETION_STATUS_KHR has to wrap *all* queries and uses >>> of the program object, and they must be skipped until COMPLETION_STATUS_KHR >>> returns true. Yes, all applications will have to be updated to take >>> advantage of this extension, but if they do, the benefits will be >>> significant. >>> >>> >>> >>> -Ken >>> >>> >>> >>> >>> >>> *Tarek Sherif* >>> >>> Senior Software Engineer, Visualization | Uber >>> >>> http://vis.gl/ >>> >>> >>> >>> >>> >>> >>> >>> On Tue, Apr 16, 2019 at 4:18 PM Ken Russell (kbr...@) < >>> public_webgl...@> wrote: >>> >>> Please review the Overview in the underlying OpenGL ES spec: >>> >>> >>> https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt >>> >>> >>> >>> >>> It describes that the extension uses one or more separate CPU threads >>> for shader compilation. If you still think we should rewrite the >>> introduction to the WebGL extension, we can do that too. >>> >>> >>> >>> Essentially, all previous code which checked for the completion of >>> compilation of shaders / linking of programs can be updated with a small >>> wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. >>> >>> >>> >>> -Ken >>> >>> >>> >>> >>> >>> >>> >>> On Tue, Apr 16, 2019 at 1:36 AM Tarek Sherif (tsherif...@) < >>> public_webgl...@> wrote: >>> >>> This is all extremely interesting, and documentation of these best >>> practices should probably be more publicly available (perhaps through a >>> non-normative note in the spec). I'm thinking the language in the extension >>> spec could be made more clear about what it's actual purpose is. It >>> currently gives the impression that enabling it is what allows for parallel >>> compilation and that this should save time, but given what Jeff and Kai >>> have said, it sounds like the purpose is to avoid CPU stalls, and that it >>> might even take longer in wall time since you're only checking once a >>> frame. Maybe some background information could be added along the lines of >>> "Normally applications must wait on get*Parameter or a draw call for >>> program linking to complete, this extension provides a mechanism for >>> querying completion status without stalling..." >>> >>> >>> >>> *Tarek Sherif* >>> >>> Senior Software Engineer, Visualization | Uber >>> >>> http://vis.gl/ >>> >>> >>> >>> >>> >>> >>> >>> >>> On Mon, Apr 15, 2019 at 11:23 PM Kai Ninomiya (kainino...@) < >>> public_webgl...@> wrote: >>> >>> >>> >>> >>> >>> On Mon, Apr 15, 2019 at 7:18 PM Tarek Sherif (tareksherif...@) < >>> public_webgl...@> wrote: >>> >>> I don't see anything in the OpenGL extension spec about what functions >>> cause stalls. Is that implementation-specific? Having an idea what to >>> expect is important for two reasons: >>> >>> 1. To make it clear that drawing will still work if >>> getProgramParameter(COMPLETION_STATUS_KHR) hasn't returned true yet >>> (i.e. the stall on a draw call) >>> >>> >>> >>> Generally, OpenGL extensions are not allowed to break existing >>> API/existing content. (In OpenGL, all extensions are always enabled; >>> there's no requestExtension.) Hence, even if you enable the extension, it >>> won't change the way your application works, and therefore the draw call >>> must still cause a stall in order to be able to use the program. >>> >>> >>> >>> 2. Almost all WebGL code I've looked at handles compilation in a way >>> similar to the following: >>> >>> gl.compileShader(vertexShader); >>> if (!gl.getShaderParameter(vertexShader, gl.COMPILE_STATUS)) //... >>> >>> gl.compileShader(fragmentShader); >>> >>> if (!gl.getShaderParameter(fragmentShader, gl.COMPILE_STATUS)) //... >>> >>> //... >>> >>> gl.linkProgram(program); >>> if (!gl.getProgramParameter(program, gl.LINK_STATUS)) //... >>> >>> I think it would be worth it to make clear that this pattern would >>> sabotage the parallel compile. >>> >>> >>> >>> I seem to remember (not sure if this is still true) that this pattern >>> also sabotages the shader compiler cache in ANGLE, because ANGLE doesn't >>> cache the COMPILE_STATUS (or was it the compile info string?). So it forces >>> the compiler to recompile just to give you the status. >>> >>> >>> >>> Tarek Sherif >>> >>> http://tareksherif.net/ >>> >>> >>> >>> >>> >>> >>> >>> >>> ??????? Original Message ??????? >>> >>> On Monday, April 15, 2019 9:00 PM, Ken Russell (kbr...@) < >>> public_webgl...@> wrote: >>> >>> >>> >>> The WebGL extension (which is basically just a wrapper) refers to the >>> underlying OpenGL / OpenGL ES extension >>> https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt >>> , >>> where this is documented. Is that sufficient? It would be better to avoid >>> duplicating a large amount of spec text from the underlying extension. >>> However, we can add some non-normative text if that would help. >>> >>> >>> >>> -Ken >>> >>> >>> >>> >>> >>> >>> >>> On Sat, Apr 13, 2019 at 3:51 AM Tarek Sherif (tareksherif...@) < >>> public_webgl...@> wrote: >>> >>> IIRC, all 3 of those functions still force a wait for the {shader to >>> finish compiling, program to finish linking} just as they did before. The >>> new semantics are only visible via the new COMPLETION_STATUS_KHR check. >>> >>> That should work perfectly for us. Can we add some language to the spec >>> about which functions cause stalls? I feel like as written, it will be easy >>> for people to use the extension incorrectly. >>> >>> >>> >>> Tarek Sherif >>> >>> http://tareksherif.net/ >>> >>> >>> >>> >>> >>> >>> >>> >>> ??????? Original Message ??????? >>> >>> On Friday, April 12, 2019 4:10 PM, Kai Ninomiya (kainino...@) < >>> public_webgl...@> wrote: >>> >>> >>> >>> Oh yes, useProgram probably won't stall. But getUniformLocation and the >>> others will stall, as will draw calls. >>> >>> >>> >>> getProgramParameter(COMPLETION_STATUS_KHR) should get faster at some >>> point; see http://crbug.com/881152 >>> which >>> Ken linked. >>> >>> >>> >>> On Fri, Apr 12, 2019 at 12:39 PM Jasper St. Pierre (jstpierre...@) >>> wrote: >>> >>> Thank you! Trying this out in my own WebGL 2 app, I see quite a >>> reduction in shader compilation time, shaving 400ms on load time on a >>> moderately complex scene. The getProgramParameter(COMPLETION_STATUS_KHR) >>> query still takes 1ms (which I believe is being tracked), but that is still >>> better from the 4ms I see in getUniformBlockIndex (my previous sync point). >>> >>> >>> >>> AFAIK, useProgram should not cause a stall, but in order to set my >>> texture samplers to bind to different units, I need to do a >>> getUniformLocation on my sampler uniform, which causes a compilation stall. >>> Same thing with getUniformBlockIndex. Do make sure that anything that might >>> query into reflection about the program (e.g. getVertexAttributeIndex, >>> getUniformLocation, getUniformBlockIndex) happens after >>> COMPLETION_STATUS_KHR returns true, since that?s another way to >>> accidentally stall on compilation completing. >>> >>> >>> >>> >>> >>> *From:* owners-public_webgl...@ >>> *On Behalf Of *Kai Ninomiya (kainino...@) >>> >>> *Sent:* Friday, April 12, 2019 10:25 AM >>> >>> *To:* Public WebGL >>> >>> *Subject:* Re: [Public WebGL] Propose promoting >>> KHR_parallel_shader_compile to community approved >>> >>> >>> >>> >>> >>> IIRC, all 3 of those functions still force a wait for the {shader to >>> finish compiling, program to finish linking} just as they did before. The >>> new semantics are only visible via the new COMPLETION_STATUS_KHR check. >>> >>> >>> >>> On Fri, Apr 12, 2019 at 10:05 AM Tarek Sherif (tsherif...@) < >>> public_webgl...@> wrote: >>> >>> Very excited about this extension, but I'm concerned about how it would >>> work in our use case. Our flagship visualization library, deck.gl >>> , >>> often shares the gl context with a separate base map rendering application >>> so that it can properly interleave visualization layers with the base map. >>> Enabling this extension seems to change the behaviour of existing WebGL >>> functions in a way that I don't believe other extensions do. My worry is >>> how our enabling KHR_parallel_shader_compile would affect applications we >>> share contexts with, i.e what happens if the typical synchronous >>> compilation logic is used after KHR_parallel_shader_compile is enabled? >>> Specifically: >>> >>> - What happens if getShaderParameter(shader, COMPILE_STATUS) is >>> called before compilation is complete? >>> - What happens if getProgramParameter(program, LINK_STATUS) is >>> called before linking is complete? >>> - What happens if useProgram is called before linking is complete? >>> >>> Thanks, >>> >>> >>> >>> >>> >>> Tarek Sherif >>> >>> Senior Software Engineer, Visualization | Uber >>> >>> http://vis.gl/ >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> *Tarek Sherif* >>> >>> Senior Software Engineer, Visualization | Uber >>> >>> http://vis.gl/ >>> >>> >>> >>> >>> >>> >>> On Fri, Apr 12, 2019 at 12:16 PM David Catuhe ( >>> David.Catuhe...@) wrote: >>> >>> Wonderful! >>> >>> >>> >>> >>> >>> *From:* owners-public_webgl...@ >>> *On Behalf Of *Ken Russell (kbr...@) >>> >>> *Sent:* Wednesday, April 10, 2019 2:56 PM >>> >>> *To:* Public WebGL >>> >>> *Subject:* Re: [Public WebGL] Propose promoting >>> KHR_parallel_shader_compile to community approved >>> >>> >>> >>> >>> >>> If your code works correctly now when enabling draft WebGL extensions in >>> Chrome, then no changes are needed. There won't be any changes to the >>> extension when it's taken out of draft status; it'll just be available by >>> default. >>> >>> >>> >>> -Ken >>> >>> >>> >>> >>> >>> On Wed, Apr 10, 2019 at 12:36 PM David Catuhe ( >>> David.Catuhe...@) wrote: >>> >>> We do have support for the extension in Babylon.js. How can we test this >>> change? >>> ------------------------------ >>> >>> >>> >>> *From:* owners-public_webgl...@ >>> on behalf of Ken Russell (kbr...@) >>> *Sent:* Wednesday, April 10, 2019 12:00:25 PM >>> *To:* public >>> *Subject:* [Public WebGL] Propose promoting KHR_parallel_shader_compile >>> to community approved >>> >>> >>> >>> WebGL community, >>> >>> >>> >>> Jie Chen from Intel has principally developed and implemented a WebGL >>> wrapper for the KHR_parallel_shader_compile extension. This allows shader >>> compilation and program linking to occur fully in parallel to the rest of >>> the WebGL application. Some small application changes are needed to take >>> full advantage of the extension, but it is otherwise fully backward >>> compatible. Jie has even emulated this extension on platforms which don't >>> support it natively. >>> >>> >>> >>> This extension solves a longstanding user complaint with WebGL, namely >>> long shader compile times on Windows. Compiles and links occur not only >>> asynchronously, but also in parallel, so there is a net speedup when using >>> this extension. Users who have tried out the draft extension are pleased >>> with the results and would like to see it made widely available. >>> >>> >>> >>> I propose promoting this extension to community approved in >>> https://github.com/KhronosGroup/WebGL/pull/2855 >>> >>> . Any comments? >>> >>> >>> >>> -Ken >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> [image: >>> https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png] >>> >>> >>> Virus-free. www.avg.com >>> >>> >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 82548 bytes Desc: not available URL: From pub...@ Fri May 10 14:10:02 2019 From: pub...@ (Ken Russell (...@...)) Date: Fri, 10 May 2019 14:10:02 -0700 Subject: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved In-Reply-To: References: Message-ID: Since there haven't been any *objections* to moving this extension forward, and since the benefits are now being seen, it's been moved to community approved in https://github.com/KhronosGroup/WebGL/pull/2855 . Please, feel free to continue to report problems with long shader compilation times - either posting here on this mailing list or on webgl-dev-list, reporting cross-browser issues on https://github.com/KhronosGroup/WebGL/issues , or on individual browsers' bug trackers. -Ken *From: *Ken Russell *Date: *Fri, May 10, 2019 at 1:39 PM *To: *Public WebGL Super. Thank you Takahiro for testing and confirming! > > > *From: *Takahiro Aoyagi (taoyagi...@) > *Date: *Fri, May 10, 2019 at 10:51 AM > *To: *Public WebGL > > I made simple tests to check the CPU elapsed time of >> gl.getProgramParameter() and gl.useProgram() after checking >> COMPLETION_STATUS_KHR is true. Both are fast here on my Windows10 Chrome >> Canary. >> >> >> >> >> https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime6.html >> >> https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime7.html >> >> Takahiro >> >> >> Virus-free. >> www.avg.com >> >> <#m_-1563479101302147647_m_-3047211929259580689_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >> >> On Sat, May 11, 2019 at 2:46 AM Ken Russell (kbr...@) < >> public_webgl...@> wrote: >> >>> Hmm. The only reason I can think of that that would happen is if you're >>> running on Windows, and ANGLE has to dynamically recompile the program >>> behind the scenes in order to handle some OpenGL ES state change. I'm not >>> 100% sure which changes require this dynamic recompilation; the ANGLE >>> developers would know best. >>> https://groups.google.com//forum/#!forum/angleproject might be helpful. >>> >>> We'd really need some test case to make progress on this. Can you >>> provide one? >>> >>> -Ken >>> >>> >>> On Fri, May 10, 2019 at 10:28 AM Jasper St. Pierre (jstpierre...@) >>> wrote: >>> >>>> Hello again. My app is now showing that getProgramParameter is >>>> completing quick, but it is spending a lot of time in useProgram. I am >>>> checking for COMPLETION_STATUS_KHR on the GL program beforehand and it is >>>> returning true. I?m guessing there?s some additional expensive work that >>>> still needs to happen at useProgram time. Is this a bug? Any ways to debug >>>> or avoid this? I?m unsure if there will be an easy repro. >>>> >>>> >>>> >>>> Again, profiler screenshot attached. >>>> >>>> >>>> >>>> *From:* owners-public_webgl...@ < >>>> owners-public_webgl...@> *On Behalf Of *Takahiro Aoyagi ( >>>> taoyagi...@) >>>> *Sent:* Friday, May 10, 2019 12:22 AM >>>> *To:* Public WebGL >>>> *Subject:* Re: [Public WebGL] Propose promoting >>>> KHR_parallel_shader_compile to community approved >>>> >>>> >>>> >>>> Confirmed COMPLETION_STATUS_KHR is very fast like 0.01ms on my test >>>> >>>> >>>> https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html >>>> >>>> >>>> >>>> Nice work! >>>> >>>> >>>> >>>> Thanks >>>> >>>> >>>> >>>> [image: >>>> https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png] >>>> >>>> >>>> Virus-free. www.avg.com >>>> >>>> >>>> >>>> >>>> On Wed, May 8, 2019 at 2:41 PM Ken Russell (kbr...@) < >>>> public_webgl...@> wrote: >>>> >>>> Jie Chen from Intel just landed a fix in Chrome dramatically improving >>>> the performance of querying COMPLETION_STATUS_KHR under >>>> http://crbug.com/881152 . The fix will be in tomorrow's Canary on >>>> Windows and macOS. >>>> >>>> >>>> >>>> This should address the last major gap with this extension. We would >>>> like to enable it by default by promoting it to community approved; any >>>> further comments? >>>> >>>> >>>> >>>> -Ken >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> *From: *Ken Russell >>>> *Date: *Fri, Apr 26, 2019 at 3:40 PM >>>> *To: *Public WebGL >>>> >>>> Thanks for the report and the clear test case. There was an existing >>>> bug about this, so the new one was duplicated into it, and some hints about >>>> implementing it were added to the preexisting bug. >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Apr 26, 2019 at 5:56 AM Takahiro Aoyagi (taoyagi...@) < >>>> public_webgl...@> wrote: >>>> >>>> Hi Chen, >>>> >>>> >>>> >>>> Opened a bug. Thanks. >>>> >>>> >>>> >>>> https://bugs.chromium.org/p/chromium/issues/detail?id=957001 >>>> >>>> >>>> >>>> Takahiro >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Apr 26, 2019 at 8:03 PM Chen, Jie A (jie.a.chen...@) < >>>> public_webgl...@> wrote: >>>> >>>> Hi Takahiro, >>>> >>>> The current implementation of COMPLETION_STATUS_KHR query in >>>> chromium incurs an expensive round-trip to the GPU thread. This may >>>> contribute to the wait time in your case. I am trying to optimize this. >>>> Could you please file a bug to chromium? I would look into it once I?ve >>>> done the optimization. >>>> >>>> >>>> >>>> *From:* owners-public_webgl...@ [mailto: >>>> owners-public_webgl...@] *On Behalf Of *Takahiro Aoyagi ( >>>> taoyagi...@) >>>> *Sent:* Friday, April 26, 2019 6:20 PM >>>> *To:* Public WebGL >>>> *Subject:* Re: [Public WebGL] Propose promoting >>>> KHR_parallel_shader_compile to community approved >>>> >>>> >>>> >>>> Hi all, >>>> >>>> >>>> >>>> I'm working on Three.js + KHR_parallel_shader_compile extension support >>>> with Fernando. >>>> >>>> >>>> >>>> https://github.com/mrdoob/three.js/issues/16321#issuecomment-486436086 >>>> >>>> >>>> >>>> I'm testing with Canary. But the behavior seems weird to me. >>>> gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) seems to wait >>>> for compile+link completion. I don't think it should wait for that, it >>>> should just do polling and returning true/false quickly instead. >>>> >>>> >>>> >>>> I made a simple test to reproduce. >>>> >>>> >>>> >>>> >>>> https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html >>>> >>>> >>>> >>>> Code snippet. >>>> >>>> >>>> >>>> const ext = gl.getExtension('KHR_parallel_shader_compile'); >>>> >>>> >>>> >>>> gl.compileShader(vertexShader); >>>> gl.compileShader(fragmentShader); >>>> gl.attachShader(program, vertexShader); >>>> gl.attachShader(program, fragmentShader); >>>> gl.linkProgram(program); >>>> >>>> const startTime = performance.now(); >>>> const status = useExtension >>>> ? gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) >>>> : gl.getProgramParameter(program, gl.LINK_STATUS); >>>> const endTime = performance.now(); >>>> >>>> const elapsedTime = endTime - startTime; >>>> >>>> >>>> >>>> On my platform, both gl.LINK_STATUS and ext.COMPLETION_STATUS_KHR take >>>> so long time about 15ms. I can accept this number for gl.LINK_STATUS >>>> because it waits for compile+link completion. But 15ms for >>>> ext.COMPLETION_STATUS_KHR looks weird to me. It shouldn't wait for the >>>> compile+link completion but should do just polling and quickly returning >>>> true/false instead. So I guess the number should be 1ms or less. >>>> >>>> >>>> >>>> Let me know if I'm missing something. Or could it be a Canary bug? >>>> >>>> >>>> >>>> My platform. >>>> >>>> >>>> >>>> OS: Windows10 >>>> >>>> Browser: Chrome Canary. >>>> >>>> Browser boot option: --use-cmd-decoder=passthrough >>>> --enable-webgl-draft-extensions >>>> >>>> >>>> >>>> >>>> >>>> Thanks >>>> >>>> >>>> >>>> Takahiro >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Apr 26, 2019 at 10:15 AM Chen, Jie A (jie.a.chen...@) < >>>> public_webgl...@> wrote: >>>> >>>> Basically, for ANGLE?s GL backend, it?s simply a wrapper for the >>>> existing GL implementations. In this sense glCompileShader() is still >>>> implementation specific. Essentially ANGLE just calls glCompileShader and >>>> check GL_COMPILE_STATUS. >>>> >>>> >>>> >>>> *From:* owners-public_webgl...@ [mailto: >>>> owners-public_webgl...@] *On Behalf Of *Jasper St. Pierre ( >>>> jstpierre...@) >>>> *Sent:* Friday, April 26, 2019 1:18 AM >>>> *To:* Public WebGL >>>> *Subject:* RE: [Public WebGL] Propose promoting >>>> KHR_parallel_shader_compile to community approved >>>> >>>> >>>> >>>> Thank you, that?s important information to know. Changing my shader >>>> compilation pipeline to wait for shader completion status is a lot more >>>> difficult, but based on some initial tests, it?s more expensive than not >>>> doing it ? the latency of getShaderParameter is too high. >>>> >>>> >>>> >>>> That said, in a lot of GL implementations, glCompileShader() is >>>> practically a no-op, and will only do an AST parse when >>>> glGetShaderParameter/InfoLog() is called (which is basically only for >>>> debugging / error checking). glLinkProgram() does full compilation of all >>>> programs, as full-PSO optimization is important. I don?t know how common >>>> this is, but multiple GL implementations I have seen do it. It might make >>>> sense for ANGLE to adopt this model as well. >>>> >>>> >>>> >>>> *From:* owners-public_webgl...@ < >>>> owners-public_webgl...@> *On Behalf Of *Chen, Jie A ( >>>> jie.a.chen...@) >>>> *Sent:* Wednesday, April 24, 2019 6:48 PM >>>> *To:* Public WebGL >>>> *Subject:* RE: [Public WebGL] Propose promoting >>>> KHR_parallel_shader_compile to community approved >>>> >>>> >>>> >>>> Absolutely. Ideally there would be no stall for linkProgram. I tried, >>>> but it?s too difficult to achieve this in ANGLE. >>>> >>>> >>>> >>>> *From:* owners-public_webgl...@ [ >>>> mailto:owners-public_webgl...@ >>>> ] *On Behalf Of *Jeff Gilbert ( >>>> jgilbert...@) >>>> *Sent:* Thursday, April 25, 2019 9:33 AM >>>> *To:* Public WebGL >>>> *Subject:* Re: [Public WebGL] Propose promoting >>>> KHR_parallel_shader_compile to community approved >>>> >>>> >>>> >>>> Possibly, but in the long run, I expect implementations to support >>>> no-stall linkProgram invocations. >>>> >>>> >>>> >>>> On Wed, Apr 24, 2019 at 6:27 PM Chen, Jie A (jie.a.chen...@) < >>>> public_webgl...@> wrote: >>>> >>>> linkProgram may stall on compileShader. To avoid the stall, you?d >>>> better make sure the COMPLETION_STATUS_KHR statuses of the attached shaders >>>> are all True before calling linkProgram. In this sense, the first workflow >>>> has less chance running into stall. >>>> >>>> >>>> >>>> *From:* owners-public_webgl...@ [mailto: >>>> owners-public_webgl...@] *On Behalf Of *Fernando Serrano >>>> Garc?a (fserrano...@) >>>> *Sent:* Wednesday, April 24, 2019 9:38 PM >>>> *To:* Public WebGL >>>> *Subject:* Re: [Public WebGL] Propose promoting >>>> KHR_parallel_shader_compile to community approved >>>> >>>> >>>> >>>> Regarding the optimal proposed workflow (grouping shaders and programs >>>> separately) of: >>>> >>>> for (const x of shaders) >>>> gl.compileShader(x); >>>> for (const x of programs) >>>> gl.linkProgram(x); >>>> >>>> >>>> >>>> versus something more on the way that we currently have in many engines >>>> as threejs: >>>> >>>> for (const x of material) >>>> >>>> gl.compileShader(fs); >>>> >>>> gl.compileShader(vs); >>>> gl.linkProgram(x); >>>> >>>> >>>> >>>> Do you think is more or less accurate the following graph for 4 >>>> materials and enabling this extension with 2 and 4 parallel threads? >>>> >>>> >>>> >>>> [image: Screen Shot 2019-04-24 at 15.35.47.png] >>>> >>>> >>>> >>>> On Wed, Apr 24, 2019 at 2:40 PM Fernando Serrano Garc?a < >>>> fserrano...@> wrote: >>>> >>>> fwiw three.js introduced a "debug" parameter (false by default) to >>>> determine if there will be a status check and call all the get* (currently >>>> in dev): >>>> >>>> - >>>> https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLShader.js#L21-L26 >>>> >>>> - >>>> https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLProgram.js#L608 >>>> >>>> >>>> >>>> so currently calling `new WebGLShader()` won't be blocking with any >>>> `get*` function and it could be used as is to compile all of them in a loop >>>> with or without the extension. >>>> >>>> the problem comes from the WebGLProgram as it should just queue itself >>>> before trying to link any program and wait until all the shader compile >>>> calls finish, then do all the link, and wait for it asynchronously before >>>> start using these programs. >>>> >>>> I have opened an issue on the three.js repo to keep track of the >>>> implementation and we have booked some time this week to take a look at it, >>>> feedback is welcome :) https://github.com/mrdoob/three.js/issues/16321 >>>> >>>> >>>> >>>> On Tue, Apr 16, 2019 at 11:55 PM Ken Russell (kbr...@) < >>>> public_webgl...@> wrote: >>>> >>>> On Tue, Apr 16, 2019 at 2:24 PM Tarek Sherif (tsherif...@) < >>>> public_webgl...@> wrote: >>>> >>>> Yes, I've read both specs. I think this language in the WebGL version >>>> is confusing: "When this extension is enabled: Shader compilation and >>>> program linking may be performed in a separate CPU thread." And neither >>>> indicates which functions are expected to cause stalls. As written, this >>>> extension requires more than most that people know implementation details. >>>> >>>> >>>> >>>> All previous operations against the program - looking up uniform >>>> locations, drawing with it, etc. - will cause stalls. The application >>>> *must* be updated to query the program's COMPLETION_STATUS_KHR status, and >>>> skip *all* operations against the program until it's no longer pending. >>>> >>>> >>>> >>>> I guess we'll just change the WebGL version of this extension spec to >>>> be much more explicit about this. >>>> >>>> >>>> >>>> >>>> >>>> Essentially, all previous code which checked for the completion of >>>> compilation of shaders / linking of programs can be updated with a small >>>> wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. >>>> >>>> >>>> >>>> This is not true because the most common way this is done will cause >>>> stalls that sabotage the parallelism, e.g.: >>>> >>>> https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLShader.js#L21-L36 >>>> >>>> >>>> https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLProgram.js#L586-L631 >>>> >>>> >>>> >>>> The check for COMPLETION_STATUS_KHR has to wrap *all* queries and uses >>>> of the program object, and they must be skipped until COMPLETION_STATUS_KHR >>>> returns true. Yes, all applications will have to be updated to take >>>> advantage of this extension, but if they do, the benefits will be >>>> significant. >>>> >>>> >>>> >>>> -Ken >>>> >>>> >>>> >>>> >>>> >>>> *Tarek Sherif* >>>> >>>> Senior Software Engineer, Visualization | Uber >>>> >>>> http://vis.gl/ >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Tue, Apr 16, 2019 at 4:18 PM Ken Russell (kbr...@) < >>>> public_webgl...@> wrote: >>>> >>>> Please review the Overview in the underlying OpenGL ES spec: >>>> >>>> >>>> https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt >>>> >>>> >>>> >>>> >>>> It describes that the extension uses one or more separate CPU threads >>>> for shader compilation. If you still think we should rewrite the >>>> introduction to the WebGL extension, we can do that too. >>>> >>>> >>>> >>>> Essentially, all previous code which checked for the completion of >>>> compilation of shaders / linking of programs can be updated with a small >>>> wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. >>>> >>>> >>>> >>>> -Ken >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Tue, Apr 16, 2019 at 1:36 AM Tarek Sherif (tsherif...@) < >>>> public_webgl...@> wrote: >>>> >>>> This is all extremely interesting, and documentation of these best >>>> practices should probably be more publicly available (perhaps through a >>>> non-normative note in the spec). I'm thinking the language in the extension >>>> spec could be made more clear about what it's actual purpose is. It >>>> currently gives the impression that enabling it is what allows for parallel >>>> compilation and that this should save time, but given what Jeff and Kai >>>> have said, it sounds like the purpose is to avoid CPU stalls, and that it >>>> might even take longer in wall time since you're only checking once a >>>> frame. Maybe some background information could be added along the lines of >>>> "Normally applications must wait on get*Parameter or a draw call for >>>> program linking to complete, this extension provides a mechanism for >>>> querying completion status without stalling..." >>>> >>>> >>>> >>>> *Tarek Sherif* >>>> >>>> Senior Software Engineer, Visualization | Uber >>>> >>>> http://vis.gl/ >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Mon, Apr 15, 2019 at 11:23 PM Kai Ninomiya (kainino...@) < >>>> public_webgl...@> wrote: >>>> >>>> >>>> >>>> >>>> >>>> On Mon, Apr 15, 2019 at 7:18 PM Tarek Sherif (tareksherif...@) < >>>> public_webgl...@> wrote: >>>> >>>> I don't see anything in the OpenGL extension spec about what functions >>>> cause stalls. Is that implementation-specific? Having an idea what to >>>> expect is important for two reasons: >>>> >>>> 1. To make it clear that drawing will still work if >>>> getProgramParameter(COMPLETION_STATUS_KHR) hasn't returned true yet >>>> (i.e. the stall on a draw call) >>>> >>>> >>>> >>>> Generally, OpenGL extensions are not allowed to break existing >>>> API/existing content. (In OpenGL, all extensions are always enabled; >>>> there's no requestExtension.) Hence, even if you enable the extension, it >>>> won't change the way your application works, and therefore the draw call >>>> must still cause a stall in order to be able to use the program. >>>> >>>> >>>> >>>> 2. Almost all WebGL code I've looked at handles compilation in a way >>>> similar to the following: >>>> >>>> gl.compileShader(vertexShader); >>>> if (!gl.getShaderParameter(vertexShader, gl.COMPILE_STATUS)) //... >>>> >>>> gl.compileShader(fragmentShader); >>>> >>>> if (!gl.getShaderParameter(fragmentShader, gl.COMPILE_STATUS)) //... >>>> >>>> //... >>>> >>>> gl.linkProgram(program); >>>> if (!gl.getProgramParameter(program, gl.LINK_STATUS)) //... >>>> >>>> I think it would be worth it to make clear that this pattern would >>>> sabotage the parallel compile. >>>> >>>> >>>> >>>> I seem to remember (not sure if this is still true) that this pattern >>>> also sabotages the shader compiler cache in ANGLE, because ANGLE doesn't >>>> cache the COMPILE_STATUS (or was it the compile info string?). So it forces >>>> the compiler to recompile just to give you the status. >>>> >>>> >>>> >>>> Tarek Sherif >>>> >>>> http://tareksherif.net/ >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> ??????? Original Message ??????? >>>> >>>> On Monday, April 15, 2019 9:00 PM, Ken Russell (kbr...@) < >>>> public_webgl...@> wrote: >>>> >>>> >>>> >>>> The WebGL extension (which is basically just a wrapper) refers to the >>>> underlying OpenGL / OpenGL ES extension >>>> https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt >>>> , >>>> where this is documented. Is that sufficient? It would be better to avoid >>>> duplicating a large amount of spec text from the underlying extension. >>>> However, we can add some non-normative text if that would help. >>>> >>>> >>>> >>>> -Ken >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Sat, Apr 13, 2019 at 3:51 AM Tarek Sherif (tareksherif...@) < >>>> public_webgl...@> wrote: >>>> >>>> IIRC, all 3 of those functions still force a wait for the {shader to >>>> finish compiling, program to finish linking} just as they did before. The >>>> new semantics are only visible via the new COMPLETION_STATUS_KHR check. >>>> >>>> That should work perfectly for us. Can we add some language to the spec >>>> about which functions cause stalls? I feel like as written, it will be easy >>>> for people to use the extension incorrectly. >>>> >>>> >>>> >>>> Tarek Sherif >>>> >>>> http://tareksherif.net/ >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> ??????? Original Message ??????? >>>> >>>> On Friday, April 12, 2019 4:10 PM, Kai Ninomiya (kainino...@) < >>>> public_webgl...@> wrote: >>>> >>>> >>>> >>>> Oh yes, useProgram probably won't stall. But getUniformLocation and the >>>> others will stall, as will draw calls. >>>> >>>> >>>> >>>> getProgramParameter(COMPLETION_STATUS_KHR) should get faster at some >>>> point; see http://crbug.com/881152 >>>> which >>>> Ken linked. >>>> >>>> >>>> >>>> On Fri, Apr 12, 2019 at 12:39 PM Jasper St. Pierre ( >>>> jstpierre...@) wrote: >>>> >>>> Thank you! Trying this out in my own WebGL 2 app, I see quite a >>>> reduction in shader compilation time, shaving 400ms on load time on a >>>> moderately complex scene. The getProgramParameter(COMPLETION_STATUS_KHR) >>>> query still takes 1ms (which I believe is being tracked), but that is still >>>> better from the 4ms I see in getUniformBlockIndex (my previous sync point). >>>> >>>> >>>> >>>> AFAIK, useProgram should not cause a stall, but in order to set my >>>> texture samplers to bind to different units, I need to do a >>>> getUniformLocation on my sampler uniform, which causes a compilation stall. >>>> Same thing with getUniformBlockIndex. Do make sure that anything that might >>>> query into reflection about the program (e.g. getVertexAttributeIndex, >>>> getUniformLocation, getUniformBlockIndex) happens after >>>> COMPLETION_STATUS_KHR returns true, since that?s another way to >>>> accidentally stall on compilation completing. >>>> >>>> >>>> >>>> >>>> >>>> *From:* owners-public_webgl...@ < >>>> owners-public_webgl...@> *On Behalf Of *Kai Ninomiya ( >>>> kainino...@) >>>> >>>> *Sent:* Friday, April 12, 2019 10:25 AM >>>> >>>> *To:* Public WebGL >>>> >>>> *Subject:* Re: [Public WebGL] Propose promoting >>>> KHR_parallel_shader_compile to community approved >>>> >>>> >>>> >>>> >>>> >>>> IIRC, all 3 of those functions still force a wait for the {shader to >>>> finish compiling, program to finish linking} just as they did before. The >>>> new semantics are only visible via the new COMPLETION_STATUS_KHR check. >>>> >>>> >>>> >>>> On Fri, Apr 12, 2019 at 10:05 AM Tarek Sherif (tsherif...@) < >>>> public_webgl...@> wrote: >>>> >>>> Very excited about this extension, but I'm concerned about how it would >>>> work in our use case. Our flagship visualization library, deck.gl >>>> , >>>> often shares the gl context with a separate base map rendering application >>>> so that it can properly interleave visualization layers with the base map. >>>> Enabling this extension seems to change the behaviour of existing WebGL >>>> functions in a way that I don't believe other extensions do. My worry is >>>> how our enabling KHR_parallel_shader_compile would affect applications we >>>> share contexts with, i.e what happens if the typical synchronous >>>> compilation logic is used after KHR_parallel_shader_compile is enabled? >>>> Specifically: >>>> >>>> - What happens if getShaderParameter(shader, COMPILE_STATUS) is >>>> called before compilation is complete? >>>> - What happens if getProgramParameter(program, LINK_STATUS) is >>>> called before linking is complete? >>>> - What happens if useProgram is called before linking is complete? >>>> >>>> Thanks, >>>> >>>> >>>> >>>> >>>> >>>> Tarek Sherif >>>> >>>> Senior Software Engineer, Visualization | Uber >>>> >>>> http://vis.gl/ >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> *Tarek Sherif* >>>> >>>> Senior Software Engineer, Visualization | Uber >>>> >>>> http://vis.gl/ >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Apr 12, 2019 at 12:16 PM David Catuhe ( >>>> David.Catuhe...@) wrote: >>>> >>>> Wonderful! >>>> >>>> >>>> >>>> >>>> >>>> *From:* owners-public_webgl...@ < >>>> owners-public_webgl...@> *On Behalf Of *Ken Russell ( >>>> kbr...@) >>>> >>>> *Sent:* Wednesday, April 10, 2019 2:56 PM >>>> >>>> *To:* Public WebGL >>>> >>>> *Subject:* Re: [Public WebGL] Propose promoting >>>> KHR_parallel_shader_compile to community approved >>>> >>>> >>>> >>>> >>>> >>>> If your code works correctly now when enabling draft WebGL extensions >>>> in Chrome, then no changes are needed. There won't be any changes to the >>>> extension when it's taken out of draft status; it'll just be available by >>>> default. >>>> >>>> >>>> >>>> -Ken >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Apr 10, 2019 at 12:36 PM David Catuhe ( >>>> David.Catuhe...@) wrote: >>>> >>>> We do have support for the extension in Babylon.js. How can we test >>>> this change? >>>> ------------------------------ >>>> >>>> >>>> >>>> *From:* owners-public_webgl...@ < >>>> owners-public_webgl...@> on behalf of Ken Russell ( >>>> kbr...@) >>>> *Sent:* Wednesday, April 10, 2019 12:00:25 PM >>>> *To:* public >>>> *Subject:* [Public WebGL] Propose promoting >>>> KHR_parallel_shader_compile to community approved >>>> >>>> >>>> >>>> WebGL community, >>>> >>>> >>>> >>>> Jie Chen from Intel has principally developed and implemented a WebGL >>>> wrapper for the KHR_parallel_shader_compile extension. This allows shader >>>> compilation and program linking to occur fully in parallel to the rest of >>>> the WebGL application. Some small application changes are needed to take >>>> full advantage of the extension, but it is otherwise fully backward >>>> compatible. Jie has even emulated this extension on platforms which don't >>>> support it natively. >>>> >>>> >>>> >>>> This extension solves a longstanding user complaint with WebGL, namely >>>> long shader compile times on Windows. Compiles and links occur not only >>>> asynchronously, but also in parallel, so there is a net speedup when using >>>> this extension. Users who have tried out the draft extension are pleased >>>> with the results and would like to see it made widely available. >>>> >>>> >>>> >>>> I propose promoting this extension to community approved in >>>> https://github.com/KhronosGroup/WebGL/pull/2855 >>>> >>>> . Any comments? >>>> >>>> >>>> >>>> -Ken >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> [image: >>>> https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png] >>>> >>>> >>>> Virus-free. www.avg.com >>>> >>>> >>>> >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 82548 bytes Desc: not available URL: From pub...@ Fri May 10 15:58:28 2019 From: pub...@ (Takahiro Aoyagi (...@...)) Date: Sat, 11 May 2019 07:58:28 +0900 Subject: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved In-Reply-To: References: Message-ID: I'm very glad this extension moves forward. Question. Can compiling+linking a program block another program's gl.get*() or gl.useProgram()? Even after confirming compile+link completion of a program with COMPLETION_STATUS_KHR, gl.getProgramParameter() or gl.useProgram() seems being blocked if another program is being compiled+linked on my Windows Canary. Is this intentional or bug? https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime8.html https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime9.html // Confirm program compile+link completion if(gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR)) { // Compile and link another program const vertexShader2 = gl.createShader(gl.VERTEX_SHADER); const fragmentShader2 = gl.createShader(gl.FRAGMENT_SHADER); const program2 = gl.createProgram(); gl.shaderSource(vertexShader2, vertexShaderCode); gl.shaderSource(fragmentShader2, fragmentShaderCode); gl.compileShader(vertexShader2); gl.compileShader(fragmentShader2); gl.attachShader(program2, vertexShader2); gl.attachShader(program2, fragmentShader2); gl.linkProgram(program2); // gl.get*() or gl.useProgram() while the other program is being compiled+linkied const startTime = performance.now(); gl.getProgramParameter(program, gl.ACTIVE_ATTRIBUTES); // or gl.useProgram(program); const endTime = performance.now(); } Takahiro Virus-free. www.avg.com <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Sat, May 11, 2019 at 6:11 AM Ken Russell (kbr...@) < public_webgl...@> wrote: > Since there haven't been any *objections* to moving this extension > forward, and since the benefits are now being seen, it's been moved to > community approved in https://github.com/KhronosGroup/WebGL/pull/2855 . > > Please, feel free to continue to report problems with long shader > compilation times - either posting here on this mailing list or on > webgl-dev-list, reporting cross-browser issues on > https://github.com/KhronosGroup/WebGL/issues , or on individual browsers' > bug trackers. > > -Ken > > > > *From: *Ken Russell > *Date: *Fri, May 10, 2019 at 1:39 PM > *To: *Public WebGL > > Super. Thank you Takahiro for testing and confirming! >> >> >> *From: *Takahiro Aoyagi (taoyagi...@) >> *Date: *Fri, May 10, 2019 at 10:51 AM >> *To: *Public WebGL >> >> I made simple tests to check the CPU elapsed time of >>> gl.getProgramParameter() and gl.useProgram() after checking >>> COMPLETION_STATUS_KHR is true. Both are fast here on my Windows10 Chrome >>> Canary. >>> >>> >>> >>> >>> https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime6.html >>> >>> https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime7.html >>> >>> Takahiro >>> >>> >>> Virus-free. >>> www.avg.com >>> >>> <#m_4832722445558905857_m_-1563479101302147647_m_-3047211929259580689_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >>> >>> On Sat, May 11, 2019 at 2:46 AM Ken Russell (kbr...@) < >>> public_webgl...@> wrote: >>> >>>> Hmm. The only reason I can think of that that would happen is if you're >>>> running on Windows, and ANGLE has to dynamically recompile the program >>>> behind the scenes in order to handle some OpenGL ES state change. I'm not >>>> 100% sure which changes require this dynamic recompilation; the ANGLE >>>> developers would know best. >>>> https://groups.google.com//forum/#!forum/angleproject might be helpful. >>>> >>>> We'd really need some test case to make progress on this. Can you >>>> provide one? >>>> >>>> -Ken >>>> >>>> >>>> On Fri, May 10, 2019 at 10:28 AM Jasper St. Pierre ( >>>> jstpierre...@) wrote: >>>> >>>>> Hello again. My app is now showing that getProgramParameter is >>>>> completing quick, but it is spending a lot of time in useProgram. I am >>>>> checking for COMPLETION_STATUS_KHR on the GL program beforehand and it is >>>>> returning true. I?m guessing there?s some additional expensive work that >>>>> still needs to happen at useProgram time. Is this a bug? Any ways to debug >>>>> or avoid this? I?m unsure if there will be an easy repro. >>>>> >>>>> >>>>> >>>>> Again, profiler screenshot attached. >>>>> >>>>> >>>>> >>>>> *From:* owners-public_webgl...@ < >>>>> owners-public_webgl...@> *On Behalf Of *Takahiro Aoyagi ( >>>>> taoyagi...@) >>>>> *Sent:* Friday, May 10, 2019 12:22 AM >>>>> *To:* Public WebGL >>>>> *Subject:* Re: [Public WebGL] Propose promoting >>>>> KHR_parallel_shader_compile to community approved >>>>> >>>>> >>>>> >>>>> Confirmed COMPLETION_STATUS_KHR is very fast like 0.01ms on my test >>>>> >>>>> >>>>> https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html >>>>> >>>>> >>>>> >>>>> Nice work! >>>>> >>>>> >>>>> >>>>> Thanks >>>>> >>>>> >>>>> >>>>> [image: >>>>> https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png] >>>>> >>>>> >>>>> Virus-free. www.avg.com >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, May 8, 2019 at 2:41 PM Ken Russell (kbr...@) < >>>>> public_webgl...@> wrote: >>>>> >>>>> Jie Chen from Intel just landed a fix in Chrome dramatically improving >>>>> the performance of querying COMPLETION_STATUS_KHR under >>>>> http://crbug.com/881152 . The fix will be in tomorrow's Canary on >>>>> Windows and macOS. >>>>> >>>>> >>>>> >>>>> This should address the last major gap with this extension. We would >>>>> like to enable it by default by promoting it to community approved; any >>>>> further comments? >>>>> >>>>> >>>>> >>>>> -Ken >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From: *Ken Russell >>>>> *Date: *Fri, Apr 26, 2019 at 3:40 PM >>>>> *To: *Public WebGL >>>>> >>>>> Thanks for the report and the clear test case. There was an existing >>>>> bug about this, so the new one was duplicated into it, and some hints about >>>>> implementing it were added to the preexisting bug. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, Apr 26, 2019 at 5:56 AM Takahiro Aoyagi (taoyagi...@) >>>>> wrote: >>>>> >>>>> Hi Chen, >>>>> >>>>> >>>>> >>>>> Opened a bug. Thanks. >>>>> >>>>> >>>>> >>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=957001 >>>>> >>>>> >>>>> >>>>> Takahiro >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, Apr 26, 2019 at 8:03 PM Chen, Jie A (jie.a.chen...@) < >>>>> public_webgl...@> wrote: >>>>> >>>>> Hi Takahiro, >>>>> >>>>> The current implementation of COMPLETION_STATUS_KHR query in >>>>> chromium incurs an expensive round-trip to the GPU thread. This may >>>>> contribute to the wait time in your case. I am trying to optimize this. >>>>> Could you please file a bug to chromium? I would look into it once I?ve >>>>> done the optimization. >>>>> >>>>> >>>>> >>>>> *From:* owners-public_webgl...@ [mailto: >>>>> owners-public_webgl...@] *On Behalf Of *Takahiro Aoyagi ( >>>>> taoyagi...@) >>>>> *Sent:* Friday, April 26, 2019 6:20 PM >>>>> *To:* Public WebGL >>>>> *Subject:* Re: [Public WebGL] Propose promoting >>>>> KHR_parallel_shader_compile to community approved >>>>> >>>>> >>>>> >>>>> Hi all, >>>>> >>>>> >>>>> >>>>> I'm working on Three.js + KHR_parallel_shader_compile extension >>>>> support with Fernando. >>>>> >>>>> >>>>> >>>>> https://github.com/mrdoob/three.js/issues/16321#issuecomment-486436086 >>>>> >>>>> >>>>> >>>>> I'm testing with Canary. But the behavior seems weird to me. >>>>> gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) seems to wait >>>>> for compile+link completion. I don't think it should wait for that, it >>>>> should just do polling and returning true/false quickly instead. >>>>> >>>>> >>>>> >>>>> I made a simple test to reproduce. >>>>> >>>>> >>>>> >>>>> >>>>> https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html >>>>> >>>>> >>>>> >>>>> Code snippet. >>>>> >>>>> >>>>> >>>>> const ext = gl.getExtension('KHR_parallel_shader_compile'); >>>>> >>>>> >>>>> >>>>> gl.compileShader(vertexShader); >>>>> gl.compileShader(fragmentShader); >>>>> gl.attachShader(program, vertexShader); >>>>> gl.attachShader(program, fragmentShader); >>>>> gl.linkProgram(program); >>>>> >>>>> const startTime = performance.now(); >>>>> const status = useExtension >>>>> ? gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) >>>>> : gl.getProgramParameter(program, gl.LINK_STATUS); >>>>> const endTime = performance.now(); >>>>> >>>>> const elapsedTime = endTime - startTime; >>>>> >>>>> >>>>> >>>>> On my platform, both gl.LINK_STATUS and ext.COMPLETION_STATUS_KHR take >>>>> so long time about 15ms. I can accept this number for gl.LINK_STATUS >>>>> because it waits for compile+link completion. But 15ms for >>>>> ext.COMPLETION_STATUS_KHR looks weird to me. It shouldn't wait for the >>>>> compile+link completion but should do just polling and quickly returning >>>>> true/false instead. So I guess the number should be 1ms or less. >>>>> >>>>> >>>>> >>>>> Let me know if I'm missing something. Or could it be a Canary bug? >>>>> >>>>> >>>>> >>>>> My platform. >>>>> >>>>> >>>>> >>>>> OS: Windows10 >>>>> >>>>> Browser: Chrome Canary. >>>>> >>>>> Browser boot option: --use-cmd-decoder=passthrough >>>>> --enable-webgl-draft-extensions >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Thanks >>>>> >>>>> >>>>> >>>>> Takahiro >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, Apr 26, 2019 at 10:15 AM Chen, Jie A (jie.a.chen...@) < >>>>> public_webgl...@> wrote: >>>>> >>>>> Basically, for ANGLE?s GL backend, it?s simply a wrapper for the >>>>> existing GL implementations. In this sense glCompileShader() is still >>>>> implementation specific. Essentially ANGLE just calls glCompileShader and >>>>> check GL_COMPILE_STATUS. >>>>> >>>>> >>>>> >>>>> *From:* owners-public_webgl...@ [mailto: >>>>> owners-public_webgl...@] *On Behalf Of *Jasper St. Pierre ( >>>>> jstpierre...@) >>>>> *Sent:* Friday, April 26, 2019 1:18 AM >>>>> *To:* Public WebGL >>>>> *Subject:* RE: [Public WebGL] Propose promoting >>>>> KHR_parallel_shader_compile to community approved >>>>> >>>>> >>>>> >>>>> Thank you, that?s important information to know. Changing my shader >>>>> compilation pipeline to wait for shader completion status is a lot more >>>>> difficult, but based on some initial tests, it?s more expensive than not >>>>> doing it ? the latency of getShaderParameter is too high. >>>>> >>>>> >>>>> >>>>> That said, in a lot of GL implementations, glCompileShader() is >>>>> practically a no-op, and will only do an AST parse when >>>>> glGetShaderParameter/InfoLog() is called (which is basically only for >>>>> debugging / error checking). glLinkProgram() does full compilation of all >>>>> programs, as full-PSO optimization is important. I don?t know how common >>>>> this is, but multiple GL implementations I have seen do it. It might make >>>>> sense for ANGLE to adopt this model as well. >>>>> >>>>> >>>>> >>>>> *From:* owners-public_webgl...@ < >>>>> owners-public_webgl...@> *On Behalf Of *Chen, Jie A ( >>>>> jie.a.chen...@) >>>>> *Sent:* Wednesday, April 24, 2019 6:48 PM >>>>> *To:* Public WebGL >>>>> *Subject:* RE: [Public WebGL] Propose promoting >>>>> KHR_parallel_shader_compile to community approved >>>>> >>>>> >>>>> >>>>> Absolutely. Ideally there would be no stall for linkProgram. I tried, >>>>> but it?s too difficult to achieve this in ANGLE. >>>>> >>>>> >>>>> >>>>> *From:* owners-public_webgl...@ [ >>>>> mailto:owners-public_webgl...@ >>>>> ] *On Behalf Of *Jeff Gilbert ( >>>>> jgilbert...@) >>>>> *Sent:* Thursday, April 25, 2019 9:33 AM >>>>> *To:* Public WebGL >>>>> *Subject:* Re: [Public WebGL] Propose promoting >>>>> KHR_parallel_shader_compile to community approved >>>>> >>>>> >>>>> >>>>> Possibly, but in the long run, I expect implementations to support >>>>> no-stall linkProgram invocations. >>>>> >>>>> >>>>> >>>>> On Wed, Apr 24, 2019 at 6:27 PM Chen, Jie A (jie.a.chen...@) < >>>>> public_webgl...@> wrote: >>>>> >>>>> linkProgram may stall on compileShader. To avoid the stall, you?d >>>>> better make sure the COMPLETION_STATUS_KHR statuses of the attached shaders >>>>> are all True before calling linkProgram. In this sense, the first workflow >>>>> has less chance running into stall. >>>>> >>>>> >>>>> >>>>> *From:* owners-public_webgl...@ [mailto: >>>>> owners-public_webgl...@] *On Behalf Of *Fernando Serrano >>>>> Garc?a (fserrano...@) >>>>> *Sent:* Wednesday, April 24, 2019 9:38 PM >>>>> *To:* Public WebGL >>>>> *Subject:* Re: [Public WebGL] Propose promoting >>>>> KHR_parallel_shader_compile to community approved >>>>> >>>>> >>>>> >>>>> Regarding the optimal proposed workflow (grouping shaders and programs >>>>> separately) of: >>>>> >>>>> for (const x of shaders) >>>>> gl.compileShader(x); >>>>> for (const x of programs) >>>>> gl.linkProgram(x); >>>>> >>>>> >>>>> >>>>> versus something more on the way that we currently have in many >>>>> engines as threejs: >>>>> >>>>> for (const x of material) >>>>> >>>>> gl.compileShader(fs); >>>>> >>>>> gl.compileShader(vs); >>>>> gl.linkProgram(x); >>>>> >>>>> >>>>> >>>>> Do you think is more or less accurate the following graph for 4 >>>>> materials and enabling this extension with 2 and 4 parallel threads? >>>>> >>>>> >>>>> >>>>> [image: Screen Shot 2019-04-24 at 15.35.47.png] >>>>> >>>>> >>>>> >>>>> On Wed, Apr 24, 2019 at 2:40 PM Fernando Serrano Garc?a < >>>>> fserrano...@> wrote: >>>>> >>>>> fwiw three.js introduced a "debug" parameter (false by default) to >>>>> determine if there will be a status check and call all the get* (currently >>>>> in dev): >>>>> >>>>> - >>>>> https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLShader.js#L21-L26 >>>>> >>>>> - >>>>> https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLProgram.js#L608 >>>>> >>>>> >>>>> >>>>> so currently calling `new WebGLShader()` won't be blocking with any >>>>> `get*` function and it could be used as is to compile all of them in a loop >>>>> with or without the extension. >>>>> >>>>> the problem comes from the WebGLProgram as it should just queue itself >>>>> before trying to link any program and wait until all the shader compile >>>>> calls finish, then do all the link, and wait for it asynchronously before >>>>> start using these programs. >>>>> >>>>> I have opened an issue on the three.js repo to keep track of the >>>>> implementation and we have booked some time this week to take a look at it, >>>>> feedback is welcome :) https://github.com/mrdoob/three.js/issues/16321 >>>>> >>>>> >>>>> >>>>> On Tue, Apr 16, 2019 at 11:55 PM Ken Russell (kbr...@) < >>>>> public_webgl...@> wrote: >>>>> >>>>> On Tue, Apr 16, 2019 at 2:24 PM Tarek Sherif (tsherif...@) < >>>>> public_webgl...@> wrote: >>>>> >>>>> Yes, I've read both specs. I think this language in the WebGL version >>>>> is confusing: "When this extension is enabled: Shader compilation and >>>>> program linking may be performed in a separate CPU thread." And neither >>>>> indicates which functions are expected to cause stalls. As written, this >>>>> extension requires more than most that people know implementation details. >>>>> >>>>> >>>>> >>>>> All previous operations against the program - looking up uniform >>>>> locations, drawing with it, etc. - will cause stalls. The application >>>>> *must* be updated to query the program's COMPLETION_STATUS_KHR status, and >>>>> skip *all* operations against the program until it's no longer pending. >>>>> >>>>> >>>>> >>>>> I guess we'll just change the WebGL version of this extension spec to >>>>> be much more explicit about this. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Essentially, all previous code which checked for the completion of >>>>> compilation of shaders / linking of programs can be updated with a small >>>>> wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. >>>>> >>>>> >>>>> >>>>> This is not true because the most common way this is done will cause >>>>> stalls that sabotage the parallelism, e.g.: >>>>> >>>>> https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLShader.js#L21-L36 >>>>> >>>>> >>>>> https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLProgram.js#L586-L631 >>>>> >>>>> >>>>> >>>>> The check for COMPLETION_STATUS_KHR has to wrap *all* queries and uses >>>>> of the program object, and they must be skipped until COMPLETION_STATUS_KHR >>>>> returns true. Yes, all applications will have to be updated to take >>>>> advantage of this extension, but if they do, the benefits will be >>>>> significant. >>>>> >>>>> >>>>> >>>>> -Ken >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *Tarek Sherif* >>>>> >>>>> Senior Software Engineer, Visualization | Uber >>>>> >>>>> http://vis.gl/ >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, Apr 16, 2019 at 4:18 PM Ken Russell (kbr...@) < >>>>> public_webgl...@> wrote: >>>>> >>>>> Please review the Overview in the underlying OpenGL ES spec: >>>>> >>>>> >>>>> https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt >>>>> >>>>> >>>>> >>>>> >>>>> It describes that the extension uses one or more separate CPU threads >>>>> for shader compilation. If you still think we should rewrite the >>>>> introduction to the WebGL extension, we can do that too. >>>>> >>>>> >>>>> >>>>> Essentially, all previous code which checked for the completion of >>>>> compilation of shaders / linking of programs can be updated with a small >>>>> wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. >>>>> >>>>> >>>>> >>>>> -Ken >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, Apr 16, 2019 at 1:36 AM Tarek Sherif (tsherif...@) < >>>>> public_webgl...@> wrote: >>>>> >>>>> This is all extremely interesting, and documentation of these best >>>>> practices should probably be more publicly available (perhaps through a >>>>> non-normative note in the spec). I'm thinking the language in the extension >>>>> spec could be made more clear about what it's actual purpose is. It >>>>> currently gives the impression that enabling it is what allows for parallel >>>>> compilation and that this should save time, but given what Jeff and Kai >>>>> have said, it sounds like the purpose is to avoid CPU stalls, and that it >>>>> might even take longer in wall time since you're only checking once a >>>>> frame. Maybe some background information could be added along the lines of >>>>> "Normally applications must wait on get*Parameter or a draw call for >>>>> program linking to complete, this extension provides a mechanism for >>>>> querying completion status without stalling..." >>>>> >>>>> >>>>> >>>>> *Tarek Sherif* >>>>> >>>>> Senior Software Engineer, Visualization | Uber >>>>> >>>>> http://vis.gl/ >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Mon, Apr 15, 2019 at 11:23 PM Kai Ninomiya (kainino...@) < >>>>> public_webgl...@> wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Mon, Apr 15, 2019 at 7:18 PM Tarek Sherif (tareksherif...@) < >>>>> public_webgl...@> wrote: >>>>> >>>>> I don't see anything in the OpenGL extension spec about what functions >>>>> cause stalls. Is that implementation-specific? Having an idea what to >>>>> expect is important for two reasons: >>>>> >>>>> 1. To make it clear that drawing will still work if >>>>> getProgramParameter(COMPLETION_STATUS_KHR) hasn't returned true yet >>>>> (i.e. the stall on a draw call) >>>>> >>>>> >>>>> >>>>> Generally, OpenGL extensions are not allowed to break existing >>>>> API/existing content. (In OpenGL, all extensions are always enabled; >>>>> there's no requestExtension.) Hence, even if you enable the extension, it >>>>> won't change the way your application works, and therefore the draw call >>>>> must still cause a stall in order to be able to use the program. >>>>> >>>>> >>>>> >>>>> 2. Almost all WebGL code I've looked at handles compilation in a way >>>>> similar to the following: >>>>> >>>>> gl.compileShader(vertexShader); >>>>> if (!gl.getShaderParameter(vertexShader, gl.COMPILE_STATUS)) //... >>>>> >>>>> gl.compileShader(fragmentShader); >>>>> >>>>> if (!gl.getShaderParameter(fragmentShader, gl.COMPILE_STATUS)) >>>>> //... >>>>> >>>>> //... >>>>> >>>>> gl.linkProgram(program); >>>>> if (!gl.getProgramParameter(program, gl.LINK_STATUS)) //... >>>>> >>>>> I think it would be worth it to make clear that this pattern would >>>>> sabotage the parallel compile. >>>>> >>>>> >>>>> >>>>> I seem to remember (not sure if this is still true) that this pattern >>>>> also sabotages the shader compiler cache in ANGLE, because ANGLE doesn't >>>>> cache the COMPILE_STATUS (or was it the compile info string?). So it forces >>>>> the compiler to recompile just to give you the status. >>>>> >>>>> >>>>> >>>>> Tarek Sherif >>>>> >>>>> http://tareksherif.net/ >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ??????? Original Message ??????? >>>>> >>>>> On Monday, April 15, 2019 9:00 PM, Ken Russell (kbr...@) < >>>>> public_webgl...@> wrote: >>>>> >>>>> >>>>> >>>>> The WebGL extension (which is basically just a wrapper) refers to the >>>>> underlying OpenGL / OpenGL ES extension >>>>> https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt >>>>> , >>>>> where this is documented. Is that sufficient? It would be better to avoid >>>>> duplicating a large amount of spec text from the underlying extension. >>>>> However, we can add some non-normative text if that would help. >>>>> >>>>> >>>>> >>>>> -Ken >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Sat, Apr 13, 2019 at 3:51 AM Tarek Sherif (tareksherif...@) < >>>>> public_webgl...@> wrote: >>>>> >>>>> IIRC, all 3 of those functions still force a wait for the {shader to >>>>> finish compiling, program to finish linking} just as they did before. The >>>>> new semantics are only visible via the new COMPLETION_STATUS_KHR check. >>>>> >>>>> That should work perfectly for us. Can we add some language to the >>>>> spec about which functions cause stalls? I feel like as written, it will be >>>>> easy for people to use the extension incorrectly. >>>>> >>>>> >>>>> >>>>> Tarek Sherif >>>>> >>>>> http://tareksherif.net/ >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ??????? Original Message ??????? >>>>> >>>>> On Friday, April 12, 2019 4:10 PM, Kai Ninomiya (kainino...@) < >>>>> public_webgl...@> wrote: >>>>> >>>>> >>>>> >>>>> Oh yes, useProgram probably won't stall. But getUniformLocation and >>>>> the others will stall, as will draw calls. >>>>> >>>>> >>>>> >>>>> getProgramParameter(COMPLETION_STATUS_KHR) should get faster at some >>>>> point; see http://crbug.com/881152 >>>>> which >>>>> Ken linked. >>>>> >>>>> >>>>> >>>>> On Fri, Apr 12, 2019 at 12:39 PM Jasper St. Pierre ( >>>>> jstpierre...@) wrote: >>>>> >>>>> Thank you! Trying this out in my own WebGL 2 app, I see quite a >>>>> reduction in shader compilation time, shaving 400ms on load time on a >>>>> moderately complex scene. The getProgramParameter(COMPLETION_STATUS_KHR) >>>>> query still takes 1ms (which I believe is being tracked), but that is still >>>>> better from the 4ms I see in getUniformBlockIndex (my previous sync point). >>>>> >>>>> >>>>> >>>>> AFAIK, useProgram should not cause a stall, but in order to set my >>>>> texture samplers to bind to different units, I need to do a >>>>> getUniformLocation on my sampler uniform, which causes a compilation stall. >>>>> Same thing with getUniformBlockIndex. Do make sure that anything that might >>>>> query into reflection about the program (e.g. getVertexAttributeIndex, >>>>> getUniformLocation, getUniformBlockIndex) happens after >>>>> COMPLETION_STATUS_KHR returns true, since that?s another way to >>>>> accidentally stall on compilation completing. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From:* owners-public_webgl...@ < >>>>> owners-public_webgl...@> *On Behalf Of *Kai Ninomiya ( >>>>> kainino...@) >>>>> >>>>> *Sent:* Friday, April 12, 2019 10:25 AM >>>>> >>>>> *To:* Public WebGL >>>>> >>>>> *Subject:* Re: [Public WebGL] Propose promoting >>>>> KHR_parallel_shader_compile to community approved >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> IIRC, all 3 of those functions still force a wait for the {shader to >>>>> finish compiling, program to finish linking} just as they did before. The >>>>> new semantics are only visible via the new COMPLETION_STATUS_KHR check. >>>>> >>>>> >>>>> >>>>> On Fri, Apr 12, 2019 at 10:05 AM Tarek Sherif (tsherif...@) < >>>>> public_webgl...@> wrote: >>>>> >>>>> Very excited about this extension, but I'm concerned about how it >>>>> would work in our use case. Our flagship visualization library, >>>>> deck.gl >>>>> , >>>>> often shares the gl context with a separate base map rendering application >>>>> so that it can properly interleave visualization layers with the base map. >>>>> Enabling this extension seems to change the behaviour of existing WebGL >>>>> functions in a way that I don't believe other extensions do. My worry is >>>>> how our enabling KHR_parallel_shader_compile would affect applications we >>>>> share contexts with, i.e what happens if the typical synchronous >>>>> compilation logic is used after KHR_parallel_shader_compile is enabled? >>>>> Specifically: >>>>> >>>>> - What happens if getShaderParameter(shader, COMPILE_STATUS) is >>>>> called before compilation is complete? >>>>> - What happens if getProgramParameter(program, LINK_STATUS) is >>>>> called before linking is complete? >>>>> - What happens if useProgram is called before linking is complete? >>>>> >>>>> Thanks, >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Tarek Sherif >>>>> >>>>> Senior Software Engineer, Visualization | Uber >>>>> >>>>> http://vis.gl/ >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *Tarek Sherif* >>>>> >>>>> Senior Software Engineer, Visualization | Uber >>>>> >>>>> http://vis.gl/ >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, Apr 12, 2019 at 12:16 PM David Catuhe ( >>>>> David.Catuhe...@) wrote: >>>>> >>>>> Wonderful! >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From:* owners-public_webgl...@ < >>>>> owners-public_webgl...@> *On Behalf Of *Ken Russell ( >>>>> kbr...@) >>>>> >>>>> *Sent:* Wednesday, April 10, 2019 2:56 PM >>>>> >>>>> *To:* Public WebGL >>>>> >>>>> *Subject:* Re: [Public WebGL] Propose promoting >>>>> KHR_parallel_shader_compile to community approved >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> If your code works correctly now when enabling draft WebGL extensions >>>>> in Chrome, then no changes are needed. There won't be any changes to the >>>>> extension when it's taken out of draft status; it'll just be available by >>>>> default. >>>>> >>>>> >>>>> >>>>> -Ken >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Apr 10, 2019 at 12:36 PM David Catuhe ( >>>>> David.Catuhe...@) wrote: >>>>> >>>>> We do have support for the extension in Babylon.js. How can we test >>>>> this change? >>>>> ------------------------------ >>>>> >>>>> >>>>> >>>>> *From:* owners-public_webgl...@ < >>>>> owners-public_webgl...@> on behalf of Ken Russell ( >>>>> kbr...@) >>>>> *Sent:* Wednesday, April 10, 2019 12:00:25 PM >>>>> *To:* public >>>>> *Subject:* [Public WebGL] Propose promoting >>>>> KHR_parallel_shader_compile to community approved >>>>> >>>>> >>>>> >>>>> WebGL community, >>>>> >>>>> >>>>> >>>>> Jie Chen from Intel has principally developed and implemented a WebGL >>>>> wrapper for the KHR_parallel_shader_compile extension. This allows shader >>>>> compilation and program linking to occur fully in parallel to the rest of >>>>> the WebGL application. Some small application changes are needed to take >>>>> full advantage of the extension, but it is otherwise fully backward >>>>> compatible. Jie has even emulated this extension on platforms which don't >>>>> support it natively. >>>>> >>>>> >>>>> >>>>> This extension solves a longstanding user complaint with WebGL, namely >>>>> long shader compile times on Windows. Compiles and links occur not only >>>>> asynchronously, but also in parallel, so there is a net speedup when using >>>>> this extension. Users who have tried out the draft extension are pleased >>>>> with the results and would like to see it made widely available. >>>>> >>>>> >>>>> >>>>> I propose promoting this extension to community approved in >>>>> https://github.com/KhronosGroup/WebGL/pull/2855 >>>>> >>>>> . Any comments? >>>>> >>>>> >>>>> >>>>> -Ken >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> [image: >>>>> https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png] >>>>> >>>>> >>>>> Virus-free. www.avg.com >>>>> >>>>> >>>>> >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 82548 bytes Desc: not available URL: From pub...@ Fri May 10 20:42:43 2019 From: pub...@ (Chen, Jie A (...@...)) Date: Sat, 11 May 2019 03:42:43 +0000 Subject: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved In-Reply-To: References: Message-ID: <5F447A42ADFAFD499D69CF330DF2E5C160660987@SHSMSX101.ccr.corp.intel.com> Interesting question, Takahiro. My speculation is that the problem might be relevant to chrome?s multi-process architecture. As you may know, the WebGL calls run in the main thread of render process. Chrome needs to send these WebGL commands to the GPU process for actual execution. So in your case, what Chrome actually does for calls of makeProgram2 is simply putting the GL commands into a IPC buffer. But later when you retrieve a program parameter back, it then waits for the execution of all previously issued GL commands including makeProgram2. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Takahiro Aoyagi (taoyagi...@) Sent: Saturday, May 11, 2019 6:58 AM To: Public WebGL Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved I'm very glad this extension moves forward. Question. Can compiling+linking a program block another program's gl.get*() or gl.useProgram()? Even after confirming compile+link completion of a program with COMPLETION_STATUS_KHR, gl.getProgramParameter() or gl.useProgram() seems being blocked if another program is being compiled+linked on my Windows Canary. Is this intentional or bug? https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime8.html https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime9.html // Confirm program compile+link completion if(gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR)) { // Compile and link another program const vertexShader2 = gl.createShader(gl.VERTEX_SHADER); const fragmentShader2 = gl.createShader(gl.FRAGMENT_SHADER); const program2 = gl.createProgram(); gl.shaderSource(vertexShader2, vertexShaderCode); gl.shaderSource(fragmentShader2, fragmentShaderCode); gl.compileShader(vertexShader2); gl.compileShader(fragmentShader2); gl.attachShader(program2, vertexShader2); gl.attachShader(program2, fragmentShader2); gl.linkProgram(program2); // gl.get*() or gl.useProgram() while the other program is being compiled+linkied const startTime = performance.now(); gl.getProgramParameter(program, gl.ACTIVE_ATTRIBUTES); // or gl.useProgram(program); const endTime = performance.now(); } Takahiro [https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png] Virus-free. www.avg.com On Sat, May 11, 2019 at 6:11 AM Ken Russell (kbr...@) > wrote: Since there haven't been any *objections* to moving this extension forward, and since the benefits are now being seen, it's been moved to community approved in https://github.com/KhronosGroup/WebGL/pull/2855 . Please, feel free to continue to report problems with long shader compilation times - either posting here on this mailing list or on webgl-dev-list, reporting cross-browser issues on https://github.com/KhronosGroup/WebGL/issues , or on individual browsers' bug trackers. -Ken From: Ken Russell > Date: Fri, May 10, 2019 at 1:39 PM To: Public WebGL Super. Thank you Takahiro for testing and confirming! From: Takahiro Aoyagi (taoyagi...@) > Date: Fri, May 10, 2019 at 10:51 AM To: Public WebGL I made simple tests to check the CPU elapsed time of gl.getProgramParameter() and gl.useProgram() after checking COMPLETION_STATUS_KHR is true. Both are fast here on my Windows10 Chrome Canary. https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime6.html https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime7.html Takahiro [https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png] Virus-free. www.avg.com On Sat, May 11, 2019 at 2:46 AM Ken Russell (kbr...@) > wrote: Hmm. The only reason I can think of that that would happen is if you're running on Windows, and ANGLE has to dynamically recompile the program behind the scenes in order to handle some OpenGL ES state change. I'm not 100% sure which changes require this dynamic recompilation; the ANGLE developers would know best. https://groups.google.com//forum/#!forum/angleproject might be helpful. We'd really need some test case to make progress on this. Can you provide one? -Ken On Fri, May 10, 2019 at 10:28 AM Jasper St. Pierre (jstpierre...@) > wrote: Hello again. My app is now showing that getProgramParameter is completing quick, but it is spending a lot of time in useProgram. I am checking for COMPLETION_STATUS_KHR on the GL program beforehand and it is returning true. I?m guessing there?s some additional expensive work that still needs to happen at useProgram time. Is this a bug? Any ways to debug or avoid this? I?m unsure if there will be an easy repro. Again, profiler screenshot attached. From: owners-public_webgl...@ > On Behalf Of Takahiro Aoyagi (taoyagi...@) Sent: Friday, May 10, 2019 12:22 AM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Confirmed COMPLETION_STATUS_KHR is very fast like 0.01ms on my test https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html Nice work! Thanks [https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png] Virus-free. www.avg.com On Wed, May 8, 2019 at 2:41 PM Ken Russell (kbr...@) > wrote: Jie Chen from Intel just landed a fix in Chrome dramatically improving the performance of querying COMPLETION_STATUS_KHR under http://crbug.com/881152 . The fix will be in tomorrow's Canary on Windows and macOS. This should address the last major gap with this extension. We would like to enable it by default by promoting it to community approved; any further comments? -Ken From: Ken Russell > Date: Fri, Apr 26, 2019 at 3:40 PM To: Public WebGL Thanks for the report and the clear test case. There was an existing bug about this, so the new one was duplicated into it, and some hints about implementing it were added to the preexisting bug. On Fri, Apr 26, 2019 at 5:56 AM Takahiro Aoyagi (taoyagi...@) > wrote: Hi Chen, Opened a bug. Thanks. https://bugs.chromium.org/p/chromium/issues/detail?id=957001 Takahiro On Fri, Apr 26, 2019 at 8:03 PM Chen, Jie A (jie.a.chen...@) > wrote: Hi Takahiro, The current implementation of COMPLETION_STATUS_KHR query in chromium incurs an expensive round-trip to the GPU thread. This may contribute to the wait time in your case. I am trying to optimize this. Could you please file a bug to chromium? I would look into it once I?ve done the optimization. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Takahiro Aoyagi (taoyagi...@) Sent: Friday, April 26, 2019 6:20 PM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Hi all, I'm working on Three.js + KHR_parallel_shader_compile extension support with Fernando. https://github.com/mrdoob/three.js/issues/16321#issuecomment-486436086 I'm testing with Canary. But the behavior seems weird to me. gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) seems to wait for compile+link completion. I don't think it should wait for that, it should just do polling and returning true/false quickly instead. I made a simple test to reproduce. https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html Code snippet. const ext = gl.getExtension('KHR_parallel_shader_compile'); gl.compileShader(vertexShader); gl.compileShader(fragmentShader); gl.attachShader(program, vertexShader); gl.attachShader(program, fragmentShader); gl.linkProgram(program); const startTime = performance.now(); const status = useExtension ? gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) : gl.getProgramParameter(program, gl.LINK_STATUS); const endTime = performance.now(); const elapsedTime = endTime - startTime; On my platform, both gl.LINK_STATUS and ext.COMPLETION_STATUS_KHR take so long time about 15ms. I can accept this number for gl.LINK_STATUS because it waits for compile+link completion. But 15ms for ext.COMPLETION_STATUS_KHR looks weird to me. It shouldn't wait for the compile+link completion but should do just polling and quickly returning true/false instead. So I guess the number should be 1ms or less. Let me know if I'm missing something. Or could it be a Canary bug? My platform. OS: Windows10 Browser: Chrome Canary. Browser boot option: --use-cmd-decoder=passthrough --enable-webgl-draft-extensions Thanks Takahiro On Fri, Apr 26, 2019 at 10:15 AM Chen, Jie A (jie.a.chen...@) > wrote: Basically, for ANGLE?s GL backend, it?s simply a wrapper for the existing GL implementations. In this sense glCompileShader() is still implementation specific. Essentially ANGLE just calls glCompileShader and check GL_COMPILE_STATUS. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Jasper St. Pierre (jstpierre...@) Sent: Friday, April 26, 2019 1:18 AM To: Public WebGL > Subject: RE: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Thank you, that?s important information to know. Changing my shader compilation pipeline to wait for shader completion status is a lot more difficult, but based on some initial tests, it?s more expensive than not doing it ? the latency of getShaderParameter is too high. That said, in a lot of GL implementations, glCompileShader() is practically a no-op, and will only do an AST parse when glGetShaderParameter/InfoLog() is called (which is basically only for debugging / error checking). glLinkProgram() does full compilation of all programs, as full-PSO optimization is important. I don?t know how common this is, but multiple GL implementations I have seen do it. It might make sense for ANGLE to adopt this model as well. From: owners-public_webgl...@ > On Behalf Of Chen, Jie A (jie.a.chen...@) Sent: Wednesday, April 24, 2019 6:48 PM To: Public WebGL > Subject: RE: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Absolutely. Ideally there would be no stall for linkProgram. I tried, but it?s too difficult to achieve this in ANGLE. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Jeff Gilbert (jgilbert...@) Sent: Thursday, April 25, 2019 9:33 AM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Possibly, but in the long run, I expect implementations to support no-stall linkProgram invocations. On Wed, Apr 24, 2019 at 6:27 PM Chen, Jie A (jie.a.chen...@) > wrote: linkProgram may stall on compileShader. To avoid the stall, you?d better make sure the COMPLETION_STATUS_KHR statuses of the attached shaders are all True before calling linkProgram. In this sense, the first workflow has less chance running into stall. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Fernando Serrano Garc?a (fserrano...@) Sent: Wednesday, April 24, 2019 9:38 PM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Regarding the optimal proposed workflow (grouping shaders and programs separately) of: for (const x of shaders) gl.compileShader(x); for (const x of programs) gl.linkProgram(x); versus something more on the way that we currently have in many engines as threejs: for (const x of material) gl.compileShader(fs); gl.compileShader(vs); gl.linkProgram(x); Do you think is more or less accurate the following graph for 4 materials and enabling this extension with 2 and 4 parallel threads? [Screen Shot 2019-04-24 at 15.35.47.png] On Wed, Apr 24, 2019 at 2:40 PM Fernando Serrano Garc?a > wrote: fwiw three.js introduced a "debug" parameter (false by default) to determine if there will be a status check and call all the get* (currently in dev): - https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLShader.js#L21-L26 - https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLProgram.js#L608 so currently calling `new WebGLShader()` won't be blocking with any `get*` function and it could be used as is to compile all of them in a loop with or without the extension. the problem comes from the WebGLProgram as it should just queue itself before trying to link any program and wait until all the shader compile calls finish, then do all the link, and wait for it asynchronously before start using these programs. I have opened an issue on the three.js repo to keep track of the implementation and we have booked some time this week to take a look at it, feedback is welcome :) https://github.com/mrdoob/three.js/issues/16321 On Tue, Apr 16, 2019 at 11:55 PM Ken Russell (kbr...@) > wrote: On Tue, Apr 16, 2019 at 2:24 PM Tarek Sherif (tsherif...@) > wrote: Yes, I've read both specs. I think this language in the WebGL version is confusing: "When this extension is enabled: Shader compilation and program linking may be performed in a separate CPU thread." And neither indicates which functions are expected to cause stalls. As written, this extension requires more than most that people know implementation details. All previous operations against the program - looking up uniform locations, drawing with it, etc. - will cause stalls. The application *must* be updated to query the program's COMPLETION_STATUS_KHR status, and skip *all* operations against the program until it's no longer pending. I guess we'll just change the WebGL version of this extension spec to be much more explicit about this. Essentially, all previous code which checked for the completion of compilation of shaders / linking of programs can be updated with a small wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. This is not true because the most common way this is done will cause stalls that sabotage the parallelism, e.g.: https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLShader.js#L21-L36 https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLProgram.js#L586-L631 The check for COMPLETION_STATUS_KHR has to wrap *all* queries and uses of the program object, and they must be skipped until COMPLETION_STATUS_KHR returns true. Yes, all applications will have to be updated to take advantage of this extension, but if they do, the benefits will be significant. -Ken Tarek Sherif Senior Software Engineer, Visualization | Uber http://vis.gl/ On Tue, Apr 16, 2019 at 4:18 PM Ken Russell (kbr...@) > wrote: Please review the Overview in the underlying OpenGL ES spec: https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt It describes that the extension uses one or more separate CPU threads for shader compilation. If you still think we should rewrite the introduction to the WebGL extension, we can do that too. Essentially, all previous code which checked for the completion of compilation of shaders / linking of programs can be updated with a small wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. -Ken On Tue, Apr 16, 2019 at 1:36 AM Tarek Sherif (tsherif...@) > wrote: This is all extremely interesting, and documentation of these best practices should probably be more publicly available (perhaps through a non-normative note in the spec). I'm thinking the language in the extension spec could be made more clear about what it's actual purpose is. It currently gives the impression that enabling it is what allows for parallel compilation and that this should save time, but given what Jeff and Kai have said, it sounds like the purpose is to avoid CPU stalls, and that it might even take longer in wall time since you're only checking once a frame. Maybe some background information could be added along the lines of "Normally applications must wait on get*Parameter or a draw call for program linking to complete, this extension provides a mechanism for querying completion status without stalling..." Tarek Sherif Senior Software Engineer, Visualization | Uber http://vis.gl/ On Mon, Apr 15, 2019 at 11:23 PM Kai Ninomiya (kainino...@) > wrote: On Mon, Apr 15, 2019 at 7:18 PM Tarek Sherif (tareksherif...@) > wrote: I don't see anything in the OpenGL extension spec about what functions cause stalls. Is that implementation-specific? Having an idea what to expect is important for two reasons: 1. To make it clear that drawing will still work if getProgramParameter(COMPLETION_STATUS_KHR) hasn't returned true yet (i.e. the stall on a draw call) Generally, OpenGL extensions are not allowed to break existing API/existing content. (In OpenGL, all extensions are always enabled; there's no requestExtension.) Hence, even if you enable the extension, it won't change the way your application works, and therefore the draw call must still cause a stall in order to be able to use the program. 2. Almost all WebGL code I've looked at handles compilation in a way similar to the following: gl.compileShader(vertexShader); if (!gl.getShaderParameter(vertexShader, gl.COMPILE_STATUS)) //... gl.compileShader(fragmentShader); if (!gl.getShaderParameter(fragmentShader, gl.COMPILE_STATUS)) //... //... gl.linkProgram(program); if (!gl.getProgramParameter(program, gl.LINK_STATUS)) //... I think it would be worth it to make clear that this pattern would sabotage the parallel compile. I seem to remember (not sure if this is still true) that this pattern also sabotages the shader compiler cache in ANGLE, because ANGLE doesn't cache the COMPILE_STATUS (or was it the compile info string?). So it forces the compiler to recompile just to give you the status. Tarek Sherif http://tareksherif.net/ ??????? Original Message ??????? On Monday, April 15, 2019 9:00 PM, Ken Russell (kbr...@) > wrote: The WebGL extension (which is basically just a wrapper) refers to the underlying OpenGL / OpenGL ES extension https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt, where this is documented. Is that sufficient? It would be better to avoid duplicating a large amount of spec text from the underlying extension. However, we can add some non-normative text if that would help. -Ken On Sat, Apr 13, 2019 at 3:51 AM Tarek Sherif (tareksherif...@) > wrote: IIRC, all 3 of those functions still force a wait for the {shader to finish compiling, program to finish linking} just as they did before. The new semantics are only visible via the new COMPLETION_STATUS_KHR check. That should work perfectly for us. Can we add some language to the spec about which functions cause stalls? I feel like as written, it will be easy for people to use the extension incorrectly. Tarek Sherif http://tareksherif.net/ ??????? Original Message ??????? On Friday, April 12, 2019 4:10 PM, Kai Ninomiya (kainino...@) > wrote: Oh yes, useProgram probably won't stall. But getUniformLocation and the others will stall, as will draw calls. getProgramParameter(COMPLETION_STATUS_KHR) should get faster at some point; see http://crbug.com/881152 which Ken linked. On Fri, Apr 12, 2019 at 12:39 PM Jasper St. Pierre (jstpierre...@) > wrote: Thank you! Trying this out in my own WebGL 2 app, I see quite a reduction in shader compilation time, shaving 400ms on load time on a moderately complex scene. The getProgramParameter(COMPLETION_STATUS_KHR) query still takes 1ms (which I believe is being tracked), but that is still better from the 4ms I see in getUniformBlockIndex (my previous sync point). AFAIK, useProgram should not cause a stall, but in order to set my texture samplers to bind to different units, I need to do a getUniformLocation on my sampler uniform, which causes a compilation stall. Same thing with getUniformBlockIndex. Do make sure that anything that might query into reflection about the program (e.g. getVertexAttributeIndex, getUniformLocation, getUniformBlockIndex) happens after COMPLETION_STATUS_KHR returns true, since that?s another way to accidentally stall on compilation completing. From: owners-public_webgl...@ > On Behalf Of Kai Ninomiya (kainino...@) Sent: Friday, April 12, 2019 10:25 AM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved IIRC, all 3 of those functions still force a wait for the {shader to finish compiling, program to finish linking} just as they did before. The new semantics are only visible via the new COMPLETION_STATUS_KHR check. On Fri, Apr 12, 2019 at 10:05 AM Tarek Sherif (tsherif...@) > wrote: Very excited about this extension, but I'm concerned about how it would work in our use case. Our flagship visualization library, deck.gl, often shares the gl context with a separate base map rendering application so that it can properly interleave visualization layers with the base map. Enabling this extension seems to change the behaviour of existing WebGL functions in a way that I don't believe other extensions do. My worry is how our enabling KHR_parallel_shader_compile would affect applications we share contexts with, i.e what happens if the typical synchronous compilation logic is used after KHR_parallel_shader_compile is enabled? Specifically: * What happens if getShaderParameter(shader, COMPILE_STATUS) is called before compilation is complete? * What happens if getProgramParameter(program, LINK_STATUS) is called before linking is complete? * What happens if useProgram is called before linking is complete? Thanks, Tarek Sherif Senior Software Engineer, Visualization | Uber http://vis.gl/ Tarek Sherif Senior Software Engineer, Visualization | Uber http://vis.gl/ On Fri, Apr 12, 2019 at 12:16 PM David Catuhe (David.Catuhe...@) > wrote: Wonderful! From: owners-public_webgl...@ > On Behalf Of Ken Russell (kbr...@) Sent: Wednesday, April 10, 2019 2:56 PM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved If your code works correctly now when enabling draft WebGL extensions in Chrome, then no changes are needed. There won't be any changes to the extension when it's taken out of draft status; it'll just be available by default. -Ken On Wed, Apr 10, 2019 at 12:36 PM David Catuhe (David.Catuhe...@) > wrote: We do have support for the extension in Babylon.js. How can we test this change? ________________________________ From: owners-public_webgl...@ > on behalf of Ken Russell (kbr...@) > Sent: Wednesday, April 10, 2019 12:00:25 PM To: public Subject: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved WebGL community, Jie Chen from Intel has principally developed and implemented a WebGL wrapper for the KHR_parallel_shader_compile extension. This allows shader compilation and program linking to occur fully in parallel to the rest of the WebGL application. Some small application changes are needed to take full advantage of the extension, but it is otherwise fully backward compatible. Jie has even emulated this extension on platforms which don't support it natively. This extension solves a longstanding user complaint with WebGL, namely long shader compile times on Windows. Compiles and links occur not only asynchronously, but also in parallel, so there is a net speedup when using this extension. Users who have tried out the draft extension are pleased with the results and would like to see it made widely available. I propose promoting this extension to community approved in https://github.com/KhronosGroup/WebGL/pull/2855 . Any comments? -Ken [https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png] Virus-free. www.avg.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 82548 bytes Desc: image001.png URL: From pub...@ Sat May 11 11:27:20 2019 From: pub...@ (Takahiro Aoyagi (...@...)) Date: Sun, 12 May 2019 03:27:20 +0900 Subject: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved In-Reply-To: <5F447A42ADFAFD499D69CF330DF2E5C160660987@SHSMSX101.ccr.corp.intel.com> References: <5F447A42ADFAFD499D69CF330DF2E5C160660987@SHSMSX101.ccr.corp.intel.com> Message-ID: Hi Chen, Thanks for your explanation. What type of WebGL draw calls need to wait for all queued GL commands? In my tests, not only gl.get*() https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime9.html but also gl.useProgram() seems to wait. https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime8.html That means, I shouldn't call any gl.get*() and also I shouldn't switch program until all programs compilation+linking are done? I haven't tried yet but could draw calls wait, too? If so, I shouldn't render anything until then? Virus-free. www.avg.com <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Sat, May 11, 2019 at 12:43 PM Chen, Jie A (jie.a.chen...@) < public_webgl...@> wrote: > Interesting question, Takahiro. > > My speculation is that the problem might be relevant to chrome?s > multi-process architecture. As you may know, the WebGL calls run in the > main thread of render process. Chrome needs to send these WebGL commands to > the GPU process for actual execution. So in your case, what Chrome actually > does for calls of makeProgram2 is simply putting the GL commands into a IPC > buffer. But later when you retrieve a program parameter back, it then > waits for the execution of all previously issued GL commands including > makeProgram2. > > > > *From:* owners-public_webgl...@ [mailto: > owners-public_webgl...@] *On Behalf Of *Takahiro Aoyagi ( > taoyagi...@) > *Sent:* Saturday, May 11, 2019 6:58 AM > *To:* Public WebGL > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > I'm very glad this extension moves forward. > > > > Question. Can compiling+linking a program block another program's > gl.get*() or gl.useProgram()? > > > > Even after confirming compile+link completion of a program with > COMPLETION_STATUS_KHR, gl.getProgramParameter() or gl.useProgram() seems > being blocked if another program is being compiled+linked on my Windows > Canary. Is this intentional or bug? > > > > > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime8.html > > > > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime9.html > > > > // Confirm program compile+link completion > > if(gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR)) { > > // Compile and link another program > > const vertexShader2 = gl.createShader(gl.VERTEX_SHADER); > const fragmentShader2 = gl.createShader(gl.FRAGMENT_SHADER); > const program2 = gl.createProgram(); > > gl.shaderSource(vertexShader2, vertexShaderCode); > gl.shaderSource(fragmentShader2, fragmentShaderCode); > gl.compileShader(vertexShader2); > gl.compileShader(fragmentShader2); > gl.attachShader(program2, vertexShader2); > gl.attachShader(program2, fragmentShader2); > gl.linkProgram(program2); > > > > // gl.get*() or gl.useProgram() while the other program is being > compiled+linkied > > const startTime = performance.now(); > gl.getProgramParameter(program, gl.ACTIVE_ATTRIBUTES); // or > gl.useProgram(program); > const endTime = performance.now(); > > } > > > > Takahiro > > > > > > > Virus-free. www.avg.com > > > > > On Sat, May 11, 2019 at 6:11 AM Ken Russell (kbr...@) < > public_webgl...@> wrote: > > Since there haven't been any *objections* to moving this extension > forward, and since the benefits are now being seen, it's been moved to > community approved in https://github.com/KhronosGroup/WebGL/pull/2855 . > > > > Please, feel free to continue to report problems with long shader > compilation times - either posting here on this mailing list or on > webgl-dev-list, reporting cross-browser issues on > https://github.com/KhronosGroup/WebGL/issues , or on individual browsers' > bug trackers. > > > > -Ken > > > > > > > > *From: *Ken Russell > *Date: *Fri, May 10, 2019 at 1:39 PM > *To: *Public WebGL > > Super. Thank you Takahiro for testing and confirming! > > > > > > *From: *Takahiro Aoyagi (taoyagi...@) > *Date: *Fri, May 10, 2019 at 10:51 AM > *To: *Public WebGL > > I made simple tests to check the CPU elapsed time of > gl.getProgramParameter() and gl.useProgram() after checking > COMPLETION_STATUS_KHR is true. Both are fast here on my Windows10 Chrome > Canary. > > > > > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime6.html > > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime7.html > > > > Takahiro > > > > > > > Virus-free. www.avg.com > > > > > On Sat, May 11, 2019 at 2:46 AM Ken Russell (kbr...@) < > public_webgl...@> wrote: > > Hmm. The only reason I can think of that that would happen is if you're > running on Windows, and ANGLE has to dynamically recompile the program > behind the scenes in order to handle some OpenGL ES state change. I'm not > 100% sure which changes require this dynamic recompilation; the ANGLE > developers would know best. > https://groups.google.com//forum/#!forum/angleproject > might be helpful. > > > > We'd really need some test case to make progress on this. Can you provide > one? > > > > -Ken > > > > > > On Fri, May 10, 2019 at 10:28 AM Jasper St. Pierre (jstpierre...@) > wrote: > > Hello again. My app is now showing that getProgramParameter is completing > quick, but it is spending a lot of time in useProgram. I am checking for > COMPLETION_STATUS_KHR on the GL program beforehand and it is returning > true. I?m guessing there?s some additional expensive work that still needs > to happen at useProgram time. Is this a bug? Any ways to debug or avoid > this? I?m unsure if there will be an easy repro. > > > > Again, profiler screenshot attached. > > > > *From:* owners-public_webgl...@ *On > Behalf Of *Takahiro Aoyagi (taoyagi...@) > *Sent:* Friday, May 10, 2019 12:22 AM > *To:* Public WebGL > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Confirmed COMPLETION_STATUS_KHR is very fast like 0.01ms on my test > > > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html > > > > Nice work! > > > > Thanks > > > > [image: > https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png] > > > Virus-free. www.avg.com > > > > > On Wed, May 8, 2019 at 2:41 PM Ken Russell (kbr...@) < > public_webgl...@> wrote: > > Jie Chen from Intel just landed a fix in Chrome dramatically improving the > performance of querying COMPLETION_STATUS_KHR under > http://crbug.com/881152 . The fix will be in tomorrow's Canary on Windows > and macOS. > > > > This should address the last major gap with this extension. We would like > to enable it by default by promoting it to community approved; any further > comments? > > > > -Ken > > > > > > > > *From: *Ken Russell > *Date: *Fri, Apr 26, 2019 at 3:40 PM > *To: *Public WebGL > > Thanks for the report and the clear test case. There was an existing bug > about this, so the new one was duplicated into it, and some hints about > implementing it were added to the preexisting bug. > > > > > > On Fri, Apr 26, 2019 at 5:56 AM Takahiro Aoyagi (taoyagi...@) < > public_webgl...@> wrote: > > Hi Chen, > > > > Opened a bug. Thanks. > > > > https://bugs.chromium.org/p/chromium/issues/detail?id=957001 > > > > Takahiro > > > > > > On Fri, Apr 26, 2019 at 8:03 PM Chen, Jie A (jie.a.chen...@) < > public_webgl...@> wrote: > > Hi Takahiro, > > The current implementation of COMPLETION_STATUS_KHR query in chromium > incurs an expensive round-trip to the GPU thread. This may contribute to > the wait time in your case. I am trying to optimize this. Could you please > file a bug to chromium? I would look into it once I?ve done the > optimization. > > > > *From:* owners-public_webgl...@ [mailto: > owners-public_webgl...@] *On Behalf Of *Takahiro Aoyagi ( > taoyagi...@) > *Sent:* Friday, April 26, 2019 6:20 PM > *To:* Public WebGL > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Hi all, > > > > I'm working on Three.js + KHR_parallel_shader_compile extension support > with Fernando. > > > > https://github.com/mrdoob/three.js/issues/16321#issuecomment-486436086 > > > > I'm testing with Canary. But the behavior seems weird to me. > gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) seems to wait > for compile+link completion. I don't think it should wait for that, it > should just do polling and returning true/false quickly instead. > > > > I made a simple test to reproduce. > > > > > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html > > > > Code snippet. > > > > const ext = gl.getExtension('KHR_parallel_shader_compile'); > > > > gl.compileShader(vertexShader); > gl.compileShader(fragmentShader); > gl.attachShader(program, vertexShader); > gl.attachShader(program, fragmentShader); > gl.linkProgram(program); > > const startTime = performance.now(); > const status = useExtension > ? gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) > : gl.getProgramParameter(program, gl.LINK_STATUS); > const endTime = performance.now(); > > const elapsedTime = endTime - startTime; > > > > On my platform, both gl.LINK_STATUS and ext.COMPLETION_STATUS_KHR take so > long time about 15ms. I can accept this number for gl.LINK_STATUS because > it waits for compile+link completion. But 15ms for > ext.COMPLETION_STATUS_KHR looks weird to me. It shouldn't wait for the > compile+link completion but should do just polling and quickly returning > true/false instead. So I guess the number should be 1ms or less. > > > > Let me know if I'm missing something. Or could it be a Canary bug? > > > > My platform. > > > > OS: Windows10 > > Browser: Chrome Canary. > > Browser boot option: --use-cmd-decoder=passthrough > --enable-webgl-draft-extensions > > > > > > Thanks > > > > Takahiro > > > > > > On Fri, Apr 26, 2019 at 10:15 AM Chen, Jie A (jie.a.chen...@) < > public_webgl...@> wrote: > > Basically, for ANGLE?s GL backend, it?s simply a wrapper for the existing > GL implementations. In this sense glCompileShader() is still implementation > specific. Essentially ANGLE just calls glCompileShader and check > GL_COMPILE_STATUS. > > > > *From:* owners-public_webgl...@ [mailto: > owners-public_webgl...@] *On Behalf Of *Jasper St. Pierre ( > jstpierre...@) > *Sent:* Friday, April 26, 2019 1:18 AM > *To:* Public WebGL > *Subject:* RE: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Thank you, that?s important information to know. Changing my shader > compilation pipeline to wait for shader completion status is a lot more > difficult, but based on some initial tests, it?s more expensive than not > doing it ? the latency of getShaderParameter is too high. > > > > That said, in a lot of GL implementations, glCompileShader() is > practically a no-op, and will only do an AST parse when > glGetShaderParameter/InfoLog() is called (which is basically only for > debugging / error checking). glLinkProgram() does full compilation of all > programs, as full-PSO optimization is important. I don?t know how common > this is, but multiple GL implementations I have seen do it. It might make > sense for ANGLE to adopt this model as well. > > > > *From:* owners-public_webgl...@ *On > Behalf Of *Chen, Jie A (jie.a.chen...@) > *Sent:* Wednesday, April 24, 2019 6:48 PM > *To:* Public WebGL > *Subject:* RE: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Absolutely. Ideally there would be no stall for linkProgram. I tried, but > it?s too difficult to achieve this in ANGLE. > > > > *From:* owners-public_webgl...@ [ > mailto:owners-public_webgl...@ ] *On > Behalf Of *Jeff Gilbert (jgilbert...@) > *Sent:* Thursday, April 25, 2019 9:33 AM > *To:* Public WebGL > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Possibly, but in the long run, I expect implementations to support > no-stall linkProgram invocations. > > > > On Wed, Apr 24, 2019 at 6:27 PM Chen, Jie A (jie.a.chen...@) < > public_webgl...@> wrote: > > linkProgram may stall on compileShader. To avoid the stall, you?d better > make sure the COMPLETION_STATUS_KHR statuses of the attached shaders are > all True before calling linkProgram. In this sense, the first workflow has > less chance running into stall. > > > > *From:* owners-public_webgl...@ [mailto: > owners-public_webgl...@] *On Behalf Of *Fernando Serrano Garc?a ( > fserrano...@) > *Sent:* Wednesday, April 24, 2019 9:38 PM > *To:* Public WebGL > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Regarding the optimal proposed workflow (grouping shaders and programs > separately) of: > > for (const x of shaders) > gl.compileShader(x); > for (const x of programs) > gl.linkProgram(x); > > > > versus something more on the way that we currently have in many engines as > threejs: > > for (const x of material) > > gl.compileShader(fs); > > gl.compileShader(vs); > gl.linkProgram(x); > > > > Do you think is more or less accurate the following graph for 4 materials > and enabling this extension with 2 and 4 parallel threads? > > > > [image: Screen Shot 2019-04-24 at 15.35.47.png] > > > > On Wed, Apr 24, 2019 at 2:40 PM Fernando Serrano Garc?a < > fserrano...@> wrote: > > fwiw three.js introduced a "debug" parameter (false by default) to > determine if there will be a status check and call all the get* (currently > in dev): > > - > https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLShader.js#L21-L26 > > - > https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLProgram.js#L608 > > > > so currently calling `new WebGLShader()` won't be blocking with any `get*` > function and it could be used as is to compile all of them in a loop with > or without the extension. > > the problem comes from the WebGLProgram as it should just queue itself > before trying to link any program and wait until all the shader compile > calls finish, then do all the link, and wait for it asynchronously before > start using these programs. > > I have opened an issue on the three.js repo to keep track of the > implementation and we have booked some time this week to take a look at it, > feedback is welcome :) https://github.com/mrdoob/three.js/issues/16321 > > > > On Tue, Apr 16, 2019 at 11:55 PM Ken Russell (kbr...@) < > public_webgl...@> wrote: > > On Tue, Apr 16, 2019 at 2:24 PM Tarek Sherif (tsherif...@) < > public_webgl...@> wrote: > > Yes, I've read both specs. I think this language in the WebGL version is > confusing: "When this extension is enabled: Shader compilation and program > linking may be performed in a separate CPU thread." And neither indicates > which functions are expected to cause stalls. As written, this extension > requires more than most that people know implementation details. > > > > All previous operations against the program - looking up uniform > locations, drawing with it, etc. - will cause stalls. The application > *must* be updated to query the program's COMPLETION_STATUS_KHR status, and > skip *all* operations against the program until it's no longer pending. > > > > I guess we'll just change the WebGL version of this extension spec to be > much more explicit about this. > > > > > > Essentially, all previous code which checked for the completion of > compilation of shaders / linking of programs can be updated with a small > wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. > > > > This is not true because the most common way this is done will cause > stalls that sabotage the parallelism, e.g.: > > https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLShader.js#L21-L36 > > > https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLProgram.js#L586-L631 > > > > The check for COMPLETION_STATUS_KHR has to wrap *all* queries and uses of > the program object, and they must be skipped until COMPLETION_STATUS_KHR > returns true. Yes, all applications will have to be updated to take > advantage of this extension, but if they do, the benefits will be > significant. > > > > -Ken > > > > > > *Tarek Sherif* > > Senior Software Engineer, Visualization | Uber > > http://vis.gl/ > > > > > > > > On Tue, Apr 16, 2019 at 4:18 PM Ken Russell (kbr...@) < > public_webgl...@> wrote: > > Please review the Overview in the underlying OpenGL ES spec: > > > https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt > > > > > It describes that the extension uses one or more separate CPU threads for > shader compilation. If you still think we should rewrite the introduction > to the WebGL extension, we can do that too. > > > > Essentially, all previous code which checked for the completion of > compilation of shaders / linking of programs can be updated with a small > wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. > > > > -Ken > > > > > > > > On Tue, Apr 16, 2019 at 1:36 AM Tarek Sherif (tsherif...@) < > public_webgl...@> wrote: > > This is all extremely interesting, and documentation of these best > practices should probably be more publicly available (perhaps through a > non-normative note in the spec). I'm thinking the language in the extension > spec could be made more clear about what it's actual purpose is. It > currently gives the impression that enabling it is what allows for parallel > compilation and that this should save time, but given what Jeff and Kai > have said, it sounds like the purpose is to avoid CPU stalls, and that it > might even take longer in wall time since you're only checking once a > frame. Maybe some background information could be added along the lines of > "Normally applications must wait on get*Parameter or a draw call for > program linking to complete, this extension provides a mechanism for > querying completion status without stalling..." > > > > *Tarek Sherif* > > Senior Software Engineer, Visualization | Uber > > http://vis.gl/ > > > > > > > > > On Mon, Apr 15, 2019 at 11:23 PM Kai Ninomiya (kainino...@) < > public_webgl...@> wrote: > > > > > > On Mon, Apr 15, 2019 at 7:18 PM Tarek Sherif (tareksherif...@) < > public_webgl...@> wrote: > > I don't see anything in the OpenGL extension spec about what functions > cause stalls. Is that implementation-specific? Having an idea what to > expect is important for two reasons: > > 1. To make it clear that drawing will still work if > getProgramParameter(COMPLETION_STATUS_KHR) hasn't returned true yet (i.e. > the stall on a draw call) > > > > Generally, OpenGL extensions are not allowed to break existing > API/existing content. (In OpenGL, all extensions are always enabled; > there's no requestExtension.) Hence, even if you enable the extension, it > won't change the way your application works, and therefore the draw call > must still cause a stall in order to be able to use the program. > > > > 2. Almost all WebGL code I've looked at handles compilation in a way > similar to the following: > > gl.compileShader(vertexShader); > if (!gl.getShaderParameter(vertexShader, gl.COMPILE_STATUS)) //... > > gl.compileShader(fragmentShader); > > if (!gl.getShaderParameter(fragmentShader, gl.COMPILE_STATUS)) //... > > //... > > gl.linkProgram(program); > if (!gl.getProgramParameter(program, gl.LINK_STATUS)) //... > > I think it would be worth it to make clear that this pattern would > sabotage the parallel compile. > > > > I seem to remember (not sure if this is still true) that this pattern also > sabotages the shader compiler cache in ANGLE, because ANGLE doesn't cache > the COMPILE_STATUS (or was it the compile info string?). So it forces the > compiler to recompile just to give you the status. > > > > Tarek Sherif > > http://tareksherif.net/ > > > > > > > > > ??????? Original Message ??????? > > On Monday, April 15, 2019 9:00 PM, Ken Russell (kbr...@) < > public_webgl...@> wrote: > > > > The WebGL extension (which is basically just a wrapper) refers to the > underlying OpenGL / OpenGL ES extension > https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt > , > where this is documented. Is that sufficient? It would be better to avoid > duplicating a large amount of spec text from the underlying extension. > However, we can add some non-normative text if that would help. > > > > -Ken > > > > > > > > On Sat, Apr 13, 2019 at 3:51 AM Tarek Sherif (tareksherif...@) < > public_webgl...@> wrote: > > IIRC, all 3 of those functions still force a wait for the {shader to > finish compiling, program to finish linking} just as they did before. The > new semantics are only visible via the new COMPLETION_STATUS_KHR check. > > That should work perfectly for us. Can we add some language to the spec > about which functions cause stalls? I feel like as written, it will be easy > for people to use the extension incorrectly. > > > > Tarek Sherif > > http://tareksherif.net/ > > > > > > > > > ??????? Original Message ??????? > > On Friday, April 12, 2019 4:10 PM, Kai Ninomiya (kainino...@) < > public_webgl...@> wrote: > > > > Oh yes, useProgram probably won't stall. But getUniformLocation and the > others will stall, as will draw calls. > > > > getProgramParameter(COMPLETION_STATUS_KHR) should get faster at some > point; see http://crbug.com/881152 > which > Ken linked. > > > > On Fri, Apr 12, 2019 at 12:39 PM Jasper St. Pierre (jstpierre...@) > wrote: > > Thank you! Trying this out in my own WebGL 2 app, I see quite a reduction > in shader compilation time, shaving 400ms on load time on a moderately > complex scene. The getProgramParameter(COMPLETION_STATUS_KHR) query still > takes 1ms (which I believe is being tracked), but that is still better from > the 4ms I see in getUniformBlockIndex (my previous sync point). > > > > AFAIK, useProgram should not cause a stall, but in order to set my texture > samplers to bind to different units, I need to do a getUniformLocation on > my sampler uniform, which causes a compilation stall. Same thing with > getUniformBlockIndex. Do make sure that anything that might query into > reflection about the program (e.g. getVertexAttributeIndex, > getUniformLocation, getUniformBlockIndex) happens after > COMPLETION_STATUS_KHR returns true, since that?s another way to > accidentally stall on compilation completing. > > > > > > *From:* owners-public_webgl...@ *On > Behalf Of *Kai Ninomiya (kainino...@) > > *Sent:* Friday, April 12, 2019 10:25 AM > > *To:* Public WebGL > > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > > > IIRC, all 3 of those functions still force a wait for the {shader to > finish compiling, program to finish linking} just as they did before. The > new semantics are only visible via the new COMPLETION_STATUS_KHR check. > > > > On Fri, Apr 12, 2019 at 10:05 AM Tarek Sherif (tsherif...@) < > public_webgl...@> wrote: > > Very excited about this extension, but I'm concerned about how it would > work in our use case. Our flagship visualization library, deck.gl > , > often shares the gl context with a separate base map rendering application > so that it can properly interleave visualization layers with the base map. > Enabling this extension seems to change the behaviour of existing WebGL > functions in a way that I don't believe other extensions do. My worry is > how our enabling KHR_parallel_shader_compile would affect applications we > share contexts with, i.e what happens if the typical synchronous > compilation logic is used after KHR_parallel_shader_compile is enabled? > Specifically: > > - What happens if getShaderParameter(shader, COMPILE_STATUS) is called > before compilation is complete? > - What happens if getProgramParameter(program, LINK_STATUS) is called > before linking is complete? > - What happens if useProgram is called before linking is complete? > > Thanks, > > > > > > Tarek Sherif > > Senior Software Engineer, Visualization | Uber > > http://vis.gl/ > > > > > > > > > > > *Tarek Sherif* > > Senior Software Engineer, Visualization | Uber > > http://vis.gl/ > > > > > > > On Fri, Apr 12, 2019 at 12:16 PM David Catuhe (David.Catuhe...@) > wrote: > > Wonderful! > > > > > > *From:* owners-public_webgl...@ *On > Behalf Of *Ken Russell (kbr...@) > > *Sent:* Wednesday, April 10, 2019 2:56 PM > > *To:* Public WebGL > > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > > > If your code works correctly now when enabling draft WebGL extensions in > Chrome, then no changes are needed. There won't be any changes to the > extension when it's taken out of draft status; it'll just be available by > default. > > > > -Ken > > > > > > On Wed, Apr 10, 2019 at 12:36 PM David Catuhe (David.Catuhe...@) > wrote: > > We do have support for the extension in Babylon.js. How can we test this > change? > ------------------------------ > > > > *From:* owners-public_webgl...@ > on behalf of Ken Russell (kbr...@) > *Sent:* Wednesday, April 10, 2019 12:00:25 PM > *To:* public > *Subject:* [Public WebGL] Propose promoting KHR_parallel_shader_compile > to community approved > > > > WebGL community, > > > > Jie Chen from Intel has principally developed and implemented a WebGL > wrapper for the KHR_parallel_shader_compile extension. This allows shader > compilation and program linking to occur fully in parallel to the rest of > the WebGL application. Some small application changes are needed to take > full advantage of the extension, but it is otherwise fully backward > compatible. Jie has even emulated this extension on platforms which don't > support it natively. > > > > This extension solves a longstanding user complaint with WebGL, namely > long shader compile times on Windows. Compiles and links occur not only > asynchronously, but also in parallel, so there is a net speedup when using > this extension. Users who have tried out the draft extension are pleased > with the results and would like to see it made widely available. > > > > I propose promoting this extension to community approved in > https://github.com/KhronosGroup/WebGL/pull/2855 > > . Any comments? > > > > -Ken > > > > > > > > > > [image: > https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png] > > > Virus-free. www.avg.com > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 82548 bytes Desc: not available URL: From pub...@ Sat May 11 18:44:01 2019 From: pub...@ (Chen, Jie A (...@...)) Date: Sun, 12 May 2019 01:44:01 +0000 Subject: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved In-Reply-To: References: <5F447A42ADFAFD499D69CF330DF2E5C160660987@SHSMSX101.ccr.corp.intel.com> Message-ID: <5F447A42ADFAFD499D69CF330DF2E5C160661691@SHSMSX101.ccr.corp.intel.com> Mostly they are gl.get* like commands. You can search ?WaitForCmd? in https://cs.chromium.org/chromium/src/gpu/command_buffer/client/gles2_implementation_impl_autogen.h and https://cs.chromium.org/chromium/src/gpu/command_buffer/client/gles2_implementation.cc for them. But I don?t think gl.useProgram needs to wait. Most likely it has a different cause. I will look into it later. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Takahiro Aoyagi (taoyagi...@) Sent: Sunday, May 12, 2019 2:27 AM To: Public WebGL Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Hi Chen, Thanks for your explanation. What type of WebGL draw calls need to wait for all queued GL commands? In my tests, not only gl.get*() https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime9.html but also gl.useProgram() seems to wait. https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime8.html That means, I shouldn't call any gl.get*() and also I shouldn't switch program until all programs compilation+linking are done? I haven't tried yet but could draw calls wait, too? If so, I shouldn't render anything until then? [https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png] Virus-free. www.avg.com On Sat, May 11, 2019 at 12:43 PM Chen, Jie A (jie.a.chen...@) > wrote: Interesting question, Takahiro. My speculation is that the problem might be relevant to chrome?s multi-process architecture. As you may know, the WebGL calls run in the main thread of render process. Chrome needs to send these WebGL commands to the GPU process for actual execution. So in your case, what Chrome actually does for calls of makeProgram2 is simply putting the GL commands into a IPC buffer. But later when you retrieve a program parameter back, it then waits for the execution of all previously issued GL commands including makeProgram2. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Takahiro Aoyagi (taoyagi...@) Sent: Saturday, May 11, 2019 6:58 AM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved I'm very glad this extension moves forward. Question. Can compiling+linking a program block another program's gl.get*() or gl.useProgram()? Even after confirming compile+link completion of a program with COMPLETION_STATUS_KHR, gl.getProgramParameter() or gl.useProgram() seems being blocked if another program is being compiled+linked on my Windows Canary. Is this intentional or bug? https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime8.html https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime9.html // Confirm program compile+link completion if(gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR)) { // Compile and link another program const vertexShader2 = gl.createShader(gl.VERTEX_SHADER); const fragmentShader2 = gl.createShader(gl.FRAGMENT_SHADER); const program2 = gl.createProgram(); gl.shaderSource(vertexShader2, vertexShaderCode); gl.shaderSource(fragmentShader2, fragmentShaderCode); gl.compileShader(vertexShader2); gl.compileShader(fragmentShader2); gl.attachShader(program2, vertexShader2); gl.attachShader(program2, fragmentShader2); gl.linkProgram(program2); // gl.get*() or gl.useProgram() while the other program is being compiled+linkied const startTime = performance.now(); gl.getProgramParameter(program, gl.ACTIVE_ATTRIBUTES); // or gl.useProgram(program); const endTime = performance.now(); } Takahiro [https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png] Virus-free. www.avg.com On Sat, May 11, 2019 at 6:11 AM Ken Russell (kbr...@) > wrote: Since there haven't been any *objections* to moving this extension forward, and since the benefits are now being seen, it's been moved to community approved in https://github.com/KhronosGroup/WebGL/pull/2855 . Please, feel free to continue to report problems with long shader compilation times - either posting here on this mailing list or on webgl-dev-list, reporting cross-browser issues on https://github.com/KhronosGroup/WebGL/issues , or on individual browsers' bug trackers. -Ken From: Ken Russell > Date: Fri, May 10, 2019 at 1:39 PM To: Public WebGL Super. Thank you Takahiro for testing and confirming! From: Takahiro Aoyagi (taoyagi...@) > Date: Fri, May 10, 2019 at 10:51 AM To: Public WebGL I made simple tests to check the CPU elapsed time of gl.getProgramParameter() and gl.useProgram() after checking COMPLETION_STATUS_KHR is true. Both are fast here on my Windows10 Chrome Canary. https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime6.html https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime7.html Takahiro [https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png] Virus-free. www.avg.com On Sat, May 11, 2019 at 2:46 AM Ken Russell (kbr...@) > wrote: Hmm. The only reason I can think of that that would happen is if you're running on Windows, and ANGLE has to dynamically recompile the program behind the scenes in order to handle some OpenGL ES state change. I'm not 100% sure which changes require this dynamic recompilation; the ANGLE developers would know best. https://groups.google.com//forum/#!forum/angleproject might be helpful. We'd really need some test case to make progress on this. Can you provide one? -Ken On Fri, May 10, 2019 at 10:28 AM Jasper St. Pierre (jstpierre...@) > wrote: Hello again. My app is now showing that getProgramParameter is completing quick, but it is spending a lot of time in useProgram. I am checking for COMPLETION_STATUS_KHR on the GL program beforehand and it is returning true. I?m guessing there?s some additional expensive work that still needs to happen at useProgram time. Is this a bug? Any ways to debug or avoid this? I?m unsure if there will be an easy repro. Again, profiler screenshot attached. From: owners-public_webgl...@ > On Behalf Of Takahiro Aoyagi (taoyagi...@) Sent: Friday, May 10, 2019 12:22 AM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Confirmed COMPLETION_STATUS_KHR is very fast like 0.01ms on my test https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html Nice work! Thanks [https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png] Virus-free. www.avg.com On Wed, May 8, 2019 at 2:41 PM Ken Russell (kbr...@) > wrote: Jie Chen from Intel just landed a fix in Chrome dramatically improving the performance of querying COMPLETION_STATUS_KHR under http://crbug.com/881152 . The fix will be in tomorrow's Canary on Windows and macOS. This should address the last major gap with this extension. We would like to enable it by default by promoting it to community approved; any further comments? -Ken From: Ken Russell > Date: Fri, Apr 26, 2019 at 3:40 PM To: Public WebGL Thanks for the report and the clear test case. There was an existing bug about this, so the new one was duplicated into it, and some hints about implementing it were added to the preexisting bug. On Fri, Apr 26, 2019 at 5:56 AM Takahiro Aoyagi (taoyagi...@) > wrote: Hi Chen, Opened a bug. Thanks. https://bugs.chromium.org/p/chromium/issues/detail?id=957001 Takahiro On Fri, Apr 26, 2019 at 8:03 PM Chen, Jie A (jie.a.chen...@) > wrote: Hi Takahiro, The current implementation of COMPLETION_STATUS_KHR query in chromium incurs an expensive round-trip to the GPU thread. This may contribute to the wait time in your case. I am trying to optimize this. Could you please file a bug to chromium? I would look into it once I?ve done the optimization. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Takahiro Aoyagi (taoyagi...@) Sent: Friday, April 26, 2019 6:20 PM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Hi all, I'm working on Three.js + KHR_parallel_shader_compile extension support with Fernando. https://github.com/mrdoob/three.js/issues/16321#issuecomment-486436086 I'm testing with Canary. But the behavior seems weird to me. gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) seems to wait for compile+link completion. I don't think it should wait for that, it should just do polling and returning true/false quickly instead. I made a simple test to reproduce. https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html Code snippet. const ext = gl.getExtension('KHR_parallel_shader_compile'); gl.compileShader(vertexShader); gl.compileShader(fragmentShader); gl.attachShader(program, vertexShader); gl.attachShader(program, fragmentShader); gl.linkProgram(program); const startTime = performance.now(); const status = useExtension ? gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) : gl.getProgramParameter(program, gl.LINK_STATUS); const endTime = performance.now(); const elapsedTime = endTime - startTime; On my platform, both gl.LINK_STATUS and ext.COMPLETION_STATUS_KHR take so long time about 15ms. I can accept this number for gl.LINK_STATUS because it waits for compile+link completion. But 15ms for ext.COMPLETION_STATUS_KHR looks weird to me. It shouldn't wait for the compile+link completion but should do just polling and quickly returning true/false instead. So I guess the number should be 1ms or less. Let me know if I'm missing something. Or could it be a Canary bug? My platform. OS: Windows10 Browser: Chrome Canary. Browser boot option: --use-cmd-decoder=passthrough --enable-webgl-draft-extensions Thanks Takahiro On Fri, Apr 26, 2019 at 10:15 AM Chen, Jie A (jie.a.chen...@) > wrote: Basically, for ANGLE?s GL backend, it?s simply a wrapper for the existing GL implementations. In this sense glCompileShader() is still implementation specific. Essentially ANGLE just calls glCompileShader and check GL_COMPILE_STATUS. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Jasper St. Pierre (jstpierre...@) Sent: Friday, April 26, 2019 1:18 AM To: Public WebGL > Subject: RE: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Thank you, that?s important information to know. Changing my shader compilation pipeline to wait for shader completion status is a lot more difficult, but based on some initial tests, it?s more expensive than not doing it ? the latency of getShaderParameter is too high. That said, in a lot of GL implementations, glCompileShader() is practically a no-op, and will only do an AST parse when glGetShaderParameter/InfoLog() is called (which is basically only for debugging / error checking). glLinkProgram() does full compilation of all programs, as full-PSO optimization is important. I don?t know how common this is, but multiple GL implementations I have seen do it. It might make sense for ANGLE to adopt this model as well. From: owners-public_webgl...@ > On Behalf Of Chen, Jie A (jie.a.chen...@) Sent: Wednesday, April 24, 2019 6:48 PM To: Public WebGL > Subject: RE: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Absolutely. Ideally there would be no stall for linkProgram. I tried, but it?s too difficult to achieve this in ANGLE. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Jeff Gilbert (jgilbert...@) Sent: Thursday, April 25, 2019 9:33 AM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Possibly, but in the long run, I expect implementations to support no-stall linkProgram invocations. On Wed, Apr 24, 2019 at 6:27 PM Chen, Jie A (jie.a.chen...@) > wrote: linkProgram may stall on compileShader. To avoid the stall, you?d better make sure the COMPLETION_STATUS_KHR statuses of the attached shaders are all True before calling linkProgram. In this sense, the first workflow has less chance running into stall. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Fernando Serrano Garc?a (fserrano...@) Sent: Wednesday, April 24, 2019 9:38 PM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Regarding the optimal proposed workflow (grouping shaders and programs separately) of: for (const x of shaders) gl.compileShader(x); for (const x of programs) gl.linkProgram(x); versus something more on the way that we currently have in many engines as threejs: for (const x of material) gl.compileShader(fs); gl.compileShader(vs); gl.linkProgram(x); Do you think is more or less accurate the following graph for 4 materials and enabling this extension with 2 and 4 parallel threads? [Screen Shot 2019-04-24 at 15.35.47.png] On Wed, Apr 24, 2019 at 2:40 PM Fernando Serrano Garc?a > wrote: fwiw three.js introduced a "debug" parameter (false by default) to determine if there will be a status check and call all the get* (currently in dev): - https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLShader.js#L21-L26 - https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLProgram.js#L608 so currently calling `new WebGLShader()` won't be blocking with any `get*` function and it could be used as is to compile all of them in a loop with or without the extension. the problem comes from the WebGLProgram as it should just queue itself before trying to link any program and wait until all the shader compile calls finish, then do all the link, and wait for it asynchronously before start using these programs. I have opened an issue on the three.js repo to keep track of the implementation and we have booked some time this week to take a look at it, feedback is welcome :) https://github.com/mrdoob/three.js/issues/16321 On Tue, Apr 16, 2019 at 11:55 PM Ken Russell (kbr...@) > wrote: On Tue, Apr 16, 2019 at 2:24 PM Tarek Sherif (tsherif...@) > wrote: Yes, I've read both specs. I think this language in the WebGL version is confusing: "When this extension is enabled: Shader compilation and program linking may be performed in a separate CPU thread." And neither indicates which functions are expected to cause stalls. As written, this extension requires more than most that people know implementation details. All previous operations against the program - looking up uniform locations, drawing with it, etc. - will cause stalls. The application *must* be updated to query the program's COMPLETION_STATUS_KHR status, and skip *all* operations against the program until it's no longer pending. I guess we'll just change the WebGL version of this extension spec to be much more explicit about this. Essentially, all previous code which checked for the completion of compilation of shaders / linking of programs can be updated with a small wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. This is not true because the most common way this is done will cause stalls that sabotage the parallelism, e.g.: https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLShader.js#L21-L36 https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLProgram.js#L586-L631 The check for COMPLETION_STATUS_KHR has to wrap *all* queries and uses of the program object, and they must be skipped until COMPLETION_STATUS_KHR returns true. Yes, all applications will have to be updated to take advantage of this extension, but if they do, the benefits will be significant. -Ken Tarek Sherif Senior Software Engineer, Visualization | Uber http://vis.gl/ On Tue, Apr 16, 2019 at 4:18 PM Ken Russell (kbr...@) > wrote: Please review the Overview in the underlying OpenGL ES spec: https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt It describes that the extension uses one or more separate CPU threads for shader compilation. If you still think we should rewrite the introduction to the WebGL extension, we can do that too. Essentially, all previous code which checked for the completion of compilation of shaders / linking of programs can be updated with a small wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. -Ken On Tue, Apr 16, 2019 at 1:36 AM Tarek Sherif (tsherif...@) > wrote: This is all extremely interesting, and documentation of these best practices should probably be more publicly available (perhaps through a non-normative note in the spec). I'm thinking the language in the extension spec could be made more clear about what it's actual purpose is. It currently gives the impression that enabling it is what allows for parallel compilation and that this should save time, but given what Jeff and Kai have said, it sounds like the purpose is to avoid CPU stalls, and that it might even take longer in wall time since you're only checking once a frame. Maybe some background information could be added along the lines of "Normally applications must wait on get*Parameter or a draw call for program linking to complete, this extension provides a mechanism for querying completion status without stalling..." Tarek Sherif Senior Software Engineer, Visualization | Uber http://vis.gl/ On Mon, Apr 15, 2019 at 11:23 PM Kai Ninomiya (kainino...@) > wrote: On Mon, Apr 15, 2019 at 7:18 PM Tarek Sherif (tareksherif...@) > wrote: I don't see anything in the OpenGL extension spec about what functions cause stalls. Is that implementation-specific? Having an idea what to expect is important for two reasons: 1. To make it clear that drawing will still work if getProgramParameter(COMPLETION_STATUS_KHR) hasn't returned true yet (i.e. the stall on a draw call) Generally, OpenGL extensions are not allowed to break existing API/existing content. (In OpenGL, all extensions are always enabled; there's no requestExtension.) Hence, even if you enable the extension, it won't change the way your application works, and therefore the draw call must still cause a stall in order to be able to use the program. 2. Almost all WebGL code I've looked at handles compilation in a way similar to the following: gl.compileShader(vertexShader); if (!gl.getShaderParameter(vertexShader, gl.COMPILE_STATUS)) //... gl.compileShader(fragmentShader); if (!gl.getShaderParameter(fragmentShader, gl.COMPILE_STATUS)) //... //... gl.linkProgram(program); if (!gl.getProgramParameter(program, gl.LINK_STATUS)) //... I think it would be worth it to make clear that this pattern would sabotage the parallel compile. I seem to remember (not sure if this is still true) that this pattern also sabotages the shader compiler cache in ANGLE, because ANGLE doesn't cache the COMPILE_STATUS (or was it the compile info string?). So it forces the compiler to recompile just to give you the status. Tarek Sherif http://tareksherif.net/ ??????? Original Message ??????? On Monday, April 15, 2019 9:00 PM, Ken Russell (kbr...@) > wrote: The WebGL extension (which is basically just a wrapper) refers to the underlying OpenGL / OpenGL ES extension https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt, where this is documented. Is that sufficient? It would be better to avoid duplicating a large amount of spec text from the underlying extension. However, we can add some non-normative text if that would help. -Ken On Sat, Apr 13, 2019 at 3:51 AM Tarek Sherif (tareksherif...@) > wrote: IIRC, all 3 of those functions still force a wait for the {shader to finish compiling, program to finish linking} just as they did before. The new semantics are only visible via the new COMPLETION_STATUS_KHR check. That should work perfectly for us. Can we add some language to the spec about which functions cause stalls? I feel like as written, it will be easy for people to use the extension incorrectly. Tarek Sherif http://tareksherif.net/ ??????? Original Message ??????? On Friday, April 12, 2019 4:10 PM, Kai Ninomiya (kainino...@) > wrote: Oh yes, useProgram probably won't stall. But getUniformLocation and the others will stall, as will draw calls. getProgramParameter(COMPLETION_STATUS_KHR) should get faster at some point; see http://crbug.com/881152 which Ken linked. On Fri, Apr 12, 2019 at 12:39 PM Jasper St. Pierre (jstpierre...@) > wrote: Thank you! Trying this out in my own WebGL 2 app, I see quite a reduction in shader compilation time, shaving 400ms on load time on a moderately complex scene. The getProgramParameter(COMPLETION_STATUS_KHR) query still takes 1ms (which I believe is being tracked), but that is still better from the 4ms I see in getUniformBlockIndex (my previous sync point). AFAIK, useProgram should not cause a stall, but in order to set my texture samplers to bind to different units, I need to do a getUniformLocation on my sampler uniform, which causes a compilation stall. Same thing with getUniformBlockIndex. Do make sure that anything that might query into reflection about the program (e.g. getVertexAttributeIndex, getUniformLocation, getUniformBlockIndex) happens after COMPLETION_STATUS_KHR returns true, since that?s another way to accidentally stall on compilation completing. From: owners-public_webgl...@ > On Behalf Of Kai Ninomiya (kainino...@) Sent: Friday, April 12, 2019 10:25 AM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved IIRC, all 3 of those functions still force a wait for the {shader to finish compiling, program to finish linking} just as they did before. The new semantics are only visible via the new COMPLETION_STATUS_KHR check. On Fri, Apr 12, 2019 at 10:05 AM Tarek Sherif (tsherif...@) > wrote: Very excited about this extension, but I'm concerned about how it would work in our use case. Our flagship visualization library, deck.gl, often shares the gl context with a separate base map rendering application so that it can properly interleave visualization layers with the base map. Enabling this extension seems to change the behaviour of existing WebGL functions in a way that I don't believe other extensions do. My worry is how our enabling KHR_parallel_shader_compile would affect applications we share contexts with, i.e what happens if the typical synchronous compilation logic is used after KHR_parallel_shader_compile is enabled? Specifically: * What happens if getShaderParameter(shader, COMPILE_STATUS) is called before compilation is complete? * What happens if getProgramParameter(program, LINK_STATUS) is called before linking is complete? * What happens if useProgram is called before linking is complete? Thanks, Tarek Sherif Senior Software Engineer, Visualization | Uber http://vis.gl/ Tarek Sherif Senior Software Engineer, Visualization | Uber http://vis.gl/ On Fri, Apr 12, 2019 at 12:16 PM David Catuhe (David.Catuhe...@) > wrote: Wonderful! From: owners-public_webgl...@ > On Behalf Of Ken Russell (kbr...@) Sent: Wednesday, April 10, 2019 2:56 PM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved If your code works correctly now when enabling draft WebGL extensions in Chrome, then no changes are needed. There won't be any changes to the extension when it's taken out of draft status; it'll just be available by default. -Ken On Wed, Apr 10, 2019 at 12:36 PM David Catuhe (David.Catuhe...@) > wrote: We do have support for the extension in Babylon.js. How can we test this change? ________________________________ From: owners-public_webgl...@ > on behalf of Ken Russell (kbr...@) > Sent: Wednesday, April 10, 2019 12:00:25 PM To: public Subject: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved WebGL community, Jie Chen from Intel has principally developed and implemented a WebGL wrapper for the KHR_parallel_shader_compile extension. This allows shader compilation and program linking to occur fully in parallel to the rest of the WebGL application. Some small application changes are needed to take full advantage of the extension, but it is otherwise fully backward compatible. Jie has even emulated this extension on platforms which don't support it natively. This extension solves a longstanding user complaint with WebGL, namely long shader compile times on Windows. Compiles and links occur not only asynchronously, but also in parallel, so there is a net speedup when using this extension. Users who have tried out the draft extension are pleased with the results and would like to see it made widely available. I propose promoting this extension to community approved in https://github.com/KhronosGroup/WebGL/pull/2855 . Any comments? -Ken [https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png] Virus-free. www.avg.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 82548 bytes Desc: image002.png URL: From pub...@ Sat May 11 20:06:12 2019 From: pub...@ (Chen, Jie A (...@...)) Date: Sun, 12 May 2019 03:06:12 +0000 Subject: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved In-Reply-To: <5F447A42ADFAFD499D69CF330DF2E5C160661691@SHSMSX101.ccr.corp.intel.com> References: <5F447A42ADFAFD499D69CF330DF2E5C160660987@SHSMSX101.ccr.corp.intel.com> <5F447A42ADFAFD499D69CF330DF2E5C160661691@SHSMSX101.ccr.corp.intel.com> Message-ID: <5F447A42ADFAFD499D69CF330DF2E5C160661793@SHSMSX101.ccr.corp.intel.com> I guess I?ve found the cause for gl.useProgram. WebGL implementation inserts an extra GL command to query LinkStatus before using it. https://cs.chromium.org/chromium/src/third_party/blink/renderer/modules/webgl/webgl_rendering_context_base.cc?sq=package:chromium&g=0&l=6350 Anyway I think you don?t need to worry too much about this. Usually it doesn?t take very long to drain the command buffer. I tried your test case, which took about only 8ms on my laptop. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Chen, Jie A (jie.a.chen...@) Sent: Sunday, May 12, 2019 9:44 AM To: Public WebGL Subject: RE: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Mostly they are gl.get* like commands. You can search ?WaitForCmd? in https://cs.chromium.org/chromium/src/gpu/command_buffer/client/gles2_implementation_impl_autogen.h and https://cs.chromium.org/chromium/src/gpu/command_buffer/client/gles2_implementation.cc for them. But I don?t think gl.useProgram needs to wait. Most likely it has a different cause. I will look into it later. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Takahiro Aoyagi (taoyagi...@) Sent: Sunday, May 12, 2019 2:27 AM To: Public WebGL Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Hi Chen, Thanks for your explanation. What type of WebGL draw calls need to wait for all queued GL commands? In my tests, not only gl.get*() https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime9.html but also gl.useProgram() seems to wait. https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime8.html That means, I shouldn't call any gl.get*() and also I shouldn't switch program until all programs compilation+linking are done? I haven't tried yet but could draw calls wait, too? If so, I shouldn't render anything until then? [Image removed by sender.] Virus-free. www.avg.com On Sat, May 11, 2019 at 12:43 PM Chen, Jie A (jie.a.chen...@) > wrote: Interesting question, Takahiro. My speculation is that the problem might be relevant to chrome?s multi-process architecture. As you may know, the WebGL calls run in the main thread of render process. Chrome needs to send these WebGL commands to the GPU process for actual execution. So in your case, what Chrome actually does for calls of makeProgram2 is simply putting the GL commands into a IPC buffer. But later when you retrieve a program parameter back, it then waits for the execution of all previously issued GL commands including makeProgram2. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Takahiro Aoyagi (taoyagi...@) Sent: Saturday, May 11, 2019 6:58 AM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved I'm very glad this extension moves forward. Question. Can compiling+linking a program block another program's gl.get*() or gl.useProgram()? Even after confirming compile+link completion of a program with COMPLETION_STATUS_KHR, gl.getProgramParameter() or gl.useProgram() seems being blocked if another program is being compiled+linked on my Windows Canary. Is this intentional or bug? https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime8.html https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime9.html // Confirm program compile+link completion if(gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR)) { // Compile and link another program const vertexShader2 = gl.createShader(gl.VERTEX_SHADER); const fragmentShader2 = gl.createShader(gl.FRAGMENT_SHADER); const program2 = gl.createProgram(); gl.shaderSource(vertexShader2, vertexShaderCode); gl.shaderSource(fragmentShader2, fragmentShaderCode); gl.compileShader(vertexShader2); gl.compileShader(fragmentShader2); gl.attachShader(program2, vertexShader2); gl.attachShader(program2, fragmentShader2); gl.linkProgram(program2); // gl.get*() or gl.useProgram() while the other program is being compiled+linkied const startTime = performance.now(); gl.getProgramParameter(program, gl.ACTIVE_ATTRIBUTES); // or gl.useProgram(program); const endTime = performance.now(); } Takahiro [Image removed by sender.] Virus-free. www.avg.com On Sat, May 11, 2019 at 6:11 AM Ken Russell (kbr...@) > wrote: Since there haven't been any *objections* to moving this extension forward, and since the benefits are now being seen, it's been moved to community approved in https://github.com/KhronosGroup/WebGL/pull/2855 . Please, feel free to continue to report problems with long shader compilation times - either posting here on this mailing list or on webgl-dev-list, reporting cross-browser issues on https://github.com/KhronosGroup/WebGL/issues , or on individual browsers' bug trackers. -Ken From: Ken Russell > Date: Fri, May 10, 2019 at 1:39 PM To: Public WebGL Super. Thank you Takahiro for testing and confirming! From: Takahiro Aoyagi (taoyagi...@) > Date: Fri, May 10, 2019 at 10:51 AM To: Public WebGL I made simple tests to check the CPU elapsed time of gl.getProgramParameter() and gl.useProgram() after checking COMPLETION_STATUS_KHR is true. Both are fast here on my Windows10 Chrome Canary. https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime6.html https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime7.html Takahiro [Image removed by sender.] Virus-free. www.avg.com On Sat, May 11, 2019 at 2:46 AM Ken Russell (kbr...@) > wrote: Hmm. The only reason I can think of that that would happen is if you're running on Windows, and ANGLE has to dynamically recompile the program behind the scenes in order to handle some OpenGL ES state change. I'm not 100% sure which changes require this dynamic recompilation; the ANGLE developers would know best. https://groups.google.com//forum/#!forum/angleproject might be helpful. We'd really need some test case to make progress on this. Can you provide one? -Ken On Fri, May 10, 2019 at 10:28 AM Jasper St. Pierre (jstpierre...@) > wrote: Hello again. My app is now showing that getProgramParameter is completing quick, but it is spending a lot of time in useProgram. I am checking for COMPLETION_STATUS_KHR on the GL program beforehand and it is returning true. I?m guessing there?s some additional expensive work that still needs to happen at useProgram time. Is this a bug? Any ways to debug or avoid this? I?m unsure if there will be an easy repro. Again, profiler screenshot attached. From: owners-public_webgl...@ > On Behalf Of Takahiro Aoyagi (taoyagi...@) Sent: Friday, May 10, 2019 12:22 AM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Confirmed COMPLETION_STATUS_KHR is very fast like 0.01ms on my test https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html Nice work! Thanks [Image removed by sender. https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png] Virus-free. www.avg.com On Wed, May 8, 2019 at 2:41 PM Ken Russell (kbr...@) > wrote: Jie Chen from Intel just landed a fix in Chrome dramatically improving the performance of querying COMPLETION_STATUS_KHR under http://crbug.com/881152 . The fix will be in tomorrow's Canary on Windows and macOS. This should address the last major gap with this extension. We would like to enable it by default by promoting it to community approved; any further comments? -Ken From: Ken Russell > Date: Fri, Apr 26, 2019 at 3:40 PM To: Public WebGL Thanks for the report and the clear test case. There was an existing bug about this, so the new one was duplicated into it, and some hints about implementing it were added to the preexisting bug. On Fri, Apr 26, 2019 at 5:56 AM Takahiro Aoyagi (taoyagi...@) > wrote: Hi Chen, Opened a bug. Thanks. https://bugs.chromium.org/p/chromium/issues/detail?id=957001 Takahiro On Fri, Apr 26, 2019 at 8:03 PM Chen, Jie A (jie.a.chen...@) > wrote: Hi Takahiro, The current implementation of COMPLETION_STATUS_KHR query in chromium incurs an expensive round-trip to the GPU thread. This may contribute to the wait time in your case. I am trying to optimize this. Could you please file a bug to chromium? I would look into it once I?ve done the optimization. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Takahiro Aoyagi (taoyagi...@) Sent: Friday, April 26, 2019 6:20 PM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Hi all, I'm working on Three.js + KHR_parallel_shader_compile extension support with Fernando. https://github.com/mrdoob/three.js/issues/16321#issuecomment-486436086 I'm testing with Canary. But the behavior seems weird to me. gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) seems to wait for compile+link completion. I don't think it should wait for that, it should just do polling and returning true/false quickly instead. I made a simple test to reproduce. https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html Code snippet. const ext = gl.getExtension('KHR_parallel_shader_compile'); gl.compileShader(vertexShader); gl.compileShader(fragmentShader); gl.attachShader(program, vertexShader); gl.attachShader(program, fragmentShader); gl.linkProgram(program); const startTime = performance.now(); const status = useExtension ? gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) : gl.getProgramParameter(program, gl.LINK_STATUS); const endTime = performance.now(); const elapsedTime = endTime - startTime; On my platform, both gl.LINK_STATUS and ext.COMPLETION_STATUS_KHR take so long time about 15ms. I can accept this number for gl.LINK_STATUS because it waits for compile+link completion. But 15ms for ext.COMPLETION_STATUS_KHR looks weird to me. It shouldn't wait for the compile+link completion but should do just polling and quickly returning true/false instead. So I guess the number should be 1ms or less. Let me know if I'm missing something. Or could it be a Canary bug? My platform. OS: Windows10 Browser: Chrome Canary. Browser boot option: --use-cmd-decoder=passthrough --enable-webgl-draft-extensions Thanks Takahiro On Fri, Apr 26, 2019 at 10:15 AM Chen, Jie A (jie.a.chen...@) > wrote: Basically, for ANGLE?s GL backend, it?s simply a wrapper for the existing GL implementations. In this sense glCompileShader() is still implementation specific. Essentially ANGLE just calls glCompileShader and check GL_COMPILE_STATUS. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Jasper St. Pierre (jstpierre...@) Sent: Friday, April 26, 2019 1:18 AM To: Public WebGL > Subject: RE: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Thank you, that?s important information to know. Changing my shader compilation pipeline to wait for shader completion status is a lot more difficult, but based on some initial tests, it?s more expensive than not doing it ? the latency of getShaderParameter is too high. That said, in a lot of GL implementations, glCompileShader() is practically a no-op, and will only do an AST parse when glGetShaderParameter/InfoLog() is called (which is basically only for debugging / error checking). glLinkProgram() does full compilation of all programs, as full-PSO optimization is important. I don?t know how common this is, but multiple GL implementations I have seen do it. It might make sense for ANGLE to adopt this model as well. From: owners-public_webgl...@ > On Behalf Of Chen, Jie A (jie.a.chen...@) Sent: Wednesday, April 24, 2019 6:48 PM To: Public WebGL > Subject: RE: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Absolutely. Ideally there would be no stall for linkProgram. I tried, but it?s too difficult to achieve this in ANGLE. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Jeff Gilbert (jgilbert...@) Sent: Thursday, April 25, 2019 9:33 AM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Possibly, but in the long run, I expect implementations to support no-stall linkProgram invocations. On Wed, Apr 24, 2019 at 6:27 PM Chen, Jie A (jie.a.chen...@) > wrote: linkProgram may stall on compileShader. To avoid the stall, you?d better make sure the COMPLETION_STATUS_KHR statuses of the attached shaders are all True before calling linkProgram. In this sense, the first workflow has less chance running into stall. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Fernando Serrano Garc?a (fserrano...@) Sent: Wednesday, April 24, 2019 9:38 PM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Regarding the optimal proposed workflow (grouping shaders and programs separately) of: for (const x of shaders) gl.compileShader(x); for (const x of programs) gl.linkProgram(x); versus something more on the way that we currently have in many engines as threejs: for (const x of material) gl.compileShader(fs); gl.compileShader(vs); gl.linkProgram(x); Do you think is more or less accurate the following graph for 4 materials and enabling this extension with 2 and 4 parallel threads? [Screen Shot 2019-04-24 at 15.35.47.png] On Wed, Apr 24, 2019 at 2:40 PM Fernando Serrano Garc?a > wrote: fwiw three.js introduced a "debug" parameter (false by default) to determine if there will be a status check and call all the get* (currently in dev): - https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLShader.js#L21-L26 - https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLProgram.js#L608 so currently calling `new WebGLShader()` won't be blocking with any `get*` function and it could be used as is to compile all of them in a loop with or without the extension. the problem comes from the WebGLProgram as it should just queue itself before trying to link any program and wait until all the shader compile calls finish, then do all the link, and wait for it asynchronously before start using these programs. I have opened an issue on the three.js repo to keep track of the implementation and we have booked some time this week to take a look at it, feedback is welcome :) https://github.com/mrdoob/three.js/issues/16321 On Tue, Apr 16, 2019 at 11:55 PM Ken Russell (kbr...@) > wrote: On Tue, Apr 16, 2019 at 2:24 PM Tarek Sherif (tsherif...@) > wrote: Yes, I've read both specs. I think this language in the WebGL version is confusing: "When this extension is enabled: Shader compilation and program linking may be performed in a separate CPU thread." And neither indicates which functions are expected to cause stalls. As written, this extension requires more than most that people know implementation details. All previous operations against the program - looking up uniform locations, drawing with it, etc. - will cause stalls. The application *must* be updated to query the program's COMPLETION_STATUS_KHR status, and skip *all* operations against the program until it's no longer pending. I guess we'll just change the WebGL version of this extension spec to be much more explicit about this. Essentially, all previous code which checked for the completion of compilation of shaders / linking of programs can be updated with a small wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. This is not true because the most common way this is done will cause stalls that sabotage the parallelism, e.g.: https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLShader.js#L21-L36 https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLProgram.js#L586-L631 The check for COMPLETION_STATUS_KHR has to wrap *all* queries and uses of the program object, and they must be skipped until COMPLETION_STATUS_KHR returns true. Yes, all applications will have to be updated to take advantage of this extension, but if they do, the benefits will be significant. -Ken Tarek Sherif Senior Software Engineer, Visualization | Uber http://vis.gl/ On Tue, Apr 16, 2019 at 4:18 PM Ken Russell (kbr...@) > wrote: Please review the Overview in the underlying OpenGL ES spec: https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt It describes that the extension uses one or more separate CPU threads for shader compilation. If you still think we should rewrite the introduction to the WebGL extension, we can do that too. Essentially, all previous code which checked for the completion of compilation of shaders / linking of programs can be updated with a small wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. -Ken On Tue, Apr 16, 2019 at 1:36 AM Tarek Sherif (tsherif...@) > wrote: This is all extremely interesting, and documentation of these best practices should probably be more publicly available (perhaps through a non-normative note in the spec). I'm thinking the language in the extension spec could be made more clear about what it's actual purpose is. It currently gives the impression that enabling it is what allows for parallel compilation and that this should save time, but given what Jeff and Kai have said, it sounds like the purpose is to avoid CPU stalls, and that it might even take longer in wall time since you're only checking once a frame. Maybe some background information could be added along the lines of "Normally applications must wait on get*Parameter or a draw call for program linking to complete, this extension provides a mechanism for querying completion status without stalling..." Tarek Sherif Senior Software Engineer, Visualization | Uber http://vis.gl/ On Mon, Apr 15, 2019 at 11:23 PM Kai Ninomiya (kainino...@) > wrote: On Mon, Apr 15, 2019 at 7:18 PM Tarek Sherif (tareksherif...@) > wrote: I don't see anything in the OpenGL extension spec about what functions cause stalls. Is that implementation-specific? Having an idea what to expect is important for two reasons: 1. To make it clear that drawing will still work if getProgramParameter(COMPLETION_STATUS_KHR) hasn't returned true yet (i.e. the stall on a draw call) Generally, OpenGL extensions are not allowed to break existing API/existing content. (In OpenGL, all extensions are always enabled; there's no requestExtension.) Hence, even if you enable the extension, it won't change the way your application works, and therefore the draw call must still cause a stall in order to be able to use the program. 2. Almost all WebGL code I've looked at handles compilation in a way similar to the following: gl.compileShader(vertexShader); if (!gl.getShaderParameter(vertexShader, gl.COMPILE_STATUS)) //... gl.compileShader(fragmentShader); if (!gl.getShaderParameter(fragmentShader, gl.COMPILE_STATUS)) //... //... gl.linkProgram(program); if (!gl.getProgramParameter(program, gl.LINK_STATUS)) //... I think it would be worth it to make clear that this pattern would sabotage the parallel compile. I seem to remember (not sure if this is still true) that this pattern also sabotages the shader compiler cache in ANGLE, because ANGLE doesn't cache the COMPILE_STATUS (or was it the compile info string?). So it forces the compiler to recompile just to give you the status. Tarek Sherif http://tareksherif.net/ ??????? Original Message ??????? On Monday, April 15, 2019 9:00 PM, Ken Russell (kbr...@) > wrote: The WebGL extension (which is basically just a wrapper) refers to the underlying OpenGL / OpenGL ES extension https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt, where this is documented. Is that sufficient? It would be better to avoid duplicating a large amount of spec text from the underlying extension. However, we can add some non-normative text if that would help. -Ken On Sat, Apr 13, 2019 at 3:51 AM Tarek Sherif (tareksherif...@) > wrote: IIRC, all 3 of those functions still force a wait for the {shader to finish compiling, program to finish linking} just as they did before. The new semantics are only visible via the new COMPLETION_STATUS_KHR check. That should work perfectly for us. Can we add some language to the spec about which functions cause stalls? I feel like as written, it will be easy for people to use the extension incorrectly. Tarek Sherif http://tareksherif.net/ ??????? Original Message ??????? On Friday, April 12, 2019 4:10 PM, Kai Ninomiya (kainino...@) > wrote: Oh yes, useProgram probably won't stall. But getUniformLocation and the others will stall, as will draw calls. getProgramParameter(COMPLETION_STATUS_KHR) should get faster at some point; see http://crbug.com/881152 which Ken linked. On Fri, Apr 12, 2019 at 12:39 PM Jasper St. Pierre (jstpierre...@) > wrote: Thank you! Trying this out in my own WebGL 2 app, I see quite a reduction in shader compilation time, shaving 400ms on load time on a moderately complex scene. The getProgramParameter(COMPLETION_STATUS_KHR) query still takes 1ms (which I believe is being tracked), but that is still better from the 4ms I see in getUniformBlockIndex (my previous sync point). AFAIK, useProgram should not cause a stall, but in order to set my texture samplers to bind to different units, I need to do a getUniformLocation on my sampler uniform, which causes a compilation stall. Same thing with getUniformBlockIndex. Do make sure that anything that might query into reflection about the program (e.g. getVertexAttributeIndex, getUniformLocation, getUniformBlockIndex) happens after COMPLETION_STATUS_KHR returns true, since that?s another way to accidentally stall on compilation completing. From: owners-public_webgl...@ > On Behalf Of Kai Ninomiya (kainino...@) Sent: Friday, April 12, 2019 10:25 AM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved IIRC, all 3 of those functions still force a wait for the {shader to finish compiling, program to finish linking} just as they did before. The new semantics are only visible via the new COMPLETION_STATUS_KHR check. On Fri, Apr 12, 2019 at 10:05 AM Tarek Sherif (tsherif...@) > wrote: Very excited about this extension, but I'm concerned about how it would work in our use case. Our flagship visualization library, deck.gl, often shares the gl context with a separate base map rendering application so that it can properly interleave visualization layers with the base map. Enabling this extension seems to change the behaviour of existing WebGL functions in a way that I don't believe other extensions do. My worry is how our enabling KHR_parallel_shader_compile would affect applications we share contexts with, i.e what happens if the typical synchronous compilation logic is used after KHR_parallel_shader_compile is enabled? Specifically: * What happens if getShaderParameter(shader, COMPILE_STATUS) is called before compilation is complete? * What happens if getProgramParameter(program, LINK_STATUS) is called before linking is complete? * What happens if useProgram is called before linking is complete? Thanks, Tarek Sherif Senior Software Engineer, Visualization | Uber http://vis.gl/ Tarek Sherif Senior Software Engineer, Visualization | Uber http://vis.gl/ On Fri, Apr 12, 2019 at 12:16 PM David Catuhe (David.Catuhe...@) > wrote: Wonderful! From: owners-public_webgl...@ > On Behalf Of Ken Russell (kbr...@) Sent: Wednesday, April 10, 2019 2:56 PM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved If your code works correctly now when enabling draft WebGL extensions in Chrome, then no changes are needed. There won't be any changes to the extension when it's taken out of draft status; it'll just be available by default. -Ken On Wed, Apr 10, 2019 at 12:36 PM David Catuhe (David.Catuhe...@) > wrote: We do have support for the extension in Babylon.js. How can we test this change? ________________________________ From: owners-public_webgl...@ > on behalf of Ken Russell (kbr...@) > Sent: Wednesday, April 10, 2019 12:00:25 PM To: public Subject: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved WebGL community, Jie Chen from Intel has principally developed and implemented a WebGL wrapper for the KHR_parallel_shader_compile extension. This allows shader compilation and program linking to occur fully in parallel to the rest of the WebGL application. Some small application changes are needed to take full advantage of the extension, but it is otherwise fully backward compatible. Jie has even emulated this extension on platforms which don't support it natively. This extension solves a longstanding user complaint with WebGL, namely long shader compile times on Windows. Compiles and links occur not only asynchronously, but also in parallel, so there is a net speedup when using this extension. Users who have tried out the draft extension are pleased with the results and would like to see it made widely available. I propose promoting this extension to community approved in https://github.com/KhronosGroup/WebGL/pull/2855 . Any comments? -Ken [Image removed by sender. https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png] Virus-free. www.avg.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 362 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 82548 bytes Desc: image003.png URL: From pub...@ Sat May 11 22:53:24 2019 From: pub...@ (Kai Ninomiya (...@...)) Date: Sat, 11 May 2019 22:53:24 -0700 Subject: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved In-Reply-To: <5F447A42ADFAFD499D69CF330DF2E5C160661793@SHSMSX101.ccr.corp.intel.com> References: <5F447A42ADFAFD499D69CF330DF2E5C160660987@SHSMSX101.ccr.corp.intel.com> <5F447A42ADFAFD499D69CF330DF2E5C160661691@SHSMSX101.ccr.corp.intel.com> <5F447A42ADFAFD499D69CF330DF2E5C160661793@SHSMSX101.ccr.corp.intel.com> Message-ID: 8ms is an extraordinary long time, in frame rendering time. But do note that we cache that info, so it only takes extra time on the first useProgram. *From: *Chen, Jie A (jie.a.chen...@) *Date: *Sat, May 11, 2019, 8:07 PM *To: *Public WebGL I guess I?ve found the cause for gl.useProgram. WebGL implementation > inserts an extra GL command to query LinkStatus before using it. > > > https://cs.chromium.org/chromium/src/third_party/blink/renderer/modules/webgl/webgl_rendering_context_base.cc?sq=package:chromium&g=0&l=6350 > > > > Anyway I think you don?t need to worry too much about this. Usually it > doesn?t take very long to drain the command buffer. I tried your test case, > which took about only 8ms on my laptop. > > > > > > *From:* owners-public_webgl...@ [mailto: > owners-public_webgl...@] *On Behalf Of *Chen, Jie A ( > jie.a.chen...@) > *Sent:* Sunday, May 12, 2019 9:44 AM > *To:* Public WebGL > *Subject:* RE: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Mostly they are gl.get* like commands. You can search ?WaitForCmd? in > https://cs.chromium.org/chromium/src/gpu/command_buffer/client/gles2_implementation_impl_autogen.h and > > https://cs.chromium.org/chromium/src/gpu/command_buffer/client/gles2_implementation.cc > for them. > > But I don?t think gl.useProgram needs to wait. Most likely it has a > different cause. I will look into it later. > > > > > > *From:* owners-public_webgl...@ [mailto: > owners-public_webgl...@] *On Behalf Of *Takahiro Aoyagi ( > taoyagi...@) > *Sent:* Sunday, May 12, 2019 2:27 AM > *To:* Public WebGL > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Hi Chen, > > > > Thanks for your explanation. > > > > What type of WebGL draw calls need to wait for all queued GL commands? In > my tests, not only gl.get*() > > > > > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime9.html > > > > but also gl.useProgram() seems to wait. > > > > > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime8.html > > > > > That means, I shouldn't call any gl.get*() and also I shouldn't switch > program until all programs compilation+linking are done? > > > > I haven't tried yet but could draw calls wait, too? If so, I shouldn't > render anything until then? > > > > > > [image: Image removed by sender.] > > > Virus-free. www.avg.com > > > > > On Sat, May 11, 2019 at 12:43 PM Chen, Jie A (jie.a.chen...@) < > public_webgl...@> wrote: > > Interesting question, Takahiro. > > My speculation is that the problem might be relevant to chrome?s > multi-process architecture. As you may know, the WebGL calls run in the > main thread of render process. Chrome needs to send these WebGL commands to > the GPU process for actual execution. So in your case, what Chrome actually > does for calls of makeProgram2 is simply putting the GL commands into a IPC > buffer. But later when you retrieve a program parameter back, it then > waits for the execution of all previously issued GL commands including > makeProgram2. > > > > *From:* owners-public_webgl...@ [mailto: > owners-public_webgl...@] *On Behalf Of *Takahiro Aoyagi ( > taoyagi...@) > *Sent:* Saturday, May 11, 2019 6:58 AM > *To:* Public WebGL > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > I'm very glad this extension moves forward. > > > > Question. Can compiling+linking a program block another program's > gl.get*() or gl.useProgram()? > > > > Even after confirming compile+link completion of a program with > COMPLETION_STATUS_KHR, gl.getProgramParameter() or gl.useProgram() seems > being blocked if another program is being compiled+linked on my Windows > Canary. Is this intentional or bug? > > > > > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime8.html > > > > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime9.html > > > > // Confirm program compile+link completion > > if(gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR)) { > > // Compile and link another program > > const vertexShader2 = gl.createShader(gl.VERTEX_SHADER); > const fragmentShader2 = gl.createShader(gl.FRAGMENT_SHADER); > const program2 = gl.createProgram(); > > gl.shaderSource(vertexShader2, vertexShaderCode); > gl.shaderSource(fragmentShader2, fragmentShaderCode); > gl.compileShader(vertexShader2); > gl.compileShader(fragmentShader2); > gl.attachShader(program2, vertexShader2); > gl.attachShader(program2, fragmentShader2); > gl.linkProgram(program2); > > > > // gl.get*() or gl.useProgram() while the other program is being > compiled+linkied > > const startTime = performance.now(); > gl.getProgramParameter(program, gl.ACTIVE_ATTRIBUTES); // or > gl.useProgram(program); > const endTime = performance.now(); > > } > > > > Takahiro > > > > [image: Image removed by sender.] > > > Virus-free. www.avg.com > > > > > On Sat, May 11, 2019 at 6:11 AM Ken Russell (kbr...@) < > public_webgl...@> wrote: > > Since there haven't been any *objections* to moving this extension > forward, and since the benefits are now being seen, it's been moved to > community approved in https://github.com/KhronosGroup/WebGL/pull/2855 . > > > > Please, feel free to continue to report problems with long shader > compilation times - either posting here on this mailing list or on > webgl-dev-list, reporting cross-browser issues on > https://github.com/KhronosGroup/WebGL/issues , or on individual browsers' > bug trackers. > > > > -Ken > > > > > > > > *From: *Ken Russell > *Date: *Fri, May 10, 2019 at 1:39 PM > *To: *Public WebGL > > Super. Thank you Takahiro for testing and confirming! > > > > > > *From: *Takahiro Aoyagi (taoyagi...@) > *Date: *Fri, May 10, 2019 at 10:51 AM > *To: *Public WebGL > > I made simple tests to check the CPU elapsed time of > gl.getProgramParameter() and gl.useProgram() after checking > COMPLETION_STATUS_KHR is true. Both are fast here on my Windows10 Chrome > Canary. > > > > > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime6.html > > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime7.html > > > > Takahiro > > > > [image: Image removed by sender.] > > > Virus-free. www.avg.com > > > > > On Sat, May 11, 2019 at 2:46 AM Ken Russell (kbr...@) < > public_webgl...@> wrote: > > Hmm. The only reason I can think of that that would happen is if you're > running on Windows, and ANGLE has to dynamically recompile the program > behind the scenes in order to handle some OpenGL ES state change. I'm not > 100% sure which changes require this dynamic recompilation; the ANGLE > developers would know best. > https://groups.google.com//forum/#!forum/angleproject > might be helpful. > > > > We'd really need some test case to make progress on this. Can you provide > one? > > > > -Ken > > > > > > On Fri, May 10, 2019 at 10:28 AM Jasper St. Pierre (jstpierre...@) > wrote: > > Hello again. My app is now showing that getProgramParameter is completing > quick, but it is spending a lot of time in useProgram. I am checking for > COMPLETION_STATUS_KHR on the GL program beforehand and it is returning > true. I?m guessing there?s some additional expensive work that still needs > to happen at useProgram time. Is this a bug? Any ways to debug or avoid > this? I?m unsure if there will be an easy repro. > > > > Again, profiler screenshot attached. > > > > *From:* owners-public_webgl...@ *On > Behalf Of *Takahiro Aoyagi (taoyagi...@) > *Sent:* Friday, May 10, 2019 12:22 AM > *To:* Public WebGL > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Confirmed COMPLETION_STATUS_KHR is very fast like 0.01ms on my test > > > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html > > > > Nice work! > > > > Thanks > > > > [image: Image removed by sender. > https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png] > > > Virus-free. www.avg.com > > > > > On Wed, May 8, 2019 at 2:41 PM Ken Russell (kbr...@) < > public_webgl...@> wrote: > > Jie Chen from Intel just landed a fix in Chrome dramatically improving the > performance of querying COMPLETION_STATUS_KHR under > http://crbug.com/881152 . The fix will be in tomorrow's Canary on Windows > and macOS. > > > > This should address the last major gap with this extension. We would like > to enable it by default by promoting it to community approved; any further > comments? > > > > -Ken > > > > > > > > *From: *Ken Russell > *Date: *Fri, Apr 26, 2019 at 3:40 PM > *To: *Public WebGL > > Thanks for the report and the clear test case. There was an existing bug > about this, so the new one was duplicated into it, and some hints about > implementing it were added to the preexisting bug. > > > > > > On Fri, Apr 26, 2019 at 5:56 AM Takahiro Aoyagi (taoyagi...@) < > public_webgl...@> wrote: > > Hi Chen, > > > > Opened a bug. Thanks. > > > > https://bugs.chromium.org/p/chromium/issues/detail?id=957001 > > > > Takahiro > > > > > > On Fri, Apr 26, 2019 at 8:03 PM Chen, Jie A (jie.a.chen...@) < > public_webgl...@> wrote: > > Hi Takahiro, > > The current implementation of COMPLETION_STATUS_KHR query in chromium > incurs an expensive round-trip to the GPU thread. This may contribute to > the wait time in your case. I am trying to optimize this. Could you please > file a bug to chromium? I would look into it once I?ve done the > optimization. > > > > *From:* owners-public_webgl...@ [mailto: > owners-public_webgl...@] *On Behalf Of *Takahiro Aoyagi ( > taoyagi...@) > *Sent:* Friday, April 26, 2019 6:20 PM > *To:* Public WebGL > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Hi all, > > > > I'm working on Three.js + KHR_parallel_shader_compile extension support > with Fernando. > > > > https://github.com/mrdoob/three.js/issues/16321#issuecomment-486436086 > > > > I'm testing with Canary. But the behavior seems weird to me. > gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) seems to wait > for compile+link completion. I don't think it should wait for that, it > should just do polling and returning true/false quickly instead. > > > > I made a simple test to reproduce. > > > > > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html > > > > Code snippet. > > > > const ext = gl.getExtension('KHR_parallel_shader_compile'); > > > > gl.compileShader(vertexShader); > gl.compileShader(fragmentShader); > gl.attachShader(program, vertexShader); > gl.attachShader(program, fragmentShader); > gl.linkProgram(program); > > const startTime = performance.now(); > const status = useExtension > ? gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) > : gl.getProgramParameter(program, gl.LINK_STATUS); > const endTime = performance.now(); > > const elapsedTime = endTime - startTime; > > > > On my platform, both gl.LINK_STATUS and ext.COMPLETION_STATUS_KHR take so > long time about 15ms. I can accept this number for gl.LINK_STATUS because > it waits for compile+link completion. But 15ms for > ext.COMPLETION_STATUS_KHR looks weird to me. It shouldn't wait for the > compile+link completion but should do just polling and quickly returning > true/false instead. So I guess the number should be 1ms or less. > > > > Let me know if I'm missing something. Or could it be a Canary bug? > > > > My platform. > > > > OS: Windows10 > > Browser: Chrome Canary. > > Browser boot option: --use-cmd-decoder=passthrough > --enable-webgl-draft-extensions > > > > > > Thanks > > > > Takahiro > > > > > > On Fri, Apr 26, 2019 at 10:15 AM Chen, Jie A (jie.a.chen...@) < > public_webgl...@> wrote: > > Basically, for ANGLE?s GL backend, it?s simply a wrapper for the existing > GL implementations. In this sense glCompileShader() is still implementation > specific. Essentially ANGLE just calls glCompileShader and check > GL_COMPILE_STATUS. > > > > *From:* owners-public_webgl...@ [mailto: > owners-public_webgl...@] *On Behalf Of *Jasper St. Pierre ( > jstpierre...@) > *Sent:* Friday, April 26, 2019 1:18 AM > *To:* Public WebGL > *Subject:* RE: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Thank you, that?s important information to know. Changing my shader > compilation pipeline to wait for shader completion status is a lot more > difficult, but based on some initial tests, it?s more expensive than not > doing it ? the latency of getShaderParameter is too high. > > > > That said, in a lot of GL implementations, glCompileShader() is > practically a no-op, and will only do an AST parse when > glGetShaderParameter/InfoLog() is called (which is basically only for > debugging / error checking). glLinkProgram() does full compilation of all > programs, as full-PSO optimization is important. I don?t know how common > this is, but multiple GL implementations I have seen do it. It might make > sense for ANGLE to adopt this model as well. > > > > *From:* owners-public_webgl...@ *On > Behalf Of *Chen, Jie A (jie.a.chen...@) > *Sent:* Wednesday, April 24, 2019 6:48 PM > *To:* Public WebGL > *Subject:* RE: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Absolutely. Ideally there would be no stall for linkProgram. I tried, but > it?s too difficult to achieve this in ANGLE. > > > > *From:* owners-public_webgl...@ [ > mailto:owners-public_webgl...@ ] *On > Behalf Of *Jeff Gilbert (jgilbert...@) > *Sent:* Thursday, April 25, 2019 9:33 AM > *To:* Public WebGL > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Possibly, but in the long run, I expect implementations to support > no-stall linkProgram invocations. > > > > On Wed, Apr 24, 2019 at 6:27 PM Chen, Jie A (jie.a.chen...@) < > public_webgl...@> wrote: > > linkProgram may stall on compileShader. To avoid the stall, you?d better > make sure the COMPLETION_STATUS_KHR statuses of the attached shaders are > all True before calling linkProgram. In this sense, the first workflow has > less chance running into stall. > > > > *From:* owners-public_webgl...@ [mailto: > owners-public_webgl...@] *On Behalf Of *Fernando Serrano Garc?a ( > fserrano...@) > *Sent:* Wednesday, April 24, 2019 9:38 PM > *To:* Public WebGL > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Regarding the optimal proposed workflow (grouping shaders and programs > separately) of: > > for (const x of shaders) > gl.compileShader(x); > for (const x of programs) > gl.linkProgram(x); > > > > versus something more on the way that we currently have in many engines as > threejs: > > for (const x of material) > > gl.compileShader(fs); > > gl.compileShader(vs); > gl.linkProgram(x); > > > > Do you think is more or less accurate the following graph for 4 materials > and enabling this extension with 2 and 4 parallel threads? > > > > [image: Screen Shot 2019-04-24 at 15.35.47.png] > > > > On Wed, Apr 24, 2019 at 2:40 PM Fernando Serrano Garc?a < > fserrano...@> wrote: > > fwiw three.js introduced a "debug" parameter (false by default) to > determine if there will be a status check and call all the get* (currently > in dev): > > - > https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLShader.js#L21-L26 > > - > https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLProgram.js#L608 > > > > so currently calling `new WebGLShader()` won't be blocking with any `get*` > function and it could be used as is to compile all of them in a loop with > or without the extension. > > the problem comes from the WebGLProgram as it should just queue itself > before trying to link any program and wait until all the shader compile > calls finish, then do all the link, and wait for it asynchronously before > start using these programs. > > I have opened an issue on the three.js repo to keep track of the > implementation and we have booked some time this week to take a look at it, > feedback is welcome :) https://github.com/mrdoob/three.js/issues/16321 > > > > On Tue, Apr 16, 2019 at 11:55 PM Ken Russell (kbr...@) < > public_webgl...@> wrote: > > On Tue, Apr 16, 2019 at 2:24 PM Tarek Sherif (tsherif...@) < > public_webgl...@> wrote: > > Yes, I've read both specs. I think this language in the WebGL version is > confusing: "When this extension is enabled: Shader compilation and program > linking may be performed in a separate CPU thread." And neither indicates > which functions are expected to cause stalls. As written, this extension > requires more than most that people know implementation details. > > > > All previous operations against the program - looking up uniform > locations, drawing with it, etc. - will cause stalls. The application > *must* be updated to query the program's COMPLETION_STATUS_KHR status, and > skip *all* operations against the program until it's no longer pending. > > > > I guess we'll just change the WebGL version of this extension spec to be > much more explicit about this. > > > > > > Essentially, all previous code which checked for the completion of > compilation of shaders / linking of programs can be updated with a small > wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. > > > > This is not true because the most common way this is done will cause > stalls that sabotage the parallelism, e.g.: > > https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLShader.js#L21-L36 > > > https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLProgram.js#L586-L631 > > > > The check for COMPLETION_STATUS_KHR has to wrap *all* queries and uses of > the program object, and they must be skipped until COMPLETION_STATUS_KHR > returns true. Yes, all applications will have to be updated to take > advantage of this extension, but if they do, the benefits will be > significant. > > > > -Ken > > > > > > *Tarek Sherif* > > Senior Software Engineer, Visualization | Uber > > http://vis.gl/ > > > > > > > > On Tue, Apr 16, 2019 at 4:18 PM Ken Russell (kbr...@) < > public_webgl...@> wrote: > > Please review the Overview in the underlying OpenGL ES spec: > > > https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt > > > > > It describes that the extension uses one or more separate CPU threads for > shader compilation. If you still think we should rewrite the introduction > to the WebGL extension, we can do that too. > > > > Essentially, all previous code which checked for the completion of > compilation of shaders / linking of programs can be updated with a small > wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. > > > > -Ken > > > > > > > > On Tue, Apr 16, 2019 at 1:36 AM Tarek Sherif (tsherif...@) < > public_webgl...@> wrote: > > This is all extremely interesting, and documentation of these best > practices should probably be more publicly available (perhaps through a > non-normative note in the spec). I'm thinking the language in the extension > spec could be made more clear about what it's actual purpose is. It > currently gives the impression that enabling it is what allows for parallel > compilation and that this should save time, but given what Jeff and Kai > have said, it sounds like the purpose is to avoid CPU stalls, and that it > might even take longer in wall time since you're only checking once a > frame. Maybe some background information could be added along the lines of > "Normally applications must wait on get*Parameter or a draw call for > program linking to complete, this extension provides a mechanism for > querying completion status without stalling..." > > > > *Tarek Sherif* > > Senior Software Engineer, Visualization | Uber > > http://vis.gl/ > > > > > > > > > On Mon, Apr 15, 2019 at 11:23 PM Kai Ninomiya (kainino...@) < > public_webgl...@> wrote: > > > > > > On Mon, Apr 15, 2019 at 7:18 PM Tarek Sherif (tareksherif...@) < > public_webgl...@> wrote: > > I don't see anything in the OpenGL extension spec about what functions > cause stalls. Is that implementation-specific? Having an idea what to > expect is important for two reasons: > > 1. To make it clear that drawing will still work if > getProgramParameter(COMPLETION_STATUS_KHR) hasn't returned true yet (i.e. > the stall on a draw call) > > > > Generally, OpenGL extensions are not allowed to break existing > API/existing content. (In OpenGL, all extensions are always enabled; > there's no requestExtension.) Hence, even if you enable the extension, it > won't change the way your application works, and therefore the draw call > must still cause a stall in order to be able to use the program. > > > > 2. Almost all WebGL code I've looked at handles compilation in a way > similar to the following: > > gl.compileShader(vertexShader); > if (!gl.getShaderParameter(vertexShader, gl.COMPILE_STATUS)) //... > > gl.compileShader(fragmentShader); > > if (!gl.getShaderParameter(fragmentShader, gl.COMPILE_STATUS)) //... > > //... > > gl.linkProgram(program); > if (!gl.getProgramParameter(program, gl.LINK_STATUS)) //... > > I think it would be worth it to make clear that this pattern would > sabotage the parallel compile. > > > > I seem to remember (not sure if this is still true) that this pattern also > sabotages the shader compiler cache in ANGLE, because ANGLE doesn't cache > the COMPILE_STATUS (or was it the compile info string?). So it forces the > compiler to recompile just to give you the status. > > > > Tarek Sherif > > http://tareksherif.net/ > > > > > > > > > ??????? Original Message ??????? > > On Monday, April 15, 2019 9:00 PM, Ken Russell (kbr...@) < > public_webgl...@> wrote: > > > > The WebGL extension (which is basically just a wrapper) refers to the > underlying OpenGL / OpenGL ES extension > https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt > , > where this is documented. Is that sufficient? It would be better to avoid > duplicating a large amount of spec text from the underlying extension. > However, we can add some non-normative text if that would help. > > > > -Ken > > > > > > > > On Sat, Apr 13, 2019 at 3:51 AM Tarek Sherif (tareksherif...@) < > public_webgl...@> wrote: > > IIRC, all 3 of those functions still force a wait for the {shader to > finish compiling, program to finish linking} just as they did before. The > new semantics are only visible via the new COMPLETION_STATUS_KHR check. > > That should work perfectly for us. Can we add some language to the spec > about which functions cause stalls? I feel like as written, it will be easy > for people to use the extension incorrectly. > > > > Tarek Sherif > > http://tareksherif.net/ > > > > > > > > > ??????? Original Message ??????? > > On Friday, April 12, 2019 4:10 PM, Kai Ninomiya (kainino...@) < > public_webgl...@> wrote: > > > > Oh yes, useProgram probably won't stall. But getUniformLocation and the > others will stall, as will draw calls. > > > > getProgramParameter(COMPLETION_STATUS_KHR) should get faster at some > point; see http://crbug.com/881152 > which > Ken linked. > > > > On Fri, Apr 12, 2019 at 12:39 PM Jasper St. Pierre (jstpierre...@) > wrote: > > Thank you! Trying this out in my own WebGL 2 app, I see quite a reduction > in shader compilation time, shaving 400ms on load time on a moderately > complex scene. The getProgramParameter(COMPLETION_STATUS_KHR) query still > takes 1ms (which I believe is being tracked), but that is still better from > the 4ms I see in getUniformBlockIndex (my previous sync point). > > > > AFAIK, useProgram should not cause a stall, but in order to set my texture > samplers to bind to different units, I need to do a getUniformLocation on > my sampler uniform, which causes a compilation stall. Same thing with > getUniformBlockIndex. Do make sure that anything that might query into > reflection about the program (e.g. getVertexAttributeIndex, > getUniformLocation, getUniformBlockIndex) happens after > COMPLETION_STATUS_KHR returns true, since that?s another way to > accidentally stall on compilation completing. > > > > > > *From:* owners-public_webgl...@ *On > Behalf Of *Kai Ninomiya (kainino...@) > > *Sent:* Friday, April 12, 2019 10:25 AM > > *To:* Public WebGL > > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > > > IIRC, all 3 of those functions still force a wait for the {shader to > finish compiling, program to finish linking} just as they did before. The > new semantics are only visible via the new COMPLETION_STATUS_KHR check. > > > > On Fri, Apr 12, 2019 at 10:05 AM Tarek Sherif (tsherif...@) < > public_webgl...@> wrote: > > Very excited about this extension, but I'm concerned about how it would > work in our use case. Our flagship visualization library, deck.gl > , > often shares the gl context with a separate base map rendering application > so that it can properly interleave visualization layers with the base map. > Enabling this extension seems to change the behaviour of existing WebGL > functions in a way that I don't believe other extensions do. My worry is > how our enabling KHR_parallel_shader_compile would affect applications we > share contexts with, i.e what happens if the typical synchronous > compilation logic is used after KHR_parallel_shader_compile is enabled? > Specifically: > > - What happens if getShaderParameter(shader, COMPILE_STATUS) is called > before compilation is complete? > - What happens if getProgramParameter(program, LINK_STATUS) is called > before linking is complete? > - What happens if useProgram is called before linking is complete? > > Thanks, > > > > > > Tarek Sherif > > Senior Software Engineer, Visualization | Uber > > http://vis.gl/ > > > > > > > > > > > *Tarek Sherif* > > Senior Software Engineer, Visualization | Uber > > http://vis.gl/ > > > > > > > On Fri, Apr 12, 2019 at 12:16 PM David Catuhe (David.Catuhe...@) > wrote: > > Wonderful! > > > > > > *From:* owners-public_webgl...@ *On > Behalf Of *Ken Russell (kbr...@) > > *Sent:* Wednesday, April 10, 2019 2:56 PM > > *To:* Public WebGL > > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > > > If your code works correctly now when enabling draft WebGL extensions in > Chrome, then no changes are needed. There won't be any changes to the > extension when it's taken out of draft status; it'll just be available by > default. > > > > -Ken > > > > > > On Wed, Apr 10, 2019 at 12:36 PM David Catuhe (David.Catuhe...@) > wrote: > > We do have support for the extension in Babylon.js. How can we test this > change? > ------------------------------ > > > > *From:* owners-public_webgl...@ > on behalf of Ken Russell (kbr...@) > *Sent:* Wednesday, April 10, 2019 12:00:25 PM > *To:* public > *Subject:* [Public WebGL] Propose promoting KHR_parallel_shader_compile > to community approved > > > > WebGL community, > > > > Jie Chen from Intel has principally developed and implemented a WebGL > wrapper for the KHR_parallel_shader_compile extension. This allows shader > compilation and program linking to occur fully in parallel to the rest of > the WebGL application. Some small application changes are needed to take > full advantage of the extension, but it is otherwise fully backward > compatible. Jie has even emulated this extension on platforms which don't > support it natively. > > > > This extension solves a longstanding user complaint with WebGL, namely > long shader compile times on Windows. Compiles and links occur not only > asynchronously, but also in parallel, so there is a net speedup when using > this extension. Users who have tried out the draft extension are pleased > with the results and would like to see it made widely available. > > > > I propose promoting this extension to community approved in > https://github.com/KhronosGroup/WebGL/pull/2855 > > . Any comments? > > > > -Ken > > > > > > > > > > [image: Image removed by sender. > https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png] > > > Virus-free. www.avg.com > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 362 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4845 bytes Desc: S/MIME Cryptographic Signature URL: From pub...@ Sun May 12 02:12:52 2019 From: pub...@ (Takahiro Aoyagi (...@...)) Date: Sun, 12 May 2019 18:12:52 +0900 Subject: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved In-Reply-To: References: <5F447A42ADFAFD499D69CF330DF2E5C160660987@SHSMSX101.ccr.corp.intel.com> <5F447A42ADFAFD499D69CF330DF2E5C160661691@SHSMSX101.ccr.corp.intel.com> <5F447A42ADFAFD499D69CF330DF2E5C160661793@SHSMSX101.ccr.corp.intel.com> Message-ID: Thanks for the comments, Chen and Kai. Yeah, 8ms is very long to me. And if I compile+link two or more programs the time can be longer. > I guess I?ve found the cause for gl.useProgram. WebGL implementation inserts an extra GL command to query LinkStatus before using it. Will this be optimized (not adding the extra GL command) at some point? Or must it be necessary? > But do note that we cache that info, so it only takes extra time on the first useProgram. I confirmed that on my test. https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime10.html So far I'll try not to switch to a program which hasn't been called with gl.useProgram() yet while at least one program is being compiled+linked. On Sun, May 12, 2019 at 2:54 PM Kai Ninomiya (kainino...@) < public_webgl...@> wrote: > 8ms is an extraordinary long time, in frame rendering time. > > But do note that we cache that info, so it only takes extra time on the > first useProgram. > > *From: *Chen, Jie A (jie.a.chen...@) > *Date: *Sat, May 11, 2019, 8:07 PM > *To: *Public WebGL > > I guess I?ve found the cause for gl.useProgram. WebGL implementation >> inserts an extra GL command to query LinkStatus before using it. >> >> >> https://cs.chromium.org/chromium/src/third_party/blink/renderer/modules/webgl/webgl_rendering_context_base.cc?sq=package:chromium&g=0&l=6350 >> >> >> >> Anyway I think you don?t need to worry too much about this. Usually it >> doesn?t take very long to drain the command buffer. I tried your test case, >> which took about only 8ms on my laptop. >> >> >> >> >> >> *From:* owners-public_webgl...@ [mailto: >> owners-public_webgl...@] *On Behalf Of *Chen, Jie A ( >> jie.a.chen...@) >> *Sent:* Sunday, May 12, 2019 9:44 AM >> *To:* Public WebGL >> *Subject:* RE: [Public WebGL] Propose promoting >> KHR_parallel_shader_compile to community approved >> >> >> >> Mostly they are gl.get* like commands. You can search ?WaitForCmd? in >> https://cs.chromium.org/chromium/src/gpu/command_buffer/client/gles2_implementation_impl_autogen.h and >> >> https://cs.chromium.org/chromium/src/gpu/command_buffer/client/gles2_implementation.cc >> for them. >> >> But I don?t think gl.useProgram needs to wait. Most likely it has a >> different cause. I will look into it later. >> >> >> >> >> >> *From:* owners-public_webgl...@ [mailto: >> owners-public_webgl...@] *On Behalf Of *Takahiro Aoyagi ( >> taoyagi...@) >> *Sent:* Sunday, May 12, 2019 2:27 AM >> *To:* Public WebGL >> *Subject:* Re: [Public WebGL] Propose promoting >> KHR_parallel_shader_compile to community approved >> >> >> >> Hi Chen, >> >> >> >> Thanks for your explanation. >> >> >> >> What type of WebGL draw calls need to wait for all queued GL commands? In >> my tests, not only gl.get*() >> >> >> >> >> https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime9.html >> >> >> >> but also gl.useProgram() seems to wait. >> >> >> >> >> https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime8.html >> >> >> >> >> That means, I shouldn't call any gl.get*() and also I shouldn't switch >> program until all programs compilation+linking are done? >> >> >> >> I haven't tried yet but could draw calls wait, too? If so, I shouldn't >> render anything until then? >> >> >> >> >> >> [image: Image removed by sender.] >> >> >> Virus-free. www.avg.com >> >> >> >> >> On Sat, May 11, 2019 at 12:43 PM Chen, Jie A (jie.a.chen...@) < >> public_webgl...@> wrote: >> >> Interesting question, Takahiro. >> >> My speculation is that the problem might be relevant to chrome?s >> multi-process architecture. As you may know, the WebGL calls run in the >> main thread of render process. Chrome needs to send these WebGL commands to >> the GPU process for actual execution. So in your case, what Chrome actually >> does for calls of makeProgram2 is simply putting the GL commands into a IPC >> buffer. But later when you retrieve a program parameter back, it then >> waits for the execution of all previously issued GL commands including >> makeProgram2. >> >> >> >> *From:* owners-public_webgl...@ [mailto: >> owners-public_webgl...@] *On Behalf Of *Takahiro Aoyagi ( >> taoyagi...@) >> *Sent:* Saturday, May 11, 2019 6:58 AM >> *To:* Public WebGL >> *Subject:* Re: [Public WebGL] Propose promoting >> KHR_parallel_shader_compile to community approved >> >> >> >> I'm very glad this extension moves forward. >> >> >> >> Question. Can compiling+linking a program block another program's >> gl.get*() or gl.useProgram()? >> >> >> >> Even after confirming compile+link completion of a program with >> COMPLETION_STATUS_KHR, gl.getProgramParameter() or gl.useProgram() seems >> being blocked if another program is being compiled+linked on my Windows >> Canary. Is this intentional or bug? >> >> >> >> >> https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime8.html >> >> >> >> https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime9.html >> >> >> >> // Confirm program compile+link completion >> >> if(gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR)) { >> >> // Compile and link another program >> >> const vertexShader2 = gl.createShader(gl.VERTEX_SHADER); >> const fragmentShader2 = gl.createShader(gl.FRAGMENT_SHADER); >> const program2 = gl.createProgram(); >> >> gl.shaderSource(vertexShader2, vertexShaderCode); >> gl.shaderSource(fragmentShader2, fragmentShaderCode); >> gl.compileShader(vertexShader2); >> gl.compileShader(fragmentShader2); >> gl.attachShader(program2, vertexShader2); >> gl.attachShader(program2, fragmentShader2); >> gl.linkProgram(program2); >> >> >> >> // gl.get*() or gl.useProgram() while the other program is being >> compiled+linkied >> >> const startTime = performance.now(); >> gl.getProgramParameter(program, gl.ACTIVE_ATTRIBUTES); // or >> gl.useProgram(program); >> const endTime = performance.now(); >> >> } >> >> >> >> Takahiro >> >> >> >> [image: Image removed by sender.] >> >> >> Virus-free. www.avg.com >> >> >> >> >> On Sat, May 11, 2019 at 6:11 AM Ken Russell (kbr...@) < >> public_webgl...@> wrote: >> >> Since there haven't been any *objections* to moving this extension >> forward, and since the benefits are now being seen, it's been moved to >> community approved in https://github.com/KhronosGroup/WebGL/pull/2855 . >> >> >> >> Please, feel free to continue to report problems with long shader >> compilation times - either posting here on this mailing list or on >> webgl-dev-list, reporting cross-browser issues on >> https://github.com/KhronosGroup/WebGL/issues , or on individual >> browsers' bug trackers. >> >> >> >> -Ken >> >> >> >> >> >> >> >> *From: *Ken Russell >> *Date: *Fri, May 10, 2019 at 1:39 PM >> *To: *Public WebGL >> >> Super. Thank you Takahiro for testing and confirming! >> >> >> >> >> >> *From: *Takahiro Aoyagi (taoyagi...@) >> *Date: *Fri, May 10, 2019 at 10:51 AM >> *To: *Public WebGL >> >> I made simple tests to check the CPU elapsed time of >> gl.getProgramParameter() and gl.useProgram() after checking >> COMPLETION_STATUS_KHR is true. Both are fast here on my Windows10 Chrome >> Canary. >> >> >> >> >> https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime6.html >> >> https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime7.html >> >> >> >> Takahiro >> >> >> >> [image: Image removed by sender.] >> >> >> Virus-free. www.avg.com >> >> >> >> >> On Sat, May 11, 2019 at 2:46 AM Ken Russell (kbr...@) < >> public_webgl...@> wrote: >> >> Hmm. The only reason I can think of that that would happen is if you're >> running on Windows, and ANGLE has to dynamically recompile the program >> behind the scenes in order to handle some OpenGL ES state change. I'm not >> 100% sure which changes require this dynamic recompilation; the ANGLE >> developers would know best. >> https://groups.google.com//forum/#!forum/angleproject >> might be helpful. >> >> >> >> We'd really need some test case to make progress on this. Can you provide >> one? >> >> >> >> -Ken >> >> >> >> >> >> On Fri, May 10, 2019 at 10:28 AM Jasper St. Pierre (jstpierre...@) >> wrote: >> >> Hello again. My app is now showing that getProgramParameter is completing >> quick, but it is spending a lot of time in useProgram. I am checking for >> COMPLETION_STATUS_KHR on the GL program beforehand and it is returning >> true. I?m guessing there?s some additional expensive work that still needs >> to happen at useProgram time. Is this a bug? Any ways to debug or avoid >> this? I?m unsure if there will be an easy repro. >> >> >> >> Again, profiler screenshot attached. >> >> >> >> *From:* owners-public_webgl...@ >> *On Behalf Of *Takahiro Aoyagi (taoyagi...@) >> *Sent:* Friday, May 10, 2019 12:22 AM >> *To:* Public WebGL >> *Subject:* Re: [Public WebGL] Propose promoting >> KHR_parallel_shader_compile to community approved >> >> >> >> Confirmed COMPLETION_STATUS_KHR is very fast like 0.01ms on my test >> >> >> https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html >> >> >> >> Nice work! >> >> >> >> Thanks >> >> >> >> [image: Image removed by sender. >> https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png] >> >> >> Virus-free. www.avg.com >> >> >> >> >> On Wed, May 8, 2019 at 2:41 PM Ken Russell (kbr...@) < >> public_webgl...@> wrote: >> >> Jie Chen from Intel just landed a fix in Chrome dramatically improving >> the performance of querying COMPLETION_STATUS_KHR under >> http://crbug.com/881152 . The fix will be in tomorrow's Canary on >> Windows and macOS. >> >> >> >> This should address the last major gap with this extension. We would like >> to enable it by default by promoting it to community approved; any further >> comments? >> >> >> >> -Ken >> >> >> >> >> >> >> >> *From: *Ken Russell >> *Date: *Fri, Apr 26, 2019 at 3:40 PM >> *To: *Public WebGL >> >> Thanks for the report and the clear test case. There was an existing bug >> about this, so the new one was duplicated into it, and some hints about >> implementing it were added to the preexisting bug. >> >> >> >> >> >> On Fri, Apr 26, 2019 at 5:56 AM Takahiro Aoyagi (taoyagi...@) < >> public_webgl...@> wrote: >> >> Hi Chen, >> >> >> >> Opened a bug. Thanks. >> >> >> >> https://bugs.chromium.org/p/chromium/issues/detail?id=957001 >> >> >> >> Takahiro >> >> >> >> >> >> On Fri, Apr 26, 2019 at 8:03 PM Chen, Jie A (jie.a.chen...@) < >> public_webgl...@> wrote: >> >> Hi Takahiro, >> >> The current implementation of COMPLETION_STATUS_KHR query in >> chromium incurs an expensive round-trip to the GPU thread. This may >> contribute to the wait time in your case. I am trying to optimize this. >> Could you please file a bug to chromium? I would look into it once I?ve >> done the optimization. >> >> >> >> *From:* owners-public_webgl...@ [mailto: >> owners-public_webgl...@] *On Behalf Of *Takahiro Aoyagi ( >> taoyagi...@) >> *Sent:* Friday, April 26, 2019 6:20 PM >> *To:* Public WebGL >> *Subject:* Re: [Public WebGL] Propose promoting >> KHR_parallel_shader_compile to community approved >> >> >> >> Hi all, >> >> >> >> I'm working on Three.js + KHR_parallel_shader_compile extension support >> with Fernando. >> >> >> >> https://github.com/mrdoob/three.js/issues/16321#issuecomment-486436086 >> >> >> >> I'm testing with Canary. But the behavior seems weird to me. >> gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) seems to wait >> for compile+link completion. I don't think it should wait for that, it >> should just do polling and returning true/false quickly instead. >> >> >> >> I made a simple test to reproduce. >> >> >> >> >> https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html >> >> >> >> Code snippet. >> >> >> >> const ext = gl.getExtension('KHR_parallel_shader_compile'); >> >> >> >> gl.compileShader(vertexShader); >> gl.compileShader(fragmentShader); >> gl.attachShader(program, vertexShader); >> gl.attachShader(program, fragmentShader); >> gl.linkProgram(program); >> >> const startTime = performance.now(); >> const status = useExtension >> ? gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) >> : gl.getProgramParameter(program, gl.LINK_STATUS); >> const endTime = performance.now(); >> >> const elapsedTime = endTime - startTime; >> >> >> >> On my platform, both gl.LINK_STATUS and ext.COMPLETION_STATUS_KHR take so >> long time about 15ms. I can accept this number for gl.LINK_STATUS because >> it waits for compile+link completion. But 15ms for >> ext.COMPLETION_STATUS_KHR looks weird to me. It shouldn't wait for the >> compile+link completion but should do just polling and quickly returning >> true/false instead. So I guess the number should be 1ms or less. >> >> >> >> Let me know if I'm missing something. Or could it be a Canary bug? >> >> >> >> My platform. >> >> >> >> OS: Windows10 >> >> Browser: Chrome Canary. >> >> Browser boot option: --use-cmd-decoder=passthrough >> --enable-webgl-draft-extensions >> >> >> >> >> >> Thanks >> >> >> >> Takahiro >> >> >> >> >> >> On Fri, Apr 26, 2019 at 10:15 AM Chen, Jie A (jie.a.chen...@) < >> public_webgl...@> wrote: >> >> Basically, for ANGLE?s GL backend, it?s simply a wrapper for the existing >> GL implementations. In this sense glCompileShader() is still implementation >> specific. Essentially ANGLE just calls glCompileShader and check >> GL_COMPILE_STATUS. >> >> >> >> *From:* owners-public_webgl...@ [mailto: >> owners-public_webgl...@] *On Behalf Of *Jasper St. Pierre ( >> jstpierre...@) >> *Sent:* Friday, April 26, 2019 1:18 AM >> *To:* Public WebGL >> *Subject:* RE: [Public WebGL] Propose promoting >> KHR_parallel_shader_compile to community approved >> >> >> >> Thank you, that?s important information to know. Changing my shader >> compilation pipeline to wait for shader completion status is a lot more >> difficult, but based on some initial tests, it?s more expensive than not >> doing it ? the latency of getShaderParameter is too high. >> >> >> >> That said, in a lot of GL implementations, glCompileShader() is >> practically a no-op, and will only do an AST parse when >> glGetShaderParameter/InfoLog() is called (which is basically only for >> debugging / error checking). glLinkProgram() does full compilation of all >> programs, as full-PSO optimization is important. I don?t know how common >> this is, but multiple GL implementations I have seen do it. It might make >> sense for ANGLE to adopt this model as well. >> >> >> >> *From:* owners-public_webgl...@ >> *On Behalf Of *Chen, Jie A (jie.a.chen...@) >> *Sent:* Wednesday, April 24, 2019 6:48 PM >> *To:* Public WebGL >> *Subject:* RE: [Public WebGL] Propose promoting >> KHR_parallel_shader_compile to community approved >> >> >> >> Absolutely. Ideally there would be no stall for linkProgram. I tried, but >> it?s too difficult to achieve this in ANGLE. >> >> >> >> *From:* owners-public_webgl...@ [ >> mailto:owners-public_webgl...@ ] >> *On Behalf Of *Jeff Gilbert (jgilbert...@) >> *Sent:* Thursday, April 25, 2019 9:33 AM >> *To:* Public WebGL >> *Subject:* Re: [Public WebGL] Propose promoting >> KHR_parallel_shader_compile to community approved >> >> >> >> Possibly, but in the long run, I expect implementations to support >> no-stall linkProgram invocations. >> >> >> >> On Wed, Apr 24, 2019 at 6:27 PM Chen, Jie A (jie.a.chen...@) < >> public_webgl...@> wrote: >> >> linkProgram may stall on compileShader. To avoid the stall, you?d better >> make sure the COMPLETION_STATUS_KHR statuses of the attached shaders are >> all True before calling linkProgram. In this sense, the first workflow has >> less chance running into stall. >> >> >> >> *From:* owners-public_webgl...@ [mailto: >> owners-public_webgl...@] *On Behalf Of *Fernando Serrano Garc?a ( >> fserrano...@) >> *Sent:* Wednesday, April 24, 2019 9:38 PM >> *To:* Public WebGL >> *Subject:* Re: [Public WebGL] Propose promoting >> KHR_parallel_shader_compile to community approved >> >> >> >> Regarding the optimal proposed workflow (grouping shaders and programs >> separately) of: >> >> for (const x of shaders) >> gl.compileShader(x); >> for (const x of programs) >> gl.linkProgram(x); >> >> >> >> versus something more on the way that we currently have in many engines >> as threejs: >> >> for (const x of material) >> >> gl.compileShader(fs); >> >> gl.compileShader(vs); >> gl.linkProgram(x); >> >> >> >> Do you think is more or less accurate the following graph for 4 materials >> and enabling this extension with 2 and 4 parallel threads? >> >> >> >> [image: Screen Shot 2019-04-24 at 15.35.47.png] >> >> >> >> On Wed, Apr 24, 2019 at 2:40 PM Fernando Serrano Garc?a < >> fserrano...@> wrote: >> >> fwiw three.js introduced a "debug" parameter (false by default) to >> determine if there will be a status check and call all the get* (currently >> in dev): >> >> - >> https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLShader.js#L21-L26 >> >> - >> https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLProgram.js#L608 >> >> >> >> so currently calling `new WebGLShader()` won't be blocking with any >> `get*` function and it could be used as is to compile all of them in a loop >> with or without the extension. >> >> the problem comes from the WebGLProgram as it should just queue itself >> before trying to link any program and wait until all the shader compile >> calls finish, then do all the link, and wait for it asynchronously before >> start using these programs. >> >> I have opened an issue on the three.js repo to keep track of the >> implementation and we have booked some time this week to take a look at it, >> feedback is welcome :) https://github.com/mrdoob/three.js/issues/16321 >> >> >> >> On Tue, Apr 16, 2019 at 11:55 PM Ken Russell (kbr...@) < >> public_webgl...@> wrote: >> >> On Tue, Apr 16, 2019 at 2:24 PM Tarek Sherif (tsherif...@) < >> public_webgl...@> wrote: >> >> Yes, I've read both specs. I think this language in the WebGL version is >> confusing: "When this extension is enabled: Shader compilation and program >> linking may be performed in a separate CPU thread." And neither indicates >> which functions are expected to cause stalls. As written, this extension >> requires more than most that people know implementation details. >> >> >> >> All previous operations against the program - looking up uniform >> locations, drawing with it, etc. - will cause stalls. The application >> *must* be updated to query the program's COMPLETION_STATUS_KHR status, and >> skip *all* operations against the program until it's no longer pending. >> >> >> >> I guess we'll just change the WebGL version of this extension spec to be >> much more explicit about this. >> >> >> >> >> >> Essentially, all previous code which checked for the completion of >> compilation of shaders / linking of programs can be updated with a small >> wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. >> >> >> >> This is not true because the most common way this is done will cause >> stalls that sabotage the parallelism, e.g.: >> >> https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLShader.js#L21-L36 >> >> >> https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLProgram.js#L586-L631 >> >> >> >> The check for COMPLETION_STATUS_KHR has to wrap *all* queries and uses of >> the program object, and they must be skipped until COMPLETION_STATUS_KHR >> returns true. Yes, all applications will have to be updated to take >> advantage of this extension, but if they do, the benefits will be >> significant. >> >> >> >> -Ken >> >> >> >> >> >> *Tarek Sherif* >> >> Senior Software Engineer, Visualization | Uber >> >> http://vis.gl/ >> >> >> >> >> >> >> >> On Tue, Apr 16, 2019 at 4:18 PM Ken Russell (kbr...@) < >> public_webgl...@> wrote: >> >> Please review the Overview in the underlying OpenGL ES spec: >> >> >> https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt >> >> >> >> >> It describes that the extension uses one or more separate CPU threads for >> shader compilation. If you still think we should rewrite the introduction >> to the WebGL extension, we can do that too. >> >> >> >> Essentially, all previous code which checked for the completion of >> compilation of shaders / linking of programs can be updated with a small >> wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. >> >> >> >> -Ken >> >> >> >> >> >> >> >> On Tue, Apr 16, 2019 at 1:36 AM Tarek Sherif (tsherif...@) < >> public_webgl...@> wrote: >> >> This is all extremely interesting, and documentation of these best >> practices should probably be more publicly available (perhaps through a >> non-normative note in the spec). I'm thinking the language in the extension >> spec could be made more clear about what it's actual purpose is. It >> currently gives the impression that enabling it is what allows for parallel >> compilation and that this should save time, but given what Jeff and Kai >> have said, it sounds like the purpose is to avoid CPU stalls, and that it >> might even take longer in wall time since you're only checking once a >> frame. Maybe some background information could be added along the lines of >> "Normally applications must wait on get*Parameter or a draw call for >> program linking to complete, this extension provides a mechanism for >> querying completion status without stalling..." >> >> >> >> *Tarek Sherif* >> >> Senior Software Engineer, Visualization | Uber >> >> http://vis.gl/ >> >> >> >> >> >> >> >> >> On Mon, Apr 15, 2019 at 11:23 PM Kai Ninomiya (kainino...@) < >> public_webgl...@> wrote: >> >> >> >> >> >> On Mon, Apr 15, 2019 at 7:18 PM Tarek Sherif (tareksherif...@) < >> public_webgl...@> wrote: >> >> I don't see anything in the OpenGL extension spec about what functions >> cause stalls. Is that implementation-specific? Having an idea what to >> expect is important for two reasons: >> >> 1. To make it clear that drawing will still work if >> getProgramParameter(COMPLETION_STATUS_KHR) hasn't returned true yet >> (i.e. the stall on a draw call) >> >> >> >> Generally, OpenGL extensions are not allowed to break existing >> API/existing content. (In OpenGL, all extensions are always enabled; >> there's no requestExtension.) Hence, even if you enable the extension, it >> won't change the way your application works, and therefore the draw call >> must still cause a stall in order to be able to use the program. >> >> >> >> 2. Almost all WebGL code I've looked at handles compilation in a way >> similar to the following: >> >> gl.compileShader(vertexShader); >> if (!gl.getShaderParameter(vertexShader, gl.COMPILE_STATUS)) //... >> >> gl.compileShader(fragmentShader); >> >> if (!gl.getShaderParameter(fragmentShader, gl.COMPILE_STATUS)) //... >> >> //... >> >> gl.linkProgram(program); >> if (!gl.getProgramParameter(program, gl.LINK_STATUS)) //... >> >> I think it would be worth it to make clear that this pattern would >> sabotage the parallel compile. >> >> >> >> I seem to remember (not sure if this is still true) that this pattern >> also sabotages the shader compiler cache in ANGLE, because ANGLE doesn't >> cache the COMPILE_STATUS (or was it the compile info string?). So it forces >> the compiler to recompile just to give you the status. >> >> >> >> Tarek Sherif >> >> http://tareksherif.net/ >> >> >> >> >> >> >> >> >> ??????? Original Message ??????? >> >> On Monday, April 15, 2019 9:00 PM, Ken Russell (kbr...@) < >> public_webgl...@> wrote: >> >> >> >> The WebGL extension (which is basically just a wrapper) refers to the >> underlying OpenGL / OpenGL ES extension >> https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt >> , >> where this is documented. Is that sufficient? It would be better to avoid >> duplicating a large amount of spec text from the underlying extension. >> However, we can add some non-normative text if that would help. >> >> >> >> -Ken >> >> >> >> >> >> >> >> On Sat, Apr 13, 2019 at 3:51 AM Tarek Sherif (tareksherif...@) < >> public_webgl...@> wrote: >> >> IIRC, all 3 of those functions still force a wait for the {shader to >> finish compiling, program to finish linking} just as they did before. The >> new semantics are only visible via the new COMPLETION_STATUS_KHR check. >> >> That should work perfectly for us. Can we add some language to the spec >> about which functions cause stalls? I feel like as written, it will be easy >> for people to use the extension incorrectly. >> >> >> >> Tarek Sherif >> >> http://tareksherif.net/ >> >> >> >> >> >> >> >> >> ??????? Original Message ??????? >> >> On Friday, April 12, 2019 4:10 PM, Kai Ninomiya (kainino...@) < >> public_webgl...@> wrote: >> >> >> >> Oh yes, useProgram probably won't stall. But getUniformLocation and the >> others will stall, as will draw calls. >> >> >> >> getProgramParameter(COMPLETION_STATUS_KHR) should get faster at some >> point; see http://crbug.com/881152 >> which >> Ken linked. >> >> >> >> On Fri, Apr 12, 2019 at 12:39 PM Jasper St. Pierre (jstpierre...@) >> wrote: >> >> Thank you! Trying this out in my own WebGL 2 app, I see quite a reduction >> in shader compilation time, shaving 400ms on load time on a moderately >> complex scene. The getProgramParameter(COMPLETION_STATUS_KHR) query still >> takes 1ms (which I believe is being tracked), but that is still better from >> the 4ms I see in getUniformBlockIndex (my previous sync point). >> >> >> >> AFAIK, useProgram should not cause a stall, but in order to set my >> texture samplers to bind to different units, I need to do a >> getUniformLocation on my sampler uniform, which causes a compilation stall. >> Same thing with getUniformBlockIndex. Do make sure that anything that might >> query into reflection about the program (e.g. getVertexAttributeIndex, >> getUniformLocation, getUniformBlockIndex) happens after >> COMPLETION_STATUS_KHR returns true, since that?s another way to >> accidentally stall on compilation completing. >> >> >> >> >> >> *From:* owners-public_webgl...@ >> *On Behalf Of *Kai Ninomiya (kainino...@) >> >> *Sent:* Friday, April 12, 2019 10:25 AM >> >> *To:* Public WebGL >> >> *Subject:* Re: [Public WebGL] Propose promoting >> KHR_parallel_shader_compile to community approved >> >> >> >> >> >> IIRC, all 3 of those functions still force a wait for the {shader to >> finish compiling, program to finish linking} just as they did before. The >> new semantics are only visible via the new COMPLETION_STATUS_KHR check. >> >> >> >> On Fri, Apr 12, 2019 at 10:05 AM Tarek Sherif (tsherif...@) < >> public_webgl...@> wrote: >> >> Very excited about this extension, but I'm concerned about how it would >> work in our use case. Our flagship visualization library, deck.gl >> , >> often shares the gl context with a separate base map rendering application >> so that it can properly interleave visualization layers with the base map. >> Enabling this extension seems to change the behaviour of existing WebGL >> functions in a way that I don't believe other extensions do. My worry is >> how our enabling KHR_parallel_shader_compile would affect applications we >> share contexts with, i.e what happens if the typical synchronous >> compilation logic is used after KHR_parallel_shader_compile is enabled? >> Specifically: >> >> - What happens if getShaderParameter(shader, COMPILE_STATUS) is >> called before compilation is complete? >> - What happens if getProgramParameter(program, LINK_STATUS) is called >> before linking is complete? >> - What happens if useProgram is called before linking is complete? >> >> Thanks, >> >> >> >> >> >> Tarek Sherif >> >> Senior Software Engineer, Visualization | Uber >> >> http://vis.gl/ >> >> >> >> >> >> >> >> >> >> >> *Tarek Sherif* >> >> Senior Software Engineer, Visualization | Uber >> >> http://vis.gl/ >> >> >> >> >> >> >> On Fri, Apr 12, 2019 at 12:16 PM David Catuhe (David.Catuhe...@) >> wrote: >> >> Wonderful! >> >> >> >> >> >> *From:* owners-public_webgl...@ >> *On Behalf Of *Ken Russell (kbr...@) >> >> *Sent:* Wednesday, April 10, 2019 2:56 PM >> >> *To:* Public WebGL >> >> *Subject:* Re: [Public WebGL] Propose promoting >> KHR_parallel_shader_compile to community approved >> >> >> >> >> >> If your code works correctly now when enabling draft WebGL extensions in >> Chrome, then no changes are needed. There won't be any changes to the >> extension when it's taken out of draft status; it'll just be available by >> default. >> >> >> >> -Ken >> >> >> >> >> >> On Wed, Apr 10, 2019 at 12:36 PM David Catuhe (David.Catuhe...@) >> wrote: >> >> We do have support for the extension in Babylon.js. How can we test this >> change? >> ------------------------------ >> >> >> >> *From:* owners-public_webgl...@ >> on behalf of Ken Russell (kbr...@) >> *Sent:* Wednesday, April 10, 2019 12:00:25 PM >> *To:* public >> *Subject:* [Public WebGL] Propose promoting KHR_parallel_shader_compile >> to community approved >> >> >> >> WebGL community, >> >> >> >> Jie Chen from Intel has principally developed and implemented a WebGL >> wrapper for the KHR_parallel_shader_compile extension. This allows shader >> compilation and program linking to occur fully in parallel to the rest of >> the WebGL application. Some small application changes are needed to take >> full advantage of the extension, but it is otherwise fully backward >> compatible. Jie has even emulated this extension on platforms which don't >> support it natively. >> >> >> >> This extension solves a longstanding user complaint with WebGL, namely >> long shader compile times on Windows. Compiles and links occur not only >> asynchronously, but also in parallel, so there is a net speedup when using >> this extension. Users who have tried out the draft extension are pleased >> with the results and would like to see it made widely available. >> >> >> >> I propose promoting this extension to community approved in >> https://github.com/KhronosGroup/WebGL/pull/2855 >> >> . Any comments? >> >> >> >> -Ken >> >> >> >> >> >> >> >> >> >> [image: Image removed by sender. >> https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png] >> >> >> Virus-free. www.avg.com >> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From pub...@ Sun May 12 10:03:54 2019 From: pub...@ (Kai Ninomiya (...@...)) Date: Sun, 12 May 2019 10:03:54 -0700 Subject: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved In-Reply-To: References: <5F447A42ADFAFD499D69CF330DF2E5C160660987@SHSMSX101.ccr.corp.intel.com> <5F447A42ADFAFD499D69CF330DF2E5C160661691@SHSMSX101.ccr.corp.intel.com> <5F447A42ADFAFD499D69CF330DF2E5C160661793@SHSMSX101.ccr.corp.intel.com> Message-ID: I think we will probably need to optimize checking LINK_STATUS (which would make useProgram faster too), so that when the COMPLETION_STATUS query result is sent to the client and cached, it sends the LINK_STATUS as well, and updates the already existing link status cache. *From: *Takahiro Aoyagi (taoyagi...@) *Date: *Sun, May 12, 2019, 2:14 AM *To: *Public WebGL Thanks for the comments, Chen and Kai. > > Yeah, 8ms is very long to me. And if I compile+link two or more programs > the time can be longer. > > > I guess I?ve found the cause for gl.useProgram. WebGL implementation > inserts an extra GL command to query LinkStatus before using it. > > Will this be optimized (not adding the extra GL command) at some point? Or > must it be necessary? > > > But do note that we cache that info, so it only takes extra time on the > first useProgram. > > I confirmed that on my test. > > > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime10.html > > So far I'll try not to switch to a program which hasn't been called with > gl.useProgram() yet while at least one program is being compiled+linked. > > > On Sun, May 12, 2019 at 2:54 PM Kai Ninomiya (kainino...@) < > public_webgl...@> wrote: > >> 8ms is an extraordinary long time, in frame rendering time. >> >> But do note that we cache that info, so it only takes extra time on the >> first useProgram. >> >> *From: *Chen, Jie A (jie.a.chen...@) >> *Date: *Sat, May 11, 2019, 8:07 PM >> *To: *Public WebGL >> >> I guess I?ve found the cause for gl.useProgram. WebGL implementation >>> inserts an extra GL command to query LinkStatus before using it. >>> >>> >>> https://cs.chromium.org/chromium/src/third_party/blink/renderer/modules/webgl/webgl_rendering_context_base.cc?sq=package:chromium&g=0&l=6350 >>> >>> >>> >>> Anyway I think you don?t need to worry too much about this. Usually it >>> doesn?t take very long to drain the command buffer. I tried your test case, >>> which took about only 8ms on my laptop. >>> >>> >>> >>> >>> >>> *From:* owners-public_webgl...@ [mailto: >>> owners-public_webgl...@] *On Behalf Of *Chen, Jie A ( >>> jie.a.chen...@) >>> *Sent:* Sunday, May 12, 2019 9:44 AM >>> *To:* Public WebGL >>> *Subject:* RE: [Public WebGL] Propose promoting >>> KHR_parallel_shader_compile to community approved >>> >>> >>> >>> Mostly they are gl.get* like commands. You can search ?WaitForCmd? in >>> https://cs.chromium.org/chromium/src/gpu/command_buffer/client/gles2_implementation_impl_autogen.h and >>> >>> https://cs.chromium.org/chromium/src/gpu/command_buffer/client/gles2_implementation.cc >>> for them. >>> >>> But I don?t think gl.useProgram needs to wait. Most likely it has a >>> different cause. I will look into it later. >>> >>> >>> >>> >>> >>> *From:* owners-public_webgl...@ [mailto: >>> owners-public_webgl...@] *On Behalf Of *Takahiro Aoyagi ( >>> taoyagi...@) >>> *Sent:* Sunday, May 12, 2019 2:27 AM >>> *To:* Public WebGL >>> *Subject:* Re: [Public WebGL] Propose promoting >>> KHR_parallel_shader_compile to community approved >>> >>> >>> >>> Hi Chen, >>> >>> >>> >>> Thanks for your explanation. >>> >>> >>> >>> What type of WebGL draw calls need to wait for all queued GL commands? >>> In my tests, not only gl.get*() >>> >>> >>> >>> >>> https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime9.html >>> >>> >>> >>> but also gl.useProgram() seems to wait. >>> >>> >>> >>> >>> https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime8.html >>> >>> >>> >>> >>> That means, I shouldn't call any gl.get*() and also I shouldn't switch >>> program until all programs compilation+linking are done? >>> >>> >>> >>> I haven't tried yet but could draw calls wait, too? If so, I shouldn't >>> render anything until then? >>> >>> >>> >>> >>> >>> [image: Image removed by sender.] >>> >>> >>> Virus-free. www.avg.com >>> >>> >>> >>> >>> On Sat, May 11, 2019 at 12:43 PM Chen, Jie A (jie.a.chen...@) < >>> public_webgl...@> wrote: >>> >>> Interesting question, Takahiro. >>> >>> My speculation is that the problem might be relevant to chrome?s >>> multi-process architecture. As you may know, the WebGL calls run in the >>> main thread of render process. Chrome needs to send these WebGL commands to >>> the GPU process for actual execution. So in your case, what Chrome actually >>> does for calls of makeProgram2 is simply putting the GL commands into a IPC >>> buffer. But later when you retrieve a program parameter back, it then >>> waits for the execution of all previously issued GL commands including >>> makeProgram2. >>> >>> >>> >>> *From:* owners-public_webgl...@ [mailto: >>> owners-public_webgl...@] *On Behalf Of *Takahiro Aoyagi ( >>> taoyagi...@) >>> *Sent:* Saturday, May 11, 2019 6:58 AM >>> *To:* Public WebGL >>> *Subject:* Re: [Public WebGL] Propose promoting >>> KHR_parallel_shader_compile to community approved >>> >>> >>> >>> I'm very glad this extension moves forward. >>> >>> >>> >>> Question. Can compiling+linking a program block another program's >>> gl.get*() or gl.useProgram()? >>> >>> >>> >>> Even after confirming compile+link completion of a program with >>> COMPLETION_STATUS_KHR, gl.getProgramParameter() or gl.useProgram() seems >>> being blocked if another program is being compiled+linked on my Windows >>> Canary. Is this intentional or bug? >>> >>> >>> >>> >>> https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime8.html >>> >>> >>> >>> https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime9.html >>> >>> >>> >>> // Confirm program compile+link completion >>> >>> if(gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR)) { >>> >>> // Compile and link another program >>> >>> const vertexShader2 = gl.createShader(gl.VERTEX_SHADER); >>> const fragmentShader2 = gl.createShader(gl.FRAGMENT_SHADER); >>> const program2 = gl.createProgram(); >>> >>> gl.shaderSource(vertexShader2, vertexShaderCode); >>> gl.shaderSource(fragmentShader2, fragmentShaderCode); >>> gl.compileShader(vertexShader2); >>> gl.compileShader(fragmentShader2); >>> gl.attachShader(program2, vertexShader2); >>> gl.attachShader(program2, fragmentShader2); >>> gl.linkProgram(program2); >>> >>> >>> >>> // gl.get*() or gl.useProgram() while the other program is being >>> compiled+linkied >>> >>> const startTime = performance.now(); >>> gl.getProgramParameter(program, gl.ACTIVE_ATTRIBUTES); // or >>> gl.useProgram(program); >>> const endTime = performance.now(); >>> >>> } >>> >>> >>> >>> Takahiro >>> >>> >>> >>> [image: Image removed by sender.] >>> >>> >>> Virus-free. www.avg.com >>> >>> >>> >>> >>> On Sat, May 11, 2019 at 6:11 AM Ken Russell (kbr...@) < >>> public_webgl...@> wrote: >>> >>> Since there haven't been any *objections* to moving this extension >>> forward, and since the benefits are now being seen, it's been moved to >>> community approved in https://github.com/KhronosGroup/WebGL/pull/2855 . >>> >>> >>> >>> Please, feel free to continue to report problems with long shader >>> compilation times - either posting here on this mailing list or on >>> webgl-dev-list, reporting cross-browser issues on >>> https://github.com/KhronosGroup/WebGL/issues , or on individual >>> browsers' bug trackers. >>> >>> >>> >>> -Ken >>> >>> >>> >>> >>> >>> >>> >>> *From: *Ken Russell >>> *Date: *Fri, May 10, 2019 at 1:39 PM >>> *To: *Public WebGL >>> >>> Super. Thank you Takahiro for testing and confirming! >>> >>> >>> >>> >>> >>> *From: *Takahiro Aoyagi (taoyagi...@) >>> *Date: *Fri, May 10, 2019 at 10:51 AM >>> *To: *Public WebGL >>> >>> I made simple tests to check the CPU elapsed time of >>> gl.getProgramParameter() and gl.useProgram() after checking >>> COMPLETION_STATUS_KHR is true. Both are fast here on my Windows10 Chrome >>> Canary. >>> >>> >>> >>> >>> https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime6.html >>> >>> https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime7.html >>> >>> >>> >>> Takahiro >>> >>> >>> >>> [image: Image removed by sender.] >>> >>> >>> Virus-free. www.avg.com >>> >>> >>> >>> >>> On Sat, May 11, 2019 at 2:46 AM Ken Russell (kbr...@) < >>> public_webgl...@> wrote: >>> >>> Hmm. The only reason I can think of that that would happen is if you're >>> running on Windows, and ANGLE has to dynamically recompile the program >>> behind the scenes in order to handle some OpenGL ES state change. I'm not >>> 100% sure which changes require this dynamic recompilation; the ANGLE >>> developers would know best. >>> https://groups.google.com//forum/#!forum/angleproject >>> might be helpful. >>> >>> >>> >>> We'd really need some test case to make progress on this. Can you >>> provide one? >>> >>> >>> >>> -Ken >>> >>> >>> >>> >>> >>> On Fri, May 10, 2019 at 10:28 AM Jasper St. Pierre (jstpierre...@) >>> wrote: >>> >>> Hello again. My app is now showing that getProgramParameter is >>> completing quick, but it is spending a lot of time in useProgram. I am >>> checking for COMPLETION_STATUS_KHR on the GL program beforehand and it is >>> returning true. I?m guessing there?s some additional expensive work that >>> still needs to happen at useProgram time. Is this a bug? Any ways to debug >>> or avoid this? I?m unsure if there will be an easy repro. >>> >>> >>> >>> Again, profiler screenshot attached. >>> >>> >>> >>> *From:* owners-public_webgl...@ >>> *On Behalf Of *Takahiro Aoyagi (taoyagi...@) >>> *Sent:* Friday, May 10, 2019 12:22 AM >>> *To:* Public WebGL >>> *Subject:* Re: [Public WebGL] Propose promoting >>> KHR_parallel_shader_compile to community approved >>> >>> >>> >>> Confirmed COMPLETION_STATUS_KHR is very fast like 0.01ms on my test >>> >>> >>> https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html >>> >>> >>> >>> Nice work! >>> >>> >>> >>> Thanks >>> >>> >>> >>> [image: Image removed by sender. >>> https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png] >>> >>> >>> Virus-free. www.avg.com >>> >>> >>> >>> >>> On Wed, May 8, 2019 at 2:41 PM Ken Russell (kbr...@) < >>> public_webgl...@> wrote: >>> >>> Jie Chen from Intel just landed a fix in Chrome dramatically improving >>> the performance of querying COMPLETION_STATUS_KHR under >>> http://crbug.com/881152 . The fix will be in tomorrow's Canary on >>> Windows and macOS. >>> >>> >>> >>> This should address the last major gap with this extension. We would >>> like to enable it by default by promoting it to community approved; any >>> further comments? >>> >>> >>> >>> -Ken >>> >>> >>> >>> >>> >>> >>> >>> *From: *Ken Russell >>> *Date: *Fri, Apr 26, 2019 at 3:40 PM >>> *To: *Public WebGL >>> >>> Thanks for the report and the clear test case. There was an existing bug >>> about this, so the new one was duplicated into it, and some hints about >>> implementing it were added to the preexisting bug. >>> >>> >>> >>> >>> >>> On Fri, Apr 26, 2019 at 5:56 AM Takahiro Aoyagi (taoyagi...@) < >>> public_webgl...@> wrote: >>> >>> Hi Chen, >>> >>> >>> >>> Opened a bug. Thanks. >>> >>> >>> >>> https://bugs.chromium.org/p/chromium/issues/detail?id=957001 >>> >>> >>> >>> Takahiro >>> >>> >>> >>> >>> >>> On Fri, Apr 26, 2019 at 8:03 PM Chen, Jie A (jie.a.chen...@) < >>> public_webgl...@> wrote: >>> >>> Hi Takahiro, >>> >>> The current implementation of COMPLETION_STATUS_KHR query in >>> chromium incurs an expensive round-trip to the GPU thread. This may >>> contribute to the wait time in your case. I am trying to optimize this. >>> Could you please file a bug to chromium? I would look into it once I?ve >>> done the optimization. >>> >>> >>> >>> *From:* owners-public_webgl...@ [mailto: >>> owners-public_webgl...@] *On Behalf Of *Takahiro Aoyagi ( >>> taoyagi...@) >>> *Sent:* Friday, April 26, 2019 6:20 PM >>> *To:* Public WebGL >>> *Subject:* Re: [Public WebGL] Propose promoting >>> KHR_parallel_shader_compile to community approved >>> >>> >>> >>> Hi all, >>> >>> >>> >>> I'm working on Three.js + KHR_parallel_shader_compile extension support >>> with Fernando. >>> >>> >>> >>> https://github.com/mrdoob/three.js/issues/16321#issuecomment-486436086 >>> >>> >>> >>> I'm testing with Canary. But the behavior seems weird to me. >>> gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) seems to wait >>> for compile+link completion. I don't think it should wait for that, it >>> should just do polling and returning true/false quickly instead. >>> >>> >>> >>> I made a simple test to reproduce. >>> >>> >>> >>> >>> https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html >>> >>> >>> >>> Code snippet. >>> >>> >>> >>> const ext = gl.getExtension('KHR_parallel_shader_compile'); >>> >>> >>> >>> gl.compileShader(vertexShader); >>> gl.compileShader(fragmentShader); >>> gl.attachShader(program, vertexShader); >>> gl.attachShader(program, fragmentShader); >>> gl.linkProgram(program); >>> >>> const startTime = performance.now(); >>> const status = useExtension >>> ? gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) >>> : gl.getProgramParameter(program, gl.LINK_STATUS); >>> const endTime = performance.now(); >>> >>> const elapsedTime = endTime - startTime; >>> >>> >>> >>> On my platform, both gl.LINK_STATUS and ext.COMPLETION_STATUS_KHR take >>> so long time about 15ms. I can accept this number for gl.LINK_STATUS >>> because it waits for compile+link completion. But 15ms for >>> ext.COMPLETION_STATUS_KHR looks weird to me. It shouldn't wait for the >>> compile+link completion but should do just polling and quickly returning >>> true/false instead. So I guess the number should be 1ms or less. >>> >>> >>> >>> Let me know if I'm missing something. Or could it be a Canary bug? >>> >>> >>> >>> My platform. >>> >>> >>> >>> OS: Windows10 >>> >>> Browser: Chrome Canary. >>> >>> Browser boot option: --use-cmd-decoder=passthrough >>> --enable-webgl-draft-extensions >>> >>> >>> >>> >>> >>> Thanks >>> >>> >>> >>> Takahiro >>> >>> >>> >>> >>> >>> On Fri, Apr 26, 2019 at 10:15 AM Chen, Jie A (jie.a.chen...@) < >>> public_webgl...@> wrote: >>> >>> Basically, for ANGLE?s GL backend, it?s simply a wrapper for the >>> existing GL implementations. In this sense glCompileShader() is still >>> implementation specific. Essentially ANGLE just calls glCompileShader and >>> check GL_COMPILE_STATUS. >>> >>> >>> >>> *From:* owners-public_webgl...@ [mailto: >>> owners-public_webgl...@] *On Behalf Of *Jasper St. Pierre ( >>> jstpierre...@) >>> *Sent:* Friday, April 26, 2019 1:18 AM >>> *To:* Public WebGL >>> *Subject:* RE: [Public WebGL] Propose promoting >>> KHR_parallel_shader_compile to community approved >>> >>> >>> >>> Thank you, that?s important information to know. Changing my shader >>> compilation pipeline to wait for shader completion status is a lot more >>> difficult, but based on some initial tests, it?s more expensive than not >>> doing it ? the latency of getShaderParameter is too high. >>> >>> >>> >>> That said, in a lot of GL implementations, glCompileShader() is >>> practically a no-op, and will only do an AST parse when >>> glGetShaderParameter/InfoLog() is called (which is basically only for >>> debugging / error checking). glLinkProgram() does full compilation of all >>> programs, as full-PSO optimization is important. I don?t know how common >>> this is, but multiple GL implementations I have seen do it. It might make >>> sense for ANGLE to adopt this model as well. >>> >>> >>> >>> *From:* owners-public_webgl...@ >>> *On Behalf Of *Chen, Jie A (jie.a.chen...@) >>> *Sent:* Wednesday, April 24, 2019 6:48 PM >>> *To:* Public WebGL >>> *Subject:* RE: [Public WebGL] Propose promoting >>> KHR_parallel_shader_compile to community approved >>> >>> >>> >>> Absolutely. Ideally there would be no stall for linkProgram. I tried, >>> but it?s too difficult to achieve this in ANGLE. >>> >>> >>> >>> *From:* owners-public_webgl...@ [ >>> mailto:owners-public_webgl...@ ] >>> *On Behalf Of *Jeff Gilbert (jgilbert...@) >>> *Sent:* Thursday, April 25, 2019 9:33 AM >>> *To:* Public WebGL >>> *Subject:* Re: [Public WebGL] Propose promoting >>> KHR_parallel_shader_compile to community approved >>> >>> >>> >>> Possibly, but in the long run, I expect implementations to support >>> no-stall linkProgram invocations. >>> >>> >>> >>> On Wed, Apr 24, 2019 at 6:27 PM Chen, Jie A (jie.a.chen...@) < >>> public_webgl...@> wrote: >>> >>> linkProgram may stall on compileShader. To avoid the stall, you?d better >>> make sure the COMPLETION_STATUS_KHR statuses of the attached shaders are >>> all True before calling linkProgram. In this sense, the first workflow has >>> less chance running into stall. >>> >>> >>> >>> *From:* owners-public_webgl...@ [mailto: >>> owners-public_webgl...@] *On Behalf Of *Fernando Serrano Garc?a >>> (fserrano...@) >>> *Sent:* Wednesday, April 24, 2019 9:38 PM >>> *To:* Public WebGL >>> *Subject:* Re: [Public WebGL] Propose promoting >>> KHR_parallel_shader_compile to community approved >>> >>> >>> >>> Regarding the optimal proposed workflow (grouping shaders and programs >>> separately) of: >>> >>> for (const x of shaders) >>> gl.compileShader(x); >>> for (const x of programs) >>> gl.linkProgram(x); >>> >>> >>> >>> versus something more on the way that we currently have in many engines >>> as threejs: >>> >>> for (const x of material) >>> >>> gl.compileShader(fs); >>> >>> gl.compileShader(vs); >>> gl.linkProgram(x); >>> >>> >>> >>> Do you think is more or less accurate the following graph for 4 >>> materials and enabling this extension with 2 and 4 parallel threads? >>> >>> >>> >>> [image: Screen Shot 2019-04-24 at 15.35.47.png] >>> >>> >>> >>> On Wed, Apr 24, 2019 at 2:40 PM Fernando Serrano Garc?a < >>> fserrano...@> wrote: >>> >>> fwiw three.js introduced a "debug" parameter (false by default) to >>> determine if there will be a status check and call all the get* (currently >>> in dev): >>> >>> - >>> https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLShader.js#L21-L26 >>> >>> - >>> https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLProgram.js#L608 >>> >>> >>> >>> so currently calling `new WebGLShader()` won't be blocking with any >>> `get*` function and it could be used as is to compile all of them in a loop >>> with or without the extension. >>> >>> the problem comes from the WebGLProgram as it should just queue itself >>> before trying to link any program and wait until all the shader compile >>> calls finish, then do all the link, and wait for it asynchronously before >>> start using these programs. >>> >>> I have opened an issue on the three.js repo to keep track of the >>> implementation and we have booked some time this week to take a look at it, >>> feedback is welcome :) https://github.com/mrdoob/three.js/issues/16321 >>> >>> >>> >>> On Tue, Apr 16, 2019 at 11:55 PM Ken Russell (kbr...@) < >>> public_webgl...@> wrote: >>> >>> On Tue, Apr 16, 2019 at 2:24 PM Tarek Sherif (tsherif...@) < >>> public_webgl...@> wrote: >>> >>> Yes, I've read both specs. I think this language in the WebGL version is >>> confusing: "When this extension is enabled: Shader compilation and program >>> linking may be performed in a separate CPU thread." And neither indicates >>> which functions are expected to cause stalls. As written, this extension >>> requires more than most that people know implementation details. >>> >>> >>> >>> All previous operations against the program - looking up uniform >>> locations, drawing with it, etc. - will cause stalls. The application >>> *must* be updated to query the program's COMPLETION_STATUS_KHR status, and >>> skip *all* operations against the program until it's no longer pending. >>> >>> >>> >>> I guess we'll just change the WebGL version of this extension spec to be >>> much more explicit about this. >>> >>> >>> >>> >>> >>> Essentially, all previous code which checked for the completion of >>> compilation of shaders / linking of programs can be updated with a small >>> wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. >>> >>> >>> >>> This is not true because the most common way this is done will cause >>> stalls that sabotage the parallelism, e.g.: >>> >>> https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLShader.js#L21-L36 >>> >>> >>> https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLProgram.js#L586-L631 >>> >>> >>> >>> The check for COMPLETION_STATUS_KHR has to wrap *all* queries and uses >>> of the program object, and they must be skipped until COMPLETION_STATUS_KHR >>> returns true. Yes, all applications will have to be updated to take >>> advantage of this extension, but if they do, the benefits will be >>> significant. >>> >>> >>> >>> -Ken >>> >>> >>> >>> >>> >>> *Tarek Sherif* >>> >>> Senior Software Engineer, Visualization | Uber >>> >>> http://vis.gl/ >>> >>> >>> >>> >>> >>> >>> >>> On Tue, Apr 16, 2019 at 4:18 PM Ken Russell (kbr...@) < >>> public_webgl...@> wrote: >>> >>> Please review the Overview in the underlying OpenGL ES spec: >>> >>> >>> https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt >>> >>> >>> >>> >>> It describes that the extension uses one or more separate CPU threads >>> for shader compilation. If you still think we should rewrite the >>> introduction to the WebGL extension, we can do that too. >>> >>> >>> >>> Essentially, all previous code which checked for the completion of >>> compilation of shaders / linking of programs can be updated with a small >>> wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. >>> >>> >>> >>> -Ken >>> >>> >>> >>> >>> >>> >>> >>> On Tue, Apr 16, 2019 at 1:36 AM Tarek Sherif (tsherif...@) < >>> public_webgl...@> wrote: >>> >>> This is all extremely interesting, and documentation of these best >>> practices should probably be more publicly available (perhaps through a >>> non-normative note in the spec). I'm thinking the language in the extension >>> spec could be made more clear about what it's actual purpose is. It >>> currently gives the impression that enabling it is what allows for parallel >>> compilation and that this should save time, but given what Jeff and Kai >>> have said, it sounds like the purpose is to avoid CPU stalls, and that it >>> might even take longer in wall time since you're only checking once a >>> frame. Maybe some background information could be added along the lines of >>> "Normally applications must wait on get*Parameter or a draw call for >>> program linking to complete, this extension provides a mechanism for >>> querying completion status without stalling..." >>> >>> >>> >>> *Tarek Sherif* >>> >>> Senior Software Engineer, Visualization | Uber >>> >>> http://vis.gl/ >>> >>> >>> >>> >>> >>> >>> >>> >>> On Mon, Apr 15, 2019 at 11:23 PM Kai Ninomiya (kainino...@) < >>> public_webgl...@> wrote: >>> >>> >>> >>> >>> >>> On Mon, Apr 15, 2019 at 7:18 PM Tarek Sherif (tareksherif...@) < >>> public_webgl...@> wrote: >>> >>> I don't see anything in the OpenGL extension spec about what functions >>> cause stalls. Is that implementation-specific? Having an idea what to >>> expect is important for two reasons: >>> >>> 1. To make it clear that drawing will still work if >>> getProgramParameter(COMPLETION_STATUS_KHR) hasn't returned true yet >>> (i.e. the stall on a draw call) >>> >>> >>> >>> Generally, OpenGL extensions are not allowed to break existing >>> API/existing content. (In OpenGL, all extensions are always enabled; >>> there's no requestExtension.) Hence, even if you enable the extension, it >>> won't change the way your application works, and therefore the draw call >>> must still cause a stall in order to be able to use the program. >>> >>> >>> >>> 2. Almost all WebGL code I've looked at handles compilation in a way >>> similar to the following: >>> >>> gl.compileShader(vertexShader); >>> if (!gl.getShaderParameter(vertexShader, gl.COMPILE_STATUS)) //... >>> >>> gl.compileShader(fragmentShader); >>> >>> if (!gl.getShaderParameter(fragmentShader, gl.COMPILE_STATUS)) //... >>> >>> //... >>> >>> gl.linkProgram(program); >>> if (!gl.getProgramParameter(program, gl.LINK_STATUS)) //... >>> >>> I think it would be worth it to make clear that this pattern would >>> sabotage the parallel compile. >>> >>> >>> >>> I seem to remember (not sure if this is still true) that this pattern >>> also sabotages the shader compiler cache in ANGLE, because ANGLE doesn't >>> cache the COMPILE_STATUS (or was it the compile info string?). So it forces >>> the compiler to recompile just to give you the status. >>> >>> >>> >>> Tarek Sherif >>> >>> http://tareksherif.net/ >>> >>> >>> >>> >>> >>> >>> >>> >>> ??????? Original Message ??????? >>> >>> On Monday, April 15, 2019 9:00 PM, Ken Russell (kbr...@) < >>> public_webgl...@> wrote: >>> >>> >>> >>> The WebGL extension (which is basically just a wrapper) refers to the >>> underlying OpenGL / OpenGL ES extension >>> https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt >>> , >>> where this is documented. Is that sufficient? It would be better to avoid >>> duplicating a large amount of spec text from the underlying extension. >>> However, we can add some non-normative text if that would help. >>> >>> >>> >>> -Ken >>> >>> >>> >>> >>> >>> >>> >>> On Sat, Apr 13, 2019 at 3:51 AM Tarek Sherif (tareksherif...@) < >>> public_webgl...@> wrote: >>> >>> IIRC, all 3 of those functions still force a wait for the {shader to >>> finish compiling, program to finish linking} just as they did before. The >>> new semantics are only visible via the new COMPLETION_STATUS_KHR check. >>> >>> That should work perfectly for us. Can we add some language to the spec >>> about which functions cause stalls? I feel like as written, it will be easy >>> for people to use the extension incorrectly. >>> >>> >>> >>> Tarek Sherif >>> >>> http://tareksherif.net/ >>> >>> >>> >>> >>> >>> >>> >>> >>> ??????? Original Message ??????? >>> >>> On Friday, April 12, 2019 4:10 PM, Kai Ninomiya (kainino...@) < >>> public_webgl...@> wrote: >>> >>> >>> >>> Oh yes, useProgram probably won't stall. But getUniformLocation and the >>> others will stall, as will draw calls. >>> >>> >>> >>> getProgramParameter(COMPLETION_STATUS_KHR) should get faster at some >>> point; see http://crbug.com/881152 >>> which >>> Ken linked. >>> >>> >>> >>> On Fri, Apr 12, 2019 at 12:39 PM Jasper St. Pierre (jstpierre...@) >>> wrote: >>> >>> Thank you! Trying this out in my own WebGL 2 app, I see quite a >>> reduction in shader compilation time, shaving 400ms on load time on a >>> moderately complex scene. The getProgramParameter(COMPLETION_STATUS_KHR) >>> query still takes 1ms (which I believe is being tracked), but that is still >>> better from the 4ms I see in getUniformBlockIndex (my previous sync point). >>> >>> >>> >>> AFAIK, useProgram should not cause a stall, but in order to set my >>> texture samplers to bind to different units, I need to do a >>> getUniformLocation on my sampler uniform, which causes a compilation stall. >>> Same thing with getUniformBlockIndex. Do make sure that anything that might >>> query into reflection about the program (e.g. getVertexAttributeIndex, >>> getUniformLocation, getUniformBlockIndex) happens after >>> COMPLETION_STATUS_KHR returns true, since that?s another way to >>> accidentally stall on compilation completing. >>> >>> >>> >>> >>> >>> *From:* owners-public_webgl...@ >>> *On Behalf Of *Kai Ninomiya (kainino...@) >>> >>> *Sent:* Friday, April 12, 2019 10:25 AM >>> >>> *To:* Public WebGL >>> >>> *Subject:* Re: [Public WebGL] Propose promoting >>> KHR_parallel_shader_compile to community approved >>> >>> >>> >>> >>> >>> IIRC, all 3 of those functions still force a wait for the {shader to >>> finish compiling, program to finish linking} just as they did before. The >>> new semantics are only visible via the new COMPLETION_STATUS_KHR check. >>> >>> >>> >>> On Fri, Apr 12, 2019 at 10:05 AM Tarek Sherif (tsherif...@) < >>> public_webgl...@> wrote: >>> >>> Very excited about this extension, but I'm concerned about how it would >>> work in our use case. Our flagship visualization library, deck.gl >>> , >>> often shares the gl context with a separate base map rendering application >>> so that it can properly interleave visualization layers with the base map. >>> Enabling this extension seems to change the behaviour of existing WebGL >>> functions in a way that I don't believe other extensions do. My worry is >>> how our enabling KHR_parallel_shader_compile would affect applications we >>> share contexts with, i.e what happens if the typical synchronous >>> compilation logic is used after KHR_parallel_shader_compile is enabled? >>> Specifically: >>> >>> - What happens if getShaderParameter(shader, COMPILE_STATUS) is >>> called before compilation is complete? >>> - What happens if getProgramParameter(program, LINK_STATUS) is >>> called before linking is complete? >>> - What happens if useProgram is called before linking is complete? >>> >>> Thanks, >>> >>> >>> >>> >>> >>> Tarek Sherif >>> >>> Senior Software Engineer, Visualization | Uber >>> >>> http://vis.gl/ >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> *Tarek Sherif* >>> >>> Senior Software Engineer, Visualization | Uber >>> >>> http://vis.gl/ >>> >>> >>> >>> >>> >>> >>> On Fri, Apr 12, 2019 at 12:16 PM David Catuhe ( >>> David.Catuhe...@) wrote: >>> >>> Wonderful! >>> >>> >>> >>> >>> >>> *From:* owners-public_webgl...@ >>> *On Behalf Of *Ken Russell (kbr...@) >>> >>> *Sent:* Wednesday, April 10, 2019 2:56 PM >>> >>> *To:* Public WebGL >>> >>> *Subject:* Re: [Public WebGL] Propose promoting >>> KHR_parallel_shader_compile to community approved >>> >>> >>> >>> >>> >>> If your code works correctly now when enabling draft WebGL extensions in >>> Chrome, then no changes are needed. There won't be any changes to the >>> extension when it's taken out of draft status; it'll just be available by >>> default. >>> >>> >>> >>> -Ken >>> >>> >>> >>> >>> >>> On Wed, Apr 10, 2019 at 12:36 PM David Catuhe ( >>> David.Catuhe...@) wrote: >>> >>> We do have support for the extension in Babylon.js. How can we test this >>> change? >>> ------------------------------ >>> >>> >>> >>> *From:* owners-public_webgl...@ >>> on behalf of Ken Russell (kbr...@) >>> *Sent:* Wednesday, April 10, 2019 12:00:25 PM >>> *To:* public >>> *Subject:* [Public WebGL] Propose promoting KHR_parallel_shader_compile >>> to community approved >>> >>> >>> >>> WebGL community, >>> >>> >>> >>> Jie Chen from Intel has principally developed and implemented a WebGL >>> wrapper for the KHR_parallel_shader_compile extension. This allows shader >>> compilation and program linking to occur fully in parallel to the rest of >>> the WebGL application. Some small application changes are needed to take >>> full advantage of the extension, but it is otherwise fully backward >>> compatible. Jie has even emulated this extension on platforms which don't >>> support it natively. >>> >>> >>> >>> This extension solves a longstanding user complaint with WebGL, namely >>> long shader compile times on Windows. Compiles and links occur not only >>> asynchronously, but also in parallel, so there is a net speedup when using >>> this extension. Users who have tried out the draft extension are pleased >>> with the results and would like to see it made widely available. >>> >>> >>> >>> I propose promoting this extension to community approved in >>> https://github.com/KhronosGroup/WebGL/pull/2855 >>> >>> . Any comments? >>> >>> >>> >>> -Ken >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> [image: Image removed by sender. >>> https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png] >>> >>> >>> Virus-free. www.avg.com >>> >>> >>> >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4845 bytes Desc: S/MIME Cryptographic Signature URL: From pub...@ Sun May 12 20:02:31 2019 From: pub...@ (Jasper St. Pierre (...@...)) Date: Mon, 13 May 2019 03:02:31 +0000 Subject: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved In-Reply-To: References: <5F447A42ADFAFD499D69CF330DF2E5C160660987@SHSMSX101.ccr.corp.intel.com> <5F447A42ADFAFD499D69CF330DF2E5C160661691@SHSMSX101.ccr.corp.intel.com> <5F447A42ADFAFD499D69CF330DF2E5C160661793@SHSMSX101.ccr.corp.intel.com> , Message-ID: I should probably note that the cause for the long stalls on gl.useProgram was found. It turns out that ANGLE, at least on D3D11, will recompile the shader program for every set of vertex attributes that it is used with. The initial compileShader / linkProgram calls was done without having any VAO or vertex attributes bound. Setting up a dummy VAO before compiling the shaders and linking the programs fixed this. It's unfortunate that WebGL does not expose ARB_vertex_attrib_binding, so setting up the dummy VAO was a bit clunky, but it wasn't too bad. Make sure you compile your shaders with the correct vertex attribute set up or you risk a dynamic shader recompilation. ________________________________ From: owners-public_webgl...@ on behalf of Kai Ninomiya (kainino...@) Sent: Sunday, May 12, 2019 10:03:54 AM To: public webgl Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved I think we will probably need to optimize checking LINK_STATUS (which would make useProgram faster too), so that when the COMPLETION_STATUS query result is sent to the client and cached, it sends the LINK_STATUS as well, and updates the already existing link status cache. From: Takahiro Aoyagi (taoyagi...@) > Date: Sun, May 12, 2019, 2:14 AM To: Public WebGL Thanks for the comments, Chen and Kai. Yeah, 8ms is very long to me. And if I compile+link two or more programs the time can be longer. > I guess I??ve found the cause for gl.useProgram. WebGL implementation inserts an extra GL command to query LinkStatus before using it. Will this be optimized (not adding the extra GL command) at some point? Or must it be necessary? > But do note that we cache that info, so it only takes extra time on the first useProgram. I confirmed that on my test. https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime10.html So far I'll try not to switch to a program which hasn't been called with gl.useProgram() yet while at least one program is being compiled+linked. On Sun, May 12, 2019 at 2:54 PM Kai Ninomiya (kainino...@) > wrote: 8ms is an extraordinary long time, in frame rendering time. But do note that we cache that info, so it only takes extra time on the first useProgram. From: Chen, Jie A (jie.a.chen...@) > Date: Sat, May 11, 2019, 8:07 PM To: Public WebGL I guess I??ve found the cause for gl.useProgram. WebGL implementation inserts an extra GL command to query LinkStatus before using it. https://cs.chromium.org/chromium/src/third_party/blink/renderer/modules/webgl/webgl_rendering_context_base.cc?sq=package:chromium&g=0&l=6350 Anyway I think you don??t need to worry too much about this. Usually it doesn??t take very long to drain the command buffer. I tried your test case, which took about only 8ms on my laptop. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Chen, Jie A (jie.a.chen...@) Sent: Sunday, May 12, 2019 9:44 AM To: Public WebGL > Subject: RE: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Mostly they are gl.get* like commands. You can search ??WaitForCmd?? in https://cs.chromium.org/chromium/src/gpu/command_buffer/client/gles2_implementation_impl_autogen.h and https://cs.chromium.org/chromium/src/gpu/command_buffer/client/gles2_implementation.cc for them. But I don??t think gl.useProgram needs to wait. Most likely it has a different cause. I will look into it later. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Takahiro Aoyagi (taoyagi...@) Sent: Sunday, May 12, 2019 2:27 AM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Hi Chen, Thanks for your explanation. What type of WebGL draw calls need to wait for all queued GL commands? In my tests, not only gl.get*() https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime9.html but also gl.useProgram() seems to wait. https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime8.html That means, I shouldn't call any gl.get*() and also I shouldn't switch program until all programs compilation+linking are done? I haven't tried yet but could draw calls wait, too? If so, I shouldn't render anything until then? [Image removed by sender.] Virus-free. www.avg.com On Sat, May 11, 2019 at 12:43 PM Chen, Jie A (jie.a.chen...@) > wrote: Interesting question, Takahiro. My speculation is that the problem might be relevant to chrome??s multi-process architecture. As you may know, the WebGL calls run in the main thread of render process. Chrome needs to send these WebGL commands to the GPU process for actual execution. So in your case, what Chrome actually does for calls of makeProgram2 is simply putting the GL commands into a IPC buffer. But later when you retrieve a program parameter back, it then waits for the execution of all previously issued GL commands including makeProgram2. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Takahiro Aoyagi (taoyagi...@) Sent: Saturday, May 11, 2019 6:58 AM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved I'm very glad this extension moves forward. Question. Can compiling+linking a program block another program's gl.get*() or gl.useProgram()? Even after confirming compile+link completion of a program with COMPLETION_STATUS_KHR, gl.getProgramParameter() or gl.useProgram() seems being blocked if another program is being compiled+linked on my Windows Canary. Is this intentional or bug? https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime8.html https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime9.html // Confirm program compile+link completion if(gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR)) { // Compile and link another program const vertexShader2 = gl.createShader(gl.VERTEX_SHADER); const fragmentShader2 = gl.createShader(gl.FRAGMENT_SHADER); const program2 = gl.createProgram(); gl.shaderSource(vertexShader2, vertexShaderCode); gl.shaderSource(fragmentShader2, fragmentShaderCode); gl.compileShader(vertexShader2); gl.compileShader(fragmentShader2); gl.attachShader(program2, vertexShader2); gl.attachShader(program2, fragmentShader2); gl.linkProgram(program2); // gl.get*() or gl.useProgram() while the other program is being compiled+linkied const startTime = performance.now(); gl.getProgramParameter(program, gl.ACTIVE_ATTRIBUTES); // or gl.useProgram(program); const endTime = performance.now(); } Takahiro [Image removed by sender.] Virus-free. www.avg.com On Sat, May 11, 2019 at 6:11 AM Ken Russell (kbr...@) > wrote: Since there haven't been any *objections* to moving this extension forward, and since the benefits are now being seen, it's been moved to community approved in https://github.com/KhronosGroup/WebGL/pull/2855 . Please, feel free to continue to report problems with long shader compilation times - either posting here on this mailing list or on webgl-dev-list, reporting cross-browser issues on https://github.com/KhronosGroup/WebGL/issues , or on individual browsers' bug trackers. -Ken From: Ken Russell > Date: Fri, May 10, 2019 at 1:39 PM To: Public WebGL Super. Thank you Takahiro for testing and confirming! From: Takahiro Aoyagi (taoyagi...@) > Date: Fri, May 10, 2019 at 10:51 AM To: Public WebGL I made simple tests to check the CPU elapsed time of gl.getProgramParameter() and gl.useProgram() after checking COMPLETION_STATUS_KHR is true. Both are fast here on my Windows10 Chrome Canary. https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime6.html https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime7.html Takahiro [Image removed by sender.] Virus-free. www.avg.com On Sat, May 11, 2019 at 2:46 AM Ken Russell (kbr...@) > wrote: Hmm. The only reason I can think of that that would happen is if you're running on Windows, and ANGLE has to dynamically recompile the program behind the scenes in order to handle some OpenGL ES state change. I'm not 100% sure which changes require this dynamic recompilation; the ANGLE developers would know best. https://groups.google.com//forum/#!forum/angleproject might be helpful. We'd really need some test case to make progress on this. Can you provide one? -Ken On Fri, May 10, 2019 at 10:28 AM Jasper St. Pierre (jstpierre...@) > wrote: Hello again. My app is now showing that getProgramParameter is completing quick, but it is spending a lot of time in useProgram. I am checking for COMPLETION_STATUS_KHR on the GL program beforehand and it is returning true. I??m guessing there??s some additional expensive work that still needs to happen at useProgram time. Is this a bug? Any ways to debug or avoid this? I??m unsure if there will be an easy repro. Again, profiler screenshot attached. From: owners-public_webgl...@ > On Behalf Of Takahiro Aoyagi (taoyagi...@) Sent: Friday, May 10, 2019 12:22 AM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Confirmed COMPLETION_STATUS_KHR is very fast like 0.01ms on my test https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html Nice work! Thanks [Image removed by sender. https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png] Virus-free. www.avg.com On Wed, May 8, 2019 at 2:41 PM Ken Russell (kbr...@) > wrote: Jie Chen from Intel just landed a fix in Chrome dramatically improving the performance of querying COMPLETION_STATUS_KHR under http://crbug.com/881152 . The fix will be in tomorrow's Canary on Windows and macOS. This should address the last major gap with this extension. We would like to enable it by default by promoting it to community approved; any further comments? -Ken From: Ken Russell > Date: Fri, Apr 26, 2019 at 3:40 PM To: Public WebGL Thanks for the report and the clear test case. There was an existing bug about this, so the new one was duplicated into it, and some hints about implementing it were added to the preexisting bug. On Fri, Apr 26, 2019 at 5:56 AM Takahiro Aoyagi (taoyagi...@) > wrote: Hi Chen, Opened a bug. Thanks. https://bugs.chromium.org/p/chromium/issues/detail?id=957001 Takahiro On Fri, Apr 26, 2019 at 8:03 PM Chen, Jie A (jie.a.chen...@) > wrote: Hi Takahiro, The current implementation of COMPLETION_STATUS_KHR query in chromium incurs an expensive round-trip to the GPU thread. This may contribute to the wait time in your case. I am trying to optimize this. Could you please file a bug to chromium? I would look into it once I??ve done the optimization. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Takahiro Aoyagi (taoyagi...@) Sent: Friday, April 26, 2019 6:20 PM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Hi all, I'm working on Three.js + KHR_parallel_shader_compile extension support with Fernando. https://github.com/mrdoob/three.js/issues/16321#issuecomment-486436086 I'm testing with Canary. But the behavior seems weird to me. gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) seems to wait for compile+link completion. I don't think it should wait for that, it should just do polling and returning true/false quickly instead. I made a simple test to reproduce. https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html Code snippet. const ext = gl.getExtension('KHR_parallel_shader_compile'); gl.compileShader(vertexShader); gl.compileShader(fragmentShader); gl.attachShader(program, vertexShader); gl.attachShader(program, fragmentShader); gl.linkProgram(program); const startTime = performance.now(); const status = useExtension ? gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) : gl.getProgramParameter(program, gl.LINK_STATUS); const endTime = performance.now(); const elapsedTime = endTime - startTime; On my platform, both gl.LINK_STATUS and ext.COMPLETION_STATUS_KHR take so long time about 15ms. I can accept this number for gl.LINK_STATUS because it waits for compile+link completion. But 15ms for ext.COMPLETION_STATUS_KHR looks weird to me. It shouldn't wait for the compile+link completion but should do just polling and quickly returning true/false instead. So I guess the number should be 1ms or less. Let me know if I'm missing something. Or could it be a Canary bug? My platform. OS: Windows10 Browser: Chrome Canary. Browser boot option: --use-cmd-decoder=passthrough --enable-webgl-draft-extensions Thanks Takahiro On Fri, Apr 26, 2019 at 10:15 AM Chen, Jie A (jie.a.chen...@) > wrote: Basically, for ANGLE??s GL backend, it??s simply a wrapper for the existing GL implementations. In this sense glCompileShader() is still implementation specific. Essentially ANGLE just calls glCompileShader and check GL_COMPILE_STATUS. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Jasper St. Pierre (jstpierre...@) Sent: Friday, April 26, 2019 1:18 AM To: Public WebGL > Subject: RE: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Thank you, that??s important information to know. Changing my shader compilation pipeline to wait for shader completion status is a lot more difficult, but based on some initial tests, it??s more expensive than not doing it ?C the latency of getShaderParameter is too high. That said, in a lot of GL implementations, glCompileShader() is practically a no-op, and will only do an AST parse when glGetShaderParameter/InfoLog() is called (which is basically only for debugging / error checking). glLinkProgram() does full compilation of all programs, as full-PSO optimization is important. I don??t know how common this is, but multiple GL implementations I have seen do it. It might make sense for ANGLE to adopt this model as well. From: owners-public_webgl...@ > On Behalf Of Chen, Jie A (jie.a.chen...@) Sent: Wednesday, April 24, 2019 6:48 PM To: Public WebGL > Subject: RE: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Absolutely. Ideally there would be no stall for linkProgram. I tried, but it??s too difficult to achieve this in ANGLE. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Jeff Gilbert (jgilbert...@) Sent: Thursday, April 25, 2019 9:33 AM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Possibly, but in the long run, I expect implementations to support no-stall linkProgram invocations. On Wed, Apr 24, 2019 at 6:27 PM Chen, Jie A (jie.a.chen...@) > wrote: linkProgram may stall on compileShader. To avoid the stall, you??d better make sure the COMPLETION_STATUS_KHR statuses of the attached shaders are all True before calling linkProgram. In this sense, the first workflow has less chance running into stall. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Fernando Serrano Garc??a (fserrano...@) Sent: Wednesday, April 24, 2019 9:38 PM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Regarding the optimal proposed workflow (grouping shaders and programs separately) of: for (const x of shaders) gl.compileShader(x); for (const x of programs) gl.linkProgram(x); versus something more on the way that we currently have in many engines as threejs: for (const x of material) gl.compileShader(fs); gl.compileShader(vs); gl.linkProgram(x); Do you think is more or less accurate the following graph for 4 materials and enabling this extension with 2 and 4 parallel threads? [Screen Shot 2019-04-24 at 15.35.47.png] On Wed, Apr 24, 2019 at 2:40 PM Fernando Serrano Garc??a > wrote: fwiw three.js introduced a "debug" parameter (false by default) to determine if there will be a status check and call all the get* (currently in dev): - https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLShader.js#L21-L26 - https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLProgram.js#L608 so currently calling `new WebGLShader()` won't be blocking with any `get*` function and it could be used as is to compile all of them in a loop with or without the extension. the problem comes from the WebGLProgram as it should just queue itself before trying to link any program and wait until all the shader compile calls finish, then do all the link, and wait for it asynchronously before start using these programs. I have opened an issue on the three.js repo to keep track of the implementation and we have booked some time this week to take a look at it, feedback is welcome :) https://github.com/mrdoob/three.js/issues/16321 On Tue, Apr 16, 2019 at 11:55 PM Ken Russell (kbr...@) > wrote: On Tue, Apr 16, 2019 at 2:24 PM Tarek Sherif (tsherif...@) > wrote: Yes, I've read both specs. I think this language in the WebGL version is confusing: "When this extension is enabled: Shader compilation and program linking may be performed in a separate CPU thread." And neither indicates which functions are expected to cause stalls. As written, this extension requires more than most that people know implementation details. All previous operations against the program - looking up uniform locations, drawing with it, etc. - will cause stalls. The application *must* be updated to query the program's COMPLETION_STATUS_KHR status, and skip *all* operations against the program until it's no longer pending. I guess we'll just change the WebGL version of this extension spec to be much more explicit about this. Essentially, all previous code which checked for the completion of compilation of shaders / linking of programs can be updated with a small wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. This is not true because the most common way this is done will cause stalls that sabotage the parallelism, e.g.: https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLShader.js#L21-L36 https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLProgram.js#L586-L631 The check for COMPLETION_STATUS_KHR has to wrap *all* queries and uses of the program object, and they must be skipped until COMPLETION_STATUS_KHR returns true. Yes, all applications will have to be updated to take advantage of this extension, but if they do, the benefits will be significant. -Ken Tarek Sherif Senior Software Engineer, Visualization | Uber http://vis.gl/ On Tue, Apr 16, 2019 at 4:18 PM Ken Russell (kbr...@) > wrote: Please review the Overview in the underlying OpenGL ES spec: https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt It describes that the extension uses one or more separate CPU threads for shader compilation. If you still think we should rewrite the introduction to the WebGL extension, we can do that too. Essentially, all previous code which checked for the completion of compilation of shaders / linking of programs can be updated with a small wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. -Ken On Tue, Apr 16, 2019 at 1:36 AM Tarek Sherif (tsherif...@) > wrote: This is all extremely interesting, and documentation of these best practices should probably be more publicly available (perhaps through a non-normative note in the spec). I'm thinking the language in the extension spec could be made more clear about what it's actual purpose is. It currently gives the impression that enabling it is what allows for parallel compilation and that this should save time, but given what Jeff and Kai have said, it sounds like the purpose is to avoid CPU stalls, and that it might even take longer in wall time since you're only checking once a frame. Maybe some background information could be added along the lines of "Normally applications must wait on get*Parameter or a draw call for program linking to complete, this extension provides a mechanism for querying completion status without stalling..." Tarek Sherif Senior Software Engineer, Visualization | Uber http://vis.gl/ On Mon, Apr 15, 2019 at 11:23 PM Kai Ninomiya (kainino...@) > wrote: On Mon, Apr 15, 2019 at 7:18 PM Tarek Sherif (tareksherif...@) > wrote: I don't see anything in the OpenGL extension spec about what functions cause stalls. Is that implementation-specific? Having an idea what to expect is important for two reasons: 1. To make it clear that drawing will still work if getProgramParameter(COMPLETION_STATUS_KHR) hasn't returned true yet (i.e. the stall on a draw call) Generally, OpenGL extensions are not allowed to break existing API/existing content. (In OpenGL, all extensions are always enabled; there's no requestExtension.) Hence, even if you enable the extension, it won't change the way your application works, and therefore the draw call must still cause a stall in order to be able to use the program. 2. Almost all WebGL code I've looked at handles compilation in a way similar to the following: gl.compileShader(vertexShader); if (!gl.getShaderParameter(vertexShader, gl.COMPILE_STATUS)) //... gl.compileShader(fragmentShader); if (!gl.getShaderParameter(fragmentShader, gl.COMPILE_STATUS)) //... //... gl.linkProgram(program); if (!gl.getProgramParameter(program, gl.LINK_STATUS)) //... I think it would be worth it to make clear that this pattern would sabotage the parallel compile. I seem to remember (not sure if this is still true) that this pattern also sabotages the shader compiler cache in ANGLE, because ANGLE doesn't cache the COMPILE_STATUS (or was it the compile info string?). So it forces the compiler to recompile just to give you the status. Tarek Sherif http://tareksherif.net/ ?\?\?\?\?\?\?\ Original Message ?\?\?\?\?\?\?\ On Monday, April 15, 2019 9:00 PM, Ken Russell (kbr...@) > wrote: The WebGL extension (which is basically just a wrapper) refers to the underlying OpenGL / OpenGL ES extension https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt, where this is documented. Is that sufficient? It would be better to avoid duplicating a large amount of spec text from the underlying extension. However, we can add some non-normative text if that would help. -Ken On Sat, Apr 13, 2019 at 3:51 AM Tarek Sherif (tareksherif...@) > wrote: IIRC, all 3 of those functions still force a wait for the {shader to finish compiling, program to finish linking} just as they did before. The new semantics are only visible via the new COMPLETION_STATUS_KHR check. That should work perfectly for us. Can we add some language to the spec about which functions cause stalls? I feel like as written, it will be easy for people to use the extension incorrectly. Tarek Sherif http://tareksherif.net/ ?\?\?\?\?\?\?\ Original Message ?\?\?\?\?\?\?\ On Friday, April 12, 2019 4:10 PM, Kai Ninomiya (kainino...@) > wrote: Oh yes, useProgram probably won't stall. But getUniformLocation and the others will stall, as will draw calls. getProgramParameter(COMPLETION_STATUS_KHR) should get faster at some point; see http://crbug.com/881152 which Ken linked. On Fri, Apr 12, 2019 at 12:39 PM Jasper St. Pierre (jstpierre...@) > wrote: Thank you! Trying this out in my own WebGL 2 app, I see quite a reduction in shader compilation time, shaving 400ms on load time on a moderately complex scene. The getProgramParameter(COMPLETION_STATUS_KHR) query still takes 1ms (which I believe is being tracked), but that is still better from the 4ms I see in getUniformBlockIndex (my previous sync point). AFAIK, useProgram should not cause a stall, but in order to set my texture samplers to bind to different units, I need to do a getUniformLocation on my sampler uniform, which causes a compilation stall. Same thing with getUniformBlockIndex. Do make sure that anything that might query into reflection about the program (e.g. getVertexAttributeIndex, getUniformLocation, getUniformBlockIndex) happens after COMPLETION_STATUS_KHR returns true, since that??s another way to accidentally stall on compilation completing. From: owners-public_webgl...@ > On Behalf Of Kai Ninomiya (kainino...@) Sent: Friday, April 12, 2019 10:25 AM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved IIRC, all 3 of those functions still force a wait for the {shader to finish compiling, program to finish linking} just as they did before. The new semantics are only visible via the new COMPLETION_STATUS_KHR check. On Fri, Apr 12, 2019 at 10:05 AM Tarek Sherif (tsherif...@) > wrote: Very excited about this extension, but I'm concerned about how it would work in our use case. Our flagship visualization library, deck.gl, often shares the gl context with a separate base map rendering application so that it can properly interleave visualization layers with the base map. Enabling this extension seems to change the behaviour of existing WebGL functions in a way that I don't believe other extensions do. My worry is how our enabling KHR_parallel_shader_compile would affect applications we share contexts with, i.e what happens if the typical synchronous compilation logic is used after KHR_parallel_shader_compile is enabled? Specifically: * What happens if getShaderParameter(shader, COMPILE_STATUS) is called before compilation is complete? * What happens if getProgramParameter(program, LINK_STATUS) is called before linking is complete? * What happens if useProgram is called before linking is complete? Thanks, Tarek Sherif Senior Software Engineer, Visualization | Uber http://vis.gl/ Tarek Sherif Senior Software Engineer, Visualization | Uber http://vis.gl/ On Fri, Apr 12, 2019 at 12:16 PM David Catuhe (David.Catuhe...@) > wrote: Wonderful! From: owners-public_webgl...@ > On Behalf Of Ken Russell (kbr...@) Sent: Wednesday, April 10, 2019 2:56 PM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved If your code works correctly now when enabling draft WebGL extensions in Chrome, then no changes are needed. There won't be any changes to the extension when it's taken out of draft status; it'll just be available by default. -Ken On Wed, Apr 10, 2019 at 12:36 PM David Catuhe (David.Catuhe...@) > wrote: We do have support for the extension in Babylon.js. How can we test this change? ________________________________ From: owners-public_webgl...@ > on behalf of Ken Russell (kbr...@) > Sent: Wednesday, April 10, 2019 12:00:25 PM To: public Subject: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved WebGL community, Jie Chen from Intel has principally developed and implemented a WebGL wrapper for the KHR_parallel_shader_compile extension. This allows shader compilation and program linking to occur fully in parallel to the rest of the WebGL application. Some small application changes are needed to take full advantage of the extension, but it is otherwise fully backward compatible. Jie has even emulated this extension on platforms which don't support it natively. This extension solves a longstanding user complaint with WebGL, namely long shader compile times on Windows. Compiles and links occur not only asynchronously, but also in parallel, so there is a net speedup when using this extension. Users who have tried out the draft extension are pleased with the results and would like to see it made widely available. I propose promoting this extension to community approved in https://github.com/KhronosGroup/WebGL/pull/2855 . Any comments? -Ken [Image removed by sender. https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png] Virus-free. www.avg.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From pub...@ Mon May 13 10:51:25 2019 From: pub...@ (Kai Ninomiya (...@...)) Date: Mon, 13 May 2019 10:51:25 -0700 Subject: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved In-Reply-To: References: <5F447A42ADFAFD499D69CF330DF2E5C160660987@SHSMSX101.ccr.corp.intel.com> <5F447A42ADFAFD499D69CF330DF2E5C160661691@SHSMSX101.ccr.corp.intel.com> <5F447A42ADFAFD499D69CF330DF2E5C160661793@SHSMSX101.ccr.corp.intel.com> Message-ID: Jasper, thanks for looking into that! I think Chrome should print a performance warning if we compile a shader that ends up getting recompiled before ever being used. Jie, would you be interested in looking into adding this warning? *From: *Jasper St. Pierre (jstpierre...@) *Date: *Sun, May 12, 2019 at 8:03 PM *To: *Public WebGL I should probably note that the cause for the long stalls on gl.useProgram > was found. It turns out that ANGLE, at least on D3D11, will recompile the > shader program for every set of vertex attributes that it is used with. The > initial compileShader / linkProgram calls was done without having any VAO > or vertex attributes bound. Setting up a dummy VAO before compiling the > shaders and linking the programs fixed this. It's unfortunate that WebGL > does not expose ARB_vertex_attrib_binding, so setting up the dummy VAO > was a bit clunky, but it wasn't too bad. Make sure you compile your shaders > with the correct vertex attribute set up or you risk a dynamic shader > recompilation. > ------------------------------ > *From:* owners-public_webgl...@ > on behalf of Kai Ninomiya (kainino...@) > *Sent:* Sunday, May 12, 2019 10:03:54 AM > *To:* public webgl > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > I think we will probably need to optimize checking LINK_STATUS (which > would make useProgram faster too), so that when the COMPLETION_STATUS query > result is sent to the client and cached, it sends the LINK_STATUS as well, > and updates the already existing link status cache. > > *From: *Takahiro Aoyagi (taoyagi...@) > *Date: *Sun, May 12, 2019, 2:14 AM > *To: *Public WebGL > > Thanks for the comments, Chen and Kai. > > Yeah, 8ms is very long to me. And if I compile+link two or more programs > the time can be longer. > > > I guess I?ve found the cause for gl.useProgram. WebGL implementation > inserts an extra GL command to query LinkStatus before using it. > > Will this be optimized (not adding the extra GL command) at some point? Or > must it be necessary? > > > But do note that we cache that info, so it only takes extra time on the > first useProgram. > > I confirmed that on my test. > > > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime10.html > > So far I'll try not to switch to a program which hasn't been called with > gl.useProgram() yet while at least one program is being compiled+linked. > > > On Sun, May 12, 2019 at 2:54 PM Kai Ninomiya (kainino...@) < > public_webgl...@> wrote: > > 8ms is an extraordinary long time, in frame rendering time. > > But do note that we cache that info, so it only takes extra time on the > first useProgram. > > *From: *Chen, Jie A (jie.a.chen...@) > *Date: *Sat, May 11, 2019, 8:07 PM > *To: *Public WebGL > > I guess I?ve found the cause for gl.useProgram. WebGL implementation > inserts an extra GL command to query LinkStatus before using it. > > > https://cs.chromium.org/chromium/src/third_party/blink/renderer/modules/webgl/webgl_rendering_context_base.cc?sq=package:chromium&g=0&l=6350 > > > > Anyway I think you don?t need to worry too much about this. Usually it > doesn?t take very long to drain the command buffer. I tried your test case, > which took about only 8ms on my laptop. > > > > > > *From:* owners-public_webgl...@ [mailto: > owners-public_webgl...@] *On Behalf Of *Chen, Jie A ( > jie.a.chen...@) > *Sent:* Sunday, May 12, 2019 9:44 AM > *To:* Public WebGL > *Subject:* RE: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Mostly they are gl.get* like commands. You can search ?WaitForCmd? in > https://cs.chromium.org/chromium/src/gpu/command_buffer/client/gles2_implementation_impl_autogen.h and > > https://cs.chromium.org/chromium/src/gpu/command_buffer/client/gles2_implementation.cc > for them. > > But I don?t think gl.useProgram needs to wait. Most likely it has a > different cause. I will look into it later. > > > > > > *From:* owners-public_webgl...@ [mailto: > owners-public_webgl...@] *On Behalf Of *Takahiro Aoyagi ( > taoyagi...@) > *Sent:* Sunday, May 12, 2019 2:27 AM > *To:* Public WebGL > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Hi Chen, > > > > Thanks for your explanation. > > > > What type of WebGL draw calls need to wait for all queued GL commands? In > my tests, not only gl.get*() > > > > > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime9.html > > > > but also gl.useProgram() seems to wait. > > > > > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime8.html > > > > > That means, I shouldn't call any gl.get*() and also I shouldn't switch > program until all programs compilation+linking are done? > > > > I haven't tried yet but could draw calls wait, too? If so, I shouldn't > render anything until then? > > > > > > [image: Image removed by sender.] > > > Virus-free. www.avg.com > > > > > On Sat, May 11, 2019 at 12:43 PM Chen, Jie A (jie.a.chen...@) < > public_webgl...@> wrote: > > Interesting question, Takahiro. > > My speculation is that the problem might be relevant to chrome?s > multi-process architecture. As you may know, the WebGL calls run in the > main thread of render process. Chrome needs to send these WebGL commands to > the GPU process for actual execution. So in your case, what Chrome actually > does for calls of makeProgram2 is simply putting the GL commands into a IPC > buffer. But later when you retrieve a program parameter back, it then > waits for the execution of all previously issued GL commands including > makeProgram2. > > > > *From:* owners-public_webgl...@ [mailto: > owners-public_webgl...@] *On Behalf Of *Takahiro Aoyagi ( > taoyagi...@) > *Sent:* Saturday, May 11, 2019 6:58 AM > *To:* Public WebGL > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > I'm very glad this extension moves forward. > > > > Question. Can compiling+linking a program block another program's > gl.get*() or gl.useProgram()? > > > > Even after confirming compile+link completion of a program with > COMPLETION_STATUS_KHR, gl.getProgramParameter() or gl.useProgram() seems > being blocked if another program is being compiled+linked on my Windows > Canary. Is this intentional or bug? > > > > > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime8.html > > > > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime9.html > > > > // Confirm program compile+link completion > > if(gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR)) { > > // Compile and link another program > > const vertexShader2 = gl.createShader(gl.VERTEX_SHADER); > const fragmentShader2 = gl.createShader(gl.FRAGMENT_SHADER); > const program2 = gl.createProgram(); > > gl.shaderSource(vertexShader2, vertexShaderCode); > gl.shaderSource(fragmentShader2, fragmentShaderCode); > gl.compileShader(vertexShader2); > gl.compileShader(fragmentShader2); > gl.attachShader(program2, vertexShader2); > gl.attachShader(program2, fragmentShader2); > gl.linkProgram(program2); > > > > // gl.get*() or gl.useProgram() while the other program is being > compiled+linkied > > const startTime = performance.now(); > gl.getProgramParameter(program, gl.ACTIVE_ATTRIBUTES); // or > gl.useProgram(program); > const endTime = performance.now(); > > } > > > > Takahiro > > > > [image: Image removed by sender.] > > > Virus-free. www.avg.com > > > > > On Sat, May 11, 2019 at 6:11 AM Ken Russell (kbr...@) < > public_webgl...@> wrote: > > Since there haven't been any *objections* to moving this extension > forward, and since the benefits are now being seen, it's been moved to > community approved in https://github.com/KhronosGroup/WebGL/pull/2855 . > > > > Please, feel free to continue to report problems with long shader > compilation times - either posting here on this mailing list or on > webgl-dev-list, reporting cross-browser issues on > https://github.com/KhronosGroup/WebGL/issues , or on individual browsers' > bug trackers. > > > > -Ken > > > > > > > > *From: *Ken Russell > *Date: *Fri, May 10, 2019 at 1:39 PM > *To: *Public WebGL > > Super. Thank you Takahiro for testing and confirming! > > > > > > *From: *Takahiro Aoyagi (taoyagi...@) > *Date: *Fri, May 10, 2019 at 10:51 AM > *To: *Public WebGL > > I made simple tests to check the CPU elapsed time of > gl.getProgramParameter() and gl.useProgram() after checking > COMPLETION_STATUS_KHR is true. Both are fast here on my Windows10 Chrome > Canary. > > > > > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime6.html > > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime7.html > > > > Takahiro > > > > [image: Image removed by sender.] > > > Virus-free. www.avg.com > > > > > On Sat, May 11, 2019 at 2:46 AM Ken Russell (kbr...@) < > public_webgl...@> wrote: > > Hmm. The only reason I can think of that that would happen is if you're > running on Windows, and ANGLE has to dynamically recompile the program > behind the scenes in order to handle some OpenGL ES state change. I'm not > 100% sure which changes require this dynamic recompilation; the ANGLE > developers would know best. > https://groups.google.com//forum/#!forum/angleproject > might be helpful. > > > > We'd really need some test case to make progress on this. Can you provide > one? > > > > -Ken > > > > > > On Fri, May 10, 2019 at 10:28 AM Jasper St. Pierre (jstpierre...@) > wrote: > > Hello again. My app is now showing that getProgramParameter is completing > quick, but it is spending a lot of time in useProgram. I am checking for > COMPLETION_STATUS_KHR on the GL program beforehand and it is returning > true. I?m guessing there?s some additional expensive work that still needs > to happen at useProgram time. Is this a bug? Any ways to debug or avoid > this? I?m unsure if there will be an easy repro. > > > > Again, profiler screenshot attached. > > > > *From:* owners-public_webgl...@ *On > Behalf Of *Takahiro Aoyagi (taoyagi...@) > *Sent:* Friday, May 10, 2019 12:22 AM > *To:* Public WebGL > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Confirmed COMPLETION_STATUS_KHR is very fast like 0.01ms on my test > > > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html > > > > Nice work! > > > > Thanks > > > > [image: Image removed by sender. > https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png] > > > Virus-free. www.avg.com > > > > > On Wed, May 8, 2019 at 2:41 PM Ken Russell (kbr...@) < > public_webgl...@> wrote: > > Jie Chen from Intel just landed a fix in Chrome dramatically improving the > performance of querying COMPLETION_STATUS_KHR under > http://crbug.com/881152 . The fix will be in tomorrow's Canary on Windows > and macOS. > > > > This should address the last major gap with this extension. We would like > to enable it by default by promoting it to community approved; any further > comments? > > > > -Ken > > > > > > > > *From: *Ken Russell > *Date: *Fri, Apr 26, 2019 at 3:40 PM > *To: *Public WebGL > > Thanks for the report and the clear test case. There was an existing bug > about this, so the new one was duplicated into it, and some hints about > implementing it were added to the preexisting bug. > > > > > > On Fri, Apr 26, 2019 at 5:56 AM Takahiro Aoyagi (taoyagi...@) < > public_webgl...@> wrote: > > Hi Chen, > > > > Opened a bug. Thanks. > > > > https://bugs.chromium.org/p/chromium/issues/detail?id=957001 > > > > Takahiro > > > > > > On Fri, Apr 26, 2019 at 8:03 PM Chen, Jie A (jie.a.chen...@) < > public_webgl...@> wrote: > > Hi Takahiro, > > The current implementation of COMPLETION_STATUS_KHR query in chromium > incurs an expensive round-trip to the GPU thread. This may contribute to > the wait time in your case. I am trying to optimize this. Could you please > file a bug to chromium? I would look into it once I?ve done the > optimization. > > > > *From:* owners-public_webgl...@ [mailto: > owners-public_webgl...@] *On Behalf Of *Takahiro Aoyagi ( > taoyagi...@) > *Sent:* Friday, April 26, 2019 6:20 PM > *To:* Public WebGL > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Hi all, > > > > I'm working on Three.js + KHR_parallel_shader_compile extension support > with Fernando. > > > > https://github.com/mrdoob/three.js/issues/16321#issuecomment-486436086 > > > > I'm testing with Canary. But the behavior seems weird to me. > gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) seems to wait > for compile+link completion. I don't think it should wait for that, it > should just do polling and returning true/false quickly instead. > > > > I made a simple test to reproduce. > > > > > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html > > > > Code snippet. > > > > const ext = gl.getExtension('KHR_parallel_shader_compile'); > > > > gl.compileShader(vertexShader); > gl.compileShader(fragmentShader); > gl.attachShader(program, vertexShader); > gl.attachShader(program, fragmentShader); > gl.linkProgram(program); > > const startTime = performance.now(); > const status = useExtension > ? gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) > : gl.getProgramParameter(program, gl.LINK_STATUS); > const endTime = performance.now(); > > const elapsedTime = endTime - startTime; > > > > On my platform, both gl.LINK_STATUS and ext.COMPLETION_STATUS_KHR take so > long time about 15ms. I can accept this number for gl.LINK_STATUS because > it waits for compile+link completion. But 15ms for > ext.COMPLETION_STATUS_KHR looks weird to me. It shouldn't wait for the > compile+link completion but should do just polling and quickly returning > true/false instead. So I guess the number should be 1ms or less. > > > > Let me know if I'm missing something. Or could it be a Canary bug? > > > > My platform. > > > > OS: Windows10 > > Browser: Chrome Canary. > > Browser boot option: --use-cmd-decoder=passthrough > --enable-webgl-draft-extensions > > > > > > Thanks > > > > Takahiro > > > > > > On Fri, Apr 26, 2019 at 10:15 AM Chen, Jie A (jie.a.chen...@) < > public_webgl...@> wrote: > > Basically, for ANGLE?s GL backend, it?s simply a wrapper for the existing > GL implementations. In this sense glCompileShader() is still implementation > specific. Essentially ANGLE just calls glCompileShader and check > GL_COMPILE_STATUS. > > > > *From:* owners-public_webgl...@ [mailto: > owners-public_webgl...@] *On Behalf Of *Jasper St. Pierre ( > jstpierre...@) > *Sent:* Friday, April 26, 2019 1:18 AM > *To:* Public WebGL > *Subject:* RE: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Thank you, that?s important information to know. Changing my shader > compilation pipeline to wait for shader completion status is a lot more > difficult, but based on some initial tests, it?s more expensive than not > doing it ? the latency of getShaderParameter is too high. > > > > That said, in a lot of GL implementations, glCompileShader() is > practically a no-op, and will only do an AST parse when > glGetShaderParameter/InfoLog() is called (which is basically only for > debugging / error checking). glLinkProgram() does full compilation of all > programs, as full-PSO optimization is important. I don?t know how common > this is, but multiple GL implementations I have seen do it. It might make > sense for ANGLE to adopt this model as well. > > > > *From:* owners-public_webgl...@ *On > Behalf Of *Chen, Jie A (jie.a.chen...@) > *Sent:* Wednesday, April 24, 2019 6:48 PM > *To:* Public WebGL > *Subject:* RE: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Absolutely. Ideally there would be no stall for linkProgram. I tried, but > it?s too difficult to achieve this in ANGLE. > > > > *From:* owners-public_webgl...@ [ > mailto:owners-public_webgl...@ ] *On > Behalf Of *Jeff Gilbert (jgilbert...@) > *Sent:* Thursday, April 25, 2019 9:33 AM > *To:* Public WebGL > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Possibly, but in the long run, I expect implementations to support > no-stall linkProgram invocations. > > > > On Wed, Apr 24, 2019 at 6:27 PM Chen, Jie A (jie.a.chen...@) < > public_webgl...@> wrote: > > linkProgram may stall on compileShader. To avoid the stall, you?d better > make sure the COMPLETION_STATUS_KHR statuses of the attached shaders are > all True before calling linkProgram. In this sense, the first workflow has > less chance running into stall. > > > > *From:* owners-public_webgl...@ [mailto: > owners-public_webgl...@] *On Behalf Of *Fernando Serrano Garc?a ( > fserrano...@) > *Sent:* Wednesday, April 24, 2019 9:38 PM > *To:* Public WebGL > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Regarding the optimal proposed workflow (grouping shaders and programs > separately) of: > > for (const x of shaders) > gl.compileShader(x); > for (const x of programs) > gl.linkProgram(x); > > > > versus something more on the way that we currently have in many engines as > threejs: > > for (const x of material) > > gl.compileShader(fs); > > gl.compileShader(vs); > gl.linkProgram(x); > > > > Do you think is more or less accurate the following graph for 4 materials > and enabling this extension with 2 and 4 parallel threads? > > > > [image: Screen Shot 2019-04-24 at 15.35.47.png] > > > > On Wed, Apr 24, 2019 at 2:40 PM Fernando Serrano Garc?a < > fserrano...@> wrote: > > fwiw three.js introduced a "debug" parameter (false by default) to > determine if there will be a status check and call all the get* (currently > in dev): > > - > https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLShader.js#L21-L26 > > - > https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLProgram.js#L608 > > > > so currently calling `new WebGLShader()` won't be blocking with any `get*` > function and it could be used as is to compile all of them in a loop with > or without the extension. > > the problem comes from the WebGLProgram as it should just queue itself > before trying to link any program and wait until all the shader compile > calls finish, then do all the link, and wait for it asynchronously before > start using these programs. > > I have opened an issue on the three.js repo to keep track of the > implementation and we have booked some time this week to take a look at it, > feedback is welcome :) https://github.com/mrdoob/three.js/issues/16321 > > > > On Tue, Apr 16, 2019 at 11:55 PM Ken Russell (kbr...@) < > public_webgl...@> wrote: > > On Tue, Apr 16, 2019 at 2:24 PM Tarek Sherif (tsherif...@) < > public_webgl...@> wrote: > > Yes, I've read both specs. I think this language in the WebGL version is > confusing: "When this extension is enabled: Shader compilation and program > linking may be performed in a separate CPU thread." And neither indicates > which functions are expected to cause stalls. As written, this extension > requires more than most that people know implementation details. > > > > All previous operations against the program - looking up uniform > locations, drawing with it, etc. - will cause stalls. The application > *must* be updated to query the program's COMPLETION_STATUS_KHR status, and > skip *all* operations against the program until it's no longer pending. > > > > I guess we'll just change the WebGL version of this extension spec to be > much more explicit about this. > > > > > > Essentially, all previous code which checked for the completion of > compilation of shaders / linking of programs can be updated with a small > wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. > > > > This is not true because the most common way this is done will cause > stalls that sabotage the parallelism, e.g.: > > https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLShader.js#L21-L36 > > > https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLProgram.js#L586-L631 > > > > The check for COMPLETION_STATUS_KHR has to wrap *all* queries and uses of > the program object, and they must be skipped until COMPLETION_STATUS_KHR > returns true. Yes, all applications will have to be updated to take > advantage of this extension, but if they do, the benefits will be > significant. > > > > -Ken > > > > > > *Tarek Sherif* > > Senior Software Engineer, Visualization | Uber > > http://vis.gl/ > > > > > > > > On Tue, Apr 16, 2019 at 4:18 PM Ken Russell (kbr...@) < > public_webgl...@> wrote: > > Please review the Overview in the underlying OpenGL ES spec: > > > https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt > > > > > It describes that the extension uses one or more separate CPU threads for > shader compilation. If you still think we should rewrite the introduction > to the WebGL extension, we can do that too. > > > > Essentially, all previous code which checked for the completion of > compilation of shaders / linking of programs can be updated with a small > wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. > > > > -Ken > > > > > > > > On Tue, Apr 16, 2019 at 1:36 AM Tarek Sherif (tsherif...@) < > public_webgl...@> wrote: > > This is all extremely interesting, and documentation of these best > practices should probably be more publicly available (perhaps through a > non-normative note in the spec). I'm thinking the language in the extension > spec could be made more clear about what it's actual purpose is. It > currently gives the impression that enabling it is what allows for parallel > compilation and that this should save time, but given what Jeff and Kai > have said, it sounds like the purpose is to avoid CPU stalls, and that it > might even take longer in wall time since you're only checking once a > frame. Maybe some background information could be added along the lines of > "Normally applications must wait on get*Parameter or a draw call for > program linking to complete, this extension provides a mechanism for > querying completion status without stalling..." > > > > *Tarek Sherif* > > Senior Software Engineer, Visualization | Uber > > http://vis.gl/ > > > > > > > > > On Mon, Apr 15, 2019 at 11:23 PM Kai Ninomiya (kainino...@) < > public_webgl...@> wrote: > > > > > > On Mon, Apr 15, 2019 at 7:18 PM Tarek Sherif (tareksherif...@) < > public_webgl...@> wrote: > > I don't see anything in the OpenGL extension spec about what functions > cause stalls. Is that implementation-specific? Having an idea what to > expect is important for two reasons: > > 1. To make it clear that drawing will still work if > getProgramParameter(COMPLETION_STATUS_KHR) hasn't returned true yet (i.e. > the stall on a draw call) > > > > Generally, OpenGL extensions are not allowed to break existing > API/existing content. (In OpenGL, all extensions are always enabled; > there's no requestExtension.) Hence, even if you enable the extension, it > won't change the way your application works, and therefore the draw call > must still cause a stall in order to be able to use the program. > > > > 2. Almost all WebGL code I've looked at handles compilation in a way > similar to the following: > > gl.compileShader(vertexShader); > if (!gl.getShaderParameter(vertexShader, gl.COMPILE_STATUS)) //... > > gl.compileShader(fragmentShader); > > if (!gl.getShaderParameter(fragmentShader, gl.COMPILE_STATUS)) //... > > //... > > gl.linkProgram(program); > if (!gl.getProgramParameter(program, gl.LINK_STATUS)) //... > > I think it would be worth it to make clear that this pattern would > sabotage the parallel compile. > > > > I seem to remember (not sure if this is still true) that this pattern also > sabotages the shader compiler cache in ANGLE, because ANGLE doesn't cache > the COMPILE_STATUS (or was it the compile info string?). So it forces the > compiler to recompile just to give you the status. > > > > Tarek Sherif > > http://tareksherif.net/ > > > > > > > > > ??????? Original Message ??????? > > On Monday, April 15, 2019 9:00 PM, Ken Russell (kbr...@) < > public_webgl...@> wrote: > > > > The WebGL extension (which is basically just a wrapper) refers to the > underlying OpenGL / OpenGL ES extension > https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt > , > where this is documented. Is that sufficient? It would be better to avoid > duplicating a large amount of spec text from the underlying extension. > However, we can add some non-normative text if that would help. > > > > -Ken > > > > > > > > On Sat, Apr 13, 2019 at 3:51 AM Tarek Sherif (tareksherif...@) < > public_webgl...@> wrote: > > IIRC, all 3 of those functions still force a wait for the {shader to > finish compiling, program to finish linking} just as they did before. The > new semantics are only visible via the new COMPLETION_STATUS_KHR check. > > That should work perfectly for us. Can we add some language to the spec > about which functions cause stalls? I feel like as written, it will be easy > for people to use the extension incorrectly. > > > > Tarek Sherif > > http://tareksherif.net/ > > > > > > > > > ??????? Original Message ??????? > > On Friday, April 12, 2019 4:10 PM, Kai Ninomiya (kainino...@) < > public_webgl...@> wrote: > > > > Oh yes, useProgram probably won't stall. But getUniformLocation and the > others will stall, as will draw calls. > > > > getProgramParameter(COMPLETION_STATUS_KHR) should get faster at some > point; see http://crbug.com/881152 > which > Ken linked. > > > > On Fri, Apr 12, 2019 at 12:39 PM Jasper St. Pierre (jstpierre...@) > wrote: > > Thank you! Trying this out in my own WebGL 2 app, I see quite a reduction > in shader compilation time, shaving 400ms on load time on a moderately > complex scene. The getProgramParameter(COMPLETION_STATUS_KHR) query still > takes 1ms (which I believe is being tracked), but that is still better from > the 4ms I see in getUniformBlockIndex (my previous sync point). > > > > AFAIK, useProgram should not cause a stall, but in order to set my texture > samplers to bind to different units, I need to do a getUniformLocation on > my sampler uniform, which causes a compilation stall. Same thing with > getUniformBlockIndex. Do make sure that anything that might query into > reflection about the program (e.g. getVertexAttributeIndex, > getUniformLocation, getUniformBlockIndex) happens after > COMPLETION_STATUS_KHR returns true, since that?s another way to > accidentally stall on compilation completing. > > > > > > *From:* owners-public_webgl...@ *On > Behalf Of *Kai Ninomiya (kainino...@) > > *Sent:* Friday, April 12, 2019 10:25 AM > > *To:* Public WebGL > > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > > > IIRC, all 3 of those functions still force a wait for the {shader to > finish compiling, program to finish linking} just as they did before. The > new semantics are only visible via the new COMPLETION_STATUS_KHR check. > > > > On Fri, Apr 12, 2019 at 10:05 AM Tarek Sherif (tsherif...@) < > public_webgl...@> wrote: > > Very excited about this extension, but I'm concerned about how it would > work in our use case. Our flagship visualization library, deck.gl > , > often shares the gl context with a separate base map rendering application > so that it can properly interleave visualization layers with the base map. > Enabling this extension seems to change the behaviour of existing WebGL > functions in a way that I don't believe other extensions do. My worry is > how our enabling KHR_parallel_shader_compile would affect applications we > share contexts with, i.e what happens if the typical synchronous > compilation logic is used after KHR_parallel_shader_compile is enabled? > Specifically: > > - What happens if getShaderParameter(shader, COMPILE_STATUS) is called > before compilation is complete? > - What happens if getProgramParameter(program, LINK_STATUS) is called > before linking is complete? > - What happens if useProgram is called before linking is complete? > > Thanks, > > > > > > Tarek Sherif > > Senior Software Engineer, Visualization | Uber > > http://vis.gl/ > > > > > > > > > > > *Tarek Sherif* > > Senior Software Engineer, Visualization | Uber > > http://vis.gl/ > > > > > > > On Fri, Apr 12, 2019 at 12:16 PM David Catuhe (David.Catuhe...@) > wrote: > > Wonderful! > > > > > > *From:* owners-public_webgl...@ *On > Behalf Of *Ken Russell (kbr...@) > > *Sent:* Wednesday, April 10, 2019 2:56 PM > > *To:* Public WebGL > > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > > > If your code works correctly now when enabling draft WebGL extensions in > Chrome, then no changes are needed. There won't be any changes to the > extension when it's taken out of draft status; it'll just be available by > default. > > > > -Ken > > > > > > On Wed, Apr 10, 2019 at 12:36 PM David Catuhe (David.Catuhe...@) > wrote: > > We do have support for the extension in Babylon.js. How can we test this > change? > ------------------------------ > > > > *From:* owners-public_webgl...@ > on behalf of Ken Russell (kbr...@) > *Sent:* Wednesday, April 10, 2019 12:00:25 PM > *To:* public > *Subject:* [Public WebGL] Propose promoting KHR_parallel_shader_compile > to community approved > > > > WebGL community, > > > > Jie Chen from Intel has principally developed and implemented a WebGL > wrapper for the KHR_parallel_shader_compile extension. This allows shader > compilation and program linking to occur fully in parallel to the rest of > the WebGL application. Some small application changes are needed to take > full advantage of the extension, but it is otherwise fully backward > compatible. Jie has even emulated this extension on platforms which don't > support it natively. > > > > This extension solves a longstanding user complaint with WebGL, namely > long shader compile times on Windows. Compiles and links occur not only > asynchronously, but also in parallel, so there is a net speedup when using > this extension. Users who have tried out the draft extension are pleased > with the results and would like to see it made widely available. > > > > I propose promoting this extension to community approved in > https://github.com/KhronosGroup/WebGL/pull/2855 > > . Any comments? > > > > -Ken > > > > > > > > > > [image: Image removed by sender. > https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png] > > > Virus-free. www.avg.com > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4845 bytes Desc: S/MIME Cryptographic Signature URL: From pub...@ Tue May 14 00:46:00 2019 From: pub...@ (Chen, Jie A (...@...)) Date: Tue, 14 May 2019 07:46:00 +0000 Subject: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved In-Reply-To: References: <5F447A42ADFAFD499D69CF330DF2E5C160660987@SHSMSX101.ccr.corp.intel.com> <5F447A42ADFAFD499D69CF330DF2E5C160661691@SHSMSX101.ccr.corp.intel.com> <5F447A42ADFAFD499D69CF330DF2E5C160661793@SHSMSX101.ccr.corp.intel.com> Message-ID: <5F447A42ADFAFD499D69CF330DF2E5C1606630CF@SHSMSX101.ccr.corp.intel.com> Kai, I?d like to do that. As far as I know, dynamic recompilation is not seldom seen in ANGLE d3d backend. I not am sure if that would be over warned. Probably we should file a bug to the ANGLE team firstly. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Kai Ninomiya (kainino...@) Sent: Tuesday, May 14, 2019 1:51 AM To: Public WebGL Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Jasper, thanks for looking into that! I think Chrome should print a performance warning if we compile a shader that ends up getting recompiled before ever being used. Jie, would you be interested in looking into adding this warning? From: Jasper St. Pierre (jstpierre...@) > Date: Sun, May 12, 2019 at 8:03 PM To: Public WebGL I should probably note that the cause for the long stalls on gl.useProgram was found. It turns out that ANGLE, at least on D3D11, will recompile the shader program for every set of vertex attributes that it is used with. The initial compileShader / linkProgram calls was done without having any VAO or vertex attributes bound. Setting up a dummy VAO before compiling the shaders and linking the programs fixed this. It's unfortunate that WebGL does not expose ARB_vertex_attrib_binding, so setting up the dummy VAO was a bit clunky, but it wasn't too bad. Make sure you compile your shaders with the correct vertex attribute set up or you risk a dynamic shader recompilation. ________________________________ From: owners-public_webgl...@ > on behalf of Kai Ninomiya (kainino...@) > Sent: Sunday, May 12, 2019 10:03:54 AM To: public webgl Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved I think we will probably need to optimize checking LINK_STATUS (which would make useProgram faster too), so that when the COMPLETION_STATUS query result is sent to the client and cached, it sends the LINK_STATUS as well, and updates the already existing link status cache. From: Takahiro Aoyagi (taoyagi...@) > Date: Sun, May 12, 2019, 2:14 AM To: Public WebGL Thanks for the comments, Chen and Kai. Yeah, 8ms is very long to me. And if I compile+link two or more programs the time can be longer. > I guess I?ve found the cause for gl.useProgram. WebGL implementation inserts an extra GL command to query LinkStatus before using it. Will this be optimized (not adding the extra GL command) at some point? Or must it be necessary? > But do note that we cache that info, so it only takes extra time on the first useProgram. I confirmed that on my test. https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime10.html So far I'll try not to switch to a program which hasn't been called with gl.useProgram() yet while at least one program is being compiled+linked. On Sun, May 12, 2019 at 2:54 PM Kai Ninomiya (kainino...@) > wrote: 8ms is an extraordinary long time, in frame rendering time. But do note that we cache that info, so it only takes extra time on the first useProgram. From: Chen, Jie A (jie.a.chen...@) > Date: Sat, May 11, 2019, 8:07 PM To: Public WebGL I guess I?ve found the cause for gl.useProgram. WebGL implementation inserts an extra GL command to query LinkStatus before using it. https://cs.chromium.org/chromium/src/third_party/blink/renderer/modules/webgl/webgl_rendering_context_base.cc?sq=package:chromium&g=0&l=6350 Anyway I think you don?t need to worry too much about this. Usually it doesn?t take very long to drain the command buffer. I tried your test case, which took about only 8ms on my laptop. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Chen, Jie A (jie.a.chen...@) Sent: Sunday, May 12, 2019 9:44 AM To: Public WebGL > Subject: RE: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Mostly they are gl.get* like commands. You can search ?WaitForCmd? in https://cs.chromium.org/chromium/src/gpu/command_buffer/client/gles2_implementation_impl_autogen.h and https://cs.chromium.org/chromium/src/gpu/command_buffer/client/gles2_implementation.cc for them. But I don?t think gl.useProgram needs to wait. Most likely it has a different cause. I will look into it later. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Takahiro Aoyagi (taoyagi...@) Sent: Sunday, May 12, 2019 2:27 AM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Hi Chen, Thanks for your explanation. What type of WebGL draw calls need to wait for all queued GL commands? In my tests, not only gl.get*() https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime9.html but also gl.useProgram() seems to wait. https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime8.html That means, I shouldn't call any gl.get*() and also I shouldn't switch program until all programs compilation+linking are done? I haven't tried yet but could draw calls wait, too? If so, I shouldn't render anything until then? Virus-free. www.avg.com On Sat, May 11, 2019 at 12:43 PM Chen, Jie A (jie.a.chen...@) wrote: Interesting question, Takahiro. My speculation is that the problem might be relevant to chrome?s multi-process architecture. As you may know, the WebGL calls run in the main thread of render process. Chrome needs to send these WebGL commands to the GPU process for actual execution. So in your case, what Chrome actually does for calls of makeProgram2 is simply putting the GL commands into a IPC buffer. But later when you retrieve a program parameter back, it then waits for the execution of all previously issued GL commands including makeProgram2. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Takahiro Aoyagi (taoyagi...@) Sent: Saturday, May 11, 2019 6:58 AM To: Public WebGL Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved I'm very glad this extension moves forward. Question. Can compiling+linking a program block another program's gl.get*() or gl.useProgram()? Even after confirming compile+link completion of a program with COMPLETION_STATUS_KHR, gl.getProgramParameter() or gl.useProgram() seems being blocked if another program is being compiled+linked on my Windows Canary. Is this intentional or bug? https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime8.html https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime9.html // Confirm program compile+link completion if(gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR)) { // Compile and link another program const vertexShader2 = gl.createShader(gl.VERTEX_SHADER); const fragmentShader2 = gl.createShader(gl.FRAGMENT_SHADER); const program2 = gl.createProgram(); gl.shaderSource(vertexShader2, vertexShaderCode); gl.shaderSource(fragmentShader2, fragmentShaderCode); gl.compileShader(vertexShader2); gl.compileShader(fragmentShader2); gl.attachShader(program2, vertexShader2); gl.attachShader(program2, fragmentShader2); gl.linkProgram(program2); // gl.get*() or gl.useProgram() while the other program is being compiled+linkied const startTime = performance.now(); gl.getProgramParameter(program, gl.ACTIVE_ATTRIBUTES); // or gl.useProgram(program); const endTime = performance.now(); } Takahiro Virus-free. www.avg.com On Sat, May 11, 2019 at 6:11 AM Ken Russell (kbr...@) wrote: Since there haven't been any *objections* to moving this extension forward, and since the benefits are now being seen, it's been moved to community approved in https://github.com/KhronosGroup/WebGL/pull/2855 . Please, feel free to continue to report problems with long shader compilation times - either posting here on this mailing list or on webgl-dev-list, reporting cross-browser issues on https://github.com/KhronosGroup/WebGL/issues , or on individual browsers' bug trackers. -Ken From: Ken Russell Date: Fri, May 10, 2019 at 1:39 PM To: Public WebGL Super. Thank you Takahiro for testing and confirming! From: Takahiro Aoyagi (taoyagi...@) Date: Fri, May 10, 2019 at 10:51 AM To: Public WebGL I made simple tests to check the CPU elapsed time of gl.getProgramParameter() and gl.useProgram() after checking COMPLETION_STATUS_KHR is true. Both are fast here on my Windows10 Chrome Canary. https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime6.html https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime7.html Takahiro Virus-free. www.avg.com On Sat, May 11, 2019 at 2:46 AM Ken Russell (kbr...@) wrote: Hmm. The only reason I can think of that that would happen is if you're running on Windows, and ANGLE has to dynamically recompile the program behind the scenes in order to handle some OpenGL ES state change. I'm not 100% sure which changes require this dynamic recompilation; the ANGLE developers would know best. https://groups.google.com//forum/#!forum/angleproject might be helpful. We'd really need some test case to make progress on this. Can you provide one? -Ken On Fri, May 10, 2019 at 10:28 AM Jasper St. Pierre (jstpierre...@) wrote: Hello again. My app is now showing that getProgramParameter is completing quick, but it is spending a lot of time in useProgram. I am checking for COMPLETION_STATUS_KHR on the GL program beforehand and it is returning true. I?m guessing there?s some additional expensive work that still needs to happen at useProgram time. Is this a bug? Any ways to debug or avoid this? I?m unsure if there will be an easy repro. Again, profiler screenshot attached. From: owners-public_webgl...@ On Behalf Of Takahiro Aoyagi (taoyagi...@) Sent: Friday, May 10, 2019 12:22 AM To: Public WebGL Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Confirmed COMPLETION_STATUS_KHR is very fast like 0.01ms on my test https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html Nice work! Thanks Virus-free. www.avg.com On Wed, May 8, 2019 at 2:41 PM Ken Russell (kbr...@) wrote: Jie Chen from Intel just landed a fix in Chrome dramatically improving the performance of querying COMPLETION_STATUS_KHR under http://crbug.com/881152 . The fix will be in tomorrow's Canary on Windows and macOS. This should address the last major gap with this extension. We would like to enable it by default by promoting it to community approved; any further comments? -Ken From: Ken Russell Date: Fri, Apr 26, 2019 at 3:40 PM To: Public WebGL Thanks for the report and the clear test case. There was an existing bug about this, so the new one was duplicated into it, and some hints about implementing it were added to the preexisting bug. On Fri, Apr 26, 2019 at 5:56 AM Takahiro Aoyagi (taoyagi...@) wrote: Hi Chen, Opened a bug. Thanks. https://bugs.chromium.org/p/chromium/issues/detail?id=957001 Takahiro On Fri, Apr 26, 2019 at 8:03 PM Chen, Jie A (jie.a.chen...@) wrote: Hi Takahiro, The current implementation of COMPLETION_STATUS_KHR query in chromium incurs an expensive round-trip to the GPU thread. This may contribute to the wait time in your case. I am trying to optimize this. Could you please file a bug to chromium? I would look into it once I?ve done the optimization. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Takahiro Aoyagi (taoyagi...@) Sent: Friday, April 26, 2019 6:20 PM To: Public WebGL Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Hi all, I'm working on Three.js + KHR_parallel_shader_compile extension support with Fernando. https://github.com/mrdoob/three.js/issues/16321#issuecomment-486436086 I'm testing with Canary. But the behavior seems weird to me. gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) seems to wait for compile+link completion. I don't think it should wait for that, it should just do polling and returning true/false quickly instead. I made a simple test to reproduce. https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html Code snippet. const ext = gl.getExtension('KHR_parallel_shader_compile'); gl.compileShader(vertexShader); gl.compileShader(fragmentShader); gl.attachShader(program, vertexShader); gl.attachShader(program, fragmentShader); gl.linkProgram(program); const startTime = performance.now(); const status = useExtension ? gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) : gl.getProgramParameter(program, gl.LINK_STATUS); const endTime = performance.now(); const elapsedTime = endTime - startTime; On my platform, both gl.LINK_STATUS and ext.COMPLETION_STATUS_KHR take so long time about 15ms. I can accept this number for gl.LINK_STATUS because it waits for compile+link completion. But 15ms for ext.COMPLETION_STATUS_KHR looks weird to me. It shouldn't wait for the compile+link completion but should do just polling and quickly returning true/false instead. So I guess the number should be 1ms or less. Let me know if I'm missing something. Or could it be a Canary bug? My platform. OS: Windows10 Browser: Chrome Canary. Browser boot option: --use-cmd-decoder=passthrough --enable-webgl-draft-extensions Thanks Takahiro On Fri, Apr 26, 2019 at 10:15 AM Chen, Jie A (jie.a.chen...@) wrote: Basically, for ANGLE?s GL backend, it?s simply a wrapper for the existing GL implementations. In this sense glCompileShader() is still implementation specific. Essentially ANGLE just calls glCompileShader and check GL_COMPILE_STATUS. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Jasper St. Pierre (jstpierre...@) Sent: Friday, April 26, 2019 1:18 AM To: Public WebGL Subject: RE: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Thank you, that?s important information to know. Changing my shader compilation pipeline to wait for shader completion status is a lot more difficult, but based on some initial tests, it?s more expensive than not doing it ? the latency of getShaderParameter is too high. That said, in a lot of GL implementations, glCompileShader() is practically a no-op, and will only do an AST parse when glGetShaderParameter/InfoLog() is called (which is basically only for debugging / error checking). glLinkProgram() does full compilation of all programs, as full-PSO optimization is important. I don?t know how common this is, but multiple GL implementations I have seen do it. It might make sense for ANGLE to adopt this model as well. From: owners-public_webgl...@ On Behalf Of Chen, Jie A (jie.a.chen...@) Sent: Wednesday, April 24, 2019 6:48 PM To: Public WebGL Subject: RE: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Absolutely. Ideally there would be no stall for linkProgram. I tried, but it?s too difficult to achieve this in ANGLE. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Jeff Gilbert (jgilbert...@) Sent: Thursday, April 25, 2019 9:33 AM To: Public WebGL Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Possibly, but in the long run, I expect implementations to support no-stall linkProgram invocations. On Wed, Apr 24, 2019 at 6:27 PM Chen, Jie A (jie.a.chen...@) wrote: linkProgram may stall on compileShader. To avoid the stall, you?d better make sure the COMPLETION_STATUS_KHR statuses of the attached shaders are all True before calling linkProgram. In this sense, the first workflow has less chance running into stall. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Fernando Serrano Garc?a (fserrano...@) Sent: Wednesday, April 24, 2019 9:38 PM To: Public WebGL Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Regarding the optimal proposed workflow (grouping shaders and programs separately) of: for (const x of shaders) gl.compileShader(x); for (const x of programs) gl.linkProgram(x); versus something more on the way that we currently have in many engines as threejs: for (const x of material) gl.compileShader(fs); gl.compileShader(vs); gl.linkProgram(x); Do you think is more or less accurate the following graph for 4 materials and enabling this extension with 2 and 4 parallel threads? On Wed, Apr 24, 2019 at 2:40 PM Fernando Serrano Garc?a wrote: fwiw three.js introduced a "debug" parameter (false by default) to determine if there will be a status check and call all the get* (currently in dev): - https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLShader.js#L21-L26 - https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLProgram.js#L608 so currently calling `new WebGLShader()` won't be blocking with any `get*` function and it could be used as is to compile all of them in a loop with or without the extension. the problem comes from the WebGLProgram as it should just queue itself before trying to link any program and wait until all the shader compile calls finish, then do all the link, and wait for it asynchronously before start using these programs. I have opened an issue on the three.js repo to keep track of the implementation and we have booked some time this week to take a look at it, feedback is welcome :) https://github.com/mrdoob/three.js/issues/16321 On Tue, Apr 16, 2019 at 11:55 PM Ken Russell (kbr...@) wrote: On Tue, Apr 16, 2019 at 2:24 PM Tarek Sherif (tsherif...@) wrote: Yes, I've read both specs. I think this language in the WebGL version is confusing: "When this extension is enabled: Shader compilation and program linking may be performed in a separate CPU thread." And neither indicates which functions are expected to cause stalls. As written, this extension requires more than most that people know implementation details. All previous operations against the program - looking up uniform locations, drawing with it, etc. - will cause stalls. The application *must* be updated to query the program's COMPLETION_STATUS_KHR status, and skip *all* operations against the program until it's no longer pending. I guess we'll just change the WebGL version of this extension spec to be much more explicit about this. Essentially, all previous code which checked for the completion of compilation of shaders / linking of programs can be updated with a small wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. This is not true because the most common way this is done will cause stalls that sabotage the parallelism, e.g.: https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLShader.js#L21-L36 https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLProgram.js#L586-L631 The check for COMPLETION_STATUS_KHR has to wrap *all* queries and uses of the program object, and they must be skipped until COMPLETION_STATUS_KHR returns true. Yes, all applications will have to be updated to take advantage of this extension, but if they do, the benefits will be significant. -Ken Tarek Sherif Senior Software Engineer, Visualization | Uber http://vis.gl/ On Tue, Apr 16, 2019 at 4:18 PM Ken Russell (kbr...@) wrote: Please review the Overview in the underlying OpenGL ES spec: https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt It describes that the extension uses one or more separate CPU threads for shader compilation. If you still think we should rewrite the introduction to the WebGL extension, we can do that too. Essentially, all previous code which checked for the completion of compilation of shaders / linking of programs can be updated with a small wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. -Ken On Tue, Apr 16, 2019 at 1:36 AM Tarek Sherif (tsherif...@) wrote: This is all extremely interesting, and documentation of these best practices should probably be more publicly available (perhaps through a non-normative note in the spec). I'm thinking the language in the extension spec could be made more clear about what it's actual purpose is. It currently gives the impression that enabling it is what allows for parallel compilation and that this should save time, but given what Jeff and Kai have said, it sounds like the purpose is to avoid CPU stalls, and that it might even take longer in wall time since you're only checking once a frame. Maybe some background information could be added along the lines of "Normally applications must wait on get*Parameter or a draw call for program linking to complete, this extension provides a mechanism for querying completion status without stalling..." Tarek Sherif Senior Software Engineer, Visualization | Uber http://vis.gl/ On Mon, Apr 15, 2019 at 11:23 PM Kai Ninomiya (kainino...@) wrote: On Mon, Apr 15, 2019 at 7:18 PM Tarek Sherif (tareksherif...@) wrote: I don't see anything in the OpenGL extension spec about what functions cause stalls. Is that implementation-specific? Having an idea what to expect is important for two reasons: 1. To make it clear that drawing will still work if getProgramParameter(COMPLETION_STATUS_KHR) hasn't returned true yet (i.e. the stall on a draw call) Generally, OpenGL extensions are not allowed to break existing API/existing content. (In OpenGL, all extensions are always enabled; there's no requestExtension.) Hence, even if you enable the extension, it won't change the way your application works, and therefore the draw call must still cause a stall in order to be able to use the program. 2. Almost all WebGL code I've looked at handles compilation in a way similar to the following: gl.compileShader(vertexShader); if (!gl.getShaderParameter(vertexShader, gl.COMPILE_STATUS)) //... gl.compileShader(fragmentShader); if (!gl.getShaderParameter(fragmentShader, gl.COMPILE_STATUS)) //... //... gl.linkProgram(program); if (!gl.getProgramParameter(program, gl.LINK_STATUS)) //... I think it would be worth it to make clear that this pattern would sabotage the parallel compile. I seem to remember (not sure if this is still true) that this pattern also sabotages the shader compiler cache in ANGLE, because ANGLE doesn't cache the COMPILE_STATUS (or was it the compile info string?). So it forces the compiler to recompile just to give you the status. Tarek Sherif http://tareksherif.net/ ??????? Original Message ??????? On Monday, April 15, 2019 9:00 PM, Ken Russell (kbr...@) wrote: The WebGL extension (which is basically just a wrapper) refers to the underlying OpenGL / OpenGL ES extension https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt, where this is documented. Is that sufficient? It would be better to avoid duplicating a large amount of spec text from the underlying extension. However, we can add some non-normative text if that would help. -Ken On Sat, Apr 13, 2019 at 3:51 AM Tarek Sherif (tareksherif...@) wrote: IIRC, all 3 of those functions still force a wait for the {shader to finish compiling, program to finish linking} just as they did before. The new semantics are only visible via the new COMPLETION_STATUS_KHR check. That should work perfectly for us. Can we add some language to the spec about which functions cause stalls? I feel like as written, it will be easy for people to use the extension incorrectly. Tarek Sherif http://tareksherif.net/ ??????? Original Message ??????? On Friday, April 12, 2019 4:10 PM, Kai Ninomiya (kainino...@) wrote: Oh yes, useProgram probably won't stall. But getUniformLocation and the others will stall, as will draw calls. getProgramParameter(COMPLETION_STATUS_KHR) should get faster at some point; see http://crbug.com/881152 which Ken linked. On Fri, Apr 12, 2019 at 12:39 PM Jasper St. Pierre (jstpierre...@) wrote: Thank you! Trying this out in my own WebGL 2 app, I see quite a reduction in shader compilation time, shaving 400ms on load time on a moderately complex scene. The getProgramParameter(COMPLETION_STATUS_KHR) query still takes 1ms (which I believe is being tracked), but that is still better from the 4ms I see in getUniformBlockIndex (my previous sync point). AFAIK, useProgram should not cause a stall, but in order to set my texture samplers to bind to different units, I need to do a getUniformLocation on my sampler uniform, which causes a compilation stall. Same thing with getUniformBlockIndex. Do make sure that anything that might query into reflection about the program (e.g. getVertexAttributeIndex, getUniformLocation, getUniformBlockIndex) happens after COMPLETION_STATUS_KHR returns true, since that?s another way to accidentally stall on compilation completing. From: owners-public_webgl...@ On Behalf Of Kai Ninomiya (kainino...@) Sent: Friday, April 12, 2019 10:25 AM To: Public WebGL Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved IIRC, all 3 of those functions still force a wait for the {shader to finish compiling, program to finish linking} just as they did before. The new semantics are only visible via the new COMPLETION_STATUS_KHR check. On Fri, Apr 12, 2019 at 10:05 AM Tarek Sherif (tsherif...@) wrote: Very excited about this extension, but I'm concerned about how it would work in our use case. Our flagship visualization library, deck.gl, often shares the gl context with a separate base map rendering application so that it can properly interleave visualization layers with the base map. Enabling this extension seems to change the behaviour of existing WebGL functions in a way that I don't believe other extensions do. My worry is how our enabling KHR_parallel_shader_compile would affect applications we share contexts with, i.e what happens if the typical synchronous compilation logic is used after KHR_parallel_shader_compile is enabled? Specifically: * What happens if getShaderParameter(shader, COMPILE_STATUS) is called before compilation is complete? * What happens if getProgramParameter(program, LINK_STATUS) is called before linking is complete? * What happens if useProgram is called before linking is complete? Thanks, Tarek Sherif Senior Software Engineer, Visualization | Uber http://vis.gl/ Tarek Sherif Senior Software Engineer, Visualization | Uber http://vis.gl/ On Fri, Apr 12, 2019 at 12:16 PM David Catuhe (David.Catuhe...@) wrote: Wonderful! From: owners-public_webgl...@ On Behalf Of Ken Russell (kbr...@) Sent: Wednesday, April 10, 2019 2:56 PM To: Public WebGL Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved If your code works correctly now when enabling draft WebGL extensions in Chrome, then no changes are needed. There won't be any changes to the extension when it's taken out of draft status; it'll just be available by default. -Ken On Wed, Apr 10, 2019 at 12:36 PM David Catuhe (David.Catuhe...@) wrote: We do have support for the extension in Babylon.js. How can we test this change? ________________________________ From: owners-public_webgl...@ on behalf of Ken Russell (kbr...@) Sent: Wednesday, April 10, 2019 12:00:25 PM To: public Subject: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved WebGL community, Jie Chen from Intel has principally developed and implemented a WebGL wrapper for the KHR_parallel_shader_compile extension. This allows shader compilation and program linking to occur fully in parallel to the rest of the WebGL application. Some small application changes are needed to take full advantage of the extension, but it is otherwise fully backward compatible. Jie has even emulated this extension on platforms which don't support it natively. This extension solves a longstanding user complaint with WebGL, namely long shader compile times on Windows. Compiles and links occur not only asynchronously, but also in parallel, so there is a net speedup when using this extension. Users who have tried out the draft extension are pleased with the results and would like to see it made widely available. I propose promoting this extension to community approved in https://github.com/KhronosGroup/WebGL/pull/2855 . Any comments? -Ken Virus-free. www.avg.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From pub...@ Wed May 15 08:25:29 2019 From: pub...@ (Takahiro Aoyagi (...@...)) Date: Thu, 16 May 2019 00:25:29 +0900 Subject: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved In-Reply-To: <5F447A42ADFAFD499D69CF330DF2E5C1606630CF@SHSMSX101.ccr.corp.intel.com> References: <5F447A42ADFAFD499D69CF330DF2E5C160660987@SHSMSX101.ccr.corp.intel.com> <5F447A42ADFAFD499D69CF330DF2E5C160661691@SHSMSX101.ccr.corp.intel.com> <5F447A42ADFAFD499D69CF330DF2E5C160661793@SHSMSX101.ccr.corp.intel.com> <5F447A42ADFAFD499D69CF330DF2E5C1606630CF@SHSMSX101.ccr.corp.intel.com> Message-ID: Still WIP but I confirmed Three.js + KHR_parallel_shader_compile extension with some optimizations improves the frame rate dropping on application start up. https://twitter.com/superhoge/status/1128438246638333953 Regarding recompilation message, I think such type of hints are very helpful to us optimize the JS graphics engine. Actually I had a hard time with optimizing Three.js because WebGL inside is kinda black box to me. On Tue, May 14, 2019 at 4:47 PM Chen, Jie A (jie.a.chen...@) < public_webgl...@> wrote: > Kai, I?d like to do that. As far as I know, dynamic recompilation is not > seldom seen in ANGLE d3d backend. I not am sure if that would be over > warned. Probably we should file a bug to the ANGLE team firstly. > > > > *From:* owners-public_webgl...@ [mailto: > owners-public_webgl...@] *On Behalf Of *Kai Ninomiya ( > kainino...@) > *Sent:* Tuesday, May 14, 2019 1:51 AM > *To:* Public WebGL > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Jasper, thanks for looking into that! > > > > I think Chrome should print a performance warning if we compile a shader > that ends up getting recompiled before ever being used. > > > > Jie, would you be interested in looking into adding this warning? > > > > *From: *Jasper St. Pierre (jstpierre...@) > > *Date: *Sun, May 12, 2019 at 8:03 PM > *To: *Public WebGL > > I should probably note that the cause for the long stalls on gl.useProgram > was found. It turns out that ANGLE, at least on D3D11, will recompile the > shader program for every set of vertex attributes that it is used with. The > initial compileShader / linkProgram calls was done without having any VAO > or vertex attributes bound. Setting up a dummy VAO before compiling the > shaders and linking the programs fixed this. It's unfortunate that WebGL > does not expose ARB_vertex_attrib_binding, so setting up the dummy VAO was > a bit clunky, but it wasn't too bad. Make sure you compile your shaders > with the correct vertex attribute set up or you risk a dynamic shader > recompilation. > ------------------------------ > > *From:* owners-public_webgl...@ > on behalf of Kai Ninomiya (kainino...@) > *Sent:* Sunday, May 12, 2019 10:03:54 AM > *To:* public webgl > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > I think we will probably need to optimize checking LINK_STATUS (which > would make useProgram faster too), so that when the COMPLETION_STATUS query > result is sent to the client and cached, it sends the LINK_STATUS as well, > and updates the already existing link status cache. > > > > *From: *Takahiro Aoyagi (taoyagi...@) > *Date: *Sun, May 12, 2019, 2:14 AM > *To: *Public WebGL > > Thanks for the comments, Chen and Kai. > > > > Yeah, 8ms is very long to me. And if I compile+link two or more programs > the time can be longer. > > > > > I guess I?ve found the cause for gl.useProgram. WebGL implementation > inserts an extra GL command to query LinkStatus before using it. > > > > Will this be optimized (not adding the extra GL command) at some point? Or > must it be necessary? > > > > > But do note that we cache that info, so it only takes extra time on the > first useProgram. > > > > I confirmed that on my test. > > > > > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime10.html > > > > So far I'll try not to switch to a program which hasn't been called with > gl.useProgram() yet while at least one program is being compiled+linked. > > > > > > On Sun, May 12, 2019 at 2:54 PM Kai Ninomiya (kainino...@) < > public_webgl...@> wrote: > > 8ms is an extraordinary long time, in frame rendering time. > > > > But do note that we cache that info, so it only takes extra time on the > first useProgram. > > > > *From: *Chen, Jie A (jie.a.chen...@) > *Date: *Sat, May 11, 2019, 8:07 PM > *To: *Public WebGL > > I guess I?ve found the cause for gl.useProgram. WebGL implementation > inserts an extra GL command to query LinkStatus before using it. > > > https://cs.chromium.org/chromium/src/third_party/blink/renderer/modules/webgl/webgl_rendering_context_base.cc?sq=package:chromium&g=0&l=6350 > > > > Anyway I think you don?t need to worry too much about this. Usually it > doesn?t take very long to drain the command buffer. I tried your test case, > which took about only 8ms on my laptop. > > > > > > *From:* owners-public_webgl...@ [mailto: > owners-public_webgl...@] *On Behalf Of *Chen, Jie A ( > jie.a.chen...@) > *Sent:* Sunday, May 12, 2019 9:44 AM > *To:* Public WebGL > *Subject:* RE: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Mostly they are gl.get* like commands. You can search ?WaitForCmd? in > https://cs.chromium.org/chromium/src/gpu/command_buffer/client/gles2_implementation_impl_autogen.h and > > https://cs.chromium.org/chromium/src/gpu/command_buffer/client/gles2_implementation.cc > for them. > > But I don?t think gl.useProgram needs to wait. Most likely it has a > different cause. I will look into it later. > > > > > > *From:* owners-public_webgl...@ [mailto: > owners-public_webgl...@] *On Behalf Of *Takahiro Aoyagi ( > taoyagi...@) > *Sent:* Sunday, May 12, 2019 2:27 AM > *To:* Public WebGL > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Hi Chen, > > > > Thanks for your explanation. > > > > What type of WebGL draw calls need to wait for all queued GL commands? In > my tests, not only gl.get*() > > > > > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime9.html > > > > but also gl.useProgram() seems to wait. > > > > > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime8.html > > > > > That means, I shouldn't call any gl.get*() and also I shouldn't switch > program until all programs compilation+linking are done? > > > > I haven't tried yet but could draw calls wait, too? If so, I shouldn't > render anything until then? > > > > > > Virus-free. *www.avg.com* > > > > > > On Sat, May 11, 2019 at 12:43 PM Chen, Jie A (*jie.a.chen...@*) < > *public_webgl...@*> wrote: > > > Interesting question, Takahiro. > > > My speculation is that the problem might be relevant to chrome?s > multi-process architecture. As you may know, the WebGL calls run in the > main thread of render process. Chrome needs to send these WebGL commands to > the GPU process for actual execution. So in your case, what Chrome actually > does for calls of makeProgram2 is simply putting the GL commands into a IPC > buffer. But later when you retrieve a program parameter back, it then > waits for the execution of all previously issued GL commands including > makeProgram2. > > > > > > *From:* *owners-public_webgl...@* [mailto: > *owners-public_webgl...@*] *On Behalf Of *Takahiro Aoyagi ( > *taoyagi...@*) > *Sent:* Saturday, May 11, 2019 6:58 AM > *To:* Public WebGL <*public_webgl...@*> > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > > > I'm very glad this extension moves forward. > > > > > > Question. Can compiling+linking a program block another program's > gl.get*() or gl.useProgram()? > > > > > > Even after confirming compile+link completion of a program with > COMPLETION_STATUS_KHR, gl.getProgramParameter() or gl.useProgram() seems > being blocked if another program is being compiled+linked on my Windows > Canary. Is this intentional or bug? > > > > > > > *https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime8.html* > > > > *https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime9.html* > > > > > > // Confirm program compile+link completion > > > if(gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR)) { > > > // Compile and link another program > > > const vertexShader2 = gl.createShader(gl.VERTEX_SHADER); > const fragmentShader2 = gl.createShader(gl.FRAGMENT_SHADER); > const program2 = gl.createProgram(); > > gl.shaderSource(vertexShader2, vertexShaderCode); > gl.shaderSource(fragmentShader2, fragmentShaderCode); > gl.compileShader(vertexShader2); > gl.compileShader(fragmentShader2); > gl.attachShader(program2, vertexShader2); > gl.attachShader(program2, fragmentShader2); > gl.linkProgram(program2); > > > > > > // gl.get*() or gl.useProgram() while the other program is being > compiled+linkied > > > const startTime = performance.now(); > gl.getProgramParameter(program, gl.ACTIVE_ATTRIBUTES); // or > gl.useProgram(program); > const endTime = performance.now(); > > > } > > > > > > Takahiro > > > > > > > > > Virus-free. *www.avg.com* > > > > > > On Sat, May 11, 2019 at 6:11 AM Ken Russell (*kbr...@*) < > *public_webgl...@*> wrote: > > > Since there haven't been any *objections* to moving this extension > forward, and since the benefits are now being seen, it's been moved to > community approved in *https://github.com/KhronosGroup/WebGL/pull/2855* . > > > > > > Please, feel free to continue to report problems with long shader > compilation times - either posting here on this mailing list or on > webgl-dev-list, reporting cross-browser issues on > *https://github.com/KhronosGroup/WebGL/issues* , or on individual > browsers' bug trackers. > > > > > > -Ken > > > > > > > > > > > > *From: *Ken Russell <*kbr...@*> > *Date: *Fri, May 10, 2019 at 1:39 PM > *To: *Public WebGL > > > Super. Thank you Takahiro for testing and confirming! > > > > > > > > > *From: *Takahiro Aoyagi (*taoyagi...@*) < > *public_webgl...@*> > *Date: *Fri, May 10, 2019 at 10:51 AM > *To: *Public WebGL > > > I made simple tests to check the CPU elapsed time of > gl.getProgramParameter() and gl.useProgram() after checking > COMPLETION_STATUS_KHR is true. Both are fast here on my Windows10 Chrome > Canary. > > > > > > > *https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime6.html* > *https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime7.html* > > > > > > Takahiro > > > > > > > > > Virus-free. *www.avg.com* > > > > > > On Sat, May 11, 2019 at 2:46 AM Ken Russell (*kbr...@*) < > *public_webgl...@*> wrote: > > > Hmm. The only reason I can think of that that would happen is if you're > running on Windows, and ANGLE has to dynamically recompile the program > behind the scenes in order to handle some OpenGL ES state change. I'm not > 100% sure which changes require this dynamic recompilation; the ANGLE > developers would know best. > *https://groups.google.com//forum/#!forum/angleproject* might be helpful. > > > > > > We'd really need some test case to make progress on this. Can you provide > one? > > > > > > -Ken > > > > > > > > > On Fri, May 10, 2019 at 10:28 AM Jasper St. Pierre (*jstpierre...@*) > <*public_webgl...@*> wrote: > > > Hello again. My app is now showing that getProgramParameter is completing > quick, but it is spending a lot of time in useProgram. I am checking for > COMPLETION_STATUS_KHR on the GL program beforehand and it is returning > true. I?m guessing there?s some additional expensive work that still needs > to happen at useProgram time. Is this a bug? Any ways to debug or avoid > this? I?m unsure if there will be an easy repro. > > > > > > Again, profiler screenshot attached. > > > > > > *From:* *owners-public_webgl...@* < > *owners-public_webgl...@*> *On Behalf Of *Takahiro Aoyagi ( > *taoyagi...@*) > *Sent:* Friday, May 10, 2019 12:22 AM > *To:* Public WebGL <*public_webgl...@*> > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > > > Confirmed COMPLETION_STATUS_KHR is very fast like 0.01ms on my test > > > > *https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html* > > > > > > Nice work! > > > > > > Thanks > > > > > > > > > Virus-free. *www.avg.com* > > > > > > On Wed, May 8, 2019 at 2:41 PM Ken Russell (*kbr...@*) < > *public_webgl...@*> wrote: > > > Jie Chen from Intel just landed a fix in Chrome dramatically improving the > performance of querying COMPLETION_STATUS_KHR under > *http://crbug.com/881152* . The fix will be in tomorrow's Canary on > Windows and macOS. > > > > > > This should address the last major gap with this extension. We would like > to enable it by default by promoting it to community approved; any further > comments? > > > > > > -Ken > > > > > > > > > > > > *From: *Ken Russell <*kbr...@*> > *Date: *Fri, Apr 26, 2019 at 3:40 PM > *To: *Public WebGL > > > Thanks for the report and the clear test case. There was an existing bug > about this, so the new one was duplicated into it, and some hints about > implementing it were added to the preexisting bug. > > > > > > > > > On Fri, Apr 26, 2019 at 5:56 AM Takahiro Aoyagi (*taoyagi...@*) < > *public_webgl...@*> wrote: > > > Hi Chen, > > > > > > Opened a bug. Thanks. > > > > > > *https://bugs.chromium.org/p/chromium/issues/detail?id=957001* > > > > > > Takahiro > > > > > > > > > On Fri, Apr 26, 2019 at 8:03 PM Chen, Jie A (*jie.a.chen...@*) < > *public_webgl...@*> wrote: > > > Hi Takahiro, > > > The current implementation of COMPLETION_STATUS_KHR query in chromium > incurs an expensive round-trip to the GPU thread. This may contribute to > the wait time in your case. I am trying to optimize this. Could you please > file a bug to chromium? I would look into it once I?ve done the > optimization. > > > > > > *From:* *owners-public_webgl...@* [mailto: > *owners-public_webgl...@*] *On Behalf Of *Takahiro Aoyagi ( > *taoyagi...@*) > *Sent:* Friday, April 26, 2019 6:20 PM > *To:* Public WebGL <*public_webgl...@*> > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > > > Hi all, > > > > > > I'm working on Three.js + KHR_parallel_shader_compile extension support > with Fernando. > > > > > > *https://github.com/mrdoob/three.js/issues/16321#issuecomment-486436086* > > > > > > I'm testing with Canary. But the behavior seems weird to me. > gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) seems to wait > for compile+link completion. I don't think it should wait for that, it > should just do polling and returning true/false quickly instead. > > > > > > I made a simple test to reproduce. > > > > > > > *https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html* > > > > > > Code snippet. > > > > > > const ext = gl.getExtension('KHR_parallel_shader_compile'); > > > > > > gl.compileShader(vertexShader); > gl.compileShader(fragmentShader); > gl.attachShader(program, vertexShader); > gl.attachShader(program, fragmentShader); > gl.linkProgram(program); > > const startTime = performance.now(); > const status = useExtension > ? gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) > : gl.getProgramParameter(program, gl.LINK_STATUS); > const endTime = performance.now(); > > > const elapsedTime = endTime - startTime; > > > > > > On my platform, both gl.LINK_STATUS and ext.COMPLETION_STATUS_KHR take so > long time about 15ms. I can accept this number for gl.LINK_STATUS because > it waits for compile+link completion. But 15ms for > ext.COMPLETION_STATUS_KHR looks weird to me. It shouldn't wait for the > compile+link completion but should do just polling and quickly returning > true/false instead. So I guess the number should be 1ms or less. > > > > > > Let me know if I'm missing something. Or could it be a Canary bug? > > > > > > My platform. > > > > > > OS: Windows10 > > > Browser: Chrome Canary. > > > Browser boot option: --use-cmd-decoder=passthrough > --enable-webgl-draft-extensions > > > > > > > > > Thanks > > > > > > Takahiro > > > > > > > > > On Fri, Apr 26, 2019 at 10:15 AM Chen, Jie A (*jie.a.chen...@*) < > *public_webgl...@*> wrote: > > > Basically, for ANGLE?s GL backend, it?s simply a wrapper for the existing > GL implementations. In this sense glCompileShader() is still implementation > specific. Essentially ANGLE just calls glCompileShader and check > GL_COMPILE_STATUS. > > > > > > *From:* *owners-public_webgl...@* [mailto: > *owners-public_webgl...@*] *On Behalf Of *Jasper St. Pierre ( > *jstpierre...@*) > *Sent:* Friday, April 26, 2019 1:18 AM > *To:* Public WebGL <*public_webgl...@*> > *Subject:* RE: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > > > Thank you, that?s important information to know. Changing my shader > compilation pipeline to wait for shader completion status is a lot more > difficult, but based on some initial tests, it?s more expensive than not > doing it ? the latency of getShaderParameter is too high. > > > > > > That said, in a lot of GL implementations, glCompileShader() is > practically a no-op, and will only do an AST parse when > glGetShaderParameter/InfoLog() is called (which is basically only for > debugging / error checking). glLinkProgram() does full compilation of all > programs, as full-PSO optimization is important. I don?t know how common > this is, but multiple GL implementations I have seen do it. It might make > sense for ANGLE to adopt this model as well. > > > > > > *From:* *owners-public_webgl...@* < > *owners-public_webgl...@*> *On Behalf Of *Chen, Jie A ( > *jie.a.chen...@*) > *Sent:* Wednesday, April 24, 2019 6:48 PM > *To:* Public WebGL <*public_webgl...@*> > *Subject:* RE: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > > > Absolutely. Ideally there would be no stall for linkProgram. I tried, but > it?s too difficult to achieve this in ANGLE. > > > > > > *From:* *owners-public_webgl...@* [ > *mailto:owners-public_webgl...@*] *On Behalf Of *Jeff Gilbert ( > *jgilbert...@*) > *Sent:* Thursday, April 25, 2019 9:33 AM > *To:* Public WebGL <*public_webgl...@*> > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > > > Possibly, but in the long run, I expect implementations to support > no-stall linkProgram invocations. > > > > > > On Wed, Apr 24, 2019 at 6:27 PM Chen, Jie A (*jie.a.chen...@*) < > *public_webgl...@*> wrote: > > > linkProgram may stall on compileShader. To avoid the stall, you?d better > make sure the COMPLETION_STATUS_KHR statuses of the attached shaders are > all True before calling linkProgram. In this sense, the first workflow has > less chance running into stall. > > > > > > *From:* *owners-public_webgl...@* [mailto: > *owners-public_webgl...@*] *On Behalf Of *Fernando Serrano Garc?a > (*fserrano...@*) > *Sent:* Wednesday, April 24, 2019 9:38 PM > *To:* Public WebGL <*public_webgl...@*> > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > > > Regarding the optimal proposed workflow (grouping shaders and programs > separately) of: > > > for (const x of shaders) > gl.compileShader(x); > for (const x of programs) > gl.linkProgram(x); > > > > > > versus something more on the way that we currently have in many engines as > threejs: > > > for (const x of material) > > > gl.compileShader(fs); > > > gl.compileShader(vs); > gl.linkProgram(x); > > > > > > Do you think is more or less accurate the following graph for 4 materials > and enabling this extension with 2 and 4 parallel threads? > > > > > > > > > On Wed, Apr 24, 2019 at 2:40 PM Fernando Serrano Garc?a < > *fserrano...@*> wrote: > > > fwiw three.js introduced a "debug" parameter (false by default) to > determine if there will be a status check and call all the get* (currently > in dev): > > > - > *https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLShader.js#L21-L26* > > > - > *https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLProgram.js#L608* > > > > > > so currently calling `new WebGLShader()` won't be blocking with any `get*` > function and it could be used as is to compile all of them in a loop with > or without the extension. > > > the problem comes from the WebGLProgram as it should just queue itself > before trying to link any program and wait until all the shader compile > calls finish, then do all the link, and wait for it asynchronously before > start using these programs. > > > I have opened an issue on the three.js repo to keep track of the > implementation and we have booked some time this week to take a look at it, > feedback is welcome :) *https://github.com/mrdoob/three.js/issues/16321* > > > > > > On Tue, Apr 16, 2019 at 11:55 PM Ken Russell (*kbr...@*) < > *public_webgl...@*> wrote: > > > On Tue, Apr 16, 2019 at 2:24 PM Tarek Sherif (*tsherif...@*) < > *public_webgl...@*> wrote: > > > Yes, I've read both specs. I think this language in the WebGL version is > confusing: "When this extension is enabled: Shader compilation and program > linking may be performed in a separate CPU thread." And neither indicates > which functions are expected to cause stalls. As written, this extension > requires more than most that people know implementation details. > > > > > > All previous operations against the program - looking up uniform > locations, drawing with it, etc. - will cause stalls. The application > *must* be updated to query the program's COMPLETION_STATUS_KHR status, and > skip *all* operations against the program until it's no longer pending. > > > > > > I guess we'll just change the WebGL version of this extension spec to be > much more explicit about this. > > > > > > > > > Essentially, all previous code which checked for the completion of > compilation of shaders / linking of programs can be updated with a small > wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. > > > > > > This is not true because the most common way this is done will cause > stalls that sabotage the parallelism, e.g.: > > *https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLShader.js#L21-L36* > > > > *https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLProgram.js#L586-L631* > > > > > > The check for COMPLETION_STATUS_KHR has to wrap *all* queries and uses of > the program object, and they must be skipped until COMPLETION_STATUS_KHR > returns true. Yes, all applications will have to be updated to take > advantage of this extension, but if they do, the benefits will be > significant. > > > > > > -Ken > > > > > > > > > *Tarek Sherif* > > > Senior Software Engineer, Visualization | Uber > > > *http://vis.gl/* > > > > > > > > > > > > On Tue, Apr 16, 2019 at 4:18 PM Ken Russell (*kbr...@*) < > *public_webgl...@*> wrote: > > > Please review the Overview in the underlying OpenGL ES spec: > > > > *https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt* > > > > > > It describes that the extension uses one or more separate CPU threads for > shader compilation. If you still think we should rewrite the introduction > to the WebGL extension, we can do that too. > > > > > > Essentially, all previous code which checked for the completion of > compilation of shaders / linking of programs can be updated with a small > wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. > > > > > > -Ken > > > > > > > > > > > > On Tue, Apr 16, 2019 at 1:36 AM Tarek Sherif (*tsherif...@*) < > *public_webgl...@*> wrote: > > > This is all extremely interesting, and documentation of these best > practices should probably be more publicly available (perhaps through a > non-normative note in the spec). I'm thinking the language in the extension > spec could be made more clear about what it's actual purpose is. It > currently gives the impression that enabling it is what allows for parallel > compilation and that this should save time, but given what Jeff and Kai > have said, it sounds like the purpose is to avoid CPU stalls, and that it > might even take longer in wall time since you're only checking once a > frame. Maybe some background information could be added along the lines of > "Normally applications must wait on get*Parameter or a draw call for > program linking to complete, this extension provides a mechanism for > querying completion status without stalling..." > > > > > > > *Tarek Sherif* > > > Senior Software Engineer, Visualization | Uber > > > *http://vis.gl/* > > > > > > > > > > > > On Mon, Apr 15, 2019 at 11:23 PM Kai Ninomiya (*kainino...@*) < > *public_webgl...@*> wrote: > > > > > > > > > On Mon, Apr 15, 2019 at 7:18 PM Tarek Sherif (*tareksherif...@*) < > *public_webgl...@*> wrote: > > > I don't see anything in the OpenGL extension spec about what functions > cause stalls. Is that implementation-specific? Having an idea what to > expect is important for two reasons: > > > 1. To make it clear that drawing will still work if > getProgramParameter(COMPLETION_STATUS_KHR) hasn't returned true yet (i.e. > the stall on a draw call) > > > > > > Generally, OpenGL extensions are not allowed to break existing > API/existing content. (In OpenGL, all extensions are always enabled; > there's no requestExtension.) Hence, even if you enable the extension, it > won't change the way your application works, and therefore the draw call > must still cause a stall in order to be able to use the program. > > > > > > 2. Almost all WebGL code I've looked at handles compilation in a way > similar to the following: > > > gl.compileShader(vertexShader); > if (!gl.getShaderParameter(vertexShader, gl.COMPILE_STATUS)) //... > > > gl.compileShader(fragmentShader); > > > if (!gl.getShaderParameter(fragmentShader, gl.COMPILE_STATUS)) //... > > > //... > > > gl.linkProgram(program); > if (!gl.getProgramParameter(program, gl.LINK_STATUS)) //... > > > I think it would be worth it to make clear that this pattern would > sabotage the parallel compile. > > > > > > I seem to remember (not sure if this is still true) that this pattern also > sabotages the shader compiler cache in ANGLE, because ANGLE doesn't cache > the COMPILE_STATUS (or was it the compile info string?). So it forces the > compiler to recompile just to give you the status. > > > > > > Tarek Sherif > > > *http://tareksherif.net/* > > > > > > > > > > > > ??????? Original Message ??????? > > > On Monday, April 15, 2019 9:00 PM, Ken Russell (*kbr...@*) < > *public_webgl...@*> wrote: > > > > > > The WebGL extension (which is basically just a wrapper) refers to the > underlying OpenGL / OpenGL ES extension > *https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt*, > where this is documented. Is that sufficient? It would be better to avoid > duplicating a large amount of spec text from the underlying extension. > However, we can add some non-normative text if that would help. > > > > > > -Ken > > > > > > > > > > > > On Sat, Apr 13, 2019 at 3:51 AM Tarek Sherif (*tareksherif...@*) < > *public_webgl...@*> wrote: > > > IIRC, all 3 of those functions still force a wait for the {shader to > finish compiling, program to finish linking} just as they did before. The > new semantics are only visible via the new COMPLETION_STATUS_KHR check. > > > That should work perfectly for us. Can we add some language to the spec > about which functions cause stalls? I feel like as written, it will be easy > for people to use the extension incorrectly. > > > > > > Tarek Sherif > > > *http://tareksherif.net/* > > > > > > > > > > > > ??????? Original Message ??????? > > > On Friday, April 12, 2019 4:10 PM, Kai Ninomiya (*kainino...@*) < > *public_webgl...@*> wrote: > > > > > > Oh yes, useProgram probably won't stall. But getUniformLocation and the > others will stall, as will draw calls. > > > > > > getProgramParameter(COMPLETION_STATUS_KHR) should get faster at some > point; see *http://crbug.com/881152* which Ken linked. > > > > > > On Fri, Apr 12, 2019 at 12:39 PM Jasper St. Pierre (*jstpierre...@*) > <*public_webgl...@*> wrote: > > > Thank you! Trying this out in my own WebGL 2 app, I see quite a reduction > in shader compilation time, shaving 400ms on load time on a moderately > complex scene. The getProgramParameter(COMPLETION_STATUS_KHR) query still > takes 1ms (which I believe is being tracked), but that is still better from > the 4ms I see in getUniformBlockIndex (my previous sync point). > > > > > > AFAIK, useProgram should not cause a stall, but in order to set my texture > samplers to bind to different units, I need to do a getUniformLocation on > my sampler uniform, which causes a compilation stall. Same thing with > getUniformBlockIndex. Do make sure that anything that might query into > reflection about the program (e.g. getVertexAttributeIndex, > getUniformLocation, getUniformBlockIndex) happens after > COMPLETION_STATUS_KHR returns true, since that?s another way to > accidentally stall on compilation completing. > > > > > > > > > *From:* *owners-public_webgl...@* < > *owners-public_webgl...@*> *On Behalf Of *Kai Ninomiya ( > *kainino...@*) > > > *Sent:* Friday, April 12, 2019 10:25 AM > > > *To:* Public WebGL <*public_webgl...@*> > > > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > > > > > > IIRC, all 3 of those functions still force a wait for the {shader to > finish compiling, program to finish linking} just as they did before. The > new semantics are only visible via the new COMPLETION_STATUS_KHR check. > > > > > > On Fri, Apr 12, 2019 at 10:05 AM Tarek Sherif (*tsherif...@*) < > *public_webgl...@*> wrote: > > > Very excited about this extension, but I'm concerned about how it would > work in our use case. Our flagship visualization library, *deck.gl*, > often shares the gl context with a separate base map rendering application > so that it can properly interleave visualization layers with the base map. > Enabling this extension seems to change the behaviour of existing WebGL > functions in a way that I don't believe other extensions do. My worry is > how our enabling KHR_parallel_shader_compile would affect applications we > share contexts with, i.e what happens if the typical synchronous > compilation logic is used after KHR_parallel_shader_compile is enabled? > Specifically: > > > - What happens if getShaderParameter(shader, COMPILE_STATUS) is called > before compilation is complete? > > - What happens if getProgramParameter(program, LINK_STATUS) is called > before linking is complete? > > - What happens if useProgram is called before linking is complete? > > > Thanks, > > > > > > > > > Tarek Sherif > > > Senior Software Engineer, Visualization | Uber > > > *http://vis.gl/* > > > > > > > > > > > > > > > *Tarek Sherif* > > > Senior Software Engineer, Visualization | Uber > > > *http://vis.gl/* > > > > > > > > > On Fri, Apr 12, 2019 at 12:16 PM David Catuhe ( > *David.Catuhe...@*) <*public_webgl...@*> wrote: > > > Wonderful! > > > > > > > > > *From:* *owners-public_webgl...@* < > *owners-public_webgl...@*> *On Behalf Of *Ken Russell ( > *kbr...@*) > > > *Sent:* Wednesday, April 10, 2019 2:56 PM > > > *To:* Public WebGL <*public_webgl...@*> > > > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > > > > > > If your code works correctly now when enabling draft WebGL extensions in > Chrome, then no changes are needed. There won't be any changes to the > extension when it's taken out of draft status; it'll just be available by > default. > > > > > > -Ken > > > > > > > > > On Wed, Apr 10, 2019 at 12:36 PM David Catuhe ( > *David.Catuhe...@*) <*public_webgl...@*> wrote: > > > We do have support for the extension in Babylon.js. How can we test this > change? > > > > > ------------------------------ > > > > > > > > > *From:* *owners-public_webgl...@* < > *owners-public_webgl...@*> on behalf of Ken Russell ( > *kbr...@*) <*public_webgl...@*> > *Sent:* Wednesday, April 10, 2019 12:00:25 PM > *To:* public > *Subject:* [Public WebGL] Propose promoting KHR_parallel_shader_compile > to community approved > > > > > > WebGL community, > > > > > > Jie Chen from Intel has principally developed and implemented a WebGL > wrapper for the KHR_parallel_shader_compile extension. This allows shader > compilation and program linking to occur fully in parallel to the rest of > the WebGL application. Some small application changes are needed to take > full advantage of the extension, but it is otherwise fully backward > compatible. Jie has even emulated this extension on platforms which don't > support it natively. > > > > > > This extension solves a longstanding user complaint with WebGL, namely > long shader compile times on Windows. Compiles and links occur not only > asynchronously, but also in parallel, so there is a net speedup when using > this extension. Users who have tried out the draft extension are pleased > with the results and would like to see it made widely available. > > > > > > I propose promoting this extension to community approved in > *https://github.com/KhronosGroup/WebGL/pull/2855* . Any comments? > > > > > > -Ken > > > > > > > > > > > > > > > > > > Virus-free. *www.avg.com* > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pub...@ Wed May 15 18:06:10 2019 From: pub...@ (Chen, Jie A (...@...)) Date: Thu, 16 May 2019 01:06:10 +0000 Subject: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved In-Reply-To: References: <5F447A42ADFAFD499D69CF330DF2E5C160660987@SHSMSX101.ccr.corp.intel.com> <5F447A42ADFAFD499D69CF330DF2E5C160661691@SHSMSX101.ccr.corp.intel.com> <5F447A42ADFAFD499D69CF330DF2E5C160661793@SHSMSX101.ccr.corp.intel.com> <5F447A42ADFAFD499D69CF330DF2E5C1606630CF@SHSMSX101.ccr.corp.intel.com> Message-ID: <5F447A42ADFAFD499D69CF330DF2E5C1606662A9@SHSMSX101.ccr.corp.intel.com> Great work! For the recompilation message, I filed an ANGLE bug for it. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Takahiro Aoyagi (taoyagi...@) Sent: Wednesday, May 15, 2019 11:25 PM To: Public WebGL Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Still WIP but I confirmed Three.js + KHR_parallel_shader_compile extension with some optimizations improves the frame rate dropping on application start up. https://twitter.com/superhoge/status/1128438246638333953 Regarding recompilation message, I think such type of hints are very helpful to us optimize the JS graphics engine. Actually I had a hard time with optimizing Three.js because WebGL inside is kinda black box to me. On Tue, May 14, 2019 at 4:47 PM Chen, Jie A (jie.a.chen...@) > wrote: Kai, I?d like to do that. As far as I know, dynamic recompilation is not seldom seen in ANGLE d3d backend. I not am sure if that would be over warned. Probably we should file a bug to the ANGLE team firstly. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Kai Ninomiya (kainino...@) Sent: Tuesday, May 14, 2019 1:51 AM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Jasper, thanks for looking into that! I think Chrome should print a performance warning if we compile a shader that ends up getting recompiled before ever being used. Jie, would you be interested in looking into adding this warning? From: Jasper St. Pierre (jstpierre...@) > Date: Sun, May 12, 2019 at 8:03 PM To: Public WebGL I should probably note that the cause for the long stalls on gl.useProgram was found. It turns out that ANGLE, at least on D3D11, will recompile the shader program for every set of vertex attributes that it is used with. The initial compileShader / linkProgram calls was done without having any VAO or vertex attributes bound. Setting up a dummy VAO before compiling the shaders and linking the programs fixed this. It's unfortunate that WebGL does not expose ARB_vertex_attrib_binding, so setting up the dummy VAO was a bit clunky, but it wasn't too bad. Make sure you compile your shaders with the correct vertex attribute set up or you risk a dynamic shader recompilation. ________________________________ From: owners-public_webgl...@ > on behalf of Kai Ninomiya (kainino...@) > Sent: Sunday, May 12, 2019 10:03:54 AM To: public webgl Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved I think we will probably need to optimize checking LINK_STATUS (which would make useProgram faster too), so that when the COMPLETION_STATUS query result is sent to the client and cached, it sends the LINK_STATUS as well, and updates the already existing link status cache. From: Takahiro Aoyagi (taoyagi...@) > Date: Sun, May 12, 2019, 2:14 AM To: Public WebGL Thanks for the comments, Chen and Kai. Yeah, 8ms is very long to me. And if I compile+link two or more programs the time can be longer. > I guess I?ve found the cause for gl.useProgram. WebGL implementation inserts an extra GL command to query LinkStatus before using it. Will this be optimized (not adding the extra GL command) at some point? Or must it be necessary? > But do note that we cache that info, so it only takes extra time on the first useProgram. I confirmed that on my test. https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime10.html So far I'll try not to switch to a program which hasn't been called with gl.useProgram() yet while at least one program is being compiled+linked. On Sun, May 12, 2019 at 2:54 PM Kai Ninomiya (kainino...@) > wrote: 8ms is an extraordinary long time, in frame rendering time. But do note that we cache that info, so it only takes extra time on the first useProgram. From: Chen, Jie A (jie.a.chen...@) > Date: Sat, May 11, 2019, 8:07 PM To: Public WebGL I guess I?ve found the cause for gl.useProgram. WebGL implementation inserts an extra GL command to query LinkStatus before using it. https://cs.chromium.org/chromium/src/third_party/blink/renderer/modules/webgl/webgl_rendering_context_base.cc?sq=package:chromium&g=0&l=6350 Anyway I think you don?t need to worry too much about this. Usually it doesn?t take very long to drain the command buffer. I tried your test case, which took about only 8ms on my laptop. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Chen, Jie A (jie.a.chen...@) Sent: Sunday, May 12, 2019 9:44 AM To: Public WebGL > Subject: RE: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Mostly they are gl.get* like commands. You can search ?WaitForCmd? in https://cs.chromium.org/chromium/src/gpu/command_buffer/client/gles2_implementation_impl_autogen.h and https://cs.chromium.org/chromium/src/gpu/command_buffer/client/gles2_implementation.cc for them. But I don?t think gl.useProgram needs to wait. Most likely it has a different cause. I will look into it later. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Takahiro Aoyagi (taoyagi...@) Sent: Sunday, May 12, 2019 2:27 AM To: Public WebGL > Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Hi Chen, Thanks for your explanation. What type of WebGL draw calls need to wait for all queued GL commands? In my tests, not only gl.get*() https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime9.html but also gl.useProgram() seems to wait. https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime8.html That means, I shouldn't call any gl.get*() and also I shouldn't switch program until all programs compilation+linking are done? I haven't tried yet but could draw calls wait, too? If so, I shouldn't render anything until then? Virus-free. www.avg.com On Sat, May 11, 2019 at 12:43 PM Chen, Jie A (jie.a.chen...@) wrote: Interesting question, Takahiro. My speculation is that the problem might be relevant to chrome?s multi-process architecture. As you may know, the WebGL calls run in the main thread of render process. Chrome needs to send these WebGL commands to the GPU process for actual execution. So in your case, what Chrome actually does for calls of makeProgram2 is simply putting the GL commands into a IPC buffer. But later when you retrieve a program parameter back, it then waits for the execution of all previously issued GL commands including makeProgram2. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Takahiro Aoyagi (taoyagi...@) Sent: Saturday, May 11, 2019 6:58 AM To: Public WebGL Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved I'm very glad this extension moves forward. Question. Can compiling+linking a program block another program's gl.get*() or gl.useProgram()? Even after confirming compile+link completion of a program with COMPLETION_STATUS_KHR, gl.getProgramParameter() or gl.useProgram() seems being blocked if another program is being compiled+linked on my Windows Canary. Is this intentional or bug? https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime8.html https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime9.html // Confirm program compile+link completion if(gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR)) { // Compile and link another program const vertexShader2 = gl.createShader(gl.VERTEX_SHADER); const fragmentShader2 = gl.createShader(gl.FRAGMENT_SHADER); const program2 = gl.createProgram(); gl.shaderSource(vertexShader2, vertexShaderCode); gl.shaderSource(fragmentShader2, fragmentShaderCode); gl.compileShader(vertexShader2); gl.compileShader(fragmentShader2); gl.attachShader(program2, vertexShader2); gl.attachShader(program2, fragmentShader2); gl.linkProgram(program2); // gl.get*() or gl.useProgram() while the other program is being compiled+linkied const startTime = performance.now(); gl.getProgramParameter(program, gl.ACTIVE_ATTRIBUTES); // or gl.useProgram(program); const endTime = performance.now(); } Takahiro Virus-free. www.avg.com On Sat, May 11, 2019 at 6:11 AM Ken Russell (kbr...@) wrote: Since there haven't been any *objections* to moving this extension forward, and since the benefits are now being seen, it's been moved to community approved in https://github.com/KhronosGroup/WebGL/pull/2855 . Please, feel free to continue to report problems with long shader compilation times - either posting here on this mailing list or on webgl-dev-list, reporting cross-browser issues on https://github.com/KhronosGroup/WebGL/issues , or on individual browsers' bug trackers. -Ken From: Ken Russell Date: Fri, May 10, 2019 at 1:39 PM To: Public WebGL Super. Thank you Takahiro for testing and confirming! From: Takahiro Aoyagi (taoyagi...@) Date: Fri, May 10, 2019 at 10:51 AM To: Public WebGL I made simple tests to check the CPU elapsed time of gl.getProgramParameter() and gl.useProgram() after checking COMPLETION_STATUS_KHR is true. Both are fast here on my Windows10 Chrome Canary. https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime6.html https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime7.html Takahiro Virus-free. www.avg.com On Sat, May 11, 2019 at 2:46 AM Ken Russell (kbr...@) wrote: Hmm. The only reason I can think of that that would happen is if you're running on Windows, and ANGLE has to dynamically recompile the program behind the scenes in order to handle some OpenGL ES state change. I'm not 100% sure which changes require this dynamic recompilation; the ANGLE developers would know best. https://groups.google.com//forum/#!forum/angleproject might be helpful. We'd really need some test case to make progress on this. Can you provide one? -Ken On Fri, May 10, 2019 at 10:28 AM Jasper St. Pierre (jstpierre...@) wrote: Hello again. My app is now showing that getProgramParameter is completing quick, but it is spending a lot of time in useProgram. I am checking for COMPLETION_STATUS_KHR on the GL program beforehand and it is returning true. I?m guessing there?s some additional expensive work that still needs to happen at useProgram time. Is this a bug? Any ways to debug or avoid this? I?m unsure if there will be an easy repro. Again, profiler screenshot attached. From: owners-public_webgl...@ On Behalf Of Takahiro Aoyagi (taoyagi...@) Sent: Friday, May 10, 2019 12:22 AM To: Public WebGL Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Confirmed COMPLETION_STATUS_KHR is very fast like 0.01ms on my test https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html Nice work! Thanks Virus-free. www.avg.com On Wed, May 8, 2019 at 2:41 PM Ken Russell (kbr...@) wrote: Jie Chen from Intel just landed a fix in Chrome dramatically improving the performance of querying COMPLETION_STATUS_KHR under http://crbug.com/881152 . The fix will be in tomorrow's Canary on Windows and macOS. This should address the last major gap with this extension. We would like to enable it by default by promoting it to community approved; any further comments? -Ken From: Ken Russell Date: Fri, Apr 26, 2019 at 3:40 PM To: Public WebGL Thanks for the report and the clear test case. There was an existing bug about this, so the new one was duplicated into it, and some hints about implementing it were added to the preexisting bug. On Fri, Apr 26, 2019 at 5:56 AM Takahiro Aoyagi (taoyagi...@) wrote: Hi Chen, Opened a bug. Thanks. https://bugs.chromium.org/p/chromium/issues/detail?id=957001 Takahiro On Fri, Apr 26, 2019 at 8:03 PM Chen, Jie A (jie.a.chen...@) wrote: Hi Takahiro, The current implementation of COMPLETION_STATUS_KHR query in chromium incurs an expensive round-trip to the GPU thread. This may contribute to the wait time in your case. I am trying to optimize this. Could you please file a bug to chromium? I would look into it once I?ve done the optimization. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Takahiro Aoyagi (taoyagi...@) Sent: Friday, April 26, 2019 6:20 PM To: Public WebGL Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Hi all, I'm working on Three.js + KHR_parallel_shader_compile extension support with Fernando. https://github.com/mrdoob/three.js/issues/16321#issuecomment-486436086 I'm testing with Canary. But the behavior seems weird to me. gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) seems to wait for compile+link completion. I don't think it should wait for that, it should just do polling and returning true/false quickly instead. I made a simple test to reproduce. https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html Code snippet. const ext = gl.getExtension('KHR_parallel_shader_compile'); gl.compileShader(vertexShader); gl.compileShader(fragmentShader); gl.attachShader(program, vertexShader); gl.attachShader(program, fragmentShader); gl.linkProgram(program); const startTime = performance.now(); const status = useExtension ? gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) : gl.getProgramParameter(program, gl.LINK_STATUS); const endTime = performance.now(); const elapsedTime = endTime - startTime; On my platform, both gl.LINK_STATUS and ext.COMPLETION_STATUS_KHR take so long time about 15ms. I can accept this number for gl.LINK_STATUS because it waits for compile+link completion. But 15ms for ext.COMPLETION_STATUS_KHR looks weird to me. It shouldn't wait for the compile+link completion but should do just polling and quickly returning true/false instead. So I guess the number should be 1ms or less. Let me know if I'm missing something. Or could it be a Canary bug? My platform. OS: Windows10 Browser: Chrome Canary. Browser boot option: --use-cmd-decoder=passthrough --enable-webgl-draft-extensions Thanks Takahiro On Fri, Apr 26, 2019 at 10:15 AM Chen, Jie A (jie.a.chen...@) wrote: Basically, for ANGLE?s GL backend, it?s simply a wrapper for the existing GL implementations. In this sense glCompileShader() is still implementation specific. Essentially ANGLE just calls glCompileShader and check GL_COMPILE_STATUS. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Jasper St. Pierre (jstpierre...@) Sent: Friday, April 26, 2019 1:18 AM To: Public WebGL Subject: RE: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Thank you, that?s important information to know. Changing my shader compilation pipeline to wait for shader completion status is a lot more difficult, but based on some initial tests, it?s more expensive than not doing it ? the latency of getShaderParameter is too high. That said, in a lot of GL implementations, glCompileShader() is practically a no-op, and will only do an AST parse when glGetShaderParameter/InfoLog() is called (which is basically only for debugging / error checking). glLinkProgram() does full compilation of all programs, as full-PSO optimization is important. I don?t know how common this is, but multiple GL implementations I have seen do it. It might make sense for ANGLE to adopt this model as well. From: owners-public_webgl...@ On Behalf Of Chen, Jie A (jie.a.chen...@) Sent: Wednesday, April 24, 2019 6:48 PM To: Public WebGL Subject: RE: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Absolutely. Ideally there would be no stall for linkProgram. I tried, but it?s too difficult to achieve this in ANGLE. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Jeff Gilbert (jgilbert...@) Sent: Thursday, April 25, 2019 9:33 AM To: Public WebGL Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Possibly, but in the long run, I expect implementations to support no-stall linkProgram invocations. On Wed, Apr 24, 2019 at 6:27 PM Chen, Jie A (jie.a.chen...@) wrote: linkProgram may stall on compileShader. To avoid the stall, you?d better make sure the COMPLETION_STATUS_KHR statuses of the attached shaders are all True before calling linkProgram. In this sense, the first workflow has less chance running into stall. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Fernando Serrano Garc?a (fserrano...@) Sent: Wednesday, April 24, 2019 9:38 PM To: Public WebGL Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved Regarding the optimal proposed workflow (grouping shaders and programs separately) of: for (const x of shaders) gl.compileShader(x); for (const x of programs) gl.linkProgram(x); versus something more on the way that we currently have in many engines as threejs: for (const x of material) gl.compileShader(fs); gl.compileShader(vs); gl.linkProgram(x); Do you think is more or less accurate the following graph for 4 materials and enabling this extension with 2 and 4 parallel threads? On Wed, Apr 24, 2019 at 2:40 PM Fernando Serrano Garc?a wrote: fwiw three.js introduced a "debug" parameter (false by default) to determine if there will be a status check and call all the get* (currently in dev): - https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLShader.js#L21-L26 - https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLProgram.js#L608 so currently calling `new WebGLShader()` won't be blocking with any `get*` function and it could be used as is to compile all of them in a loop with or without the extension. the problem comes from the WebGLProgram as it should just queue itself before trying to link any program and wait until all the shader compile calls finish, then do all the link, and wait for it asynchronously before start using these programs. I have opened an issue on the three.js repo to keep track of the implementation and we have booked some time this week to take a look at it, feedback is welcome :) https://github.com/mrdoob/three.js/issues/16321 On Tue, Apr 16, 2019 at 11:55 PM Ken Russell (kbr...@) wrote: On Tue, Apr 16, 2019 at 2:24 PM Tarek Sherif (tsherif...@) wrote: Yes, I've read both specs. I think this language in the WebGL version is confusing: "When this extension is enabled: Shader compilation and program linking may be performed in a separate CPU thread." And neither indicates which functions are expected to cause stalls. As written, this extension requires more than most that people know implementation details. All previous operations against the program - looking up uniform locations, drawing with it, etc. - will cause stalls. The application *must* be updated to query the program's COMPLETION_STATUS_KHR status, and skip *all* operations against the program until it's no longer pending. I guess we'll just change the WebGL version of this extension spec to be much more explicit about this. Essentially, all previous code which checked for the completion of compilation of shaders / linking of programs can be updated with a small wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. This is not true because the most common way this is done will cause stalls that sabotage the parallelism, e.g.: https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLShader.js#L21-L36 https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLProgram.js#L586-L631 The check for COMPLETION_STATUS_KHR has to wrap *all* queries and uses of the program object, and they must be skipped until COMPLETION_STATUS_KHR returns true. Yes, all applications will have to be updated to take advantage of this extension, but if they do, the benefits will be significant. -Ken Tarek Sherif Senior Software Engineer, Visualization | Uber http://vis.gl/ On Tue, Apr 16, 2019 at 4:18 PM Ken Russell (kbr...@) wrote: Please review the Overview in the underlying OpenGL ES spec: https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt It describes that the extension uses one or more separate CPU threads for shader compilation. If you still think we should rewrite the introduction to the WebGL extension, we can do that too. Essentially, all previous code which checked for the completion of compilation of shaders / linking of programs can be updated with a small wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. -Ken On Tue, Apr 16, 2019 at 1:36 AM Tarek Sherif (tsherif...@) wrote: This is all extremely interesting, and documentation of these best practices should probably be more publicly available (perhaps through a non-normative note in the spec). I'm thinking the language in the extension spec could be made more clear about what it's actual purpose is. It currently gives the impression that enabling it is what allows for parallel compilation and that this should save time, but given what Jeff and Kai have said, it sounds like the purpose is to avoid CPU stalls, and that it might even take longer in wall time since you're only checking once a frame. Maybe some background information could be added along the lines of "Normally applications must wait on get*Parameter or a draw call for program linking to complete, this extension provides a mechanism for querying completion status without stalling..." Tarek Sherif Senior Software Engineer, Visualization | Uber http://vis.gl/ On Mon, Apr 15, 2019 at 11:23 PM Kai Ninomiya (kainino...@) wrote: On Mon, Apr 15, 2019 at 7:18 PM Tarek Sherif (tareksherif...@) wrote: I don't see anything in the OpenGL extension spec about what functions cause stalls. Is that implementation-specific? Having an idea what to expect is important for two reasons: 1. To make it clear that drawing will still work if getProgramParameter(COMPLETION_STATUS_KHR) hasn't returned true yet (i.e. the stall on a draw call) Generally, OpenGL extensions are not allowed to break existing API/existing content. (In OpenGL, all extensions are always enabled; there's no requestExtension.) Hence, even if you enable the extension, it won't change the way your application works, and therefore the draw call must still cause a stall in order to be able to use the program. 2. Almost all WebGL code I've looked at handles compilation in a way similar to the following: gl.compileShader(vertexShader); if (!gl.getShaderParameter(vertexShader, gl.COMPILE_STATUS)) //... gl.compileShader(fragmentShader); if (!gl.getShaderParameter(fragmentShader, gl.COMPILE_STATUS)) //... //... gl.linkProgram(program); if (!gl.getProgramParameter(program, gl.LINK_STATUS)) //... I think it would be worth it to make clear that this pattern would sabotage the parallel compile. I seem to remember (not sure if this is still true) that this pattern also sabotages the shader compiler cache in ANGLE, because ANGLE doesn't cache the COMPILE_STATUS (or was it the compile info string?). So it forces the compiler to recompile just to give you the status. Tarek Sherif http://tareksherif.net/ ??????? Original Message ??????? On Monday, April 15, 2019 9:00 PM, Ken Russell (kbr...@) wrote: The WebGL extension (which is basically just a wrapper) refers to the underlying OpenGL / OpenGL ES extension https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt, where this is documented. Is that sufficient? It would be better to avoid duplicating a large amount of spec text from the underlying extension. However, we can add some non-normative text if that would help. -Ken On Sat, Apr 13, 2019 at 3:51 AM Tarek Sherif (tareksherif...@) wrote: IIRC, all 3 of those functions still force a wait for the {shader to finish compiling, program to finish linking} just as they did before. The new semantics are only visible via the new COMPLETION_STATUS_KHR check. That should work perfectly for us. Can we add some language to the spec about which functions cause stalls? I feel like as written, it will be easy for people to use the extension incorrectly. Tarek Sherif http://tareksherif.net/ ??????? Original Message ??????? On Friday, April 12, 2019 4:10 PM, Kai Ninomiya (kainino...@) wrote: Oh yes, useProgram probably won't stall. But getUniformLocation and the others will stall, as will draw calls. getProgramParameter(COMPLETION_STATUS_KHR) should get faster at some point; see http://crbug.com/881152 which Ken linked. On Fri, Apr 12, 2019 at 12:39 PM Jasper St. Pierre (jstpierre...@) wrote: Thank you! Trying this out in my own WebGL 2 app, I see quite a reduction in shader compilation time, shaving 400ms on load time on a moderately complex scene. The getProgramParameter(COMPLETION_STATUS_KHR) query still takes 1ms (which I believe is being tracked), but that is still better from the 4ms I see in getUniformBlockIndex (my previous sync point). AFAIK, useProgram should not cause a stall, but in order to set my texture samplers to bind to different units, I need to do a getUniformLocation on my sampler uniform, which causes a compilation stall. Same thing with getUniformBlockIndex. Do make sure that anything that might query into reflection about the program (e.g. getVertexAttributeIndex, getUniformLocation, getUniformBlockIndex) happens after COMPLETION_STATUS_KHR returns true, since that?s another way to accidentally stall on compilation completing. From: owners-public_webgl...@ On Behalf Of Kai Ninomiya (kainino...@) Sent: Friday, April 12, 2019 10:25 AM To: Public WebGL Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved IIRC, all 3 of those functions still force a wait for the {shader to finish compiling, program to finish linking} just as they did before. The new semantics are only visible via the new COMPLETION_STATUS_KHR check. On Fri, Apr 12, 2019 at 10:05 AM Tarek Sherif (tsherif...@) wrote: Very excited about this extension, but I'm concerned about how it would work in our use case. Our flagship visualization library, deck.gl, often shares the gl context with a separate base map rendering application so that it can properly interleave visualization layers with the base map. Enabling this extension seems to change the behaviour of existing WebGL functions in a way that I don't believe other extensions do. My worry is how our enabling KHR_parallel_shader_compile would affect applications we share contexts with, i.e what happens if the typical synchronous compilation logic is used after KHR_parallel_shader_compile is enabled? Specifically: * What happens if getShaderParameter(shader, COMPILE_STATUS) is called before compilation is complete? * What happens if getProgramParameter(program, LINK_STATUS) is called before linking is complete? * What happens if useProgram is called before linking is complete? Thanks, Tarek Sherif Senior Software Engineer, Visualization | Uber http://vis.gl/ Tarek Sherif Senior Software Engineer, Visualization | Uber http://vis.gl/ On Fri, Apr 12, 2019 at 12:16 PM David Catuhe (David.Catuhe...@) wrote: Wonderful! From: owners-public_webgl...@ On Behalf Of Ken Russell (kbr...@) Sent: Wednesday, April 10, 2019 2:56 PM To: Public WebGL Subject: Re: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved If your code works correctly now when enabling draft WebGL extensions in Chrome, then no changes are needed. There won't be any changes to the extension when it's taken out of draft status; it'll just be available by default. -Ken On Wed, Apr 10, 2019 at 12:36 PM David Catuhe (David.Catuhe...@) wrote: We do have support for the extension in Babylon.js. How can we test this change? ________________________________ From: owners-public_webgl...@ on behalf of Ken Russell (kbr...@) Sent: Wednesday, April 10, 2019 12:00:25 PM To: public Subject: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved WebGL community, Jie Chen from Intel has principally developed and implemented a WebGL wrapper for the KHR_parallel_shader_compile extension. This allows shader compilation and program linking to occur fully in parallel to the rest of the WebGL application. Some small application changes are needed to take full advantage of the extension, but it is otherwise fully backward compatible. Jie has even emulated this extension on platforms which don't support it natively. This extension solves a longstanding user complaint with WebGL, namely long shader compile times on Windows. Compiles and links occur not only asynchronously, but also in parallel, so there is a net speedup when using this extension. Users who have tried out the draft extension are pleased with the results and would like to see it made widely available. I propose promoting this extension to community approved in https://github.com/KhronosGroup/WebGL/pull/2855 . Any comments? -Ken Virus-free. www.avg.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From pub...@ Fri May 17 16:08:59 2019 From: pub...@ (Ken Russell (...@...)) Date: Fri, 17 May 2019 16:08:59 -0700 Subject: [Public WebGL] Propose promoting KHR_parallel_shader_compile to community approved In-Reply-To: <5F447A42ADFAFD499D69CF330DF2E5C1606662A9@SHSMSX101.ccr.corp.intel.com> References: <5F447A42ADFAFD499D69CF330DF2E5C160660987@SHSMSX101.ccr.corp.intel.com> <5F447A42ADFAFD499D69CF330DF2E5C160661691@SHSMSX101.ccr.corp.intel.com> <5F447A42ADFAFD499D69CF330DF2E5C160661793@SHSMSX101.ccr.corp.intel.com> <5F447A42ADFAFD499D69CF330DF2E5C1606630CF@SHSMSX101.ccr.corp.intel.com> <5F447A42ADFAFD499D69CF330DF2E5C1606662A9@SHSMSX101.ccr.corp.intel.com> Message-ID: Yes, great work Takahiro integrating this extension into Three.js! Exciting to see it's providing benefits! Great work Jie in getting this extension over the finish line! Looking forward to all WebGL libraries using this extension to provide a smoother user experience! -Ken *From: *Chen, Jie A (jie.a.chen...@) *Date: *Wed, May 15, 2019 at 6:07 PM *To: *Public WebGL Great work! > > For the recompilation message, I filed an ANGLE bug for it. > > > > *From:* owners-public_webgl...@ [mailto: > owners-public_webgl...@] *On Behalf Of *Takahiro Aoyagi ( > taoyagi...@) > *Sent:* Wednesday, May 15, 2019 11:25 PM > *To:* Public WebGL > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Still WIP but I confirmed Three.js + KHR_parallel_shader_compile extension > with some optimizations improves the frame rate dropping on application > start up. > > > > https://twitter.com/superhoge/status/1128438246638333953 > > > > Regarding recompilation message, I think such type of hints are very > helpful to us optimize the JS graphics engine. Actually I had a hard time > with optimizing Three.js because WebGL inside is kinda black box to me. > > > > > > On Tue, May 14, 2019 at 4:47 PM Chen, Jie A (jie.a.chen...@) < > public_webgl...@> wrote: > > Kai, I?d like to do that. As far as I know, dynamic recompilation is not > seldom seen in ANGLE d3d backend. I not am sure if that would be over > warned. Probably we should file a bug to the ANGLE team firstly. > > > > *From:* owners-public_webgl...@ [mailto: > owners-public_webgl...@] *On Behalf Of *Kai Ninomiya ( > kainino...@) > *Sent:* Tuesday, May 14, 2019 1:51 AM > *To:* Public WebGL > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Jasper, thanks for looking into that! > > > > I think Chrome should print a performance warning if we compile a shader > that ends up getting recompiled before ever being used. > > > > Jie, would you be interested in looking into adding this warning? > > > > *From: *Jasper St. Pierre (jstpierre...@) > > *Date: *Sun, May 12, 2019 at 8:03 PM > *To: *Public WebGL > > I should probably note that the cause for the long stalls on gl.useProgram > was found. It turns out that ANGLE, at least on D3D11, will recompile the > shader program for every set of vertex attributes that it is used with. The > initial compileShader / linkProgram calls was done without having any VAO > or vertex attributes bound. Setting up a dummy VAO before compiling the > shaders and linking the programs fixed this. It's unfortunate that WebGL > does not expose ARB_vertex_attrib_binding, so setting up the dummy VAO was > a bit clunky, but it wasn't too bad. Make sure you compile your shaders > with the correct vertex attribute set up or you risk a dynamic shader > recompilation. > ------------------------------ > > *From:* owners-public_webgl...@ > on behalf of Kai Ninomiya (kainino...@) > *Sent:* Sunday, May 12, 2019 10:03:54 AM > *To:* public webgl > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > I think we will probably need to optimize checking LINK_STATUS (which > would make useProgram faster too), so that when the COMPLETION_STATUS query > result is sent to the client and cached, it sends the LINK_STATUS as well, > and updates the already existing link status cache. > > > > *From: *Takahiro Aoyagi (taoyagi...@) > *Date: *Sun, May 12, 2019, 2:14 AM > *To: *Public WebGL > > Thanks for the comments, Chen and Kai. > > > > Yeah, 8ms is very long to me. And if I compile+link two or more programs > the time can be longer. > > > > > I guess I?ve found the cause for gl.useProgram. WebGL implementation > inserts an extra GL command to query LinkStatus before using it. > > > > Will this be optimized (not adding the extra GL command) at some point? Or > must it be necessary? > > > > > But do note that we cache that info, so it only takes extra time on the > first useProgram. > > > > I confirmed that on my test. > > > > > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime10.html > > > > So far I'll try not to switch to a program which hasn't been called with > gl.useProgram() yet while at least one program is being compiled+linked. > > > > > > On Sun, May 12, 2019 at 2:54 PM Kai Ninomiya (kainino...@) < > public_webgl...@> wrote: > > 8ms is an extraordinary long time, in frame rendering time. > > > > But do note that we cache that info, so it only takes extra time on the > first useProgram. > > > > *From: *Chen, Jie A (jie.a.chen...@) > *Date: *Sat, May 11, 2019, 8:07 PM > *To: *Public WebGL > > I guess I?ve found the cause for gl.useProgram. WebGL implementation > inserts an extra GL command to query LinkStatus before using it. > > > https://cs.chromium.org/chromium/src/third_party/blink/renderer/modules/webgl/webgl_rendering_context_base.cc?sq=package:chromium&g=0&l=6350 > > > > Anyway I think you don?t need to worry too much about this. Usually it > doesn?t take very long to drain the command buffer. I tried your test case, > which took about only 8ms on my laptop. > > > > > > *From:* owners-public_webgl...@ [mailto: > owners-public_webgl...@] *On Behalf Of *Chen, Jie A ( > jie.a.chen...@) > *Sent:* Sunday, May 12, 2019 9:44 AM > *To:* Public WebGL > *Subject:* RE: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Mostly they are gl.get* like commands. You can search ?WaitForCmd? in > https://cs.chromium.org/chromium/src/gpu/command_buffer/client/gles2_implementation_impl_autogen.h and > > https://cs.chromium.org/chromium/src/gpu/command_buffer/client/gles2_implementation.cc > for them. > > But I don?t think gl.useProgram needs to wait. Most likely it has a > different cause. I will look into it later. > > > > > > *From:* owners-public_webgl...@ [mailto: > owners-public_webgl...@] *On Behalf Of *Takahiro Aoyagi ( > taoyagi...@) > *Sent:* Sunday, May 12, 2019 2:27 AM > *To:* Public WebGL > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > Hi Chen, > > > > Thanks for your explanation. > > > > What type of WebGL draw calls need to wait for all queued GL commands? In > my tests, not only gl.get*() > > > > > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime9.html > > > > but also gl.useProgram() seems to wait. > > > > > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime8.html > > > > > That means, I shouldn't call any gl.get*() and also I shouldn't switch > program until all programs compilation+linking are done? > > > > I haven't tried yet but could draw calls wait, too? If so, I shouldn't > render anything until then? > > > > > > Virus-free. www.avg.com > > > > > > On Sat, May 11, 2019 at 12:43 PM Chen, Jie A (jie.a.chen...@) < > public_webgl...@> wrote: > > > Interesting question, Takahiro. > > > My speculation is that the problem might be relevant to chrome?s > multi-process architecture. As you may know, the WebGL calls run in the > main thread of render process. Chrome needs to send these WebGL commands to > the GPU process for actual execution. So in your case, what Chrome actually > does for calls of makeProgram2 is simply putting the GL commands into a IPC > buffer. But later when you retrieve a program parameter back, it then > waits for the execution of all previously issued GL commands including > makeProgram2. > > > > > > *From:* owners-public_webgl...@ [mailto: > owners-public_webgl...@] *On Behalf Of *Takahiro Aoyagi ( > taoyagi...@) > *Sent:* Saturday, May 11, 2019 6:58 AM > *To:* Public WebGL > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > > > I'm very glad this extension moves forward. > > > > > > Question. Can compiling+linking a program block another program's > gl.get*() or gl.useProgram()? > > > > > > Even after confirming compile+link completion of a program with > COMPLETION_STATUS_KHR, gl.getProgramParameter() or gl.useProgram() seems > being blocked if another program is being compiled+linked on my Windows > Canary. Is this intentional or bug? > > > > > > > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime8.html > > > > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime9.html > > > > > > // Confirm program compile+link completion > > > if(gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR)) { > > > // Compile and link another program > > > const vertexShader2 = gl.createShader(gl.VERTEX_SHADER); > const fragmentShader2 = gl.createShader(gl.FRAGMENT_SHADER); > const program2 = gl.createProgram(); > > gl.shaderSource(vertexShader2, vertexShaderCode); > gl.shaderSource(fragmentShader2, fragmentShaderCode); > gl.compileShader(vertexShader2); > gl.compileShader(fragmentShader2); > gl.attachShader(program2, vertexShader2); > gl.attachShader(program2, fragmentShader2); > gl.linkProgram(program2); > > > > > > // gl.get*() or gl.useProgram() while the other program is being > compiled+linkied > > > const startTime = performance.now(); > gl.getProgramParameter(program, gl.ACTIVE_ATTRIBUTES); // or > gl.useProgram(program); > const endTime = performance.now(); > > > } > > > > > > Takahiro > > > > > > Virus-free. www.avg.com > > > > > > On Sat, May 11, 2019 at 6:11 AM Ken Russell (kbr...@) < > public_webgl...@> wrote: > > > Since there haven't been any *objections* to moving this extension > forward, and since the benefits are now being seen, it's been moved to > community approved in https://github.com/KhronosGroup/WebGL/pull/2855 . > > > > > > Please, feel free to continue to report problems with long shader > compilation times - either posting here on this mailing list or on > webgl-dev-list, reporting cross-browser issues on > https://github.com/KhronosGroup/WebGL/issues , or on individual browsers' > bug trackers. > > > > > > -Ken > > > > > > > > > > > > *From: *Ken Russell > *Date: *Fri, May 10, 2019 at 1:39 PM > *To: *Public WebGL > > > Super. Thank you Takahiro for testing and confirming! > > > > > > > > > *From: *Takahiro Aoyagi (taoyagi...@) > *Date: *Fri, May 10, 2019 at 10:51 AM > *To: *Public WebGL > > > I made simple tests to check the CPU elapsed time of > gl.getProgramParameter() and gl.useProgram() after checking > COMPLETION_STATUS_KHR is true. Both are fast here on my Windows10 Chrome > Canary. > > > > > > > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime6.html > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/blocktime7.html > > > > > > Takahiro > > > > > > Virus-free. www.avg.com > > > > > > On Sat, May 11, 2019 at 2:46 AM Ken Russell (kbr...@) < > public_webgl...@> wrote: > > > Hmm. The only reason I can think of that that would happen is if you're > running on Windows, and ANGLE has to dynamically recompile the program > behind the scenes in order to handle some OpenGL ES state change. I'm not > 100% sure which changes require this dynamic recompilation; the ANGLE > developers would know best. > https://groups.google.com//forum/#!forum/angleproject might be helpful. > > > > > > We'd really need some test case to make progress on this. Can you provide > one? > > > > > > -Ken > > > > > > > > > On Fri, May 10, 2019 at 10:28 AM Jasper St. Pierre (jstpierre...@) > wrote: > > > Hello again. My app is now showing that getProgramParameter is completing > quick, but it is spending a lot of time in useProgram. I am checking for > COMPLETION_STATUS_KHR on the GL program beforehand and it is returning > true. I?m guessing there?s some additional expensive work that still needs > to happen at useProgram time. Is this a bug? Any ways to debug or avoid > this? I?m unsure if there will be an easy repro. > > > > > > Again, profiler screenshot attached. > > > > > > *From:* owners-public_webgl...@ *On > Behalf Of *Takahiro Aoyagi (taoyagi...@) > *Sent:* Friday, May 10, 2019 12:22 AM > *To:* Public WebGL > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > > > Confirmed COMPLETION_STATUS_KHR is very fast like 0.01ms on my test > > > > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html > > > > > > Nice work! > > > > > > Thanks > > > > > > Virus-free. www.avg.com > > > > > > On Wed, May 8, 2019 at 2:41 PM Ken Russell (kbr...@) < > public_webgl...@> wrote: > > > Jie Chen from Intel just landed a fix in Chrome dramatically improving the > performance of querying COMPLETION_STATUS_KHR under > http://crbug.com/881152 . The fix will be in tomorrow's Canary on Windows > and macOS. > > > > > > This should address the last major gap with this extension. We would like > to enable it by default by promoting it to community approved; any further > comments? > > > > > > -Ken > > > > > > > > > > > > *From: *Ken Russell > *Date: *Fri, Apr 26, 2019 at 3:40 PM > *To: *Public WebGL > > > Thanks for the report and the clear test case. There was an existing bug > about this, so the new one was duplicated into it, and some hints about > implementing it were added to the preexisting bug. > > > > > > > > > On Fri, Apr 26, 2019 at 5:56 AM Takahiro Aoyagi (taoyagi...@) < > public_webgl...@> wrote: > > > Hi Chen, > > > > > > Opened a bug. Thanks. > > > > > > https://bugs.chromium.org/p/chromium/issues/detail?id=957001 > > > > > > Takahiro > > > > > > > > > On Fri, Apr 26, 2019 at 8:03 PM Chen, Jie A (jie.a.chen...@) < > public_webgl...@> wrote: > > > Hi Takahiro, > > > The current implementation of COMPLETION_STATUS_KHR query in chromium > incurs an expensive round-trip to the GPU thread. This may contribute to > the wait time in your case. I am trying to optimize this. Could you please > file a bug to chromium? I would look into it once I?ve done the > optimization. > > > > > > *From:* owners-public_webgl...@ [mailto: > owners-public_webgl...@] *On Behalf Of *Takahiro Aoyagi ( > taoyagi...@) > *Sent:* Friday, April 26, 2019 6:20 PM > *To:* Public WebGL > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > > > Hi all, > > > > > > I'm working on Three.js + KHR_parallel_shader_compile extension support > with Fernando. > > > > > > https://github.com/mrdoob/three.js/issues/16321#issuecomment-486436086 > > > > > > I'm testing with Canary. But the behavior seems weird to me. > gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) seems to wait > for compile+link completion. I don't think it should wait for that, it > should just do polling and returning true/false quickly instead. > > > > > > I made a simple test to reproduce. > > > > > > > https://raw.githack.com/takahirox/KHR_parallel_shader_compile_test/master/index.html > > > > > > Code snippet. > > > > > > const ext = gl.getExtension('KHR_parallel_shader_compile'); > > > > > > gl.compileShader(vertexShader); > gl.compileShader(fragmentShader); > gl.attachShader(program, vertexShader); > gl.attachShader(program, fragmentShader); > gl.linkProgram(program); > > const startTime = performance.now(); > const status = useExtension > ? gl.getProgramParameter(program, ext.COMPLETION_STATUS_KHR) > : gl.getProgramParameter(program, gl.LINK_STATUS); > const endTime = performance.now(); > > > const elapsedTime = endTime - startTime; > > > > > > On my platform, both gl.LINK_STATUS and ext.COMPLETION_STATUS_KHR take so > long time about 15ms. I can accept this number for gl.LINK_STATUS because > it waits for compile+link completion. But 15ms for > ext.COMPLETION_STATUS_KHR looks weird to me. It shouldn't wait for the > compile+link completion but should do just polling and quickly returning > true/false instead. So I guess the number should be 1ms or less. > > > > > > Let me know if I'm missing something. Or could it be a Canary bug? > > > > > > My platform. > > > > > > OS: Windows10 > > > Browser: Chrome Canary. > > > Browser boot option: --use-cmd-decoder=passthrough > --enable-webgl-draft-extensions > > > > > > > > > Thanks > > > > > > Takahiro > > > > > > > > > On Fri, Apr 26, 2019 at 10:15 AM Chen, Jie A (jie.a.chen...@) < > public_webgl...@> wrote: > > > Basically, for ANGLE?s GL backend, it?s simply a wrapper for the existing > GL implementations. In this sense glCompileShader() is still implementation > specific. Essentially ANGLE just calls glCompileShader and check > GL_COMPILE_STATUS. > > > > > > *From:* owners-public_webgl...@ [mailto: > owners-public_webgl...@] *On Behalf Of *Jasper St. Pierre ( > jstpierre...@) > *Sent:* Friday, April 26, 2019 1:18 AM > *To:* Public WebGL > *Subject:* RE: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > > > Thank you, that?s important information to know. Changing my shader > compilation pipeline to wait for shader completion status is a lot more > difficult, but based on some initial tests, it?s more expensive than not > doing it ? the latency of getShaderParameter is too high. > > > > > > That said, in a lot of GL implementations, glCompileShader() is > practically a no-op, and will only do an AST parse when > glGetShaderParameter/InfoLog() is called (which is basically only for > debugging / error checking). glLinkProgram() does full compilation of all > programs, as full-PSO optimization is important. I don?t know how common > this is, but multiple GL implementations I have seen do it. It might make > sense for ANGLE to adopt this model as well. > > > > > > *From:* owners-public_webgl...@ *On > Behalf Of *Chen, Jie A (jie.a.chen...@) > *Sent:* Wednesday, April 24, 2019 6:48 PM > *To:* Public WebGL > *Subject:* RE: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > > > Absolutely. Ideally there would be no stall for linkProgram. I tried, but > it?s too difficult to achieve this in ANGLE. > > > > > > *From:* owners-public_webgl...@ [ > mailto:owners-public_webgl...@] *On Behalf Of *Jeff Gilbert ( > jgilbert...@) > *Sent:* Thursday, April 25, 2019 9:33 AM > *To:* Public WebGL > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > > > Possibly, but in the long run, I expect implementations to support > no-stall linkProgram invocations. > > > > > > On Wed, Apr 24, 2019 at 6:27 PM Chen, Jie A (jie.a.chen...@) < > public_webgl...@> wrote: > > > linkProgram may stall on compileShader. To avoid the stall, you?d better > make sure the COMPLETION_STATUS_KHR statuses of the attached shaders are > all True before calling linkProgram. In this sense, the first workflow has > less chance running into stall. > > > > > > *From:* owners-public_webgl...@ [mailto: > owners-public_webgl...@] *On Behalf Of *Fernando Serrano Garc?a ( > fserrano...@) > *Sent:* Wednesday, April 24, 2019 9:38 PM > *To:* Public WebGL > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > > > Regarding the optimal proposed workflow (grouping shaders and programs > separately) of: > > > for (const x of shaders) > gl.compileShader(x); > for (const x of programs) > gl.linkProgram(x); > > > > > > versus something more on the way that we currently have in many engines as > threejs: > > > for (const x of material) > > > gl.compileShader(fs); > > > gl.compileShader(vs); > gl.linkProgram(x); > > > > > > Do you think is more or less accurate the following graph for 4 materials > and enabling this extension with 2 and 4 parallel threads? > > > > > > > > > On Wed, Apr 24, 2019 at 2:40 PM Fernando Serrano Garc?a < > fserrano...@> wrote: > > > fwiw three.js introduced a "debug" parameter (false by default) to > determine if there will be a status check and call all the get* (currently > in dev): > > > - > https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLShader.js#L21-L26 > > > - > https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLProgram.js#L608 > > > > > > so currently calling `new WebGLShader()` won't be blocking with any `get*` > function and it could be used as is to compile all of them in a loop with > or without the extension. > > > the problem comes from the WebGLProgram as it should just queue itself > before trying to link any program and wait until all the shader compile > calls finish, then do all the link, and wait for it asynchronously before > start using these programs. > > > I have opened an issue on the three.js repo to keep track of the > implementation and we have booked some time this week to take a look at it, > feedback is welcome :) https://github.com/mrdoob/three.js/issues/16321 > > > > > > On Tue, Apr 16, 2019 at 11:55 PM Ken Russell (kbr...@) < > public_webgl...@> wrote: > > > On Tue, Apr 16, 2019 at 2:24 PM Tarek Sherif (tsherif...@) < > public_webgl...@> wrote: > > > Yes, I've read both specs. I think this language in the WebGL version is > confusing: "When this extension is enabled: Shader compilation and program > linking may be performed in a separate CPU thread." And neither indicates > which functions are expected to cause stalls. As written, this extension > requires more than most that people know implementation details. > > > > > > All previous operations against the program - looking up uniform > locations, drawing with it, etc. - will cause stalls. The application > *must* be updated to query the program's COMPLETION_STATUS_KHR status, and > skip *all* operations against the program until it's no longer pending. > > > > > > I guess we'll just change the WebGL version of this extension spec to be > much more explicit about this. > > > > > > > > > Essentially, all previous code which checked for the completion of > compilation of shaders / linking of programs can be updated with a small > wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. > > > > > > This is not true because the most common way this is done will cause > stalls that sabotage the parallelism, e.g.: > > https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLShader.js#L21-L36 > > > > https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLProgram.js#L586-L631 > > > > > > The check for COMPLETION_STATUS_KHR has to wrap *all* queries and uses of > the program object, and they must be skipped until COMPLETION_STATUS_KHR > returns true. Yes, all applications will have to be updated to take > advantage of this extension, but if they do, the benefits will be > significant. > > > > > > -Ken > > > > > > > > > *Tarek Sherif* > > > Senior Software Engineer, Visualization | Uber > > > http://vis.gl/ > > > > > > > > > > > > On Tue, Apr 16, 2019 at 4:18 PM Ken Russell (kbr...@) < > public_webgl...@> wrote: > > > Please review the Overview in the underlying OpenGL ES spec: > > > > https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt > > > > > > It describes that the extension uses one or more separate CPU threads for > shader compilation. If you still think we should rewrite the introduction > to the WebGL extension, we can do that too. > > > > > > Essentially, all previous code which checked for the completion of > compilation of shaders / linking of programs can be updated with a small > wrapper which checks COMPLETION_STATUS_KHR for the linking of programs. > > > > > > -Ken > > > > > > > > > > > > On Tue, Apr 16, 2019 at 1:36 AM Tarek Sherif (tsherif...@) < > public_webgl...@> wrote: > > > This is all extremely interesting, and documentation of these best > practices should probably be more publicly available (perhaps through a > non-normative note in the spec). I'm thinking the language in the extension > spec could be made more clear about what it's actual purpose is. It > currently gives the impression that enabling it is what allows for parallel > compilation and that this should save time, but given what Jeff and Kai > have said, it sounds like the purpose is to avoid CPU stalls, and that it > might even take longer in wall time since you're only checking once a > frame. Maybe some background information could be added along the lines of > "Normally applications must wait on get*Parameter or a draw call for > program linking to complete, this extension provides a mechanism for > querying completion status without stalling..." > > > > > > > *Tarek Sherif* > > > Senior Software Engineer, Visualization | Uber > > > http://vis.gl/ > > > > > > > > > > > > On Mon, Apr 15, 2019 at 11:23 PM Kai Ninomiya (kainino...@) < > public_webgl...@> wrote: > > > > > > > > > On Mon, Apr 15, 2019 at 7:18 PM Tarek Sherif (tareksherif...@) < > public_webgl...@> wrote: > > > I don't see anything in the OpenGL extension spec about what functions > cause stalls. Is that implementation-specific? Having an idea what to > expect is important for two reasons: > > > 1. To make it clear that drawing will still work if > getProgramParameter(COMPLETION_STATUS_KHR) hasn't returned true yet (i.e. > the stall on a draw call) > > > > > > Generally, OpenGL extensions are not allowed to break existing > API/existing content. (In OpenGL, all extensions are always enabled; > there's no requestExtension.) Hence, even if you enable the extension, it > won't change the way your application works, and therefore the draw call > must still cause a stall in order to be able to use the program. > > > > > > 2. Almost all WebGL code I've looked at handles compilation in a way > similar to the following: > > > gl.compileShader(vertexShader); > if (!gl.getShaderParameter(vertexShader, gl.COMPILE_STATUS)) //... > > > gl.compileShader(fragmentShader); > > > if (!gl.getShaderParameter(fragmentShader, gl.COMPILE_STATUS)) //... > > > //... > > > gl.linkProgram(program); > if (!gl.getProgramParameter(program, gl.LINK_STATUS)) //... > > > I think it would be worth it to make clear that this pattern would > sabotage the parallel compile. > > > > > > I seem to remember (not sure if this is still true) that this pattern also > sabotages the shader compiler cache in ANGLE, because ANGLE doesn't cache > the COMPILE_STATUS (or was it the compile info string?). So it forces the > compiler to recompile just to give you the status. > > > > > > Tarek Sherif > > > http://tareksherif.net/ > > > > > > > > > > > > ??????? Original Message ??????? > > > On Monday, April 15, 2019 9:00 PM, Ken Russell (kbr...@) < > public_webgl...@> wrote: > > > > > > The WebGL extension (which is basically just a wrapper) refers to the > underlying OpenGL / OpenGL ES extension > https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt, > where this is documented. Is that sufficient? It would be better to avoid > duplicating a large amount of spec text from the underlying extension. > However, we can add some non-normative text if that would help. > > > > > > -Ken > > > > > > > > > > > > On Sat, Apr 13, 2019 at 3:51 AM Tarek Sherif (tareksherif...@) < > public_webgl...@> wrote: > > > IIRC, all 3 of those functions still force a wait for the {shader to > finish compiling, program to finish linking} just as they did before. The > new semantics are only visible via the new COMPLETION_STATUS_KHR check. > > > That should work perfectly for us. Can we add some language to the spec > about which functions cause stalls? I feel like as written, it will be easy > for people to use the extension incorrectly. > > > > > > Tarek Sherif > > > http://tareksherif.net/ > > > > > > > > > > > > ??????? Original Message ??????? > > > On Friday, April 12, 2019 4:10 PM, Kai Ninomiya (kainino...@) < > public_webgl...@> wrote: > > > > > > Oh yes, useProgram probably won't stall. But getUniformLocation and the > others will stall, as will draw calls. > > > > > > getProgramParameter(COMPLETION_STATUS_KHR) should get faster at some > point; see http://crbug.com/881152 which Ken linked. > > > > > > On Fri, Apr 12, 2019 at 12:39 PM Jasper St. Pierre (jstpierre...@) > wrote: > > > Thank you! Trying this out in my own WebGL 2 app, I see quite a reduction > in shader compilation time, shaving 400ms on load time on a moderately > complex scene. The getProgramParameter(COMPLETION_STATUS_KHR) query still > takes 1ms (which I believe is being tracked), but that is still better from > the 4ms I see in getUniformBlockIndex (my previous sync point). > > > > > > AFAIK, useProgram should not cause a stall, but in order to set my texture > samplers to bind to different units, I need to do a getUniformLocation on > my sampler uniform, which causes a compilation stall. Same thing with > getUniformBlockIndex. Do make sure that anything that might query into > reflection about the program (e.g. getVertexAttributeIndex, > getUniformLocation, getUniformBlockIndex) happens after > COMPLETION_STATUS_KHR returns true, since that?s another way to > accidentally stall on compilation completing. > > > > > > > > > *From:* owners-public_webgl...@ *On > Behalf Of *Kai Ninomiya (kainino...@) > > > *Sent:* Friday, April 12, 2019 10:25 AM > > > *To:* Public WebGL > > > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > > > > > > IIRC, all 3 of those functions still force a wait for the {shader to > finish compiling, program to finish linking} just as they did before. The > new semantics are only visible via the new COMPLETION_STATUS_KHR check. > > > > > > On Fri, Apr 12, 2019 at 10:05 AM Tarek Sherif (tsherif...@) < > public_webgl...@> wrote: > > > Very excited about this extension, but I'm concerned about how it would > work in our use case. Our flagship visualization library, deck.gl, often > shares the gl context with a separate base map rendering application so > that it can properly interleave visualization layers with the base map. > Enabling this extension seems to change the behaviour of existing WebGL > functions in a way that I don't believe other extensions do. My worry is > how our enabling KHR_parallel_shader_compile would affect applications we > share contexts with, i.e what happens if the typical synchronous > compilation logic is used after KHR_parallel_shader_compile is enabled? > Specifically: > > > - What happens if getShaderParameter(shader, COMPILE_STATUS) is called > before compilation is complete? > > - What happens if getProgramParameter(program, LINK_STATUS) is called > before linking is complete? > > - What happens if useProgram is called before linking is complete? > > > Thanks, > > > > > > > > > Tarek Sherif > > > Senior Software Engineer, Visualization | Uber > > > http://vis.gl/ > > > > > > > > > > > > > > > *Tarek Sherif* > > > Senior Software Engineer, Visualization | Uber > > > http://vis.gl/ > > > > > > > > > On Fri, Apr 12, 2019 at 12:16 PM David Catuhe (David.Catuhe...@) > wrote: > > > Wonderful! > > > > > > > > > *From:* owners-public_webgl...@ *On > Behalf Of *Ken Russell (kbr...@) > > > *Sent:* Wednesday, April 10, 2019 2:56 PM > > > *To:* Public WebGL > > > *Subject:* Re: [Public WebGL] Propose promoting > KHR_parallel_shader_compile to community approved > > > > > > > > > If your code works correctly now when enabling draft WebGL extensions in > Chrome, then no changes are needed. There won't be any changes to the > extension when it's taken out of draft status; it'll just be available by > default. > > > > > > -Ken > > > > > > > > > On Wed, Apr 10, 2019 at 12:36 PM David Catuhe (David.Catuhe...@) > wrote: > > > We do have support for the extension in Babylon.js. How can we test this > change? > > > > > ------------------------------ > > > > > > > > > > > *From:* owners-public_webgl...@ > on behalf of Ken Russell (kbr...@) > *Sent:* Wednesday, April 10, 2019 12:00:25 PM > *To:* public > *Subject:* [Public WebGL] Propose promoting KHR_parallel_shader_compile > to community approved > > > > > > WebGL community, > > > > > > Jie Chen from Intel has principally developed and implemented a WebGL > wrapper for the KHR_parallel_shader_compile extension. This allows shader > compilation and program linking to occur fully in parallel to the rest of > the WebGL application. Some small application changes are needed to take > full advantage of the extension, but it is otherwise fully backward > compatible. Jie has even emulated this extension on platforms which don't > support it natively. > > > > > > This extension solves a longstanding user complaint with WebGL, namely > long shader compile times on Windows. Compiles and links occur not only > asynchronously, but also in parallel, so there is a net speedup when using > this extension. Users who have tried out the draft extension are pleased > with the results and would like to see it made widely available. > > > > > > I propose promoting this extension to community approved in > https://github.com/KhronosGroup/WebGL/pull/2855 . Any comments? > > > > > > -Ken > > > > > > > > > > > > > > > Virus-free. www.avg.com > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: