【TA-霜狼_may-《百人计划》】图形3.4 延迟渲染管线介绍

3.4.1 渲染路径

渲染路径（Rendering Path）
决定光照的实现方式，简而言之，就是当前渲染目标使用光照的流程。

3.4.2 渲染方式

前向渲染（Forward Rendering）
延迟渲染 （Deferred Rendering）

默认管线demo介绍

前向渲染效果：
延迟渲染效果：

3.4.3 前向渲染

在前向渲染过程中，渲染每一帧时，每个顶点 / 片元都要执行一次片元着色器代码，这时需要将所有的光照信息都传递到片元着色器中。
虽然大部分的光照都趋向于小型化，即其照亮的区域不大，但即便这个光源距离很远，在计算光照的时候还是会将所有的光源都纳入考虑范围。
例如：物体受到n个光源影响，那么在每一个片元着色器代码中，都必须把n个光源都传递进这个片元着色器中进行计算。
在forward rendering中可以自定义设置需要进行逐像素渲染的光源数量。

3.4.4 延迟渲染

先不去做迭代三角形做光照计算，而是先找到所有能看到的像素，再去迭代光照。直接迭代三角形的话会造成大量开销，非常浪费。

将渲染拆分成两个渲染通道（pass）
第一个pass成为几何处理通路。首先将场景渲染一次，获得待渲染对象的各种几何信息存储到名为G-buffer的缓冲区中，这些缓冲区将会在之后用作更复杂的光照计算。
由于有深度测试，所以最终写入G-buffer中的各个数据都是离摄像机最近的片元的几何属性，这意味着最后在G-buffer中的片元必定要进行光照计算。

第二个pass成为光照处理通路。该pass会遍历所有G-buffer中的位置、颜色、法线等参数，执行一次光照计算。

无法用延迟渲染的方式对透明或者半透明物体进行渲染，所以在延迟渲染的过程中，透明物体的渲染依旧按照前向渲染的方式进行，在最后进行处理。

延迟渲染先将图像信息存入一个2D的RT（Render Texture）中，每一个RT都可以写进一个G-buffer中，所以当使用G-buffer中的数据进行光照计算时，相当于2D条件下的光照处理。

3.4.5 不同渲染路径的特性

1. 后处理方式不同
   • 前向渲染需要单独渲染出一张深度图
   • 延迟渲染可以直接使用G-buffer中的深度图进行直接计算
2. 着色计算不同（shader）
   • 由于延迟渲染光照计算统一在LightPass中完成，所以只能选择单个光照模型，如果你需要其他的光照模型，只能切换pass
3. 抗锯齿方式不同

优缺点比较

前向渲染缺点：

1. 光源数量对计算复杂度影响巨大
2. 访问深度等数据需要额外计算

前向渲染优点：

1. 支持半透明渲染
2. 支持使用多个光照pass
3. 支持自定义光照计算方式

延迟渲染缺点：

1. 对MSAA支持不友好
2. 透明物体渲染存在问题
3. 占用大量的显存带宽

延迟渲染优点：

1. 大量光照场景优势明显
2. 只渲染可见像素，节省计算量
3. 对后处理支持良好
4. 用更少的shader

其他

渲染路径设置

移动端优化

• 两个TBDR的理解
  • 一个是SIGGRAPH 2010上提出的，通过分块来降低带宽内存用量
  • 一个是PowerVR基于手机GPU的TBR架构提出的，通过HSR减少OverDraw

通过对画面进行分块来解决带宽瓶颈的问题。

其他渲染路径

• 延迟光照（Light Pre-Pass / Deferred Lighting）：减少G-buffer占用的过多开销，支持多种光照模型
• Forward+ （Tiled Forward Rendering， 分块前向渲染）：减少带宽，支持多光源，需要一个强制的preZ（深度计算）。它利用分块索引的方式以及深度和法线信息达到需要进行光照计算的片元进行光照计算
• 群组计算 Clustered Rendering

MSAA

DX9不支持MSAA，由于延迟渲染中像素已经被光栅化了，所以无法用更大的像素对其进行渲染，造成MSAA失效的问题。

不同path下光源shader的编写

官方文档中有详细的说明

preZ / Zprepass

其中一个是利用pass进行深度计算，另一则是将深度信息绘制成RT，用途在于当进行大型草渲染的时候进行使用，或者是在透明物体的渲染过程中进行使用。

一般在主机游戏中使用延迟渲染

作业

延迟渲染管线的优缺点

