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.