Texture Compression and Quality Metrics (OpenGL4.3 thread spinoff)

brunogm

Newcomer
WE can expect PS4 and Durango to have hardware customization to fully support OpenGL 4.3 including the ETC2 and ASTC texture compression formats?

Sony allegedly included a volatile bit in the L2 caches to improve compute workload.
By including ASTC they future proof and increase bandwith utilization down the road. Anyone has info about this?
 
ASTC is simply a significantly more efficient texture compression format than S3TC/DXTC, regardless of API. That said, I believe both ETC2 and ASTC are royalty free only for use in Khronos APIs.
 
WE can expect PS4 and Durango to have hardware customization to fully support OpenGL 4.3 including the ETC2 and ASTC texture compression formats?
In short, no. ASTC was finalized well after GCN was; none of the PC GCN parts support it, and I don't expect the PS4 will either. I believe it's the same story on ETC; GCN parts implement ETC1 in software, and don't support ETC2 at all.

What I would expect is that PS4 will use appropriately licensed versions of the D3D texture compression formats, which the hardware already supports. For standard RGB texture maps this would mean using BC7 (does this have an OpenGL name?), the far superior successor to DXTC in D3D11.
 
Last edited by a moderator:
ASTC is simply a significantly more efficient texture compression format than S3TC/DXTC, regardless of API.
It's better at low bit rates, but BC7 is similar at 8bpp (RGB/RGBA) - i.e. very high quality. It'll be good to have both available in the long run of course.
 
So BPTC will be THE format used in consoles, while ETC2 is used by tablets in the next year ?

Even with fast BPTC compressors like http://gamma.cs.unc.edu/FasTC/
considerable production effort is wasted in such texture compression fragmentation.

http://www.anandtech.com/show/6134/...s-30-opengl-43-astc-texture-compression-clu/4 shows that BPTC is only 3:1 for a RGB 24bit texture, in such case, bandwith limitation will have more impact than a little customization in the Texture Units.

AMD will have to support these new formats anyway bring then now for both consoles and the ecosystem can benefit of a single all-around, future-proof format at a lower cost.
 
AMD co-authored ASTC, it's likely they will support it. Now, how again could we get this as option into DX11? Thank you MS.
PVRTC2 and ETC2 will stay relative niche, as they are late. Both duck tape S3TC type interpolation onto PVRTC1 and ETC1. ASTC is just so much more than that, +greyscale, +HDR.
 
So BPTC will be THE format used in consoles, while ETC2 is used by tablets in the next year ?
We won't know for sure until the PS4 ships and developers can talk about it more freely, but yes, that's my expectation. GCN doesn't support ASTC so I see no reason for a GCN APU to support it. The lead time to get a feature like that in silicon is very long (in fact I'd expect to see it in an ARM GPU before anything else due to the shorter lead times for SoC GPUs).
 
We won't know for sure until the PS4 ships and developers can talk about it more freely, but yes, that's my expectation. GCN doesn't support ASTC so I see no reason for a GCN APU to support it. The lead time to get a feature like that in silicon is very long (in fact I'd expect to see it in an ARM GPU before anything else due to the shorter lead times for SoC GPUs).

Given that Mali T-604 already support ASTC in hardware and is already in the market. One can only hope that AMD will further customize GCN besides the "volatile compute" bit in the L2 cache.
 
ASTC is simply a significantly more efficient texture compression format than S3TC/DXTC, regardless of API.
That's not true. BC7 beats ASTC in ARM's own comparison, and BC6H ties with ASTC in HDR content when identical bit rates are used. (http://www.youtube.com/watch?feature=player_detailpage&v=9oerz8SR9x8 from 13:38). BC5 is also very hard to beat in normal map compression (*). The new DXTC formats are very good for high quality (high bit rate) content. ASTC support in DirectX would of course be a nice bonus, since it also supports very low bit rates. Low bit rate support would be useful for many other use cases than storing color data (especially with 3d textures).

(*). Assuming you use 16 bit source normals and a normal map compressor that calculates error metric from decoded renormalized data (Crytek has a paper of this). BC5 decompresses to two 16 bit channels on any recent (DX10/11) GPU. The quality on smooth gradients is comparable to 10.5 bit per channel uncompressed normal (in best case).
 
Define "efficient"

Bitrate needed to reach a particular quality level? or are there other efficiency aspects that you would like to highlight? (encode time? HW area/power cost? memory bandwidth? compressibility with things like Rich Geldreich's "crunch" tool?)

In our testing, when comparing ASTC to "old" formats like PVRTC1, ETC1, S3TC and BC5 (but not BC6/7), ASTC has typically been able to achieve equal quality at about 2/3 of the bitrate, as measured by PSNR (i.e. ASTC 1.28bit = PVRTC1 2bit, ASTC 2.67bit = DXT1 4bit, ASTC 5.12bit = BC5 8bit). For the BC5 to ASTC comparison, this assumes 2-component normal maps with a reconstructed-normal-angular-error metric like the one sebbbi mentioned; for PVRTC1/S3TC/ETC1 to ASTC this assumes RGB textures with a flat error metric.

As for BC7, what we've seen is that ASTC 8bit doesn't beat BC7 on RGB textures but usually does beat it on things like normal maps and RGBA textures. As such, BC7 could be said to be "more efficient" for RGB textures in cases where the quality level actually required is legitimately higher than what e.g. ASTC 6.4bit can provide but NOT higher than what BC7 can provide - which seems to be rather uncommon.
 
As for BC7, what we've seen is that ASTC 8bit doesn't beat BC7 on RGB textures but usually does beat it on things like normal maps and RGBA textures.
Which BC7 compressor were you using? I ask because the ones available publicly right now are mostly pretty terrible. I would expect BC7 to do at least as well as ASTC at similar bit-rates. Of course these are "very high" bit rates on the overall scale of things, but certainly on desktop/console-class hardware it's clear that this is desirable for a lot of textures.
 
My understanding was that this one is supposed to be OK on quality (albeit quite bad on encode time) - are there any better-quality BC7 encoders around?
Publicly that's probably one of the better ones, but as you note, very brute force and slow. BC7 has a number of different compression modes that can be picked per-tile, so depending on how the encoder works, it may or may not being a good job of optimizing for stuff like uncorrelated alpha channels, normal maps, etc. even though the format can handle them reasonably well. Still, from what I've seen I'd probably call RGB and RGBA with 4x4 tiles a wash between BC7 and ASTC... i.e. both very high quality. The big advantage of ASTC is lower bit rates where it definitely looks better than BC1, etc.
 
Back
Top