• 在大量光照的场景中优势明显

• 只渲染可见像素，节省算力

• 利用G-buffer优化后续处理

• 不支持MSAA

• 透明物体无法使用这种模式

• 占用大量的显存带宽

• 延迟渲染只能用同一套lighting pass

如何优化（移动端优化技术）

问题：如何解决移动端带宽占用高的问题？
首先要分清楚PC端和移动端两种不同的架构形式。

• PC端架构IMR 和
• 移动端架构TBR

IMR

全称：Immediate Mode Rendering，我们通常说PC端GPU渲染用的是如下的架构：

• 蓝色部分代表正常的渲染管线，灰色部分对应GPU中的显存（包括集合信息，纹理信息，深度Buffer还有FrameBuffer）
• 特点：对于每一步操作，渲染管线里的读写操作都是直接在显存和GPU中传输数据的，例如上图中中间一行的箭头，向上代表读取显存，向下代表写入显存
• 这种方式下，每一次渲染完的Color和Depth数据写回到FrameBuffer和Depth Buffer都会产生很大的带宽消耗。

TBR

由于移动端需要控制功耗，大量的读写运算会急剧提高功耗，所以受到功耗限制，需要限制带宽。

TBR全称是：Tile-Based Rendering，
上图中，可以看到两个灰色条带，最下一层是系统内存（我存疑蛤）

选择TBR的原因

• 即使是1080p的分辨率，在对每一帧都进行渲染的情况下对FrameBuffer的访问量是惊人的。
• gpu的onchip memory（SRAM L1 L2 cache）较小，如果不采取措施的话将数据存储在DRAM中会造成大量的带宽消耗，从而无法控制功耗。
• 为了解决上述问题，将FrameBuffer中的数据分隔成小块装在SRAM中，方便读写，完成整块的读写之后再统一存回DRAM中；

能够减少带宽的原因

• TBR架构下，所有渲染之前的工作都在SRAM上完成，当整体完成渲染了才将数据搬回DRAM，减少了大量的读写操作；
• 针对上述操作，读取只发生在需要几何以及纹理信息的时候，写回也只发生在整批绘制完成的时候，也就是说带宽消耗最大的DepthBuffer和ColorBuffer的读写都发生在On_Chip Memory上

比较如下：

TBR的过程

1. 缓存所有绘制指令知道最后才开始进行真正绘制
2. 首先对所有图元进行VS，把相关的所有绘制数据保存起来
3. 计算每个tile都包含那些图元
4. 开始绘制一个tile
5. 依次绘制每个tile
6. 把绘制好的所有tile拷贝到FrameBuffer中

TBR的实现策略

• 在TBR中并不是来一个绘制就执行一个全过程，这样还是会有大量的读写操作问题。
• TBR一般的策略是：对于从CPU发来的绘制，只对他们进行顶点处理，然后将产生的结果暂时存回物理内存，等到非要刷新整个FrameBuffer的时候，再对这部分数据做光栅化；

TBDR

什么是TBDR

Tile-based defer rendering
只有PowerVR的GPU是TBDR架构，其余的GPU还是TBR架构，是对TBR的改进，在TBR的基础上再加了一个Deferred。通过增加Rasterize（光栅化）到PS这一步之间的延迟，实现延后PS的操作

TBR与TBDR的区别

TBR： VS - Defer - RS - PS
TBDR： VS - Defer1 - RS - Defer2 - PS
通过第二个defer，真正最大程度的实现了“延后（Defer）PS的执行”，以避免执行不必要的PS计算带来的开销;

HSR

HSR对标之前学到过的Early-Z方法，由于TBR的特性，所有的图元信息都在被绘制前就完全保存下来，所以对这些信息进行深度计算，就不需要考虑绘制顺序问题了，从而几乎零成本的避免了OverDraw问题。

回答

1. 在不使用FrameBuffer的时候 clear 或者 discard
2. 在每一帧渲染前尽量clear
3. 不要在每一帧中频繁的切换FrameBuffer
4. 贴图尽量压缩
5. 尽量开启Mipmap
6. 随机纹理寻址相比相邻纹理寻址开销更大
7. Trilinear/Anisotropic相对于Bilinear开销更大
8. 使用LUT（Look up texture）可能会负优化
9. 通道图尽量合并，减少贴图的采样次数
10. 控制FrameBuffer的大小
11. 避免大量的drawcall和顶点量
12. 避免gpu上的 copy-on-write

参考链接