移动端GPU优化指南（一）

前言

与桌面端GPU的IMR架构不同，移动端采用的是TBR架构

什么是IMR（Immediate Mode Rendering）

IMR（Immediate Mode Rendering），立即模式渲染架构是桌面端（电脑）所采用的GPU渲染架构，IMR通常是整屏像素一起渲染，不去对像素进行分块，立即模式GPU将渲染过程处理为严格的命令流，在每个绘图的调用流程中的每个图元上一次进行顶点着色和像素着色。

伪代码如下：
```
for draw in renderPass:
    for primitive in draw:
        for vertex in primitive:
            execute_vertex_shader(vertex)
        if primitive not culled:
            for fragment in primitive:
                execute_fragment_shader(fragment)
```
- 优势：
  
  IMR的硬件数据和内存交互如下图所示：
  
  备注：DDR为数据流， FIFO：First In First Out队列
  
  图上可以看出，在IMR架构中，顶点着色器以及其他与几何相关的着色器的输出可以保留在GPU内部的芯片，着色器的输出可以存储在FIFO缓冲区中，直到流水线的下一个阶段准备使用数据为止，GPU很少使用外部存储器带宽来存储和检索中间几何结果。IMR的优势是每个primitive直接提交渲染，pipeline没有中断，渲染速度快，pipeline并行起来时，每个Raster core只要负责render分给它的primitive即可，无需其他控制逻辑，只需在pixel shader后对Raster出的pixel做个排序。
- 劣势：
  1. 如果有很大的图形（主要是三角形）需要被渲染，那framebuffer就会很大，比如对于整个屏幕的颜色渲染或者深度渲染就会消耗很多存储资源，但是片上是没有这么多资源的，因此就要频繁读取DDR。很多和当前frame有关的操作( 比如blending, depth testing 或者stencil testing)都需要读取这个working set，存储器上的带宽负载可能会非常高，并且这样能耗也很高，对于移动设备来说，这种方式很不利于设备运行；
  2. Z-test跟blending都要频繁从framebuffer里读数据，毕竟framebuffer是位于Memory上，带宽压力和功耗自然会很高；
  3. Overdraw的问题，比如Application在一帧里先画了棵树，然后画了面墙刚好遮住了树，在IMR下树仍然要在Pixel Shader里Sample texture，而Texture也是放在Memory，存储单元访问功耗大。
什么是TBR（Tile-Based Rendering）

TBR（Tile-Based Rendering）基于图块渲染也被称基于瓦片渲染或基于小方块渲染，它是一种在光学空间中通过规则的网格细分计算机图形图像并分别渲染网格（Grid）或图块（Tile）各部分的过程。这种设计的优点在于，与立即绘制整个帧的立即模式渲染系统相比，它减少了对内存和带宽的消耗。这使得基于图块的渲染系统（TBR）特别常见于低功耗硬件设备。图块渲染有时也被称为中置排序（Sort Middle）架构，因为它在绘图流水线中间而不是接近结束时进行几何排序。目前所有的移动设备基本采用的GPU架构，以Mali为例，Mali GPU使用基于图块的渲染架构。这意味着GPU将输出帧缓冲区渲染为几个不同的较小子区域，称为图块。然后，它会在完成后将每个图块写出到内存中。使用Mali GPU，这些图块很小，每个图块仅16x16像素。

基于图块的渲染将屏幕分成小块，并对每个小图块进行着色着色，直到将其写出到内存中为止。为了使这项工作有效，GPU必须预先知道哪些几何图形有助于每个图块。因此，基于图块的渲染器将每个渲染过程分为两个处理过程：
1. 第一遍执行所有与几何相关的处理，并生成图块列表数据结构，该结构指示哪些图元对每个屏幕图块起作用。
2. 第二遍将逐块执行所有片段处理，并在完成后将切片写回到内存中。请注意，Mali GPU渲染16x16的图块。
伪代码如下：
```
# Pass one
for draw in renderPass:
    for primitive in draw:
        for vertex in primitive:
            execute_vertex_shader(vertex)
        if primitive not culled:
            append_tile_list(primitive)

# Pass two
for tile in renderPass:
    for primitive in tile:
        for fragment in primitive:
            execute_fragment_shader(fragment)
```
TBR架构的硬件数据流以及与内存的交互如下图所示：

