On top of that, I found this tip. glGetInternalformativ with GL_FRAGMENT_TEXTURE returns GL_FULL_SUPPORT instead of GL_CAVEAT_SUPPORT. Like I said, I know for a fact that there is no hardware support for ETC2/EAC. 
Oh! Also. glTexImage2D returns GL_INVALID_VALUE if I try to use any of the ETC2/EAC formats as the internalformat.
Yay, I love you AMD.
Compressing to ETC2 only to convert to uncompressed means you save no space in graphics memory and take an unnecessary hit in visual quality. Re-compressing to another compressed format means you loose even more quality.
Well, basically what I'd like to do is compress all of my assets using a lossy codec similar to JPEG for distribution. During installation I would like to find out what texture formats are actually supported by the hardware (the ones that will give the best performance and quality) and then do a one time conversion
If you do like the sound of JPEG->DXT, for small on-disc files and native-GPU-decompression, then check out the crunch library.
It achieves the same goal, except instead of using JPEG, they use their own format which supports fast transcoding to DXT. This means that you lose less information overall (compared to original->JPEG->lossy->DXT->more lossy) and your conversion to DXT is much faster.
It occurs to me that these results are going to depend a lot of which driver version you're using. You so say "latest drivers" in your original post, but are these the latest release drivers or the latest beta drivers?
I ask because you're using GL 4.3 features (such as ARB_internalformat_query2) but AMD don't have a full GL 4.3 driver out of beta for your hardware yet. So (1) you shouln't expect ARB_internalformat_query2 to give you meaningful results, and (2) if you're using a beta driver with GL 4.3 support, you should expect bugs (it is beta, after all).
Compressing to ETC2 only to convert to uncompressed means you save no space in graphics memory and take an unnecessary hit in visual quality. Re-compressing to another compressed format means you loose even more quality.
Well, basically what I'd like to do is compress all of my assets using a lossy codec similar to JPEG for distribution. During installation I would like to find out what texture formats are actually supported by the hardware (the ones that will give the best performance and quality) and then do a one time conversion
Erm... you've just gone lossy -> lossy with your JPEG -> "whatever" conversion, frankly an extra decompression step isn't going to damage your quality anyway as you stuffed it with the first conversion to JPEG.
In short; your idea here combines basically the worst of everything. There is a reason the data path tends to be 'non-lossy' (TGA, PNG, TIFF) to lossy (BCn/DXTn)...
I will partially disagree on this:
the quality loss of DXT is a typically bit greater than the usual quality loss of JPEG (at higher quality settings, eg, 80% - 90%), so the added quality loss isn't really likely to be "actually noticeable" (vs going straight from PNG or similar).
the main reason to prefer PNG for distribution would mostly be that it natively supports an alpha-channel, rather than needing to have it added on either via extensions/hacks (the route I went), or as a separate alpha-image.
a downside I think of using RGB based formats for distribution is that the conversion speed is lower and using a fast conversion strategy generally tends to result in lower-quality compressed textures (more so with BC7, which can look "pretty good" with offline conversion, but where quick-and-dirty conversion tends to produce results "not significantly better than DXT").
this is mostly because a lot of BC7's more advanced features aren't really usable by a real-time encoder via any algos I am currently aware of, however, with a quick/dirty encoder, it is still possible to benefit from an increased color depth over DXTn.
this issue is partly why some amount of effort in my case is (still) going into specialized image formats and video-codecs, with the goal of basically being to do a little bit more work on the encoder side to produce higher-quality final output, while also being able to offer high-speed decompression (direct to DXTn / BCn).
though, at a downside that, at-least for video, the current size/quality falls a bit short of "real" video codecs (ex: MPEG-4, ...), albeit it is still fairly effective for animated textures.
decided to leave out a lot of the specifics, but it basically recently this means trying to design/implement what is looking like a "scary beast" of a codec (*) in the vague hope that it will be able to pull off around 0.05 bpp and still have 300 Mpix/sec decompression speeds, vs my existing codec which pulls off an "amazing" (0.25-0.5 bpp and ~ 300-400 Mpix/sec, though with rather lackluster image quality at said 0.25 bpp).
*: the goal still being to be able to quickly decode to DXTn / BCn. (previously, it was termed as being a VQ codec, but I don't really know if it counts, as it is more of a "hybrid").
Erm... you've just gone lossy -> lossy with your JPEG -> "whatever" conversion, frankly an extra decompression step isn't going to damage your quality anyway as you stuffed it with the first conversion to JPEG.
In short; your idea here combines basically the worst of everything. There is a reason the data path tends to be 'non-lossy' (TGA, PNG, TIFF) to lossy (BCn/DXTn)...
Well, I didn't say JPEG, I said something like JPEG. As far as lossy codecs go, JPEG is horrible, and you can do a lot better than it these days. The idea was to use a better lossy codec with relatively low compression ratios to achieve near perceptually lossless encoding, in order to minimize download size. Then, during installation, re-compress to the most optimal compressed texture format supported by the hardware.
It occurs to me that these results are going to depend a lot of which driver version you're using. You so say "latest drivers" in your original post, but are these the latest release drivers or the latest beta drivers?
I ask because you're using GL 4.3 features (such as ARB_internalformat_query2) but AMD don't have a full GL 4.3 driver out of beta for your hardware yet. So (1) you shouln't expect ARB_internalformat_query2 to give you meaningful results, and (2) if you're using a beta driver with GL 4.3 support, you should expect bugs (it is beta, after all).
Yes, I'm using the 4.3 beta drivers. That's really no excuse though. ARB_internalformat_query2 was a supported extension before the 4.3 beta, and most of the issues I am having have nothing at all to do with 4.3 related features. If they don't work in this driver, I would be very surprised if they worked in the release drivers. That being said, I realize now that a new version of the beta drivers became available not long ago, so I will give that a try and see if it fixes anything (not going to hold my breath.) Edit: Yep, nothing has changed.
