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 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/
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.
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.
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.