Archives Discussions

[chris_f]

I've ran into a lot of issues and frankly I see no point in creating a separate discussion for all of them. They are all somewhat related anyway. I am using the latest 13.11 Beta (12/3/2013) driver for Windows 7 64-bit with a 4.3 core profile debug context. My graphics card is a HD 5850.

1. If any of the BPTC compressed texture enums are used in conjunction with glTexStorage functions, it will create a BPTC texture but subsequent attempts to fill it using an uncompressed source with the glTexSubImage functions will result in a corrupt texture (looks like colorful noise to me). No errors are picked up by glGetError or KHR_debug. Perhaps the driver is simply copying the uncompressed data into the compressed texture verbatim?
2. If a sRGB type is used as the internalformat with glTexStorage functions, the texture will appear overexposed when sampled in a fragment shader, as if the implementation is treating it as linear data during sampling. This does not happen if a sRGB type is used with the glTexImage functions. This also affects compressed sRGB types like GL_COMPRESSED_SRGB_S3TC_DXT1_EXT. No errors are picked up by glGetError or KHR_debug.
3. If you use generic compressed texture format enum (e.g GL_COMPRESSED_SRGB_ALPHA) as the internalformat for a call to a glTexImage function and then query the texture afterwards for its internalformat, you will get back the generic compressed format instead of a specific compressed format as is called for by the spec.
4. If you use glGetInternalformativ to query GL_FRAGMENT_TEXTURE for one of the ETC2/EAC texture formats, you will get back GL_FULL_SUPPORT instead of GL_CAVEAT_SUPPORT. I know for a fact my GPU does not have hardware support for ETC2/EAC and reading the GL 4.3 spec makes it seem pretty clear that this should be considered a caveat.
5. If any of the ETC2/EAC compressed texture enums are used as the internalformat to a glTexImage function, an error of GL_INVALID_VALUE is generated. According to the GL 4.3 spec, the ETC2/EAC formats should be compatible with glTexImage.

[cgrant78]

1. If the texture is created compress, why would you try to fill it with compressed data ? afaik glTexSubImage* does not do format conversion. The SubImage functions are use to update portion of the already created texture.

2. What do you mean treating it as linear during sampling ? Do you mean the return result or the its treating the content of the texture as linear ? Are you gamma correcting the output being written by your fragment shader? Or are you using sRGB frame buffers?

wrt to 4 and 5, in #4 you said your are certain your GPU does not support ETC2/EAC textures in HW, so I don't understand why you would expect creating an ETC2/EAC texture to not give you an error/

[chris_f]

cgrant78@netzero.com wrote:

1. If the texture is created compress, why would you try to fill it with compressed data ? afaik glTexSubImage* does not do format conversion. The SubImage functions are use to update portion of the already created texture.

Would you like to find for me where at in the GL spec it says that glTexSubImage doesn't work with compressed textures? Supposing that were even the case, then glTexSubImage should generate an error like GL_INVALID_OPERATION.

cgrant78@netzero.com wrote:

2. What do you mean treating it as linear during sampling ? Do you mean the return result or the its treating the content of the texture as linear ? Are you gamma correcting the output being written by your fragment shader? Or are you using sRGB frame buffers?

Whether or not the framebuffer is sRGB is irrelevant. The source image data is ordinary 8-bit sRGB. Using a format like GL_SRGB8_ALPHA8 simply tells the implementation that it needs to perform a sRGB -> linear RGB conversion every time it samples from the texture. This is completely transparent to you and you end up with linear values in your fragment shader. The problem is (it might appear) for some reason, when you create a texture with glTexStorage* this conversion is not taking place, as if glTexStorage* has somehow not properly flagged the texture as being sRGB. As I said, this problem only exists with glTexStorage*, not glTexImage*

cgrant78@netzero.com wrote:

wrt to 4 and 5, in #4 you said your are certain your GPU does not support ETC2/EAC textures in HW, so I don't understand why you would expect creating an ETC2/EAC texture to not give you an error/

That's not how OpenGL works. Support for ETC2/EAC is required for an OpenGL 4.3 implementation. That means if you don't have hardware support, you need to include support though some alternative means, like software emulation, thus the caveat.

[cgrant78]

wrt. to 1. I did not say glTexSubImage doesn't work with compressed textures. My statement was that it does not do format conversion, i.e you cannot use glTexSubImage to upload uncompressed data to a compressed texture and assume that the driver will do the conversion. Afaik there is nothing in the specification in regards to that behavior. From the spec pg section 8.6( Alternative Texture Image Specification) pg 194

Texture images with compressed internal formats may be stored in such a way

that it is not possible to modify an image with subimage commands without having

to decompress and recompress the texture image. Even if the image were modified

in this manner, it may not be possible to preserve the contents of some of

the texels outside the region being modified. To avoid these complications, the

GL does not support arbitrary modifications to texture images with compressed

internal formats.

My understanding from that entire section on texture image specification is that what you are trying to do is not allowed.

The data will probably get upload, but will be garbage since its expecting the data to be formatted according to the compression algorithm being used. I'm currently using glCompressedTexSubImage* to upload compressed data to a texture previously created with a compressed texture format in my case GL_COMPRESSED_RGBA_S3TC_DXT1_EXT and GL_COMPRESSED_RGBA_S3TC_DXT5_EXT.

wrt to 2 the questions posed was in order to get clarification, seeing now you actually explain what you are seeing we can disregards those

wrt to 4 & 5, how does OpenGL work ? Maybe in this case of ETC2/EAC texture support / GL 4.3, but if the driver does not provide support for a GL feature then it cannot be utilized by you application. That is the whole purpose of the extension mechanism, to query which features are supported by the driver implementation. If the driver implementer choose not to implement feature x in software and there is no hw support for the feature, then it stands to reason that the feature will be unavailable for usage.

If the OpenGL specification was the strictly adhere to my driver implementers, there wouldn't be that much differing behavior between implementations. So your GL app should behave the same on all vendor platform, sadly that is not the reality of the situation, not in the desktop space, and even its even worse in the mobile space.

[chris_f]

You quoted page 194, but you should have read further. It goes on to say:

If the internal format of the texture image being modified is one of the spe-

cific compressed formats described in table 8.14, the texture is stored using the

corresponding compressed texture image encoding (see appendix C). Since such

images are easily edited along 4 × 4 texel boundaries, the limitations on subim-

age location and size are relaxed for TexSubImage2D, TexSubImage3D, Copy-

TexSubImage2D, and CopyTexSubImage3D.

There is no reason to think that under any circumstance TexSubImage* would be expecting compressed texture data, that is why CompressedTexSubImage* exists. Further, if TexSubImage* expected compressed texture data when used on a compressed texture, that would not explain why I can use TexSubImage2D with uncompressed data to fill a DXT1 texture.

I'm not sure you are understanding me when I say that ETC2/EAC is required. It's not up for debate. ETC2 and EAC are part of the core functionality of OpenGL 4.3, extensions and querying mechanisms have nothing to do with it. I'm using the OpenGL 4.3 driver and a 4.3 core profile context, therefore it must support these texture formats.