学习教程来自:【技术美术百人计划】图形 3.7 移动端TB(D)R架构基础

移动端GPU的TB(D)R架构

1. 当前移动端GPU概况

市场占比概况(数据来自学习教程PPT)

1.1 移动端和桌面端功耗对比

移动端和桌面端功耗对比(数据来自学习教程PPT)差距约100倍

1.2 移动端和桌面端带宽对比

移动端和桌面端带宽对比(来自学习教程PPT)差距约10倍

2. 名词解释

SoC(System on Chip):芯片。把CPU GPU 内存 通信基带 GPS模块等整合在一起的芯片
System Memory:手机内存。CPU和GPU共用的一块片内LPDDR物理内存,一般有几个G
On-chip Memory:缓存。CPU和GPU的高速SRAM的Cache缓存,一般几百K到几M,比内存快几倍到几十倍,他们都共享内存地址空间(桌面端是分开的)。在TB(D)R架构下会存储Tile的颜色、深度和模板缓冲
Stall:GPU必须串行的2次计算之间的等待过程
FillRate:ROP运行时钟频率 X ROP个数 X 每个时钟ROP可以处理的像素个数
TB(D)R/Tile-Based(Deferred)Rendering:主流的移动GPU渲染架构,对应PC的IMR(Immediate Mode Rendering)。屏幕被分成16或32的像素块渲染
TBR流程:VS-Defer-RS-PS
TBDS流程:VS-Defer-RS-Defer-PS(见7、8描述2个defer过程)
Defer:延迟,阻塞+批处理待渲染的一帧中的多个数据,然后一起处理

3. 立即渲染(IMR)

IMR工作流程(来自https://www.imaginationtech.com/)

4. 基于块元的渲染TB(D)R

  1. 逐个图元(顶点着色+图元加入TileList):阶段1执行几何相关的处理,生成Primitive List/图元列表,确定Tile上的图元有哪些
  2. 逐个分块(片元着色等):逐Tile执行光栅化和后续处理,完成后将Frame Buffer从Tile Buffer写回System Memory中

    5. TB(D)R的硬件渲染顺序

    TB(D)R工作流程(来自https://www.imaginationtech.com/)

6. IMR和TB(D)R对比

TB(D)R对比和IMR对比(来自学习教程PPT)

总体上看,TBR降低了功耗和带宽,但帧率上并不比IMR快

TBR的优缺点:

优点:

  1. TBR有利于消除OverDraw,其中PowerVR的HSR技术和Mali的Forward Pixel Killing技术,都最大限度的减少了被遮挡像素的texturing和shading
  2. Cached Friendly,在缓存中的读写速度远高于全局内存,以降低render rate的代价,减低了带宽和功耗。

缺点:

  1. binning过程:在VS过程后输出几何数据到DDR,然后被FS读取,几何数据过多的情况下可能在此处产生性能瓶颈
  2. 当三角形覆盖在多个tile上时,需要绘制很多次,此时性能低于IMR模式

7. Binning过程(第一个Defer)

过程:图元分配到对应的块元

Binning过程(来自学习教程PPT)

测试工具:Adreno Profiler

8. 不同GPU的Early-Depth-Test(第二个Defer)

8.1 Qualcomm Adreno的LDR(Android)

硬件的occlusion culling:在正常渲染管线之前,VS生成低精度depth texture,剔除不可见的三角形

8.2 Mali的FPK(Android)

Forward Pixel Kill技术:在Early-Z阶段之后,使用一个FIFO队列抛弃被遮挡的Quad(例子中是2*2的像素)

FPK过程(来自学习教程PPT)

8.3 Power-VR的HSR(IOS)

Hidden Surface Removal技术:沿一条射线从第一个不透明片元向后剔除被遮挡的片元

HSR过程(来自学习教程PPT)

9. 优化建议

  1. 不使用FrameBuffer时及时Clear或Discard:清空了在tile buffer上的中间数据。Unity中,不适用RT时调用Discard。OpenGL ES中善用glClear、glInvalidateFrameBuffer,避免不必要的Resolve(tile buffer刷新到系统内存)行为
  2. 减少一帧中FrameBuffer绑定的频繁切换:减少了tile buffer和系统内存之间的stall操作
  3. 考察Alpha Test和Alpha混合的实际表现,合理使用。减少Alpha混合实现透明时的混合范围(例如将透明区域的Mesh裁剪掉替换为多边形)
  4. 使用Alpha Test时先进行提前深度测试
  5. 图片尽量压缩,例如ASTC ETC2
  6. 图片尽量开启mipmap
  7. 贴图采样:UV值尽量使用VS中传出的Varying变量(VS向PS中传递的变量)(连续),不要再FS中动态计算UV(非连续),造成CacheMiss
  8. 在延迟渲染中尽量利用Tile Buffer
  9. 项目配置中不同的配置导致的帧率变化,可能是带宽占用的问题
  10. MSAA在TBDR下消耗很小:硬件速度快
  11. 减少FS中Clip(HLSL)、discard(GLSL)、gl_FragDepth的使用:会打断Early-DT的执行
  12. 区分使用float、half、fix:1). 降低带宽占用 2). 减少GPU周期提高并行程度 3). 降低统一变量寄存器数量,从而降低寄存器数量溢出风险,参考Unity3D shader优化技巧集合
  13. 减少FrameData压力:顶点处理部分容易成为瓶颈,应避免使用曲面细分shader、置换贴图等负操作。提倡使用模型LOD,且尽早进行遮挡剔除(如umbra)

作业

打包场景到Android平台,对比优化前和优化后的结果
提前总结:以下优化效果测试了贴图大小的影响,关闭了一些影响不大的后处理效果,没有进行shader的修改。
测试环境:2.84 GHz 骁龙865八核 8GB运存

0. 优化前

场景来自Unity Asset 资源链接

优化前 PPT 1500ms

优化前 1500ms

优化1:从上边的图看,瓶颈在GPU。经过尝试后关闭了摄像机中一个后处理(远处场景模糊处理),

1. 关闭耗时的后处理

优化1 36.88ms

2. 贴图调整

贴图调整前 为2048X2048 38ms左右

  1. Texture Compression设置为ETC:没啥效果,依旧为38ms,看来默认就会有一些压缩
  2. Max Size 2048 -> 256 -> 32:差别不大,降低了5ms左右,画质变差了很多。可能由于开启了MipMap,远处的贴图降低了分辨率,近处的物体也不是很多。还有可能由于手机的性能瓶颈不在这里,故调整贴图大小差别不大
    贴图调整为32X32 34ms


    如图,当摄像机离散的变化到一个新位置时,渲染的时间会突然增加再慢慢减少,往复循环。

3. Shader

场景中使用的材质

这个场景里的Shader没找到从哪里能改,卒 ### 4. 一些后处理效果的删除 经测试,关掉这些后处理效果能在最终效果差别不大的情况下提升帧率(贴图在2048分辨率下) 点评:这些效果使用了深度图,深度图本身进行了额外的渲染来生成,并且读写本身也占用了大量的带宽,所以消耗很大。
关闭的效果

关闭后 平均28ms左右 最高33ms 和将贴图改到32分辨率结果相似

效果图

优化前