From baj...@ Thu Sep 6 11:15:55 2012 From: baj...@ (Brandon Jones) Date: Thu, 6 Sep 2012 11:15:55 -0700 Subject: [Public WebGL] Resolving OES_vertex_array_object issues Message-ID: I'm currently working on exposing the OES_vertex_array_object extension to Chrome, building on the work Ben Vanik did in Webkit. There is still an outstanding issue listed on the extension that should be resolved first, however. Quoting from the spec : *The OES_vertex_array_object spec does not make it clear what happens to buffers that are deleted when they are referenced by vertex array objects. It is inferred that all buffers are reference counted.* *Before OES_vertex_array_object there was no way to use a deleted buffer in a single context as the spec states it would be unbound from all bind points. After OES_vertex_array_object it is now possible to use deleted buffers.* *Furthermore, the OpenGL ES 2.0 spec specifies that using a deleted buffer has undefined results including possibly corrupt rendering and generating GL errors. Undefined behavior is unacceptable for WebGL.* As implied by the above text, it seems as if the natural resolution is to require that buffers be reference counted so that a buffer that has been referenced by a VAO will not be removed even after DeleteBuffer has been called, though further attempts to bind to that buffer directly should fail. In my opinion this feels like the most straightforward solution. Gregg Tavares pointed out to me that under this model the buffers should behave consistently with textures that are deleted while bound to a framebuffer: pg. 114 section 4.4.3 If a texture object is deleted while its image is attached to the currently >> bound > > framebuffer, then it is as if FramebufferTexture2D had been called, with a >> texture > > of 0, for each attachment point to which this image was attached in the >> currently > > bound framebuffer. In other words, this texture image is ?rst detached >> from all > > attachment points in the currently bound framebuffer. Note that the >> texture image is > > speci?cally not detached from any other framebuffer objects. Detaching the >> texture > > image from any other framebuffer objects is the responsibility of the >> application. > > Which would mean that deleted buffers would be dereferenced if they are referenced by the currently bound VAO (including the default VAO) but not from any other VAOs. The alternative is to immediately delete the buffers and generate an error when the user attempts to draw with a VAO that references a deleted buffer. Is there any reason why we should prefer immediate deletion to a reference counting model? Either way it would be nice to resolve the issue in the spec so that we can make this extension available everywhere. --Brandon Jones -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Thu Sep 6 13:02:48 2012 From: gma...@ (=?UTF-8?B?R3JlZ2cgVGF2YXJlcyAo56S+55SoKQ==?=) Date: Thu, 6 Sep 2012 13:02:48 -0700 Subject: [Public WebGL] Resolving OES_vertex_array_object issues In-Reply-To: References: Message-ID: I should point out that for WebGL this means that most implementations will need to not call glDeleteBuffer when the user calls webgl.deleteBuffer but instead wait for all references to be released before calling glDeleteBuffer. Otherwise, according to the ES 2.0 spec "... attempting to use a deleted buffer ... > produces unde?ned results, including but not limited to possible GL errors > and > rendering corruption" ES 3.0 fixes this problem and requires buffers to be reference counted and usable past deletion just like other GL resources. Chrome already does this WebKit does not yet (yea, I know Chrome is built on WebKit but in Chrome we run our own GL) I haven't checked Firefox -g On Thu, Sep 6, 2012 at 11:15 AM, Brandon Jones wrote: > I'm currently working on exposing the OES_vertex_array_object extension to > Chrome, building on the work Ben Vanik did in Webkit. There is still an > outstanding issue listed on the extension that should be resolved first, > however. > > Quoting from the spec > : > > *The OES_vertex_array_object spec does not make it clear what happens to > buffers that are deleted when they are referenced by vertex array objects. > It is inferred that all buffers are reference counted.* > > *Before OES_vertex_array_object there was no way to use a deleted buffer > in a single context as the spec states it would be unbound from all bind > points. After OES_vertex_array_object it is now possible to use deleted > buffers.* > > *Furthermore, the OpenGL ES 2.0 spec specifies that using a deleted > buffer has undefined results including possibly corrupt rendering and > generating GL errors. Undefined behavior is unacceptable for WebGL.* > > As implied by the above text, it seems as if the natural resolution is to > require that buffers be reference counted so that a buffer that has been > referenced by a VAO will not be removed even after DeleteBuffer has been > called, though further attempts to bind to that buffer directly should > fail. In my opinion this feels like the most straightforward solution. > > Gregg Tavares pointed out to me that under this model the buffers should > behave consistently with textures that are deleted while bound to a > framebuffer: > > pg. 114 section 4.4.3 > > If a texture object is deleted while its image is attached to the >>> currently bound >> >> framebuffer, then it is as if FramebufferTexture2D had been called, with >>> a texture >> >> of 0, for each attachment point to which this image was attached in the >>> currently >> >> bound framebuffer. In other words, this texture image is ?rst detached >>> from all >> >> attachment points in the currently bound framebuffer. Note that the >>> texture image is >> >> speci?cally not detached from any other framebuffer objects. Detaching >>> the texture >> >> image from any other framebuffer objects is the responsibility of the >>> application. >> >> > Which would mean that deleted buffers would be dereferenced if they are > referenced by the currently bound VAO (including the default VAO) but not > from any other VAOs. > > The alternative is to immediately delete the buffers and generate an error > when the user attempts to draw with a VAO that references a deleted buffer. > > Is there any reason why we should prefer immediate deletion to a reference > counting model? Either way it would be nice to resolve the issue in the > spec so that we can make this extension available everywhere. > > --Brandon Jones > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwi...@ Fri Sep 7 09:15:06 2012 From: dwi...@ (Wilson, Diego) Date: Fri, 7 Sep 2012 16:15:06 +0000 Subject: [Public WebGL] ATC texture size computation Message-ID: <033CAC3586C48445A9740E2C20EF9D4F19B8E273@NASANEXD01C.na.qualcomm.com> Hello, The AMD_compressed_ATC_texture format is documented here: http://www.khronos.org/registry/gles/extensions/AMD/AMD_compressed_ATC_texture.txt It was brought to my attention that this compressed texture format is a good candidate for exposing as a WebGL extension. And that it is only missing one piece of information: the buffer size computation. Below is that information that has been verified both with experts in the format and empirically. Compressed texture images stored using the ATC compressed image formats are represented as a collection of 4x4 texel blocks. The size in bytes of a compressed ATC_RGB_AMD image is: ((width_in_texels+3)/4) * ((height_in_texels+3)/4) * 8 The size in bytes of a compressed ATC_RGBA_EXPLICIT_ALPHA_AMD or ATC_RGBA_INTERPOLATED_ALPHA_AMD image is: ((width_in_texels+3)/4) * ((height_in_texels+3)/4) * 16 I'm currently working to include this in public documentation as well. Regards, _________________ Diego Wilson -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Fri Sep 7 09:23:20 2012 From: bja...@ (Benoit Jacob) Date: Fri, 07 Sep 2012 12:23:20 -0400 Subject: [Public WebGL] ATC texture size computation In-Reply-To: <033CAC3586C48445A9740E2C20EF9D4F19B8E273@NASANEXD01C.na.qualcomm.com> References: <033CAC3586C48445A9740E2C20EF9D4F19B8E273@NASANEXD01C.na.qualcomm.com> Message-ID: <504A1F78.9020007@mozilla.com> Many thanks! I confirm that I'm very interested in exposing ATC as a WebGL extension, and the information below was the only missing piece. I will write a spec proposal very soon. The interest in ATC comes from the fact that together with PVRTC it's one of the two widespread mobile generalist compressed texture formats, and while PVRTC already has a WebGL extension spec proposal, it alone isn't enough to cover most of the existing devices: at least Qualcomm GPUs do not support PVRTC. Thus in order for WebGL games to take off on mobile devices we need to expose both PVRTC and ATC, the latter being made possible by Diego's email. Thanks, Benoit On 12-09-07 12:15 PM, Wilson, Diego wrote: > > Hello, > > > > The AMD_compressed_ATC_texture format is documented here: > > > > http://www.khronos.org/registry/gles/extensions/AMD/AMD_compressed_ATC_texture.txt > > > > It was brought to my attention that this compressed texture format is > a good candidate for exposing as a WebGL extension. And that it is > only missing one piece of information: the buffer size computation. > Below is that information that has been verified both with experts in > the format and empirically. > > > > Compressed texture images stored using the ATC compressed image > formats are represented as a collection of 4x4 texel blocks. > > > > The size in bytes of a compressed ATC_RGB_AMD image is: > > > > ((width_in_texels+3)/4) * ((height_in_texels+3)/4) * 8 > > > > The size in bytes of a compressed ATC_RGBA_EXPLICIT_ALPHA_AMD or > ATC_RGBA_INTERPOLATED_ALPHA_AMD image is: > > > > ((width_in_texels+3)/4) * ((height_in_texels+3)/4) * 16 > > > > I'm currently working to include this in public documentation as well. > > > > Regards, > > > > _________________ > > Diego Wilson > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Sep 7 09:22:36 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Fri, 7 Sep 2012 18:22:36 +0200 Subject: [Public WebGL] ATC texture size computation In-Reply-To: <033CAC3586C48445A9740E2C20EF9D4F19B8E273@NASANEXD01C.na.qualcomm.com> References: <033CAC3586C48445A9740E2C20EF9D4F19B8E273@NASANEXD01C.na.qualcomm.com> Message-ID: Quoting from the specification: "The details of these formats is not disclosed, so refer to AMD's Compressonator tool in order to encode your textures offline: http://ati.amd.com/developer/compressonator.html" This is not acceptable for any standard intended for the web. The format has to be documented and is required to be independently implementable. On Fri, Sep 7, 2012 at 6:15 PM, Wilson, Diego wrote: > Hello,**** > > ** ** > > The AMD_compressed_ATC_texture format is documented here:**** > > ** ** > > > http://www.khronos.org/registry/gles/extensions/AMD/AMD_compressed_ATC_texture.txt > **** > > ** ** > > It was brought to my attention that this compressed texture format is a > good candidate for exposing as a WebGL extension. And that it is only > missing one piece of information: the buffer size computation. Below is > that information that has been verified both with experts in the format and > empirically.**** > > ** ** > > Compressed texture images stored using the ATC compressed image formats > are represented as a collection of 4x4 texel blocks.**** > > ** ** > > The size in bytes of a compressed ATC_RGB_AMD image is:**** > > ** ** > > ((width_in_texels+3)/4) * ((height_in_texels+3)/4) * 8**** > > ** ** > > The size in bytes of a compressed ATC_RGBA_EXPLICIT_ALPHA_AMD or > ATC_RGBA_INTERPOLATED_ALPHA_AMD image is:**** > > ** ** > > ((width_in_texels+3)/4) * ((height_in_texels+3)/4) * 16 **** > > ** ** > > I?m currently working to include this in public documentation as well.**** > > ** ** > > Regards,**** > > ** ** > > _________________**** > > Diego Wilson**** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Sep 7 09:25:30 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Fri, 7 Sep 2012 18:25:30 +0200 Subject: [Public WebGL] ATC texture size computation In-Reply-To: References: <033CAC3586C48445A9740E2C20EF9D4F19B8E273@NASANEXD01C.na.qualcomm.com> Message-ID: Another issue with this is that about 99% of webgl use is desktops, and only 50% of those (optimistically, or according to http://feedback.wildfiregames.com/report/opengl/) support ATC compressed textures (unsurprisingly only AMDs, ha-ha). I'm unsure of how wise it would be to introduce something that isn't working for half of installations. Afaik extensions have been shot down here for less. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Sep 7 09:34:28 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Fri, 7 Sep 2012 18:34:28 +0200 Subject: [Public WebGL] ATC texture size computation In-Reply-To: <504A1F78.9020007@mozilla.com> References: <033CAC3586C48445A9740E2C20EF9D4F19B8E273@NASANEXD01C.na.qualcomm.com> <504A1F78.9020007@mozilla.com> Message-ID: On Fri, Sep 7, 2012 at 6:23 PM, Benoit Jacob wrote: > Many thanks! > > I confirm that I'm very interested in exposing ATC as a WebGL extension, > and the information below was the only missing piece. I will write a spec > proposal very soon. > So you're just gonna gloss over the fact that this here is a piece of technology that'll break on half of desktops. Alright, nevermind. But how're you gonna gloss over the fact that the format is not specified, making it impossible to convert an to a texture or a texture back to bytes or an ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Fri Sep 7 09:37:55 2012 From: bja...@ (Benoit Jacob) Date: Fri, 07 Sep 2012 12:37:55 -0400 Subject: [Public WebGL] ATC texture size computation In-Reply-To: References: <033CAC3586C48445A9740E2C20EF9D4F19B8E273@NASANEXD01C.na.qualcomm.com> Message-ID: <504A22E3.9040104@mozilla.com> On 12-09-07 12:22 PM, Florian B?sch wrote: > Quoting from the specification: > > "The details of these formats is not disclosed, so refer to AMD's > Compressonator tool in order to encode your textures offline: > http://ati.amd.com/developer/compressonator.html" > This is not acceptable for any standard intended for the web. The > format has to be documented and is required to be independently > implementable. Speaking only for Mozilla here (we have had some internal concertation), we are willing to make a pragmatic compromise. The choice is either do this, or leave the mobile gaming market to other platforms which already expose these compressed texture formats (indeed, which expose raw OpenGL ES with extensions). I don't believe that the Web would be better off by abandoning this market. There was a very real problem though that was indeed a non-starter: the buffer size formula was not even documented. That's what Diego's email fixed. I can live with the rest. Benoit > > On Fri, Sep 7, 2012 at 6:15 PM, Wilson, Diego > wrote: > > Hello, > > > > The AMD_compressed_ATC_texture format is documented here: > > > > http://www.khronos.org/registry/gles/extensions/AMD/AMD_compressed_ATC_texture.txt > > > > It was brought to my attention that this compressed texture format > is a good candidate for exposing as a WebGL extension. And that it > is only missing one piece of information: the buffer size > computation. Below is that information that has been verified both > with experts in the format and empirically. > > > > Compressed texture images stored using the ATC compressed image > formats are represented as a collection of 4x4 texel blocks. > > > > The size in bytes of a compressed ATC_RGB_AMD image is: > > > > ((width_in_texels+3)/4) * ((height_in_texels+3)/4) * 8 > > > > The size in bytes of a compressed ATC_RGBA_EXPLICIT_ALPHA_AMD or > ATC_RGBA_INTERPOLATED_ALPHA_AMD image is: > > > > ((width_in_texels+3)/4) * ((height_in_texels+3)/4) * 16 > > > > I?m currently working to include this in public documentation as well. > > > > Regards, > > > > _________________ > > Diego Wilson > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Fri Sep 7 09:41:05 2012 From: bja...@ (Benoit Jacob) Date: Fri, 07 Sep 2012 12:41:05 -0400 Subject: [Public WebGL] ATC texture size computation In-Reply-To: References: <033CAC3586C48445A9740E2C20EF9D4F19B8E273@NASANEXD01C.na.qualcomm.com> Message-ID: <504A23A1.5050601@mozilla.com> On 12-09-07 12:25 PM, Florian B?sch wrote: > Another issue with this is that about 99% of webgl use is desktops, > and only 50% of those (optimistically, or according > to http://feedback.wildfiregames.com/report/opengl/) support ATC > compressed textures (unsurprisingly only AMDs, ha-ha). The idea is that games should ship S3TC textures to desktop clients and ATC/PVRTC textures to mobile clients. I realize that it's uncomfortable to rely on app developers to get this right, but I don't see an alternative. We already know that compressed textures are a requirement to be a serious games platform, that we want to support both desktop and mobile, and that there isn't a universally supported compressed texture format yet. So we have to make a compromise here. Benoit > > I'm unsure of how wise it would be to introduce something that isn't > working for half of installations. Afaik extensions have been shot > down here for less. ----------------------------------------------------------- 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 baj...@ Fri Sep 7 09:58:08 2012 From: baj...@ (Brandon Jones) Date: Fri, 7 Sep 2012 09:58:08 -0700 Subject: [Public WebGL] ATC texture size computation In-Reply-To: References: <033CAC3586C48445A9740E2C20EF9D4F19B8E273@NASANEXD01C.na.qualcomm.com> <504A1F78.9020007@mozilla.com> Message-ID: On Fri, Sep 7, 2012 at 9:34 AM, Florian B?sch wrote: > > But how're you gonna gloss over the fact that the format is not specified, > making it impossible to convert an to a texture or a texture back to > bytes or an ? > I'll agree that it's a less-than-ideal situation, but I'm not sure that there's a lot of utility in ensure textures can always be represented in tags. The currently implemented S3TC textures must be manually unpacked and rendered to a canvas or data url before they can be shown in the DOM, but I've only once seen anybody bother. As long as the hardware can unpack it properly I have a hard time seeing why we shouldn't consider exposing it to give us wider hardware coverage. We don't have a whole lot of alternatives if we want compressed texture support, sadly. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rko...@ Fri Sep 7 09:58:22 2012 From: rko...@ (Kornmann, Ralf) Date: Fri, 7 Sep 2012 17:58:22 +0100 Subject: [Public WebGL] ATC texture size computation In-Reply-To: <504A23A1.5050601@mozilla.com> References: <033CAC3586C48445A9740E2C20EF9D4F19B8E273@NASANEXD01C.na.qualcomm.com> ,<504A23A1.5050601@mozilla.com> Message-ID: <9B3BEF16CBC82A45900B3F159DF91596017618DB3797@EU-MAIL-1-1.rws.ad.ea.com> Please go for it. Memory is one of our biggest problem when it comes to mobile. While many of these devices have larger display resolution than most PCs the overall memory is in general lower the a desktop GPU has exclusive by it's own. So missing texture compression is one of the features that forces us to go native on mobile. Texture compression on mobile is already a mess for native app developers. If WebGL would wait until it is sorted out on the OpenGL ES side it would never catch up. It might take years until all mobile devices support one common general useable texture compression format. Ralf ________________________________________ Von: owner-public_webgl...@ [owner-public_webgl...@] im Auftrag von Benoit Jacob [bjacob...@] Gesendet: Freitag, 7. September 2012 18:41 An: public_webgl...@ Betreff: Re: [Public WebGL] ATC texture size computation On 12-09-07 12:25 PM, Florian B?sch wrote: > Another issue with this is that about 99% of webgl use is desktops, > and only 50% of those (optimistically, or according > to http://feedback.wildfiregames.com/report/opengl/) support ATC > compressed textures (unsurprisingly only AMDs, ha-ha). The idea is that games should ship S3TC textures to desktop clients and ATC/PVRTC textures to mobile clients. I realize that it's uncomfortable to rely on app developers to get this right, but I don't see an alternative. We already know that compressed textures are a requirement to be a serious games platform, that we want to support both desktop and mobile, and that there isn't a universally supported compressed texture format yet. So we have to make a compromise here. Benoit > > I'm unsure of how wise it would be to introduce something that isn't > working for half of installations. Afaik extensions have been shot > down here for less. ----------------------------------------------------------- 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...@ Fri Sep 7 10:06:54 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Fri, 7 Sep 2012 19:06:54 +0200 Subject: [Public WebGL] ATC texture size computation In-Reply-To: References: <033CAC3586C48445A9740E2C20EF9D4F19B8E273@NASANEXD01C.na.qualcomm.com> <504A1F78.9020007@mozilla.com> Message-ID: Here's the problem in a nutshell: You expect application developers to "sort it out". Yet we'll only know how to "sort it out" once we've asked the webgl context for its supported formats. Requiring us to to cross-transpile textures in a zigillion different formats and dynamically branching out after context creation and engage an XHR2 to binarily load them. There's several things wrong with that: 1) it makes it really difficult to use 2) While I'm happy to rely on XHR2 binary loading, there might be people who aren't, besides, I think mobile support for XHR2 isn't overwhelming. 3) Unlike