备注：DDR为数据流， FIFO：First In First Out队列
TBR的出现解决了传统模型的带宽问题，因为pixel shader每次都是读取一个小块放在片上，不需要频繁读取内存，直到最后操作完成，再写入内存。甚至还能够通过压缩tile的方法进一步减少对于内存的读写。另外在图像有一些区域固定不动的时候，通过调用函数判断tile是否相同，减少重复的渲染。
- 优势：
  1. 对于IMR所有Read Z/Framebuffer，到了TBR通通不需要。TBR只需Render完tile后把on-chip的Pixel写到Frame buffer（不需要写z，因为当前帧的Z是在On-Chip的Cache上，下一帧不需要用到前一帧的z和color，所以z不需要写到FrameBuffer中）。这个好处在于TBR将Screen Tiling。这样，每次Render的区域变小，小到可以把Z/Framebuffer搬到On-Chip，快，省电。
  2. TBR给消除Overdraw提供了机会，PowerVR用了HSR（隐面剔除）技术，Mali用了Forward Pixel Killing技术，目标一样，就是要最大限度减少被遮挡pixel的texturing和shading。
  3. TBR主要是 Cached Friendly, 在cache里头的速度要比全局内存的速度快的多，以及有可能降低Render rate的代价，降低带宽，省电。
- 劣势：
  1. 由于TBR的Tiler操作需要在VertexShader阶段之后，将输出的几何数据写入到DDR，然后才被Pixel Shader读取。这之间也就是Tiler写入DDR的开销和Pixel Shader渲染读取DDR开销的平衡。另外还有一些操作，比如曲面细分（Tessellation）也不适用于TBR。
  2. 如果某些三角形叠加在数个图块（Overdraw），则需要绘制数次。这意味着总渲染时间将高于即时渲染模式。
什么是TBDR（Tile-Based Deffer Rendering）

TBDR架构关注于在渲染管线中尽可能移除冗余的操作与计算，最小化内存带宽和能耗同时提升管线处理的吞吐量。TBDR将每个Tiler的渲染过程拆分为两个步骤，一个是Hidden Surface Removal(HSR)和Deferred Pixel Shading，在前面TBR的描述中我们可知TBR最主要解决的是带宽的问题，而带宽是功耗（发热和耗电）的核心问题，虽然TBR减少了IMR的带宽开销，但是依然没有解决Overdraw的问题。

TBDR会尽可能地延迟Pixel Shading的时间，直到所有光栅化后的Fragment完成了DepthTest和HSR。对于一个场景中全是不透明几何图元的渲染画面来说。每一个光栅化完的Fragment Patch会经过HSR和Depth Test，在所有Triangle完成Raster之后，最后留下来的Fragment会留下来执行Pixel Shading。也就是在这种情况下Tile中的每一个像素只执行一次Pixel shader。

如果渲染流程中有Alpha Test/Alpha Blend/Pixel Depth Write，就会阻断Deferred Shading，因为这个时候需要执行Shading，才能正确进行后续Fragment的计算。
- Alpha Test需要执行Shading算出当前Fragment的Alpha，判断该Fragment是否被丢弃。
- Alpha Blend需要读取FrameBuffer中当前像素之前的颜色。
- Pixel Depth Write会影响到后续Fragment的HSR与Depth Test。
这三种情况下Pixel Depth Write，因为会影响到后续Fragment HSR/Depth，所以这个时候一定要执行该像素的Shading，打乱了原先Deferred的流程。具体要看GPU实现时时把整个HSR步骤积累的Fragment都Shading掉还是只把当前Fragment Shading掉。而对于Alpha Blend来说，它并不一定要打断Deferred Shading。遇到Alpha Blending的Fragment，可以把该Fragment像素位置的所有Fragment按顺序保留在列表中，等到Shading时按顺序计算Blend。但这样就会增加Pixel Shading的次数。具体的实现还是要参照GPU的实现方式，由于使用TBR，Blend的开销相对比IMR还是降低了很多。

Alpha-Test的情况是和Pixel Depth Write类似，由于Alpha Test失败Fragment会被丢弃，如果其开启了Depth Write，那么就一定要执行Shading。因为Alpha-Test会影响后续Fragment的HSR/Z-Test的流程。如果没有开启Depth Write，也可以和Blend一样保留后续所有Fragment的方式来延迟Shading。但是这个时候后续该位置的Fragment Patch都是不能被移出Shading列表的，延迟Shading也没有意义了。

TBDR目前是以高通的PowerVR为代表的TBDR，owerVR除了使用TBDR架构以外硬件上采用了统一Shader架构，统一架构和非统一架构在工作流上面的区别如下：
- 对于统一的Shader架构而言，执行Shader Programs比如Vertex和Fragment(Pixel)可以在同一个处理器模块执行。
- 而非统一的Shader架构，需要在不同的处理器模块分开执行Vertex和Fragment(Pixel)
统一的Shader架构起到了节省电量和功耗的作用相比于非统一的Shader架构。另外统一的架构对于处理Vertex或Fragment(Pixel)瓶颈的时候更容易定位和处理

非统一的着色器架构上Vertex Shader要等待Fragment(Pixel) Shader执行完后才能Push处理完的顶点数据丢给FS单元。而统一的着色器架构，处理会减少等待时间，提升性能。PowerVR全部采用的都是Unified Shader Architecture。

TBDR基本上是TBR的进阶版本与IMR相比较的优缺点基本类似这里就不在赘述。