It is certainly possible (and indeed pretty much a must) there's some cache dedicated to it in the ROP, but I was just pointing out it wouldn't make sense to store all of it on chip at once (as did older chips), as the max cache size you'd need is simply too big. But we don't know much about how ROP cache works in general (tile data + metadata), and I have no idea how this works for newer chips (which need to access this from TMUs, so probably indeed through L2). But certainly it could be stuffed into ordinary cache lines (one cache line, no matter where, can store information about quite a few tiles of course (with those mentioned 2 bits per tile, for a rgba8 format that's only 1/1024 of the data you'd need for the uncompressed pixels for this metadata, so unless you have a really terrible case not achieving any compression it's not a big deal).
You're right I forgot about morton ordering... so that would be twice the number of tiles per byte size cache line. But I was told in another thread https://forum.beyond3d.com/threads/gpu-cache-sizes-and-architectures.56731/ that at least on GCN that the CB and DB caches don't go through the L2... did it change for tonga/GCN+framebuffercompression?
Why would TMU's need access to this? If you mean render target to texture doesn't the driver resolve the compressed RT first manually? At least thats what I assumed.
Yes, fixed-length encoding - probably pixel differences in a 8x8 block.
Inefficient for what exactly - perceived quality, compression ratio, or decoding complexity?
I don't know what AMD implemented, but a resolve pass required on colour render targets might often actually increase total memory bandwidth requirements.
We should know shortly from other AIB packaging.
Thanks for your reply!
Pardon my imprecise language - I meant memory bandwidth-wise, as writing a few bytes spread out here and there is quite wasteful.
I know that upgrade demon intimately. It starts haunting me strongly every two years or so!
