[OpenGL] GL_ARB_ES3_compatibility (and GL 4.3+) imply that an online ETC2 compressor is required.

[imirkin]

GL_ARB_ES3_compatibility adds the various ETC2 formats to table 3.20 of the GL 4.2 compat specification. The specification talks about it being legal to pass an internal format to glTex(Sub)Image for any of the formats listed in 3.20, which means that the image needs to be storable in the compressed format. The GL_ARB_ES3_compatibility spec text does say, when introducing the new tokens, that they should only apply to glCompressedTexImage. However no such mention exists in the GL 4.3+ text. From the GL 4.3 core spec:

If the internal format of the texture image being modified is one of the specific compressed formats described in table 8.14, the texture is stored using the corresponding compressed texture image encoding (see appendix C)

where table 8.14 is the list of compressed formats, including ETC2.

Now, my guess is that it was never intended to require implementations to provide this. However it'd be nice to get that clarified one way or the other. S3TC, RGTC, and BPTC all require online compression. I believe ASTC does not (let's hope), although I haven't checked the text carefully.

[pdaniell-nv]

OpenGL ES doesn't require online compression but traditionally OpenGL does. The intent in adding these new formats to OpenGL was to treat them like other OpenGL compressed textures. The NVIDIA implementation does online compression for that reason. However, I'm open to the idea of not requiring online compression for these if other vendors don't want to support that.

[imirkin]

FWIW Mesa does not currently implement online compression for ETC2. I'm a bit curious what AMD and Intel do on Windows. Are you saying that NVIDIA supports even ASTC compression on desktop GL?

It should be noted that there are no conformance tests for this in CTS, as (my understanding is that) Intel passed GL 4.5 conformance with Mesa/i965.

[ianromanick]

Desktop OpenGL has traditionally required on-line compression, and I think even Pat Brown (who wrote the original GL_ARB_texture_compression spec) believes that was a mistake. Mesa has supported GL_ARB_ES3_compatibility for a really long time without on-line compression without any problems of which I'm aware. It seems unlikely that any application depends on this feature.

I'd swear that this issue came up when we were drafting GL_ARB_ES3_compatibility, but I couldn't find anything in what remains of my notes.

[pdaniell-nv]

We discussed this in the OpenGL work group meeting on Friday and agreed to not require online compression for these formats.

To resolve this I propose we add a new column to table 8.14 which indicates whether the format is allowed to be used with Tex{Sub}Image and CopyTex{Sub}Image. And add to the error sections of those commands to indicate that INVALID_OPERATION is generated if the function is called with an internalformat with a format that doesn't support these operations from table 8.14. For the OpenGL 4.6 spec, only EAC/ETC2 should not support Tex{Sub}Image and CopyTex{Sub}Image.

@oddhack Is this something you can take care of? Let me know if you need more details.

[pdaniell-nv]

@oddhack Did this issue get addressed in the latest API spec update?

[oddhack]

It did not. On the list for the next update (which, I'm thinking of trying to do one every month or so, if there's enough queued up to justify it - we waited a long time for the current updates).

[pdaniell-nv]

@oddhack Did this issue get addressed in the latest API spec update?

[oddhack]

I have queued up some language for the next spec update, which adds a "Copyable" column to the compressed format table marked YES for everything except EAC/ETC2 formats, then adds errors for TexImage* and CopyTexImage2D if internalformat is one of the formats in that table marked with NO. Because of the way the SubImage language is written, it validates the internal format of the target texture in the same way as the regular TexImage commands do for the explicit internalformat argument. So, I think this will accomplish the end.

N.b. the texture image section is a really ugly beast at this point, with errors scattered all over the place due to the immense size of the section and the many, many commands which have similar but not identical errors.

[oddhack]

Fixed in the 2019-10-22 spec updates.