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