From kbr...@ Thu Aug 6 11:53:00 2015 From: kbr...@ (Kenneth Russell) Date: Thu, 6 Aug 2015 11:53:00 -0700 Subject: [Public WebGL] Proposing moving WEBGL_compressed_texture_astc_ldr to draft Message-ID: I'd like to propose moving https://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_compressed_texture_astc_ldr/ to draft status. This is an important compressed texture format to support, and a prototype implementation is being proposed in Chromium which we'd like to land. Are there any objections? Comments in support? 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 pya...@ Thu Aug 6 15:55:25 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 7 Aug 2015 00:55:25 +0200 Subject: [Public WebGL] Proposing moving WEBGL_compressed_texture_astc_ldr to draft In-Reply-To: References: Message-ID: How's the HDR/LDR profile support going to be differentiated? In OpenGL this extension has two name-strings indicating support for both or either of the HDR or LDR profiles. On Thu, Aug 6, 2015 at 8:53 PM, Kenneth Russell wrote: > > I'd like to propose moving > > https://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_compressed_texture_astc_ldr/ > to draft status. This is an important compressed texture format to > support, and a prototype implementation is being proposed in Chromium > which we'd like to land. Are there any objections? Comments in > support? > > 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 > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jav...@ Thu Aug 6 18:24:48 2015 From: jav...@ (Javi Agenjo) Date: Fri, 7 Aug 2015 03:24:48 +0200 Subject: [Public WebGL] Presenting WebGLStudio Message-ID: Hi everyone: My name is Javi Agenjo, I work at Universitat Pompeu Fabra in Barcelona, I'm a WebGL Developer. Over the last three years I've been coding an Open Source 3D Online editor from scratch using JS+WebGL inspired by Cinema4D and Unity. My goal is to create a flexible tool to test algorithms or create interactive applications. An environment that allows to configure every step of the rendering process with a WYSIWYG interface. You can test it and see videos at http://webglstudio.org (the name is just a placeholder while I think a better one) Right now the tool is very mature and almost ready to be used in production, the last months I've been just solving bugs and cleaning up the interface. Encouraged by Kenneth Russell I decided to share it here so you all could give me some feedback. I've been coding this application all by myself for too long and I dont want to lose focus. Ken asked me why is it different from existing editors, here is a list with some of the features that I think make it worthy to give it a try: - Component based Scene Graph (plug components or remove them, very easy to create new ones, even the interface is generated automatically) - Robust render engine: Shadowmaps for omni lights, realtime spherical reflections, multiple cameras. - Mesh Painter for any texture layer. - Collada importer - Coding pad (for behaviour and shaders) - Graph editor (for postFX and behaviour) - Bone animation (morph targets on the way) - Timeline keyframes editor for animating any property (even the ones created from scripts inside the editor). - Virtual File System that allows drag and drop files from your HD to the server with shared folders, quotas and thumbnails. - Prefabs, Material library, Binary file formats,... - Very clean API with documentation - Source code separated in libraries (low-level, rendering engine, graphs, gui and editor) all in their own github repository. I beg you to give it a try and give me some feedback so I can improve it and share it with the community. Just visit http://webglstudio.org/ and try it at http://webglstudio.org/demo/ Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Thu Aug 6 21:47:54 2015 From: kbr...@ (Kenneth Russell) Date: Thu, 6 Aug 2015 21:47:54 -0700 Subject: [Public WebGL] Proposing moving WEBGL_compressed_texture_astc_ldr to draft In-Reply-To: References: Message-ID: Another extension WEBGL_compressed_texture_astc_hdr will be introduced when it's ready. WEBGL_compressed_texture_astc_ldr only covers the low dynamic range profile in https://www.opengl.org/registry/specs/KHR/texture_compression_astc_hdr.txt -- e.g. the extension string "GL_KHR_texture_compression_astc_ldr". -Ken On Thu, Aug 6, 2015 at 3:55 PM, Florian B?sch wrote: > How's the HDR/LDR profile support going to be differentiated? In OpenGL this > extension has two name-strings indicating support for both or either of the > HDR or LDR profiles. > > On Thu, Aug 6, 2015 at 8:53 PM, Kenneth Russell wrote: >> >> >> I'd like to propose moving >> >> https://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_compressed_texture_astc_ldr/ >> to draft status. This is an important compressed texture format to >> support, and a prototype implementation is being proposed in Chromium >> which we'd like to land. Are there any objections? Comments in >> support? >> >> 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 >> ----------------------------------------------------------- >> > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Thu Aug 6 23:01:17 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 7 Aug 2015 08:01:17 +0200 Subject: [Public WebGL] Proposing moving WEBGL_compressed_texture_astc_ldr to draft In-Reply-To: References: Message-ID: As far as i can see the hdr/ldr difference in terms of api and implementation effort should be zero. Hdr differs in internal compression format by higher endpoint precision, but this difference is transparent to an astc user. Both the ldr and hdr extension would return the same extension object, effectively these extensions just carry a boolean value between them. This boolean value should come straight from the driver. What is the reason not to introduce both hdr and ldr at the same time in webgl? Both gl and es untroduced them at the same time (the specs even point to the same document). On Friday, August 7, 2015, Kenneth Russell wrote: > Another extension WEBGL_compressed_texture_astc_hdr will be introduced > when it's ready. WEBGL_compressed_texture_astc_ldr only covers the low > dynamic range profile in > https://www.opengl.org/registry/specs/KHR/texture_compression_astc_hdr.txt > -- e.g. the extension string "GL_KHR_texture_compression_astc_ldr". > > -Ken > > > On Thu, Aug 6, 2015 at 3:55 PM, Florian B?sch > wrote: > > How's the HDR/LDR profile support going to be differentiated? In OpenGL > this > > extension has two name-strings indicating support for both or either of > the > > HDR or LDR profiles. > > > > On Thu, Aug 6, 2015 at 8:53 PM, Kenneth Russell > wrote: > >> > >> > >> I'd like to propose moving > >> > >> > https://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_compressed_texture_astc_ldr/ > >> to draft status. This is an important compressed texture format to > >> support, and a prototype implementation is being proposed in Chromium > >> which we'd like to land. Are there any objections? Comments in > >> support? > >> > >> 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 > >> ----------------------------------------------------------- > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Aug 7 01:11:42 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 7 Aug 2015 10:11:42 +0200 Subject: [Public WebGL] plugging floating point holes Message-ID: A question I often receive from clients is: How many people will have support for rendering to, filtering and blending > of any kind of float. Unfortunately I can't answer that question, not with webglstats.com anyway. I can't answer it because the extensions to answer these questions aren't universally implemented, and no clear path or intention on the part of some vendors to implement them either. In particular the color_buffer_float/half-float variants (which some vendors implicitly enable). It's been suggested to me multiple times to just test if floating point textures can be rendered into. Unfortunately that is not a feasible thing to do for webglstats.com. If I do that, I'd have to test RGB, RGBA, Float32, Float16, etc. I can skip over the less popular formats, but it still involves creating a buffer, creating a shader, creating a framebuffer object, creating a texture, attaching the texture to the framebuffer, setting up pointers, drawing a quad to fill the floating point texture, creating another framebuffer, creating a byte texture, rendering the result of the floating point texture to the byte texture (because floating point readback isn't necessairly supported either), read back the byte texture and finally see if rendering to worked. This process (depending on machine) takes me something between 200-500ms. During that time a user-agent will be either unresponsive, or stuttery, and it might, or might not delay loading of the page. As you can imagine, it's not feasible for webglstats to interfere with other peoples pages loading any more than necessary, and a multi-hundred millisecond impact is simply something I cannot do. Additionally, reading back floating point data is unspecified altogether (there isn't an extension for it in any case). So floating point textures are still in a state of being an incompatible, unknown, dysfunctional mess. That is more than 4 years after the introduction of WebGL, and the universal acknowledgement that floating point textures are an extraordinary useful feature. This situation is a serious obstacle for me personally and WebGL as a whole. It's not the lack of hardware support that's missing, because some variant or other of floating point support is available on nearly any semi-modern GPU in existence. What it is is the completely botched nature of the software integration of floating point textures on the UAs side, which persists to this day. This cannot go on, and WebGL2 isn't the answer. It isn't because it will be years and years before one can feasably drop WebGL1 support. Could representatives of every UA please render their suggestions about how they plan to fix this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tal...@ Fri Aug 7 01:38:34 2015 From: tal...@ (Guillem) Date: Fri, 7 Aug 2015 10:38:34 +0200 Subject: [Public WebGL] Presenting WebGLStudio In-Reply-To: References: Message-ID: Hi Agenjo, Congratulations for webglstudio. It looks very promising. Keep it up. Regards Guillem On Fri, Aug 7, 2015 at 3:24 AM, Javi Agenjo wrote: > Hi everyone: > > My name is Javi Agenjo, I work at Universitat Pompeu Fabra in Barcelona, > I'm a WebGL Developer. Over the last three years I've been coding an Open > Source 3D Online editor from scratch using JS+WebGL inspired by Cinema4D > and Unity. My goal is to create a flexible tool to test algorithms or > create interactive applications. An environment that allows to configure > every step of the rendering process with a WYSIWYG interface. > > You can test it and see videos at http://webglstudio.org (the name is > just a placeholder while I think a better one) > > Right now the tool is very mature and almost ready to be used in > production, the last months I've been just solving bugs and cleaning up the > interface. > > Encouraged by Kenneth Russell I decided to share it here so you all could > give me some feedback. I've been coding this application all by myself for > too long and I dont want to lose focus. > > Ken asked me why is it different from existing editors, here is a list > with some of the features that I think make it worthy to give it a try: > > - Component based Scene Graph (plug components or remove them, very easy > to create new ones, even the interface is generated automatically) > - Robust render engine: Shadowmaps for omni lights, realtime spherical > reflections, multiple cameras. > - Mesh Painter for any texture layer. > - Collada importer > - Coding pad (for behaviour and shaders) > - Graph editor (for postFX and behaviour) > - Bone animation (morph targets on the way) > - Timeline keyframes editor for animating any property (even the ones > created from scripts inside the editor). > - Virtual File System that allows drag and drop files from your HD to the > server with shared folders, quotas and thumbnails. > - Prefabs, Material library, Binary file formats,... > - Very clean API with documentation > - Source code separated in libraries (low-level, rendering engine, graphs, > gui and editor) all in their own github repository. > > I beg you to give it a try and give me some feedback so I can improve it > and share it with the community. > > Just visit http://webglstudio.org/ and try it at > http://webglstudio.org/demo/ > > Thanks in advance. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Fri Aug 7 13:01:35 2015 From: jgi...@ (Jeff Gilbert) Date: Fri, 7 Aug 2015 13:01:35 -0700 Subject: [Public WebGL] plugging floating point holes In-Reply-To: References: Message-ID: We largely fixed this: If OES_texture_float is enabled, you can make 32F textures, and sample from them without filtering. If OES_texture_float_linear is enabled, 32F textures may be filtered. (sampled from with LINEAR) if WEBGL_color_buffer_float is enabled, RGBA32F becomes a color-renderable effective internal format for textures and renderbuffers. Also, RGBA/FLOAT supplants RGBA/UNSIGNED_BYTE as the default supported format/type for ReadPixel. This same pattern works applies to half-floats as well. Historically, it was pretty poorly specified, but we're in a better state today. Implementations which do not match what I state above are not (I believe) in compliance with the relevant extension specs. On Fri, Aug 7, 2015 at 1:11 AM, Florian B?sch wrote: > A question I often receive from clients is: > > How many people will have support for rendering to, filtering and >> blending of any kind of float. > > > Unfortunately I can't answer that question, not with webglstats.com > anyway. > > I can't answer it because the extensions to answer these questions aren't > universally implemented, and no clear path or intention on the part of some > vendors to implement them either. In particular the > color_buffer_float/half-float variants (which some vendors implicitly > enable). > > It's been suggested to me multiple times to just test if floating point > textures can be rendered into. Unfortunately that is not a feasible thing > to do for webglstats.com. > > If I do that, I'd have to test RGB, RGBA, Float32, Float16, etc. I can > skip over the less popular formats, but it still involves creating a > buffer, creating a shader, creating a framebuffer object, creating a > texture, attaching the texture to the framebuffer, setting up pointers, > drawing a quad to fill the floating point texture, creating another > framebuffer, creating a byte texture, rendering the result of the floating > point texture to the byte texture (because floating point readback isn't > necessairly supported either), read back the byte texture and finally see > if rendering to worked. > > This process (depending on machine) takes me something between 200-500ms. > During that time a user-agent will be either unresponsive, or stuttery, and > it might, or might not delay loading of the page. > > As you can imagine, it's not feasible for webglstats to interfere with > other peoples pages loading any more than necessary, and a multi-hundred > millisecond impact is simply something I cannot do. > > Additionally, reading back floating point data is unspecified altogether > (there isn't an extension for it in any case). > > So floating point textures are still in a state of being an incompatible, > unknown, dysfunctional mess. That is more than 4 years after the > introduction of WebGL, and the universal acknowledgement that floating > point textures are an extraordinary useful feature. > > This situation is a serious obstacle for me personally and WebGL as a > whole. It's not the lack of hardware support that's missing, because some > variant or other of floating point support is available on nearly any > semi-modern GPU in existence. What it is is the completely botched nature > of the software integration of floating point textures on the UAs side, > which persists to this day. > > This cannot go on, and WebGL2 isn't the answer. It isn't because it will > be years and years before one can feasably drop WebGL1 support. > > Could representatives of every UA please render their suggestions about > how they plan to fix this? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From khr...@ Fri Aug 7 14:18:01 2015 From: khr...@ (Mark Callow) Date: Fri, 7 Aug 2015 14:18:01 -0700 Subject: [Public WebGL] plugging floating point holes In-Reply-To: References: Message-ID: > On Aug 7, 2015, at 1:01 PM, Jeff Gilbert wrote: > > We largely fixed this: > If OES_texture_float is enabled, you can make 32F textures, and sample from them without filtering. > If OES_texture_float_linear is enabled, 32F textures may be filtered. (sampled from with LINEAR) > if WEBGL_color_buffer_float is enabled, RGBA32F becomes a color-renderable effective internal format for textures and renderbuffers. Also, RGBA/FLOAT supplants RGBA/UNSIGNED_BYTE as the default supported format/type for ReadPixel. > > This same pattern works applies to half-floats as well. > > Historically, it was pretty poorly specified, but we're in a better state today. Implementations which do not match what I state above are not (I believe) in compliance with the relevant extension specs. > Agreed. Specification-wise the only wrinkle is that WEBGL_color_buffer_float can?t be used to expose float32 rendering on OpenGL ES 3 devices supporting the native EXT_color_buffer_float, because the former requires that blending of float32 colors be supported and the latter requires they not be. This is a problem because, when I asked within Khronos, only 2 vendors said they could support float32 blending on their OpenGL ES 3.x parts. I apologize for this wrinkle. When I wrote WEBGL_color_buffer_float my purpose was to provide a way for implementations to expose float32 rendering when running on desktop OpenGL. I, wrongly as it turns out, expected future OpenGL ES implementations to have the same float32 capabilities. I see 3 ways to fix this: Change WEBGL_color_buffer_float to remove support for float32 blending. Change WEBGL_color_buffer_float to add a flag that indicates if float32 blending is supported Create a new extension, e.g, (horribly long name) WEBGL_color_buffer_float_no_blend Modify the WebGL version of EXT_color_buffer_float so that it can be applied to WebGL 1 implementations. I have not looked to see how much work this might be or what damage it might to the understandability of the extension. 1 and 2 are not acceptable by this groups processes as the spec. is already approved. There is a EXT_float_blend extension in proposals which can be used by WebGL 2 implementations to expose float32 blending and could also be used by WebGL 1 implementations if we choose #1 above. I?d like to propose moving that extension to Drafts so WebGL 2 implementations on desktop can start exposing it. Regards -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From kbr...@ Fri Aug 7 19:19:57 2015 From: kbr...@ (Kenneth Russell) Date: Fri, 7 Aug 2015 19:19:57 -0700 Subject: [Public WebGL] Proposing moving WEBGL_compressed_texture_astc_ldr to draft In-Reply-To: References: Message-ID: Thanks for pointing that out. I hadn't read the KHR_ or WebGL extension wrapper carefully. Agreed, it would be technically infeasible to dynamically enable one profile but not the other. Pull request up changing the name of the extension and adding profile support to it: https://github.com/KhronosGroup/WebGL/pull/1146 . Please comment. Thanks. -Ken On Thu, Aug 6, 2015 at 11:01 PM, Florian B?sch wrote: > As far as i can see the hdr/ldr difference in terms of api and > implementation effort should be zero. Hdr differs in internal compression > format by higher endpoint precision, but this difference is transparent to > an astc user. > > Both the ldr and hdr extension would return the same extension object, > effectively these extensions just carry a boolean value between them. This > boolean value should come straight from the driver. > > What is the reason not to introduce both hdr and ldr at the same time in > webgl? Both gl and es untroduced them at the same time (the specs even point > to the same document). > > On Friday, August 7, 2015, Kenneth Russell wrote: >> >> Another extension WEBGL_compressed_texture_astc_hdr will be introduced >> when it's ready. WEBGL_compressed_texture_astc_ldr only covers the low >> dynamic range profile in >> https://www.opengl.org/registry/specs/KHR/texture_compression_astc_hdr.txt >> -- e.g. the extension string "GL_KHR_texture_compression_astc_ldr". >> >> -Ken >> >> >> On Thu, Aug 6, 2015 at 3:55 PM, Florian B?sch wrote: >> > How's the HDR/LDR profile support going to be differentiated? In OpenGL >> > this >> > extension has two name-strings indicating support for both or either of >> > the >> > HDR or LDR profiles. >> > >> > On Thu, Aug 6, 2015 at 8:53 PM, Kenneth Russell wrote: >> >> >> >> >> >> I'd like to propose moving >> >> >> >> >> >> https://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_compressed_texture_astc_ldr/ >> >> to draft status. This is an important compressed texture format to >> >> support, and a prototype implementation is being proposed in Chromium >> >> which we'd like to land. Are there any objections? Comments in >> >> support? >> >> >> >> 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 >> >> ----------------------------------------------------------- >> >> >> > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Fri Aug 7 22:27:29 2015 From: kbr...@ (Kenneth Russell) Date: Fri, 7 Aug 2015 22:27:29 -0700 Subject: [Public WebGL] plugging floating point holes In-Reply-To: References: Message-ID: On Fri, Aug 7, 2015 at 2:18 PM, Mark Callow wrote: > > On Aug 7, 2015, at 1:01 PM, Jeff Gilbert wrote: > >> We largely fixed this: >> If OES_texture_float is enabled, you can make 32F textures, and sample from >> them without filtering. >> If OES_texture_float_linear is enabled, 32F textures may be filtered. >> (sampled from with LINEAR) >> if WEBGL_color_buffer_float is enabled, RGBA32F becomes a color-renderable >> effective internal format for textures and renderbuffers. Also, RGBA/FLOAT >> supplants RGBA/UNSIGNED_BYTE as the default supported format/type for >> ReadPixel. >> >> This same pattern works applies to half-floats as well. >> >> Historically, it was pretty poorly specified, but we're in a better state >> today. Implementations which do not match what I state above are not (I >> believe) in compliance with the relevant extension specs. > > > Agreed. The specifications for these extensions are in good shape, but unfortunately there aren't any conformance tests for them. The first step toward widespread support for them would be for someone to contribute WEBGL_color_buffer_float and EXT_color_buffer_half_float tests that verify all of the assertions of the specs: - Fragment shaders' outputs are not clamped for FP color buffers (this is already tested by WebGL's oes-texture-float.html conformance test) - clearColor's input is not clamped for FP color buffers -- corollary: if a value is passed to clearColor which is out-of-range for fixed-point color buffers, it's clamped at draw time for a fixed-point color buffer - Similarly, blendColor's values aren't clamped for FP color buffers - RGBA/FLOAT readback is supported for both FP16 and FP32 color buffers - RGBA/UNSIGNED_BYTE readback is disallowed for FP16 and FP32 color buffers (note: this will break the existing oes-texture-float.html test, so this behavior would probably have to be enabled only if WEBGL_color_buffer_float/EXT_color_buffer_half_float are enabled) - etc. It's great that Firefox has led the way in exposing these extensions. The availability of thorough conformance tests would make it much easier for the Chrome team to justify exposing them as well. My opinion is that exposing the extensions -- implicitly stating their guarantees -- but having those guarantees be potentially violated is worse than the current situation where most of these behaviors are undefined. > Specification-wise the only wrinkle is that WEBGL_color_buffer_float can?t > be used to expose float32 rendering on OpenGL ES 3 devices supporting the > native EXT_color_buffer_float, because the former requires that blending of > float32 colors be supported and the latter requires they not be. This is a > problem because, when I asked within Khronos, only 2 vendors said they could > support float32 blending on their OpenGL ES 3.x parts. > > I apologize for this wrinkle. When I wrote WEBGL_color_buffer_float my > purpose was to provide a way for implementations to expose float32 rendering > when running on desktop OpenGL. I, wrongly as it turns out, expected future > OpenGL ES implementations to have the same float32 capabilities. > > I see 3 ways to fix this: > > Change WEBGL_color_buffer_float to remove support for float32 blending. > Change WEBGL_color_buffer_float to add a flag that indicates if float32 > blending is supported > Create a new extension, e.g, (horribly long name) > WEBGL_color_buffer_float_no_blend > Modify the WebGL version of EXT_color_buffer_float so that it can be applied > to WebGL 1 implementations. I have not looked to see how much work this > might be or what damage it might to the understandability of the extension. > > > 1 and 2 are not acceptable by this groups processes as the spec. is already > approved. > > There is a EXT_float_blend extension in proposals which can be used by WebGL > 2 implementations to expose float32 blending and could also be used by WebGL > 1 implementations if we choose #1 above. I?d like to propose moving that > extension to Drafts so WebGL 2 implementations on desktop can start exposing > it. I strongly support moving the EXT_float_blend proposal to draft status. I don't have an opinion about what to do about WEBGL_color_buffer_float at this point. Again, having conformance tests for it would be a strong motivator. If they were there I'd probably vote for doing (1) -- removing support for FP32 blending -- and figure out what to do about the process side. If the working group agrees to make the change then I don't see anything major blocking it -- there's one implementation of this extension and it's untested. -Ken > Regards > > -Mark > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Fri Aug 7 23:15:01 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sat, 8 Aug 2015 08:15:01 +0200 Subject: [Public WebGL] Proposing moving WEBGL_compressed_texture_astc_ldr to draft In-Reply-To: References: Message-ID: I think the getSupportedProfile function works well and I'm glad we can avoid extension duplication (as the GL and ES registries had to), so that change looks good to me. Should the generated errors and their reasons be listed in this extension text? It'd probably help with figuring out what you did wrong without having to go read the underlying specification (we have several examples of extensions that list their errors). Other than the new errors introduced, a special class of error that would be worth mentioning is what happens if you deliver an image containing blocks in the HDR profile but you only have LDR support. No error is generated if you feed such data in, but any HDR profile block will be pink (note that a file may contain both LDR and HDR blocks at the same time). On Sat, Aug 8, 2015 at 4:19 AM, Kenneth Russell wrote: > Thanks for pointing that out. I hadn't read the KHR_ or WebGL > extension wrapper carefully. Agreed, it would be technically > infeasible to dynamically enable one profile but not the other. Pull > request up changing the name of the extension and adding profile > support to it: https://github.com/KhronosGroup/WebGL/pull/1146 . > Please comment. Thanks. > > -Ken > > > On Thu, Aug 6, 2015 at 11:01 PM, Florian B?sch wrote: > > As far as i can see the hdr/ldr difference in terms of api and > > implementation effort should be zero. Hdr differs in internal compression > > format by higher endpoint precision, but this difference is transparent > to > > an astc user. > > > > Both the ldr and hdr extension would return the same extension object, > > effectively these extensions just carry a boolean value between them. > This > > boolean value should come straight from the driver. > > > > What is the reason not to introduce both hdr and ldr at the same time in > > webgl? Both gl and es untroduced them at the same time (the specs even > point > > to the same document). > > > > On Friday, August 7, 2015, Kenneth Russell wrote: > >> > >> Another extension WEBGL_compressed_texture_astc_hdr will be introduced > >> when it's ready. WEBGL_compressed_texture_astc_ldr only covers the low > >> dynamic range profile in > >> > https://www.opengl.org/registry/specs/KHR/texture_compression_astc_hdr.txt > >> -- e.g. the extension string "GL_KHR_texture_compression_astc_ldr". > >> > >> -Ken > >> > >> > >> On Thu, Aug 6, 2015 at 3:55 PM, Florian B?sch wrote: > >> > How's the HDR/LDR profile support going to be differentiated? In > OpenGL > >> > this > >> > extension has two name-strings indicating support for both or either > of > >> > the > >> > HDR or LDR profiles. > >> > > >> > On Thu, Aug 6, 2015 at 8:53 PM, Kenneth Russell > wrote: > >> >> > >> >> > >> >> I'd like to propose moving > >> >> > >> >> > >> >> > https://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_compressed_texture_astc_ldr/ > >> >> to draft status. This is an important compressed texture format to > >> >> support, and a prototype implementation is being proposed in Chromium > >> >> which we'd like to land. Are there any objections? Comments in > >> >> support? > >> >> > >> >> 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 > >> >> ----------------------------------------------------------- > >> >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Aug 7 23:16:57 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sat, 8 Aug 2015 08:16:57 +0200 Subject: [Public WebGL] Proposing moving WEBGL_compressed_texture_astc_ldr to draft In-Reply-To: References: Message-ID: On a sidenote, a JS implementation of an ASTC encoder/decoder would be quite useful. As ASTC has no known IP issues, the providing party should have no issue providing it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Aug 7 23:36:56 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sat, 8 Aug 2015 08:36:56 +0200 Subject: [Public WebGL] plugging floating point holes In-Reply-To: References: Message-ID: On Fri, Aug 7, 2015 at 11:18 PM, Mark Callow wrote: > Specification-wise the only wrinkle is that WEBGL_color_buffer_float can?t > be used to expose float32 rendering on OpenGL ES 3 devices supporting the > native EXT_color_buffer_float, because the former requires that blending of > float32 colors be supported and the latter requires they not be. This is a > problem because, when I asked within Khronos, only 2 vendors said they > could support float32 blending on their OpenGL ES 3.x parts. > > I apologize for this wrinkle. When I wrote WEBGL_color_buffer_float my > purpose was to provide a way for implementations to expose float32 > rendering when running on desktop OpenGL. I, wrongly as it turns out, > expected future OpenGL ES implementations to have the same float32 > capabilities. > > I see 3 ways to fix this: > > 1. Change WEBGL_color_buffer_float to remove support for float32 > blending. > 2. Change WEBGL_color_buffer_float to add a flag that indicates if > float32 blending is supported > 3. Create a new extension, e.g, (horribly long name) > WEBGL_color_buffer_float_no_blend > 4. Modify the WebGL version of EXT_color_buffer_float so that it can > be applied to WebGL 1 implementations. I have not looked to see how much > work this might be or what damage it might to the understandability of the > extension. > > > 1 and 2 are not acceptable by this groups processes as the spec. is > already approved. > > There is a EXT_float_blend extension in proposals which can be used by > WebGL 2 implementations to expose float32 blending and could also be used > by WebGL 1 implementations if we choose #1 above. I?d like to propose > moving that extension to Drafts so WebGL 2 implementations on desktop can > start exposing it. > I don't think there's anything to be done about the blending situation in terms of specification (it's fully specified in the context that it applies by the existing set of extensions, although it does require the color_buffer_float/half_float extensions for WebGL1 to only work if blending also works). I would be in favor of moving EXT_float_blend to draft. -------------- next part -------------- An HTML attachment was scrubbed... URL: From khr...@ Sat Aug 8 07:58:38 2015 From: khr...@ (Mark Callow) Date: Sat, 8 Aug 2015 07:58:38 -0700 Subject: [Public WebGL] plugging floating point holes In-Reply-To: References: Message-ID: <40539F01-2F00-4B29-96A5-E7822FA28BD4@callow.im> > On Aug 7, 2015, at 10:27 PM, Kenneth Russell wrote: > > I strongly support moving the EXT_float_blend proposal to draft > status. I don't have an opinion about what to do about > On Aug 7, 2015, at 11:36 PM, Florian B?sch wrote: > > I would be in favor of moving EXT_float_blend to draft. I won?t be able to create a merge request for this until the week after next, due to Siggraph. If anyone wants to do it in the meantime, feel free. Regards -Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From kbr...@ Mon Aug 10 10:12:52 2015 From: kbr...@ (Kenneth Russell) Date: Mon, 10 Aug 2015 10:12:52 -0700 Subject: [Public WebGL] Proposing moving WEBGL_compressed_texture_astc_ldr to draft In-Reply-To: References: Message-ID: On Fri, Aug 7, 2015 at 11:15 PM, Florian B?sch wrote: > I think the getSupportedProfile function works well and I'm glad we can > avoid extension duplication (as the GL and ES registries had to), so that > change looks good to me. Good. I talked with Christophe offline and confirmed the intent of the getSupportedProfiles function. I've added a non-normative about how it's intended to be used. > Should the generated errors and their reasons be listed in this extension > text? It'd probably help with figuring out what you did wrong without having > to go read the underlying specification (we have several examples of > extensions that list their errors). This could be done, but I'd be concerned about simply duplicating text from the KHR extension. For the moment I've just added a strong note at the beginning to refer to the KHR spec for the behavioral definitions. Pull requests welcome to reshape the WebGL wrapper extension. > Other than the new errors introduced, a special class of error that would be > worth mentioning is what happens if you deliver an image containing blocks > in the HDR profile but you only have LDR support. No error is generated if > you feed such data in, but any HDR profile block will be pink (note that a > file may contain both LDR and HDR blocks at the same time). Per above, it seems problematic to duplicate all of the text from the KHR extension, since that might evolve in which case we'd need to update the WebGL wrapper. I've left this as is for now. Since there weren't any objections I've moved the extension to draft status. -Ken > > > On Sat, Aug 8, 2015 at 4:19 AM, Kenneth Russell wrote: >> >> Thanks for pointing that out. I hadn't read the KHR_ or WebGL >> extension wrapper carefully. Agreed, it would be technically >> infeasible to dynamically enable one profile but not the other. Pull >> request up changing the name of the extension and adding profile >> support to it: https://github.com/KhronosGroup/WebGL/pull/1146 . >> Please comment. Thanks. >> >> -Ken >> >> >> On Thu, Aug 6, 2015 at 11:01 PM, Florian B?sch wrote: >> > As far as i can see the hdr/ldr difference in terms of api and >> > implementation effort should be zero. Hdr differs in internal >> > compression >> > format by higher endpoint precision, but this difference is transparent >> > to >> > an astc user. >> > >> > Both the ldr and hdr extension would return the same extension object, >> > effectively these extensions just carry a boolean value between them. >> > This >> > boolean value should come straight from the driver. >> > >> > What is the reason not to introduce both hdr and ldr at the same time in >> > webgl? Both gl and es untroduced them at the same time (the specs even >> > point >> > to the same document). >> > >> > On Friday, August 7, 2015, Kenneth Russell wrote: >> >> >> >> Another extension WEBGL_compressed_texture_astc_hdr will be introduced >> >> when it's ready. WEBGL_compressed_texture_astc_ldr only covers the low >> >> dynamic range profile in >> >> >> >> https://www.opengl.org/registry/specs/KHR/texture_compression_astc_hdr.txt >> >> -- e.g. the extension string "GL_KHR_texture_compression_astc_ldr". >> >> >> >> -Ken >> >> >> >> >> >> On Thu, Aug 6, 2015 at 3:55 PM, Florian B?sch wrote: >> >> > How's the HDR/LDR profile support going to be differentiated? In >> >> > OpenGL >> >> > this >> >> > extension has two name-strings indicating support for both or either >> >> > of >> >> > the >> >> > HDR or LDR profiles. >> >> > >> >> > On Thu, Aug 6, 2015 at 8:53 PM, Kenneth Russell >> >> > wrote: >> >> >> >> >> >> >> >> >> I'd like to propose moving >> >> >> >> >> >> >> >> >> >> >> >> https://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_compressed_texture_astc_ldr/ >> >> >> to draft status. This is an important compressed texture format to >> >> >> support, and a prototype implementation is being proposed in >> >> >> Chromium >> >> >> which we'd like to land. Are there any objections? Comments in >> >> >> support? >> >> >> >> >> >> 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 >> >> >> ----------------------------------------------------------- >> >> >> >> >> > > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Mon Aug 10 10:15:29 2015 From: kbr...@ (Kenneth Russell) Date: Mon, 10 Aug 2015 10:15:29 -0700 Subject: [Public WebGL] Proposing moving WEBGL_compressed_texture_astc_ldr to draft In-Reply-To: References: Message-ID: ARM's provided source code for an ASTC encoder and decoder at https://github.com/ARM-software/astc-encoder . I'm not sure about the licensing terms. Maybe someone could compile it with Emscripten? -Ken On Fri, Aug 7, 2015 at 11:16 PM, Florian B?sch wrote: > On a sidenote, a JS implementation of an ASTC encoder/decoder would be quite > useful. As ASTC has no known IP issues, the providing party should have no > issue providing it. ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Sun Aug 30 01:51:05 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 30 Aug 2015 10:51:05 +0200 Subject: [Public WebGL] WebVulkan Message-ID: There is still no specification on Vulkan (other than SPIRV). However a few details seem to emerge so I'll briefly guesstimate at how it'll look: - multi threaded and *multi processed* operation - low level bytecode to pass to the Vulkan driver to compile to GPU native code (SPIRV) - command queue assembly for anything that's not SPIRV - low driver overhead (less validation, error checking, state management etc.) *Vulkans utility* I believe there will be *substantial challenges* to program in Vulkan (and not atop some library and engine). Challenges such as: targeting each specific GPU and its registers, caches (tiers/sizes), execution groups, memory lanes, capabilities/specific instructions, etc. That is to say, it'll be *really difficult*. I also believe that you will not see any tangible benefit from using Vulkan unless you make good use of the capabilities of each GPU. I don't think that targeting a common subset of functionality common across all GPUs that run Vulkan will be any faster than OpenGL or Direct3D drivers. With that being said, I also think that Vulkan *may deliver astounding performance advantages* in specific cases on specific hardware. Because it would allow to squeeze every last bit of performance out of a given GPU. *WebVulkan Critisisim* In various discussions, tweets etc. a few main points of criticism of the idea ov WebVulkan have emerged. I'll briefly summary those positions: - You cannot expose Vulkan to the web because it would be unsafe. - WebVulkan would deliver no performance advantage because browser/DOM/JS. - Vulkan would be far too difficult for people to use on the Web. I don't agree with any of those statements, but I believe they should be discussed at an appropriate time (when Vulkan is less vapoware and more released specification). *Don't drop the ball on Vulkan* Regardless of difficulties and challenges that go with something like Vulkan and WebVulkan, it is quite clear that Vulkan is meant to run on a wide installation base. And therefore it challenges several other technologies for primacy, namely: - *OpenCL* kernels can be compiled to Vulkan, unlike OpenCL, Vulkan (should) run everywhere easily. - A lot of what *Cuda* does will probably be able to run on Vulkan, and because Vulkan is (in principle) cross platform, should offer a lot more attractive target to program against. - *Compute Shaders *are rather directly in competition with Vulkan - *OpenGL and Direct3D*: Be it either trough direct use, library or engine, both of these "legacy" APIs would be threatened by Vulkan - *Metal* (being iOS only) would have a hard position against something that runs on Android and most other platforms. Hardware accelerated rendering (and general purpose programming) on the Web is still at a nascent stage. WebGL already has to fend of the (justified) perception of being clunky to work with because it is based on ES 2.0. WebGL 2 will help somewhat, but only somewhat, because the gap to DX12 and OpenGL 4.5 (or even ES 3.1) is still stupendous. *The Web cannot afford to drop the ball on technology that will make DX12/GL4.5/ES3.1 look old and clunky. It will hurt WebGL immesurably if there is no alternative if/once that happens.* -------------- next part -------------- An HTML attachment was scrubbed... URL: From chr...@ Sun Aug 30 10:26:29 2015 From: chr...@ (Christophe Riccio) Date: Sun, 30 Aug 2015 19:26:29 +0200 Subject: [Public WebGL] WebVulkan In-Reply-To: References: Message-ID: I am actually wondering what the WebGL community think about SPIR-V ever for current WebGL. There are still improvements required in SPIR-V (fine grain capabilities) but we should expect that SPIR-V modules should be a lot easier to validate than GLSL source. I think it's too early for WebVulkan. First the ecosystem needs to develop itself (spec, drivers, validation tools) and then before WebVulkan I think web browsers developers should consider Vulkan back-ends for WebGL implementations. Thanks, Christophe On Sun, Aug 30, 2015 at 10:51 AM, Florian B?sch wrote: > There is still no specification on Vulkan (other than SPIRV). However a > few details seem to emerge so I'll briefly guesstimate at how it'll look: > > - multi threaded and *multi processed* operation > - low level bytecode to pass to the Vulkan driver to compile to GPU > native code (SPIRV) > - command queue assembly for anything that's not SPIRV > - low driver overhead (less validation, error checking, state > management etc.) > > > *Vulkans utility* > > I believe there will be *substantial challenges* to program in Vulkan > (and not atop some library and engine). Challenges such as: targeting each > specific GPU and its registers, caches (tiers/sizes), execution groups, > memory lanes, capabilities/specific instructions, etc. That is to say, > it'll be *really difficult*. I also believe that you will not see any > tangible benefit from using Vulkan unless you make good use of the > capabilities of each GPU. I don't think that targeting a common subset of > functionality common across all GPUs that run Vulkan will be any faster > than OpenGL or Direct3D drivers. > > With that being said, I also think that Vulkan *may deliver astounding > performance advantages* in specific cases on specific hardware. Because > it would allow to squeeze every last bit of performance out of a given GPU. > > *WebVulkan Critisisim* > > In various discussions, tweets etc. a few main points of criticism of the > idea ov WebVulkan have emerged. I'll briefly summary those positions: > > - You cannot expose Vulkan to the web because it would be unsafe. > - WebVulkan would deliver no performance advantage because > browser/DOM/JS. > - Vulkan would be far too difficult for people to use on the Web. > > I don't agree with any of those statements, but I believe they should be > discussed at an appropriate time (when Vulkan is less vapoware and more > released specification). > > *Don't drop the ball on Vulkan* > > Regardless of difficulties and challenges that go with something like > Vulkan and WebVulkan, it is quite clear that Vulkan is meant to run on a > wide installation base. And therefore it challenges several other > technologies for primacy, namely: > > - *OpenCL* kernels can be compiled to Vulkan, unlike OpenCL, Vulkan > (should) run everywhere easily. > - A lot of what *Cuda* does will probably be able to run on Vulkan, > and because Vulkan is (in principle) cross platform, should offer a lot > more attractive target to program against. > - *Compute Shaders *are rather directly in competition with Vulkan > - *OpenGL and Direct3D*: Be it either trough direct use, library or > engine, both of these "legacy" APIs would be threatened by Vulkan > - *Metal* (being iOS only) would have a hard position against > something that runs on Android and most other platforms. > > Hardware accelerated rendering (and general purpose programming) on the > Web is still at a nascent stage. WebGL already has to fend of the > (justified) perception of being clunky to work with because it is based on > ES 2.0. WebGL 2 will help somewhat, but only somewhat, because the gap to > DX12 and OpenGL 4.5 (or even ES 3.1) is still stupendous. > > *The Web cannot afford to drop the ball on technology that will make > DX12/GL4.5/ES3.1 look old and clunky. It will hurt WebGL immesurably if > there is no alternative if/once that happens.* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ste...@ Sun Aug 30 11:44:33 2015 From: ste...@ (Steve Baker) Date: Sun, 30 Aug 2015 13:44:33 -0500 Subject: [Public WebGL] WebVulkan In-Reply-To: References: Message-ID: Given the importance of the web - I'd really hope that the needs for WebVulkan would be high on the list of priorities for the main Vulkan group. We've felt the pain of trying to bolt a proper security structure on top of a pre-existing OpenGL API...let's not make that mistake again! Waiting until the Vulkan spec is cast in concrete before we start to consider the web implications would be to repeat history here! -- Steve Christophe Riccio wrote: > I am actually wondering what the WebGL community think about SPIR-V ever > for current WebGL. There are still improvements required in SPIR-V (fine > grain capabilities) but we should expect that SPIR-V modules should be a > lot easier to validate than GLSL source. > > I think it's too early for WebVulkan. First the ecosystem needs to develop > itself (spec, drivers, validation tools) and then before WebVulkan I think > web browsers developers should consider Vulkan back-ends for WebGL > implementations. > > Thanks, > Christophe > > On Sun, Aug 30, 2015 at 10:51 AM, Florian B??sch wrote: > >> There is still no specification on Vulkan (other than SPIRV). However a >> few details seem to emerge so I'll briefly guesstimate at how it'll >> look: >> >> - multi threaded and *multi processed* operation >> - low level bytecode to pass to the Vulkan driver to compile to GPU >> native code (SPIRV) >> - command queue assembly for anything that's not SPIRV >> - low driver overhead (less validation, error checking, state >> management etc.) >> >> >> *Vulkans utility* >> >> I believe there will be *substantial challenges* to program in Vulkan >> (and not atop some library and engine). Challenges such as: targeting >> each >> specific GPU and its registers, caches (tiers/sizes), execution groups, >> memory lanes, capabilities/specific instructions, etc. That is to say, >> it'll be *really difficult*. I also believe that you will not see any >> tangible benefit from using Vulkan unless you make good use of the >> capabilities of each GPU. I don't think that targeting a common subset >> of >> functionality common across all GPUs that run Vulkan will be any faster >> than OpenGL or Direct3D drivers. >> >> With that being said, I also think that Vulkan *may deliver astounding >> performance advantages* in specific cases on specific hardware. Because >> it would allow to squeeze every last bit of performance out of a given >> GPU. >> >> *WebVulkan Critisisim* >> >> In various discussions, tweets etc. a few main points of criticism of >> the >> idea ov WebVulkan have emerged. I'll briefly summary those positions: >> >> - You cannot expose Vulkan to the web because it would be unsafe. >> - WebVulkan would deliver no performance advantage because >> browser/DOM/JS. >> - Vulkan would be far too difficult for people to use on the Web. >> >> I don't agree with any of those statements, but I believe they should be >> discussed at an appropriate time (when Vulkan is less vapoware and more >> released specification). >> >> *Don't drop the ball on Vulkan* >> >> Regardless of difficulties and challenges that go with something like >> Vulkan and WebVulkan, it is quite clear that Vulkan is meant to run on a >> wide installation base. And therefore it challenges several other >> technologies for primacy, namely: >> >> - *OpenCL* kernels can be compiled to Vulkan, unlike OpenCL, Vulkan >> (should) run everywhere easily. >> - A lot of what *Cuda* does will probably be able to run on Vulkan, >> and because Vulkan is (in principle) cross platform, should offer a >> lot >> more attractive target to program against. >> - *Compute Shaders *are rather directly in competition with Vulkan >> - *OpenGL and Direct3D*: Be it either trough direct use, library or >> engine, both of these "legacy" APIs would be threatened by Vulkan >> - *Metal* (being iOS only) would have a hard position against >> something that runs on Android and most other platforms. >> >> Hardware accelerated rendering (and general purpose programming) on the >> Web is still at a nascent stage. WebGL already has to fend of the >> (justified) perception of being clunky to work with because it is based >> on >> ES 2.0. WebGL 2 will help somewhat, but only somewhat, because the gap >> to >> DX12 and OpenGL 4.5 (or even ES 3.1) is still stupendous. >> >> *The Web cannot afford to drop the ball on technology that will make >> DX12/GL4.5/ES3.1 look old and clunky. It will hurt WebGL immesurably if >> there is no alternative if/once that happens.* >> > -- Steve ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Sun Aug 30 11:50:54 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 30 Aug 2015 20:50:54 +0200 Subject: [Public WebGL] WebVulkan In-Reply-To: References: Message-ID: On Sun, Aug 30, 2015 at 8:44 PM, Steve Baker wrote: > We've felt the pain of trying to bolt a proper security structure on top > of a pre-existing OpenGL API...let's not make that mistake again! > > Waiting until the Vulkan spec is cast in concrete before we start to > consider the web implications would be to repeat history here! > That's quite a good point. Even though WebVulkan may be far in the future, it'd be helpful if the Vulkan WG took input on security from the WebGL WG so that an eventual integration with the web does not become a massive pain in the posterior. Actually, given the rather dismal state of security of native apps on desktops overall, considering security implications of Vulkan doesn't just benefit the Web... -------------- next part -------------- An HTML attachment was scrubbed... URL: From baj...@ Sun Aug 30 17:44:34 2015 From: baj...@ (Brandon Jones) Date: Mon, 31 Aug 2015 00:44:34 +0000 Subject: [Public WebGL] WebVulkan In-Reply-To: References: Message-ID: The WebGL working group has given input to Vulkan pretty early on in the process, but aside from a couple of broad requests the general message was "Don't dumb anything down on our account." We're too deep into WebGL 2 to be distracted much with what WebGL Next looks like, but certainly the idea of basing it on next gen APIs has been discussed. Here's the thing: it will probably be impractical to try and expose a ~1:1 mapping for Vulkan and friends on the web like we did with WebGL and GLES2/3. I'm expecting that anything we do build will require some pretty heavy shimming if you wanted to do WebAssembly builds targeting it with Vulkan/DX12 C++ code. As such my gut feeling is that instead of trying to mimic any particular next gen API on the web we should probably build something that feels web-native (Vulkan definitely does not!) while still retaining the best ideas from the current crop of APIs. Of course that puts a tremendous amount of spec effort on the WebGL working group, and I'm not sure we're currently equipped to handle that. But as I said, the current focus is WebGL 2. It's a near-term, very realistic goal that will open up significant new GPU capabilities for developers. Avoiding that work in favor of focusing on a next gen API would be doing the WebGL community a huge disservice. --Brandon On Sun, Aug 30, 2015, 11:51 AM Florian B?sch wrote: > On Sun, Aug 30, 2015 at 8:44 PM, Steve Baker wrote: > >> We've felt the pain of trying to bolt a proper security structure on top >> of a pre-existing OpenGL API...let's not make that mistake again! >> >> Waiting until the Vulkan spec is cast in concrete before we start to >> consider the web implications would be to repeat history here! >> > > That's quite a good point. Even though WebVulkan may be far in the future, > it'd be helpful if the Vulkan WG took input on security from the WebGL WG > so that an eventual integration with the web does not become a massive pain > in the posterior. Actually, given the rather dismal state of security of > native apps on desktops overall, considering security implications of > Vulkan doesn't just benefit the Web... > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Mon Aug 31 00:14:16 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Mon, 31 Aug 2015 09:14:16 +0200 Subject: [Public WebGL] WebVulkan In-Reply-To: References: Message-ID: On Mon, Aug 31, 2015 at 2:44 AM, Brandon Jones wrote: > The WebGL working group has given input to Vulkan pretty early on in the > process, but aside from a couple of broad requests the general message was > "Don't dumb anything down on our account." > If Vulkan can be sandboxed (which is a dire need on any platform) then it shouldn't be much of a pain to make it Web safe. I'd be against dumbing it down of course. I'd be much more worried if it couldn't be sandboxed. > We're too deep into WebGL 2 to be distracted much with what WebGL Next > looks like, but certainly the idea of basing it on next gen APIs has been > discussed. > I appreciate that there's a lack of resources to plot out the future of hardware accelerated rendering and computation on the Web. However that doesn't mean it doesn't have to get done too. We can't afford to keep just one ball at the time in the air. > Here's the thing: it will probably be impractical to try and expose a ~1:1 > mapping for Vulkan and friends on the web like we did with WebGL and > GLES2/3. I'm expecting that anything we do build will require some pretty > heavy shimming if you wanted to do WebAssembly builds targeting it with > Vulkan/DX12 C++ code. > I'd very much like to have a discussion on that topic, but I can't. I can't because there's no Vulkan specification. Which means that you can draw your conclusions from information not available to me. Any discussion on that basis is not productive. > As such my gut feeling is that instead of trying to mimic any particular > next gen API on the web we should probably build something that feels > web-native (Vulkan definitely does not!) while still retaining the best > ideas from the current crop of APIs. Of course that puts a tremendous > amount of spec effort on the WebGL working group, and I'm not sure we're > currently equipped to handle that. > You could argue that WebGL doesn't feel "web-native". But since there's no Vulkan specification, that point can also not effectively be discussed. However if you're looking for web-native APIs, there's VRML... . Of course there's also the mutually incompatible "runs faster than JS" variants like (p)nacl, whatever mozilla does, and the never implemented not as plugin WebCL. > But as I said, the current focus is WebGL 2. It's a near-term, very > realistic goal that will open up significant new GPU capabilities for > developers. > WebGL 2 does not open up much that you can't have with extensions in WebGL 1. It's a welcome change and the new stuff not available in extensions is good to have. But it's not a dramatic change. ES 3.1 is a dramatic change because of compute shaders. Much in the way that Vulkan is dramatic change, because it lets you run a much more powerful form of GPGPU comptuation than bolted on compute shaders. > Avoiding that work in favor of focusing on a next gen API would be doing > the WebGL community a huge disservice. > Pushing hardware accelerated rendering/computation in browsers along can't be a single task process. You can't (obviously) drop the ball on WebGL2. But you also can't drop the ball on Extensions, WebGL3 and WebGL-Next/Vulkan/whatever. If the present and future of hardware accelerated rendering/comptuation on the Web can't be serviced by the current structure/commitment to it, it's time to talk how to fix that. -------------- next part -------------- An HTML attachment was scrubbed... URL: From flo...@ Mon Aug 31 00:14:57 2015 From: flo...@ (Floh) Date: Mon, 31 Aug 2015 09:14:57 +0200 Subject: [Public WebGL] WebVulkan In-Reply-To: References: Message-ID: You should definitely have at look at Metal for inspiration what modern Web 3D API could look like. In my opinion the new resource management (or rather lack of) in Vulkan and D3D12 is way to complicated and low level for a web API and (IMHO) won't bring any benefits in a safe browser environment. Metal on the other hand can absolutely be used without an engine-layer. Metal has simple D3D11-style resource binding (you only need to make sure to not overwrite data that's not currently in use), combined with modern concepts like pre-compiled pipeline-state-objects and free-threaded command lists. In my opinion, the 'perfect' modern Web 3D API would look like this: - coarse, pre-compiled state (e.g. pipeline-state-objects) - command lists which can also be built on WebWorker threads - SPIR-V shader byte code - more or less traditional resource management, D3D11 style (MAP_DISCARD buffer renaming under the hood, resources remain live as long as used by the GPU). Trying to create a direct copy of Vulkan or D3D12 on the Web doesn't make much sense IMHO, I'd rather see a cleaned up WebGL3/OpenGLES4 with pipeline-state-objects and SPIR-V shaders. Cheers, -Floh. On Mon, Aug 31, 2015 at 2:44 AM, Brandon Jones wrote: > The WebGL working group has given input to Vulkan pretty early on in the > process, but aside from a couple of broad requests the general message was > "Don't dumb anything down on our account." > > We're too deep into WebGL 2 to be distracted much with what WebGL Next looks > like, but certainly the idea of basing it on next gen APIs has been > discussed. Here's the thing: it will probably be impractical to try and > expose a ~1:1 mapping for Vulkan and friends on the web like we did with > WebGL and GLES2/3. I'm expecting that anything we do build will require some > pretty heavy shimming if you wanted to do WebAssembly builds targeting it > with Vulkan/DX12 C++ code. > > As such my gut feeling is that instead of trying to mimic any particular > next gen API on the web we should probably build something that feels > web-native (Vulkan definitely does not!) while still retaining the best > ideas from the current crop of APIs. Of course that puts a tremendous amount > of spec effort on the WebGL working group, and I'm not sure we're currently > equipped to handle that. > > But as I said, the current focus is WebGL 2. It's a near-term, very > realistic goal that will open up significant new GPU capabilities for > developers. Avoiding that work in favor of focusing on a next gen API would > be doing the WebGL community a huge disservice. > > --Brandon > > > On Sun, Aug 30, 2015, 11:51 AM Florian B?sch wrote: >> >> On Sun, Aug 30, 2015 at 8:44 PM, Steve Baker wrote: >>> >>> We've felt the pain of trying to bolt a proper security structure on top >>> of a pre-existing OpenGL API...let's not make that mistake again! >>> >>> Waiting until the Vulkan spec is cast in concrete before we start to >>> consider the web implications would be to repeat history here! >> >> >> That's quite a good point. Even though WebVulkan may be far in the future, >> it'd be helpful if the Vulkan WG took input on security from the WebGL WG so >> that an eventual integration with the web does not become a massive pain in >> the posterior. Actually, given the rather dismal state of security of native >> apps on desktops overall, considering security implications of Vulkan >> doesn't just benefit the Web... ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Mon Aug 31 00:19:33 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Mon, 31 Aug 2015 09:19:33 +0200 Subject: [Public WebGL] WebVulkan In-Reply-To: References: Message-ID: Since there is no Vulkan specification, we don't know what it will bring. So discussion on web only alternatives is also futile (and to be frank, I don't think that if Khronos is trying to invite an ecosystem of Vulkan based libraries, that we do the Web a big service by making us mutually incompatible from it). On Mon, Aug 31, 2015 at 9:14 AM, Floh wrote: > You should definitely have at look at Metal for inspiration what > modern Web 3D API could look like. In my opinion the new resource > management (or rather lack of) in Vulkan and D3D12 is way to > complicated and low level for a web API and (IMHO) won't bring any > benefits in a safe browser environment. Metal on the other hand can > absolutely be used without an engine-layer. > > Metal has simple D3D11-style resource binding (you only need to make > sure to not overwrite data that's not currently in use), combined with > modern concepts like pre-compiled pipeline-state-objects and > free-threaded command lists. > > In my opinion, the 'perfect' modern Web 3D API would look like this: > > - coarse, pre-compiled state (e.g. pipeline-state-objects) > - command lists which can also be built on WebWorker threads > - SPIR-V shader byte code > - more or less traditional resource management, D3D11 style > (MAP_DISCARD buffer renaming under the hood, resources remain live as > long as used by the GPU). > > Trying to create a direct copy of Vulkan or D3D12 on the Web doesn't > make much sense IMHO, I'd rather see a cleaned up WebGL3/OpenGLES4 > with pipeline-state-objects and SPIR-V shaders. > > Cheers, > -Floh. > > On Mon, Aug 31, 2015 at 2:44 AM, Brandon Jones wrote: > > The WebGL working group has given input to Vulkan pretty early on in the > > process, but aside from a couple of broad requests the general message > was > > "Don't dumb anything down on our account." > > > > We're too deep into WebGL 2 to be distracted much with what WebGL Next > looks > > like, but certainly the idea of basing it on next gen APIs has been > > discussed. Here's the thing: it will probably be impractical to try and > > expose a ~1:1 mapping for Vulkan and friends on the web like we did with > > WebGL and GLES2/3. I'm expecting that anything we do build will require > some > > pretty heavy shimming if you wanted to do WebAssembly builds targeting it > > with Vulkan/DX12 C++ code. > > > > As such my gut feeling is that instead of trying to mimic any particular > > next gen API on the web we should probably build something that feels > > web-native (Vulkan definitely does not!) while still retaining the best > > ideas from the current crop of APIs. Of course that puts a tremendous > amount > > of spec effort on the WebGL working group, and I'm not sure we're > currently > > equipped to handle that. > > > > But as I said, the current focus is WebGL 2. It's a near-term, very > > realistic goal that will open up significant new GPU capabilities for > > developers. Avoiding that work in favor of focusing on a next gen API > would > > be doing the WebGL community a huge disservice. > > > > --Brandon > > > > > > On Sun, Aug 30, 2015, 11:51 AM Florian B?sch wrote: > >> > >> On Sun, Aug 30, 2015 at 8:44 PM, Steve Baker wrote: > >>> > >>> We've felt the pain of trying to bolt a proper security structure on > top > >>> of a pre-existing OpenGL API...let's not make that mistake again! > >>> > >>> Waiting until the Vulkan spec is cast in concrete before we start to > >>> consider the web implications would be to repeat history here! > >> > >> > >> That's quite a good point. Even though WebVulkan may be far in the > future, > >> it'd be helpful if the Vulkan WG took input on security from the WebGL > WG so > >> that an eventual integration with the web does not become a massive > pain in > >> the posterior. Actually, given the rather dismal state of security of > native > >> apps on desktops overall, considering security implications of Vulkan > >> doesn't just benefit the Web... > -------------- next part -------------- An HTML attachment was scrubbed... URL: