From khr...@ Wed Apr 1 07:33:53 2015 From: khr...@ (Mark Callow) Date: Wed, 1 Apr 2015 23:33:53 +0900 Subject: [Public WebGL] rejecting WEBGL_color_buffer_float and EXT_color_buffer_half_float In-Reply-To: References: <16C15D76-A306-4264-B07F-6F92C7708B45@apple.com> <7EC1E63C-5FB2-4C59-8CDD-A3D7EED34A84@apple.com> <886D7475-16D3-4A2B-B4D2-1C4D619693BD@callow.im> <1BB74D03-CDD5-4D29-9027-4169ABAC6EC1@callow.im> Message-ID: <39B3AAB6-82E6-421B-B37F-E0DE65EDE268@callow.im> > On Mar 19, 2015, at 5:10 PM, Florian B?sch wrote: > > On Tue, Feb 10, 2015 at 4:10 PM, Florian B?sch wrote: > On Tue, Feb 10, 2015 at 4:05 PM, Kenneth Russell wrote: > If it turns out that because of Mozilla's work it's trivial to expose > these extensions in other WebGL implementations, we'll consider doing > so in Chrome. > That's excellent news. I will withdraw both proposals (for moving back to draft or rejection) if this turns out to be the case. > Any update on the progress of this? Through archaeology in the Khronos records and consultations with members we have verified the situation with regards to support of various float-related features in native OpenGL {,ES}. That EXT_color_buffer_float does not support blending with float32 color buffers is a deliberate decision traceable back to the final agreed list of features for OpenGL ES 3.x. Note that linear filtering of float32 textures is also unsupported in 3.x. Two mobile-GPU vendors have said they have parts or IP that supports float32 blending so Khronos has now created an EXT_float_blend extension to expose this feature. Those two vendors have said they will support it. The existing OES_texture_float_linear extension had already been updated with interactions with OpenGL ES 3.x and is the way linear filtering is exposed. That some OpenGL implementations are reportedly clamping the parameters passed to BlendColor, ClearColor and ClearDepth likely results from the spec using the clampf type for these parameters. This is a spec bug and is not the intended behavior. The bug was introduced when ARB_color_buffer_float was folded into the core spec. It was finally fixed in an updated OpenGL 4.2 specification released April 27th, 2012. As far as I can see there is no conformance test for this. Note too that floating-point textures cannot be created in ES 3.x with unsized internal formats (i.e. format == internalformat && (type = FLOAT || type == HALF_FLOAT)). This is because unsized internal formats are deprecated. Those included in ES 3.x are only there for compatibility with ES 2 and since FP textures were ES2 extensions, it was felt compatibility was not needed. This means the WebGL 1 extensions can?t be applied to WebGL 2. For WebGL 2 FP color buffer functionality can be exposed with EXT_color_buffer_float and EXT_float_blend. There is no WebGL wrapper yet for the latter. I?ll be happy to draft one, if we are in agreement. Linear filtering of float32 textures can be exposed with OES_texture_float_linear. The clamping problem affects both WebGL 1 and WebGL 2 implementations running on certain OpenGL implemenations. The simplest answer is to say that the FP color buffer extensions are not exposed in this case. So the vital question is what percentage of users are affected. It is important to realize that this clamping problem affects those implementations currently implicitly enabling FP rendering via OES_texture_{,half_}float so it is not by itself a reason to reject the subject extensions. One of four things must be happening: (1) the WebGL implementation is raising FRAMEBUFFER_INCOMPLETE when on an affected OpenGL implementation; (2) nobody is noticing the clamping; (3) affected implementations have bugs filed against them about this problem; or (4) people notice but don?t find it important enough to file a bug. Are any implementations doing 1? Do any implementations have open bugs about the clamping? The answers should help us decide if not exposing any FP rendering in the presence of the clamping is a viable choice. 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 pya...@ Wed Apr 1 09:02:10 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 1 Apr 2015 18:02:10 +0200 Subject: [Public WebGL] rejecting WEBGL_color_buffer_float and EXT_color_buffer_half_float In-Reply-To: <39B3AAB6-82E6-421B-B37F-E0DE65EDE268@callow.im> References: <16C15D76-A306-4264-B07F-6F92C7708B45@apple.com> <7EC1E63C-5FB2-4C59-8CDD-A3D7EED34A84@apple.com> <886D7475-16D3-4A2B-B4D2-1C4D619693BD@callow.im> <1BB74D03-CDD5-4D29-9027-4169ABAC6EC1@callow.im> <39B3AAB6-82E6-421B-B37F-E0DE65EDE268@callow.im> Message-ID: On Wed, Apr 1, 2015 at 4:33 PM, Mark Callow wrote: > > Note too that floating-point textures cannot be created in ES 3.x with > unsized internal formats (i.e. format == internalformat && (type = FLOAT > || type == HALF_FLOAT)). This is because unsized internal formats are > deprecated. Those included in ES 3.x are only there for compatibility with > ES 2 and since FP textures were ES2 extensions, it was felt compatibility > was not needed. This means the WebGL 1 extensions can?t be applied to WebGL > 2. > Are we going to retire unsized format/internalformat parameters from WebGL2? I'd be sorta in favor of this, but it'd present a problem for backwards compatibility. Maybe have a canvas.getContext('webgl2-core') ? It's a deeper question than it appears on the surface. As we're going to progress trough standards, legacy cruft will accumulate (just like it accumulated in the underlying standards), and if we keep it for legacy reasons, we're essentially ending up with a "compatibility profile" where everything hangs around in forever. > For WebGL 2 FP color buffer functionality can be exposed with > EXT_color_buffer_float and EXT_float_blend. There is no WebGL wrapper yet > for the latter. I?ll be happy to draft one, if we are in agreement. Linear > filtering of float32 textures can be exposed with OES_texture_float_linear. > I see a possible collision there with WebGL 1 and WebGL 2 extension naming (particularly as these extensions would functionally differ, see unsized vs. sized formats). -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Wed Apr 1 19:19:34 2015 From: kbr...@ (Kenneth Russell) Date: Wed, 1 Apr 2015 19:19:34 -0700 Subject: [Public WebGL] extension registry markup/split for webgl 1, 2 or both In-Reply-To: References: Message-ID: On Fri, Mar 27, 2015 at 3:30 AM, Florian B?sch wrote: > Ticket: https://github.com/KhronosGroup/WebGL/issues/917 > > It's currently the case that some purely WebGL 1 related extensions are > exposed on WebGL 2 contexts which shouldn't be (because they're WebGL 2 > core). It's also the case that it's not clear in the extension registry > overview, which extensions are WebGL 1, 2 or both. > > The extension definitions have the ability to mark up against which > specification they're written, and they can also specify in which version > they become core (example quoted from EXT_frag_depth below) > > > > > > > > > Would it make sense to mark up/divide the extension in the overview in some > fashion? I think that this will make the extension registry more complicated to navigate. It will add three new sections: extensions applying to WebGL 1.0, 2.0, and both. It also won't scale well to future releases. Since the intent is to have fewer rather than more extensions, I think the current extension registry organization is reasonable. -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 kbr...@ Wed Apr 1 19:29:26 2015 From: kbr...@ (Kenneth Russell) Date: Wed, 1 Apr 2015 19:29:26 -0700 Subject: [Public WebGL] packed qualifier omission In-Reply-To: References: Message-ID: On Fri, Mar 27, 2015 at 12:45 AM, Florian B?sch wrote: > This ticket https://github.com/KhronosGroup/WebGL/issues/911 specifies that > the packed layout qualifier is dropped because it could be used in a > non-portable fashion (by querying one GPU for its packing offsets and baking > that into a buffer for delivery). > > This isn't a "problem" unique to WebGL. Native applications would be able to > commit the same mistake. Wouldn't it be better to clearly state on the > reference pages/spec/test/guides that using packed qualifiers with GPU > queried offsets that this is GPU specific and leave the feature in? > > There are probably good uses of packed UBOs for applications (such as say > reducing GPU bandwidth cost on transfer). This topic was discussed face-to-face with multiple GPU vendors at the time. The smaller vendors typically find that the behavior implemented in the larger vendors' drivers becomes the status quo standard, and that they're forced to implement it in order to get major applications and games to run on their hardware. The WebGL group did not want this to happen with the data format of uniform buffer objects. Since UBOs are likely to provide such a huge performance boost over individual setting of uniforms, their usage is likely to be widespread. App developers are unlikely to test on more GPUs than those they have available. The probability is very high that using the packed layout qualifier will result in non-portable code. Also at the time, all GPU vendors agreed there would be no major performance loss or significant memory increase by standardizing on the std140 layout for WebGL. It's for this reason that the decision was made to only support that layout in UBOs in WebGL 2.0. -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 khr...@ Wed Apr 1 20:03:29 2015 From: khr...@ (Mark Callow) Date: Thu, 2 Apr 2015 12:03:29 +0900 Subject: [Public WebGL] rejecting WEBGL_color_buffer_float and EXT_color_buffer_half_float In-Reply-To: References: <16C15D76-A306-4264-B07F-6F92C7708B45@apple.com> <7EC1E63C-5FB2-4C59-8CDD-A3D7EED34A84@apple.com> <886D7475-16D3-4A2B-B4D2-1C4D619693BD@callow.im> <1BB74D03-CDD5-4D29-9027-4169ABAC6EC1@callow.im> <39B3AAB6-82E6-421B-B37F-E0DE65EDE268@callow.im> Message-ID: <12E4CBED-CC55-443B-ADAB-D190E49CD827@callow.im> > On Apr 2, 2015, at 1:02 AM, Florian B?sch wrote: > > > Are we going to retire unsized format/internalformat parameters from WebGL2? I'd be sorta in favor of this, but it'd present a problem for backwards compatibility. Maybe have a canvas.getContext('webgl2-core') ? It's a deeper question than it appears on the surface. As we're going to progress trough standards, legacy cruft will accumulate (just like it accumulated in the underlying standards), and if we keep it for legacy reasons, we're essentially ending up with a "compatibility profile" where everything hangs around in forever. That is an interesting idea. I think I?m in favor too. I don?t think it has been discussed at all. Since applications will have to be changed to request a WebGL 2 context instead of a WebGL 1 context, strict compatibility is not essential. I agree we should have a discussion about a process for getting rid of cruft. > > For WebGL 2 FP color buffer functionality can be exposed with EXT_color_buffer_float and EXT_float_blend. There is no WebGL wrapper yet for the latter. I?ll be happy to draft one, if we are in agreement. Linear filtering of float32 textures can be exposed with OES_texture_float_linear. > I see a possible collision there with WebGL 1 and WebGL 2 extension naming (particularly as these extensions would functionally differ, see unsized vs. sized formats). Yes. One solution is to make any shared extension document interactions with both WebGL 1 and WebGL 2 in the same way the native OES_texture_float_linear does for ES 2 and ES 3. 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 pya...@ Wed Apr 1 23:38:05 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Thu, 2 Apr 2015 08:38:05 +0200 Subject: [Public WebGL] backwards compatibility handling Message-ID: It is possible that successive versions of WebGL wish to remove functionality that was contained previously in order to get rid of cruft. To some extent this is already the case with WebGL 2 as the example below illustrates: The texImage family of calls in ES 2 (and WebGL 1) accept unsized internalformat parameters such as RGB, RGBA, LUMINANCE_ALPHA, LUMINANCE and ALPHA. In ES 3 (and WebGL 2) a host of new sized formats is introduced, for example: R8, R8_SNORM, R16F, R32F etc. If you enable OES_texture_float in WebGL 1 this call becomes valid: texImage2D(TEXTURE_2D, 0, RGBA, x, y, 0, RGBA, FLOAT) However ES 3 has floating point texturing support built in (and so OES_texture_float will not be offered as an extension) you will also have to change the call to account for that only sized internalformats are valid to pass for this type: texImage2D(TEXTURE_2D, 0, RGBA32F, x, y, 0, RGBA, FLOAT) At this time most of the backwards compatibility breaking changes are related to extensions. However future revisions of the standard might also have core incompatibilities. The way this has been handled in OpenGL is by defaulting to something called a "compatibility profile" which contained everything from previous revisions of the standard in addition to the new stuff. This is undesirable for obvious reasons. However the problem this solves should not be ignored, it's how people can deploy applications written against different versions of the standard in transitionary periods where support for a new standard isn't as widespread and so older profiles need to be supported as well. Obviously it would be bad if you had to maintain two separate implementations, and even writing cleanly separable code can be a challenge sometimes. In a nutshell, it makes it easier (for the right kind of programmer) to migrate to newer profiles. Unfortunately it also makes it easier (for the wrong kind of programmer) to produce messy dysfunctional GL code, which has lead to various initiatives/libraries attempting to provide clean core profiles. Fortunately WebGL doesn't have this problem (yet). I feel it's important to have a discussion about how this should be handled in WebGL, and I see 3 alternatives (examples) 1. Do not handle it, features in WebGL are liberally removed in backwards compatibility breaking ways. This will make it a bit harder to adopt newer WebGL profiles, but it will prevent mixed spagetti code and it probably makes life easier for vendors. 2. Introduce the concept of a compatibility profile which you default to (i.e. gl.getContext('webgl2') -> webgl2 compatibility profile, gl.getContext('webgl2-core') -> webgl2 core profile. This comes with all the drawbacks of the traditional OpenGL solution to the problem. 3. Introduce the concept of a compatibility profile, but default to core (i.e. gl.getContext('webgl2') -> webgl2 core, gl.getContext('webgl2-compatibility') -> webgl2 compatibility profile. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Apr 1 23:43:58 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Thu, 2 Apr 2015 08:43:58 +0200 Subject: [Public WebGL] rejecting WEBGL_color_buffer_float and EXT_color_buffer_half_float In-Reply-To: <12E4CBED-CC55-443B-ADAB-D190E49CD827@callow.im> References: <16C15D76-A306-4264-B07F-6F92C7708B45@apple.com> <7EC1E63C-5FB2-4C59-8CDD-A3D7EED34A84@apple.com> <886D7475-16D3-4A2B-B4D2-1C4D619693BD@callow.im> <1BB74D03-CDD5-4D29-9027-4169ABAC6EC1@callow.im> <39B3AAB6-82E6-421B-B37F-E0DE65EDE268@callow.im> <12E4CBED-CC55-443B-ADAB-D190E49CD827@callow.im> Message-ID: On Thu, Apr 2, 2015 at 5:03 AM, Mark Callow wrote: > That is an interesting idea. I think I?m in favor too. I don?t think it > has been discussed at all. Since applications will have to be changed to > request a WebGL 2 context instead of a WebGL 1 context, strict > compatibility is not essential. I agree we should have a discussion about a > process for getting rid of cruft. > Spawned in its own thread. Yes. One solution is to make any shared extension document interactions > with both WebGL 1 and WebGL 2 in the same way the native > OES_texture_float_linear does for ES 2 and ES 3. > That'll work. I think there aren't any existing (community approved or ratified) WebGL extensions that would need to be edited right? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Apr 1 23:45:07 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Thu, 2 Apr 2015 08:45:07 +0200 Subject: [Public WebGL] packed qualifier omission In-Reply-To: References: Message-ID: On Thu, Apr 2, 2015 at 4:29 AM, Kenneth Russell wrote: > Also at the time, all GPU vendors agreed there would be no major > performance loss or significant memory increase by standardizing on > the std140 layout for WebGL. It's for this reason that the decision > was made to only support that layout in UBOs in WebGL 2.0. Excellent, thank you for the documentation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Apr 1 23:53:14 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Thu, 2 Apr 2015 08:53:14 +0200 Subject: [Public WebGL] extension registry markup/split for webgl 1, 2 or both In-Reply-To: References: Message-ID: I don't mean to split the actual extension. I mean to split (or at least mark up) the pages indexing the extensions. If you want to present a clean picture for instance, you should filter the landing page for extensions which are . But people will still be interested in extensions which are and which are not because they still have to support these profiles. On the other hand, people will also be interested about extensions which are only because it gives them a good overview about which extensions they should bother about to provide backwards compatible applications. I see these meaningful changes that could be made: - Add "tags" to the extension overview derived from their specification so you can get a view at a glance what they are. - Add a filtering widget (checkboxes, what have you) that blends out those extensions which you've filtered out I'd default the filter to extensions which are because that gives the cleanest picture for newcomers. On Thu, Apr 2, 2015 at 4:19 AM, Kenneth Russell wrote: > On Fri, Mar 27, 2015 at 3:30 AM, Florian B?sch wrote: > > Ticket: https://github.com/KhronosGroup/WebGL/issues/917 > > > > It's currently the case that some purely WebGL 1 related extensions are > > exposed on WebGL 2 contexts which shouldn't be (because they're WebGL 2 > > core). It's also the case that it's not clear in the extension registry > > overview, which extensions are WebGL 1, 2 or both. > > > > The extension definitions have the ability to mark up against which > > specification they're written, and they can also specify in which version > > they become core (example quoted from EXT_frag_depth below) > > > > > > > > > > > > > > > > > > Would it make sense to mark up/divide the extension in the overview in > some > > fashion? > > I think that this will make the extension registry more complicated to > navigate. It will add three new sections: extensions applying to WebGL > 1.0, 2.0, and both. It also won't scale well to future releases. Since > the intent is to have fewer rather than more extensions, I think the > current extension registry organization is reasonable. > > -Ken > -------------- next part -------------- An HTML attachment was scrubbed... URL: From juj...@ Thu Apr 2 04:04:19 2015 From: juj...@ (=?UTF-8?Q?Jukka_Jyl=C3=A4nki?=) Date: Thu, 2 Apr 2015 14:04:19 +0300 Subject: [Public WebGL] backwards compatibility handling In-Reply-To: References: Message-ID: The texture image enum combo jungle is one of the worst aspects of tedious mini changes between desktop/mobile/web GL versions, especially for engines that are designed and written with a "use latest GL version available everywhere" runtime initialization. Specifically for this case, each of the engines (e.g. Unity3D, UE4, internally knows and are interested in saying "initialize me a texture of format R32G32B32A32_FLOAT_LITTLE_ENDIAN", and what they have to do is manage a switch-case mapping of initialized GL version and flavor -> the GL enum triplet that will give the desired format. This is horrible, and time is often wasted when this mapping is not correct. This always amounts to just a simple "oh, right, this GL version X GL flavor needs that enum here instead", so it's not a huge deal to change, but it wastes time due to a pointless api inconsistency. Like you mention, there is no backwards compatibility, and there is no forwards compatibility, and there is no compatibility across GL flavors, so it is quite hairy indeed. I am not sure if there is a good overall solution to this, but what I would prefer here is that WebGL would strictly follow the GLES specs to minimize the number of disruptions in this front, so it feels like the option 1. would be the easiest from the perspective of GLES<->WebGL parity and engines that multi-target WebGL, GLES and desktop GL. 2015-04-02 9:38 GMT+03:00 Florian B?sch : > It is possible that successive versions of WebGL wish to remove > functionality that was contained previously in order to get rid of cruft. > To some extent this is already the case with WebGL 2 as the example below > illustrates: > > The texImage family of calls in ES 2 (and WebGL 1) accept unsized > internalformat parameters such as RGB, RGBA, LUMINANCE_ALPHA, LUMINANCE and > ALPHA. > > In ES 3 (and WebGL 2) a host of new sized formats is introduced, for > example: R8, R8_SNORM, R16F, R32F etc. > > If you enable OES_texture_float in WebGL 1 this call becomes valid: > > texImage2D(TEXTURE_2D, 0, RGBA, x, y, 0, RGBA, FLOAT) > > > However ES 3 has floating point texturing support built in (and so > OES_texture_float will not be offered as an extension) you will also have > to change the call to account for that only sized internalformats are valid > to pass for this type: > > texImage2D(TEXTURE_2D, 0, RGBA32F, x, y, 0, RGBA, FLOAT) > > > At this time most of the backwards compatibility breaking changes are > related to extensions. However future revisions of the standard might also > have core incompatibilities. > > The way this has been handled in OpenGL is by defaulting to something > called a "compatibility profile" which contained everything from previous > revisions of the standard in addition to the new stuff. This is undesirable > for obvious reasons. > > However the problem this solves should not be ignored, it's how people can > deploy applications written against different versions of the standard in > transitionary periods where support for a new standard isn't as widespread > and so older profiles need to be supported as well. Obviously it would be > bad if you had to maintain two separate implementations, and even writing > cleanly separable code can be a challenge sometimes. > > In a nutshell, it makes it easier (for the right kind of programmer) to > migrate to newer profiles. Unfortunately it also makes it easier (for the > wrong kind of programmer) to produce messy dysfunctional GL code, which has > lead to various initiatives/libraries attempting to provide clean core > profiles. Fortunately WebGL doesn't have this problem (yet). > > I feel it's important to have a discussion about how this should be > handled in WebGL, and I see 3 alternatives (examples) > > 1. Do not handle it, features in WebGL are liberally removed in > backwards compatibility breaking ways. This will make it a bit harder to > adopt newer WebGL profiles, but it will prevent mixed spagetti code and it > probably makes life easier for vendors. > 2. Introduce the concept of a compatibility profile which you default > to (i.e. gl.getContext('webgl2') -> webgl2 compatibility profile, > gl.getContext('webgl2-core') -> webgl2 core profile. This comes with all > the drawbacks of the traditional OpenGL solution to the problem. > 3. Introduce the concept of a compatibility profile, but default to > core (i.e. gl.getContext('webgl2') -> webgl2 core, > gl.getContext('webgl2-compatibility') -> webgl2 compatibility profile. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From baj...@ Thu Apr 2 10:39:15 2015 From: baj...@ (Brandon Jones) Date: Thu, 02 Apr 2015 17:39:15 +0000 Subject: [Public WebGL] Experiemental WebGL 2.0 implementation available in Chrome Canary Message-ID: We're excited to announce that as of today you can begin experimenting with WebGL 2.0 on Windows, Mac, and Linux Chrome Canary or Chromium builds. The process for accessing the feature is described on the Khronos Wiki "Getting a WebGL Implementation" page, but the basic idea is: - Launch the browser from a command line with the --enable-unsafe-es3-apis flag (It's not in about:flags yet!) - Use "webgl2" instead of "webgl" when you call canvas.getContext(); If you want to test that it's working you can visit http://toji.github.io/webgl2-particles/ The particle cloud will spell "WebGL 2" if you are using a WebGL 2 implementation, and use the new transform feedback feature to drive the particles! Please note that this is definitely a work-in-progress an there are some features, such as 3D textures, that we know simply don't work right now. The implementation also lacks a lot of the basic validation that we will eventually need to put in place before making the API more widely available. We want to start getting developer feedback right away, though, so that we can respond to concerns about performance, features, security, compatibility, or the general API early in the development cycle. If/when you find bugs please report them at http://crbug.com, and make sure you attach the contents of your system's about:gpu page and, when possible, a minimal reproduction of the problem. We've consistently been blown away by the creativity and talent of the WebGL community, and we can't wait to see what you do with these new features! --The Chrome WebGL team -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Thu Apr 2 10:55:04 2015 From: kbr...@ (Kenneth Russell) Date: Thu, 2 Apr 2015 10:55:04 -0700 Subject: [Public WebGL] backwards compatibility handling In-Reply-To: References: Message-ID: The plan has been to adhere to the ES 3.0 semantics during the upgrade from WebGL 1.0 to 2.0 (option #1). It's been known for a while that certain features don't behave the same way in OpenGL ES 2.0 + extensions as they do in the OpenGL ES 3.0 core. draw_buffers, an important piece of functionality, is a prime example -- in ES 3.0, in order to access this feature, shaders must be written using ESSL 3.00 syntax, and auto-upgrading shaders seems infeasible. Applications upgrading from WebGL 1.0 to 2.0 will inevitably require code changes, so it was felt at the beginning of WebGL 2.0 spec development that it should be considered a mostly-compatible but still incompatible upgrade. It's for this reason that WebGL2RenderingContext does not inherit from WebGLRenderingContext -- mostly a symbolic gesture in a dynamically typed language like JavaScript, but still a salient one. -Ken On Thu, Apr 2, 2015 at 4:04 AM, Jukka Jyl?nki wrote: > The texture image enum combo jungle is one of the worst aspects of tedious > mini changes between desktop/mobile/web GL versions, especially for engines > that are designed and written with a "use latest GL version available > everywhere" runtime initialization. Specifically for this case, each of the > engines (e.g. Unity3D, UE4, internally knows and are interested in saying > "initialize me a texture of format R32G32B32A32_FLOAT_LITTLE_ENDIAN", and > what they have to do is manage a switch-case mapping of initialized GL > version and flavor -> the GL enum triplet that will give the desired format. > This is horrible, and time is often wasted when this mapping is not correct. > This always amounts to just a simple "oh, right, this GL version X GL flavor > needs that enum here instead", so it's not a huge deal to change, but it > wastes time due to a pointless api inconsistency. Like you mention, there is > no backwards compatibility, and there is no forwards compatibility, and > there is no compatibility across GL flavors, so it is quite hairy indeed. > > I am not sure if there is a good overall solution to this, but what I would > prefer here is that WebGL would strictly follow the GLES specs to minimize > the number of disruptions in this front, so it feels like the option 1. > would be the easiest from the perspective of GLES<->WebGL parity and engines > that multi-target WebGL, GLES and desktop GL. > > > 2015-04-02 9:38 GMT+03:00 Florian B?sch : >> >> It is possible that successive versions of WebGL wish to remove >> functionality that was contained previously in order to get rid of cruft. To >> some extent this is already the case with WebGL 2 as the example below >> illustrates: >> >> The texImage family of calls in ES 2 (and WebGL 1) accept unsized >> internalformat parameters such as RGB, RGBA, LUMINANCE_ALPHA, LUMINANCE and >> ALPHA. >> >> In ES 3 (and WebGL 2) a host of new sized formats is introduced, for >> example: R8, R8_SNORM, R16F, R32F etc. >> >> If you enable OES_texture_float in WebGL 1 this call becomes valid: >> >> texImage2D(TEXTURE_2D, 0, RGBA, x, y, 0, RGBA, FLOAT) >> >> >> However ES 3 has floating point texturing support built in (and so >> OES_texture_float will not be offered as an extension) you will also have to >> change the call to account for that only sized internalformats are valid to >> pass for this type: >> >> texImage2D(TEXTURE_2D, 0, RGBA32F, x, y, 0, RGBA, FLOAT) >> >> >> At this time most of the backwards compatibility breaking changes are >> related to extensions. However future revisions of the standard might also >> have core incompatibilities. >> >> The way this has been handled in OpenGL is by defaulting to something >> called a "compatibility profile" which contained everything from previous >> revisions of the standard in addition to the new stuff. This is undesirable >> for obvious reasons. >> >> However the problem this solves should not be ignored, it's how people can >> deploy applications written against different versions of the standard in >> transitionary periods where support for a new standard isn't as widespread >> and so older profiles need to be supported as well. Obviously it would be >> bad if you had to maintain two separate implementations, and even writing >> cleanly separable code can be a challenge sometimes. >> >> In a nutshell, it makes it easier (for the right kind of programmer) to >> migrate to newer profiles. Unfortunately it also makes it easier (for the >> wrong kind of programmer) to produce messy dysfunctional GL code, which has >> lead to various initiatives/libraries attempting to provide clean core >> profiles. Fortunately WebGL doesn't have this problem (yet). >> >> I feel it's important to have a discussion about how this should be >> handled in WebGL, and I see 3 alternatives (examples) >> >> Do not handle it, features in WebGL are liberally removed in backwards >> compatibility breaking ways. This will make it a bit harder to adopt newer >> WebGL profiles, but it will prevent mixed spagetti code and it probably >> makes life easier for vendors. >> Introduce the concept of a compatibility profile which you default to >> (i.e. gl.getContext('webgl2') -> webgl2 compatibility profile, >> gl.getContext('webgl2-core') -> webgl2 core profile. This comes with all the >> drawbacks of the traditional OpenGL solution to the problem. >> Introduce the concept of a compatibility profile, but default to core >> (i.e. gl.getContext('webgl2') -> webgl2 core, >> gl.getContext('webgl2-compatibility') -> webgl2 compatibility profile. >> >> > ----------------------------------------------------------- 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...@ Thu Apr 2 12:22:29 2015 From: kbr...@ (Kenneth Russell) Date: Thu, 2 Apr 2015 12:22:29 -0700 Subject: [Public WebGL] extension registry markup/split for webgl 1, 2 or both In-Reply-To: References: Message-ID: I understood that you meant to modify the landing page, but still think that it will introduce complexity in the overview. It isn't the right time to default the extensions landing page to display by default only those extensions applying to WebGL 2.0 because initial prototypes are only just becoming available. Once they're more broadly available it'll be a better time to reconsider. -Ken On Wed, Apr 1, 2015 at 11:53 PM, Florian B?sch wrote: > I don't mean to split the actual extension. I mean to split (or at least > mark up) the pages indexing the extensions. > > If you want to present a clean picture for instance, you should filter the > landing page for extensions which are . But people will > still be interested in extensions which are and which > are not because they still have to support these > profiles. On the other hand, people will also be interested about extensions > which are only because it gives them a good overview > about which extensions they should bother about to provide backwards > compatible applications. > > I see these meaningful changes that could be made: > > Add "tags" to the extension overview derived from their > specification so you can get a view at a glance what they are. > Add a filtering widget (checkboxes, what have you) that blends out those > extensions which you've filtered out > > I'd default the filter to extensions which are because > that gives the cleanest picture for newcomers. > > On Thu, Apr 2, 2015 at 4:19 AM, Kenneth Russell wrote: >> >> On Fri, Mar 27, 2015 at 3:30 AM, Florian B?sch wrote: >> > Ticket: https://github.com/KhronosGroup/WebGL/issues/917 >> > >> > It's currently the case that some purely WebGL 1 related extensions are >> > exposed on WebGL 2 contexts which shouldn't be (because they're WebGL 2 >> > core). It's also the case that it's not clear in the extension registry >> > overview, which extensions are WebGL 1, 2 or both. >> > >> > The extension definitions have the ability to mark up against which >> > specification they're written, and they can also specify in which >> > version >> > they become core (example quoted from EXT_frag_depth below) >> > >> > >> > >> > >> > >> > >> > >> > >> > Would it make sense to mark up/divide the extension in the overview in >> > some >> > fashion? >> >> I think that this will make the extension registry more complicated to >> navigate. It will add three new sections: extensions applying to WebGL >> 1.0, 2.0, and both. It also won't scale well to future releases. Since >> the intent is to have fewer rather than more extensions, I think the >> current extension registry organization is reasonable. >> >> -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 kbr...@ Thu Apr 2 15:50:57 2015 From: kbr...@ (Kenneth Russell) Date: Thu, 2 Apr 2015 15:50:57 -0700 Subject: [Public WebGL] rejecting WEBGL_color_buffer_float and EXT_color_buffer_half_float In-Reply-To: <39B3AAB6-82E6-421B-B37F-E0DE65EDE268@callow.im> References: <16C15D76-A306-4264-B07F-6F92C7708B45@apple.com> <7EC1E63C-5FB2-4C59-8CDD-A3D7EED34A84@apple.com> <886D7475-16D3-4A2B-B4D2-1C4D619693BD@callow.im> <1BB74D03-CDD5-4D29-9027-4169ABAC6EC1@callow.im> <39B3AAB6-82E6-421B-B37F-E0DE65EDE268@callow.im> Message-ID: On Wed, Apr 1, 2015 at 7:33 AM, Mark Callow wrote: > > On Mar 19, 2015, at 5:10 PM, Florian B?sch wrote: > > On Tue, Feb 10, 2015 at 4:10 PM, Florian B?sch wrote: > On Tue, Feb 10, 2015 at 4:05 PM, Kenneth Russell wrote: > If it turns out that because of Mozilla's work it's trivial to expose > these extensions in other WebGL implementations, we'll consider doing > so in Chrome. > That's excellent news. I will withdraw both proposals (for moving back to > draft or rejection) if this turns out to be the case. > Any update on the progress of this? > > > Through archaeology in the Khronos records and consultations with members we > have verified the situation with regards to support of various float-related > features in native OpenGL {,ES}. Mark, thank you for getting to the bottom of these issues. It must have been a lot of work to figure out all of these corner cases. > That EXT_color_buffer_float does not support blending with float32 color > buffers is a deliberate decision traceable back to the final agreed list of > features for OpenGL ES 3.x. Note that linear filtering of float32 textures > is also unsupported in 3.x. Two mobile-GPU vendors have said they have parts > or IP that supports float32 blending so Khronos has now created an > EXT_float_blend extension to expose this feature. Those two vendors have > said they will support it. The existing OES_texture_float_linear extension > had already been updated with interactions with OpenGL ES 3.x and is the way > linear filtering is exposed. > > That some OpenGL implementations are reportedly clamping the parameters > passed to BlendColor, ClearColor and ClearDepth likely results from the spec > using the clampf type for these parameters. This is a spec bug and is not > the intended behavior. The bug was introduced when ARB_color_buffer_float > was folded into the core spec. It was finally fixed in an updated OpenGL 4.2 > specification released April 27th, 2012. As far as I can see there is no > conformance test for this. The WebGL conformance suite could (and should) add tests for these, at least once EXT_color_buffer_float is supported in WebGL 2.0 implementations. > Note too that floating-point textures cannot be created in ES 3.x with > unsized internal formats (i.e. format == internalformat && (type = FLOAT || > type == HALF_FLOAT)). This is because unsized internal formats are > deprecated. Those included in ES 3.x are only there for compatibility with > ES 2 and since FP textures were ES2 extensions, it was felt compatibility > was not needed. This means the WebGL 1 extensions can?t be applied to WebGL > 2. > > For WebGL 2 FP color buffer functionality can be exposed with > EXT_color_buffer_float and EXT_float_blend. There is no WebGL wrapper yet > for the latter. I?ll be happy to draft one, if we are in agreement. Linear > filtering of float32 textures can be exposed with OES_texture_float_linear. It would be great if you'd draft a WebGL wrapper for EXT_float_blend. We need to nail down this behavior once and for all in the WebGL 2 ecosystem. > The clamping problem affects both WebGL 1 and WebGL 2 implementations > running on certain OpenGL implemenations. The simplest answer is to say that > the FP color buffer extensions are not exposed in this case. So the vital > question is what percentage of users are affected. > > It is important to realize that this clamping problem affects those > implementations currently implicitly enabling FP rendering via > OES_texture_{,half_}float so it is not by itself a reason to reject the > subject extensions. One of four things must be happening: (1) the WebGL > implementation is raising FRAMEBUFFER_INCOMPLETE when on an affected OpenGL > implementation; (2) nobody is noticing the clamping; (3) affected > implementations have bugs filed against them about this problem; or (4) > people notice but don?t find it important enough to file a bug. > > Are any implementations doing 1? Do any implementations have open bugs about > the clamping? The answers should help us decide if not exposing any FP > rendering in the presence of the clamping is a viable choice. I think this has gone unnoticed. I checked Chromium's issue tracker and there are no bugs filed about the clamping of arguments to ClearColor, etc. Chromium's WebGL implementation does do some checks before enabling the floating-point rendering extensions but doesn't currently check to see that clear colors are unclamped. I'm not sure how we would safely determine how many GPUs are affected by the clamping issue. It seems more practical to restrict WebGL 2's color_buffer_float extensions to only run on OpenGL implementations that don't perform this clamping, but I'd be very concerned about breaking high-profile WebGL 1 content that doesn't actually care whether these values are clamped or not. -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 ash...@ Fri Apr 10 09:49:02 2015 From: ash...@ (Ashley Gullen) Date: Fri, 10 Apr 2015 17:49:02 +0100 Subject: [Public WebGL] OffscreenCanvas and shared resources Message-ID: I for one am looking forwards to having the ability to do async texture uploads in WebGL, since it's a cause of jank and currently difficult to work around. It looks like WebGL will be able to run from a worker via OffscreenCanvas (see: https://wiki.whatwg.org/wiki/OffscreenCanvas). This means with shared resources, we can have a WebGL context running in a worker, post it an image to create a texture from, and then receive back a texture that can be used in a latency-sensitive context (e.g. the "main" context from the main thread or another worker, where it is necessary to render at a steady 60 FPS). What's the status of shared resources in WebGL and does it need updating to integrate with the upcoming OffscreenCanvas? Ashley -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Fri Apr 10 16:36:59 2015 From: kbr...@ (Kenneth Russell) Date: Fri, 10 Apr 2015 16:36:59 -0700 Subject: [Public WebGL] OffscreenCanvas and shared resources In-Reply-To: References: Message-ID: WebGL shared resources and OffscreenCanvas are orthogonal. There are two big issues with enabling resource sharing between WebGL contexts: guaranteeing that updates to resources that should be seen in another context are actually seen, and guaranteeing that updates to resources that should not be seen in another context are not seen. Both of these behaviors are required in order to ensure portability of code. Enforcing the second is harder. It would also be crucial to not adversely impact WebGL's performance in the common case since the shared resources extension would be really intrusive in the WebGL implementation. Right now we on the Chrome team are focusing on other things. -Ken On Fri, Apr 10, 2015 at 9:49 AM, Ashley Gullen wrote: > I for one am looking forwards to having the ability to do async texture > uploads in WebGL, since it's a cause of jank and currently difficult to work > around. > > It looks like WebGL will be able to run from a worker via OffscreenCanvas > (see: https://wiki.whatwg.org/wiki/OffscreenCanvas). > > This means with shared resources, we can have a WebGL context running in a > worker, post it an image to create a texture from, and then receive back a > texture that can be used in a latency-sensitive context (e.g. the "main" > context from the main thread or another worker, where it is necessary to > render at a steady 60 FPS). > > What's the status of shared resources in WebGL and does it need updating to > integrate with the upcoming OffscreenCanvas? > > Ashley ----------------------------------------------------------- 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 Apr 10 22:14:58 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sat, 11 Apr 2015 07:14:58 +0200 Subject: [Public WebGL] using the same context with multiple canvases In-Reply-To: References: <1323262007.46206883.1359598185356.JavaMail.root@mozilla.com> <5114B8F1.9040706@jetbrains.com> Message-ID: Wanted to mention that I've hit upon yet another project that would need this capability. A product presentation site that requires presenting the product in the 3D viewport, but also requires presenting assembly options that're mixed into selection menus (like say car rims). It'd lead to hundreds of canvases, with at least a dozen or so on screen and being animated. On Fri, Mar 27, 2015 at 10:19 AM, Florian B?sch wrote: > Created a ticket for solving this issue: > https://github.com/KhronosGroup/WebGL/issues/915 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From khr...@ Sat Apr 11 20:03:52 2015 From: khr...@ (Mark Callow) Date: Sun, 12 Apr 2015 12:03:52 +0900 Subject: [Public WebGL] rejecting WEBGL_color_buffer_float and EXT_color_buffer_half_float In-Reply-To: References: <16C15D76-A306-4264-B07F-6F92C7708B45@apple.com> <7EC1E63C-5FB2-4C59-8CDD-A3D7EED34A84@apple.com> <886D7475-16D3-4A2B-B4D2-1C4D619693BD@callow.im> <1BB74D03-CDD5-4D29-9027-4169ABAC6EC1@callow.im> <39B3AAB6-82E6-421B-B37F-E0DE65EDE268@callow.im> Message-ID: <15411807-832C-499A-A0B0-89ED61655D48@callow.im> > On Apr 3, 2015, at 7:50 AM, Kenneth Russell wrote: > >> For WebGL 2 FP color buffer functionality can be exposed with >> EXT_color_buffer_float and EXT_float_blend. There is no WebGL wrapper yet >> for the latter. I?ll be happy to draft one, if we are in agreement. Linear >> filtering of float32 textures can be exposed with OES_texture_float_linear. > > It would be great if you'd draft a WebGL wrapper for EXT_float_blend. > We need to nail down this behavior once and for all in the WebGL 2 > ecosystem. I submitted a pull request - https://github.com/KhronosGroup/WebGL/pull/938. 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 Apr 13 15:13:28 2015 From: kbr...@ (Kenneth Russell) Date: Mon, 13 Apr 2015 15:13:28 -0700 Subject: [Public WebGL] rejecting WEBGL_color_buffer_float and EXT_color_buffer_half_float In-Reply-To: <15411807-832C-499A-A0B0-89ED61655D48@callow.im> References: <16C15D76-A306-4264-B07F-6F92C7708B45@apple.com> <7EC1E63C-5FB2-4C59-8CDD-A3D7EED34A84@apple.com> <886D7475-16D3-4A2B-B4D2-1C4D619693BD@callow.im> <1BB74D03-CDD5-4D29-9027-4169ABAC6EC1@callow.im> <39B3AAB6-82E6-421B-B37F-E0DE65EDE268@callow.im> <15411807-832C-499A-A0B0-89ED61655D48@callow.im> Message-ID: On Sat, Apr 11, 2015 at 8:03 PM, Mark Callow wrote: > >> On Apr 3, 2015, at 7:50 AM, Kenneth Russell wrote: >> >>> For WebGL 2 FP color buffer functionality can be exposed with >>> EXT_color_buffer_float and EXT_float_blend. There is no WebGL wrapper yet >>> for the latter. I?ll be happy to draft one, if we are in agreement. Linear >>> filtering of float32 textures can be exposed with OES_texture_float_linear. >> >> It would be great if you'd draft a WebGL wrapper for EXT_float_blend. >> We need to nail down this behavior once and for all in the WebGL 2 >> ecosystem. > > I submitted a pull request - https://github.com/KhronosGroup/WebGL/pull/938. Thanks Mark. Looks good; merged. -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...@ Thu Apr 23 10:19:37 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Thu, 23 Apr 2015 19:19:37 +0200 Subject: [Public WebGL] context loss, slowdowns and aw-snap dialogs Message-ID: When allocating resources via WebGL there is a point at which you will experience dramatic slowdowns in rendering performance due to virtualization of vram to ram (in some instances) and sometimes even to page-swap. Likewise, if a sudden context loss is experienced while a user is operating the app, it's often the case that some unseen boundary of ram has been stepped over. Sometimes these context losses can take the GPU process with them, and you'll get aw-snap dialogs, sometimes you'll get those despite the GPU process chugging along. Recovering mid-run from a context loss is a harrowing experience. Morever it is likely that trying to do so will end up in hysteresis because in restoring the resources that caused the context loss, another context loss will be provoked. Dealing with slowdowns of unknown origin can be difficult, because you don't know if a given UA/machine is running slow because it is just slow for other reasons, or if it's running slow because you caused virtualization to ram or page-swap. >From this it is fairly clear that the situation we find ourselves in is not conductive to a smooth user-experience. It is therefore absolutely mandatory that a cross-vendor way be introduced to detect how much vram you can consume before you will experience slowdowns, virtualizations, page-swaps, context losses, aw-snaps and GPU process crashes. Shotgunning everything at the vram wall and dealing with the carnage when it happens is not a sustainable way to go about writing reliable, fast, responsive and performant applications. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Thu Apr 23 11:19:08 2015 From: kbr...@ (Kenneth Russell) Date: Thu, 23 Apr 2015 11:19:08 -0700 Subject: [Public WebGL] context loss, slowdowns and aw-snap dialogs In-Reply-To: References: Message-ID: Determining the amount of available "video memory" is an ill-defined problem. Some GPUs have different memory pools for different object types, and some use unified memory architectures. Some operating systems deal better with paging resources off the GPU than others. The WebGL working group has asked GPU vendors on multiple occasions to define APIs to query the amount of video memory identically across GPUs, but there has been no success. Sorry there isn't a better solution, but I recommend defining some sort of heuristic like "use 100 bytes of video memory per pixel" and scale your application's buffer and texture usage appropriately. As far as I know, Google Maps uses such a heuristic and it works pretty well across a range of devices, since mobile devices with less available video memory also tend to have proportionately smaller screens. -Ken On Thu, Apr 23, 2015 at 10:19 AM, Florian B?sch wrote: > When allocating resources via WebGL there is a point at which you will > experience dramatic slowdowns in rendering performance due to virtualization > of vram to ram (in some instances) and sometimes even to page-swap. > > Likewise, if a sudden context loss is experienced while a user is operating > the app, it's often the case that some unseen boundary of ram has been > stepped over. > > Sometimes these context losses can take the GPU process with them, and > you'll get aw-snap dialogs, sometimes you'll get those despite the GPU > process chugging along. > > Recovering mid-run from a context loss is a harrowing experience. Morever it > is likely that trying to do so will end up in hysteresis because in > restoring the resources that caused the context loss, another context loss > will be provoked. > > Dealing with slowdowns of unknown origin can be difficult, because you don't > know if a given UA/machine is running slow because it is just slow for other > reasons, or if it's running slow because you caused virtualization to ram or > page-swap. > > From this it is fairly clear that the situation we find ourselves in is not > conductive to a smooth user-experience. It is therefore absolutely mandatory > that a cross-vendor way be introduced to detect how much vram you can > consume before you will experience slowdowns, virtualizations, page-swaps, > context losses, aw-snaps and GPU process crashes. > > Shotgunning everything at the vram wall and dealing with the carnage when it > happens is not a sustainable way to go about writing reliable, fast, > responsive and performant applications. ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Thu Apr 23 11:29:48 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Thu, 23 Apr 2015 20:29:48 +0200 Subject: [Public WebGL] context loss, slowdowns and aw-snap dialogs In-Reply-To: References: Message-ID: On Thu, Apr 23, 2015 at 8:19 PM, Kenneth Russell wrote: > Determining the amount of available "video memory" is an ill-defined > problem. Some GPUs have different memory pools for different object > types, and some use unified memory architectures. Some operating > systems deal better with paging resources off the GPU than others. I'm aware of this, it's also the reason I bring it up again. The WebGL working group has asked GPU vendors on multiple occasions to > define APIs to query the amount of video memory identically across > GPUs, but there has been no success. It'll have to happen one way or another. GPUs are increasingly taking over data management and production (as opposed to merely consumption). Before long (certainly within the next few years) applications will emerge that host most data and logic on the GPU/vram rather than on the CPU/ram (there are already a variety of such applications cropping up all over the place). If the WebGL WG has tried, and failed, to prompt a cross-vendor solution to this problem, doesn't mean it'll go away, like so many other issues of similar nature. It just means that the problem wasn't escalated properly/severly enough. I'd like GPU vendors to try to reach a solution to this before it becomes an issue of such prevalence that it becomes publicly embarrassing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Mon Apr 27 23:33:47 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Tue, 28 Apr 2015 08:33:47 +0200 Subject: [Public WebGL] shader compilation hangs/crashes Message-ID: For various reasons (ANGLE, drivers, etc.) it's possible to: - crash firefox - hang chrome (with an eventual GPU process crash) I'm sure other UAs are affected as well. I and others have observed this phenomenon on any OS, and it's nothing that's isolated. I have personally filed tickets (and even a conformance test) towards this issue. Many others have also filed tickets. Some of these tickets are of substantial age. Some pages (such as shadertoy, for reasons I get to shortly) has become the butt of a joke in some online communities (such as r/graphicsprogramming). I can understand if a shader fails to compile. I can understand if a shader, once compiled will run incredibly slow. What I cannot understand is that simply compiling a shader should hang/crash the software attempting to compile it. Shadertoy is a particular victim of this effect. This is because they're blasting up to 10 canvases each compiling a shader somebody submitted to their site at the UA. The likelyhood of encountering a UA busting shader on shadertoy is very high. You usually don't have to navigate very many overview pages to meet one for your platform. Shadertoys author is categorically refusing to do any of these things: - limit pages to one shader at a time - track which shaders provoke issues - inform shader authors about issues with their shaders Which is his prerogative. I personally don't agree with that stance, but it is a fairly valid stance to take, that UA should fix something which is obviously broken (see hangs/crashes). This has been a long-running issue, documented in many tickets. It's also become the main topic of debate whenever shadertoy pops up in a social media site somewhere. This is harmful to WebGL. For whatever reasons UAs think it's not their mission to fix a broken shader compilation pipeline, that is a sadly mistaken point of view. The bucket stops at UAs unfortunately. It's not possible to get all GPU drivers fixed right this day, even if GPU vendors could be bothered to introduce these fixes. The practice of ignoring this issue is self-defeating and just serves to cast popular WebGL pages in a bad light, and it casts WebGL as a whole in a bad light. It's a disservice to the work UA WebGL implementor teams do, because it cheapens the fruits of their labor. I'd implore every UA to take a long hard look at this issue and put it on top of their priority list to make sure their software is well behaved even with input they consider unreasonable. -------------- next part -------------- An HTML attachment was scrubbed... URL: