GPU架构杂乱备忘——IMR、TBR、TBDR

之前觉得涉及到gpu架构相关的问题只需要知道个大概就好,毕竟在图形api的层面上应该把硬件的细节给隐蔽掉,gpu的架构千千万万,每家厂商每个型号都不一样,开发者没必要掉进这个细节里面。但是最近重看Metal,特别是2.0之后新增的功能,逐渐深刻意识到一个事实——图形api已经迎来了真正的第三代。当然DX12、Vulkan和Metal在诞生时就打出了“现代图形api”的旗号,与传统api划出界限,我也只算是后知后觉。这些现代图形api的一个特点就是开放更多操纵硬件的细节,全权交给开发者来定夺。不过真正让我觉得有必要深入了解一下gpu架构的原因却是Metal在面对桌面级gpu和移动级gpu给出了差异相当大的两套api,这也让桌面端和移动端的图形编程变得截然不同。

桌面级gpu架构——IMR(Immediate Mode Rendering)

tdengine架构模型 tbdr架构_shader

IMR就是我们普遍熟悉和使用的gpu架构,以n卡为例从Tesla发展到Turing依旧还是IMR架构。这种架构也和之前的图形api与渲染管线天然契合。每一个绘图的指令来到显卡,显卡便立即执行,从头到尾跑完整个管线,最终将结果输入到Frame Buffer中。但是这种架构有一个问题,在开启深度测试后,每个fragment的输出都要和Depth Buffer中的深度值进行深度测试,如果通过测试则需要更新Depth Buffer和Frame Buffer。这个过程包括了对System Memory的一次读取和两次写入,而fragment的数量巨大,这样就带来了很大的访问System Memory的压力。而IMR的解决办法则是给gpu配备足够大缓存和足够大的带宽。不过代价却是显卡为了容纳下更多缓存使得主板越来越大,并且频繁大量的带宽访问造成巨大的耗电与发热而不得不增加单独的风扇。这些代价在桌面电脑上尚能接受,可到了移动端就变成了洪水猛兽。无论是物理空间还是耗电对于移动设备来说都弥足珍贵,也因此不得不推出一种全新的gpu架构

移动级gpu架构——TBR(Tile Based Rendering)

tdengine架构模型 tbdr架构_tdengine架构模型_02

TBR架构在gpu很近的位置增加了一片高速缓存,通常被称为Tile Memory(图中也叫On-Chip Buffer)。受限于成本、耗电等原因这块缓存不会很大,大概几十k这个量级。首先整个屏幕的画面会被分割成无数个小块,被称为tile,通常32*32大小,这样Tile Memory中足够容纳得下这个tile的相关数据。当一个绘图指令抵达显卡时,不在像IMR一样立即完成渲染,而是将通过vertex shader和裁剪后的顶点数据,根据所在tile进行分组,并将分组后数据存储到System Memory中,这块缓存也被称为Parameter Buffer (PB, 图中Primitive List和Vertex Data),然后处理下一个绘制指令。当所有绘制指令的顶点数据都做好处理存进PB或是PB达到一定容量之后才开始进行管线的下一步,即显卡会以tile为单位从PB中取回相应的顶点数据,进行光栅化、fragment shader以及逐片元处理。原本在逐片元处理中需要频繁的访问System Memory变为代价极低的对Tile Memory的访问。直到这个tile的frament将数据全部更新到Tile Memory上之后,再将该Tile Memory中的数据写回System Memory,然后执行下一个tile的处理。相比于imr零碎的大量的不可估计的对于System Memory的读写操作,TBR中变为了有限的(和tile数量一致)整块的写操作。虽然PB也在System Memory上,但是对于PB的访问是顶点数量级的(显然vertex要远小于fragment)且数据会经过特殊的压缩处理,所以这个置换依旧值当。

不过这种架构也带来了一些问题,因为渲染管线会在中途中断,这就导致在这时切换Frame Buffer变得异常麻烦。TBR的做法是会将缓存的渲染数据全部强制绘制,绘制完毕后再些换到新的Frame Buffer,这无形中就增加Tile Memory和System Memory之间数据的拷贝。也因此在移动设备上切换Frame Buffer的使用要十分慎重。但从另一方面来看那些渲染数据并没有立刻渲染,而是缓存了起来,这也带来了很大的优化空间。

更强的移动级gpu架构——TBDR(Tile Based Deferred Rendering)

tdengine架构模型 tbdr架构_shader_03

将TBDR放在这里可能会造成一种误解,认为TBDR是TBR的升级版。事实上,TBDR的是Imagination公司所独有的一种移动级gpu架构,被广泛应用于旗下PowerVR等产品中。由于其相比同时期其他TBR架构的显著优势受到苹果公司的青睐,而被搭载到iphone上。近几年iphone已经开始使用完全自研的A系列处理器也依旧是延续着TBDR架构。TBDR的优势在于利用PB中缓存的顶点数据,提前对流入到管线剩余部分的片段进行了筛选,来解决传统渲染管线的一个老大难问题——过度绘制(over draw),而实现这一步的关键就在于HSR(Hidden Surface Removal)技术。

tdengine架构模型 tbdr架构_数据_04

如上图所示Image Synthesis Processor (ISP)从PB中逐图元的取回当前tile的顶点数据(只有顶点数据),ISP会对数据进行差值并对差值得到的片元数据计算深度,并进行深度和模板测试。如果通过测试,则更新片上的深度和模板缓存,同时在tag buffer中记录该片元的图元id。当一个tile的所有图元都经过ISP的处理后,tag buffer中便会得到每个像素所对应的唯一可见的图元id。然后对这些可见的图元,以图元为单位从PB中取回顶点之外的其他varying数据(比如uv之类)通过TSPF进行差值,然后传给fragment shader。这也解释了TBDR总流程图中vertex data的两条分支,*1代表流入ISP的顶点数据,*2代表流出TSPF的其他数据。

TBDR也有一些弊端,比如那些在fragment shader中会丢弃的片元(alpha 测试)无法再fragment shader之前直到其是否需要绘制,因此对于这些片元需要通过上图中的GCS提前提交给fragment shader并计算出确切深度后返回给ISP,这个过程阻塞掉其他片元的计算,因此是一种比较昂贵的代价。另外对于半透明物体(alpha混合)由于一个片元的颜色不仅由最近片元决定,所以此时会强制绘制缓存的片元,这样便也增加了Tile Memory和System Memory之间的拷贝。因此应该将物体分组,先开启深度测试绘制非透明物体,再关闭深度测试绘制透明物体。

虽说HSR这种技术被Imagination申请了专利,并且在狭义上只有应用了HSR技术的显卡在能叫TBDR。但其他厂商也有自己针对TBR架构的优化,比如Arm的Forward Pixel Kill和骁龙的Flex Render都在力图减少过度绘制。同时在软件层面也有被称为TBD(Tile Based Deferred Shading)的着色管线,不过这和TBDR完全是两个层级的概念。

再看IMR、TBR和TBDR

IMR和TBR因为这块Tile Memory带来了完全不同的渲染流程,有些原本适用的法则,在移动端上则完全不一样。除了上面提到过的切换FBO,alpha测试以及alpha混合等问题。比如在IMR上,每一帧clear是完全不必要的,因为整个屏幕都会被重新绘制而覆盖掉上一帧的内容。但对TBR来说每一帧不clear则以为着需要在每一个tile开始的时候将上一帧的数据拷贝到Tile Memory中,为防止这种完全没必要的拷贝所以在TBR上需要每帧clear。如果考虑到TBR中Tile Memory的宝贵以及访问System Memory的难度,纹理采样也变成了一种昂贵的操作。纹理数据是存储在System Memory上,少量近期访问过的纹理会缓存在Tile Memory中,因此使用压缩纹理可以让有限的Tile Memory缓存更多的纹理数据,同时LUT(Look-Up Table)这种不符合空间局部性的纹理数据会大幅降低缓存命中应该少用。

TBR这样一种为了适合移动端种种限制而不得不诞生一种“妥协”的架构,虽有上述的种种限制,但却也带了意想不到威力。这块神奇的Tile Memory不仅带来了可以忽略的读写成本,也为渲染管线提供了一块临时的缓存。这块缓存的意义就在于,原本多个pass才能完成的渲染流程变成一个pass就可以。为了实现这种优化,在Metal 2.0中提供ImageBlock和Tile Shader等技术,允许开发者对Tile Memory上的数据进行编程,这也让移动端和桌面端渲染管线的实现有了极大的不同