GPU硬件架构 - 压缩（1）

这篇文章要讨论的不是纹理压缩（比如BC， ASTC这些压缩格式）；而是frame buffer的压缩，这一部分没有标准的格式，基本都是由各家GPU公司自己开发的算法；所以这篇文章讨论的基本是nVidia和AMD公开发布的关于这一部分的专利。
压缩的目的是为了节省带宽，当需要用到这一块framebuffer的时候，首先会读取一些压缩信息和压缩的数据，压缩信息是为了告诉GPU硬件如何对压缩数据进行解压缩，解压缩后的数据会临时存放在cache里面，当从cache被evict出去的时候，会再次压缩，并将压缩的数据写回到global memory里面。需要注意的是在渲染一个场景的时候同一块区域可能会被压缩，解压缩若干次。
需要注意的是不管是深度的压缩还是color的压缩，压缩方式都必须是无损的，也就是说没有任何信息丢失掉；这就跟很多图像压缩的方式形成了对比，比如JPEG通常情况下是一个有损的压缩（当然JPEG也有无损的压缩模式），这就意味着在图片压缩的过程信息可能会丢失；所以跟实际的数据相比会有一些区别，这种区别在depth buffer和color buffer的处理过程中是不能容忍的。
对于下面讨论的压缩算法，都有一个预设条件，就是压缩和解压缩都是在tile based（tile的意思是如果分辨率是$S_w\ast S_h$, tile的大小是$w\ast h$, 那么整个屏幕就会有 $S_w/w$ $\ast$ $S_h/h$个tile）的基础上来进行的。一个压缩的系统的基本部件如下图所示；

在这一架构中有两个核心的模块：cache和control block；由于压缩和解压缩是per tile进行的，同时访问临近pixels的情况在渲染里面是常见的，所以需要把整个tile都缓存到cache里面去。control block得到read和write requests，判断所需的数据是否在cache内。当读取的时候，要通过decompression unit将tile的压缩数据进行解压缩；当需要从cache里面写回到global memory的时候需要通过compression unit来进行压缩。而tile table用来保存一些meta数据；比如有些时候会不需要压缩，那么可以用1bit来表示，0表示不压缩，1表示压缩；也可以用2bit来表示，2’b00 表示没有压缩，2’b01表示25%的压缩，2’b10表示50%的压缩，而2’b11表示block被cleared。最后一种模式被称为fast clear。所以如果为了clear buffer，只需要将tile table的对应bit设置为2’b11。如果一个读的请求，首先检测tile table里面的对应值，如果是2’b11，就完全不需要向global memory去发送读请求。
一个例子，特定图块中的特定像素需要访问，并发出读取请求，该问题到达control block。control block确定该像素的图块是否在缓存中，如果在，则立即将数据返回给需求方。如果不是，则从缓存中evict一些块，并且需要将evict的块数据送回global memory。首先尝试压缩该图块的内容, 这发生在压缩单元中。比如说，该块可以压缩到25%，即256个字节仅使用64个字节进行编码。然后，这64个字节被发送到外部存储器，这意味着该tile的其他192个字节未被使用。tile table里面的信息同时被更新（在本例中为01）。
根据架构的不同，可以并行读取新的block，也可以在被驱逐的block被写回内存后读取。从外部存储器读取时，首先检查tile table中的tile meta信息，以检查与该block关联的压缩模式。假设当前图块被压缩到50%。这意味着从外部存储器读取128个字节，然后将这些字节解压缩并存储在缓存中。还应注意的是，用于存储tile meta数据的内存量可能相当大，因此，其信息也可能必须通过缓存访问。