移动GPU采用TBR（Tile-Based Rendering）架构，将屏幕划分为瓦片处理以减少主存访问，但对顶点数和DrawCall敏感，因顶点处理依赖主存且频繁切换上下文增加功耗。移动GPU片上缓存容量有限，受能效和面积限制。而PC GPU采用IMR架构，依赖大容量显存和高速缓存，能高效处理复杂场景和大量DrawCall。总结来看，移动平台对顶点和DrawCall更敏感，受限于小缓存和功耗，而PC平台凭借大缓存和宽松限制性能更优。
1. 移动平台的 TBR（Tile-Based Rendering）架构和顶点/DrawCall 敏感性
- TBR 架构（Tile-Based Rendering）是移动GPU常见的渲染方法，比如ARM的Mali和Imagination的PowerVR。
- TBR会将屏幕划分成许多小“瓦片（tile）”后逐个处理，每个瓦片的深度测试和像素处理会在片内缓存（片上缓存，On-chip tile buffer）中完成，最大限度减少对主存的访问，降低带宽压力和功耗。
为什么对顶点数和DrawCall特别敏感？
- TBR的一个关键点是，顶点处理和装配（vertex processing and assembly）阶段依然是在主存和统一内存体系下进行的。
- 顶点数据通常不会完全放在片上缓存（通常容量有限）中，大量的顶点意味着更多从主存读取顶点数据，带宽压力升高。
- 同时大量DrawCall意味着CPU和GPU切换上下文更频繁，多线程和命令缓冲区压力也更大，影响性能。
- 由于移动设备对带宽和功耗极度敏感，过多的顶点读取和DrawCall会迅速成为瓶颈。
2. 移动GPU片上缓存设计受能效和面积限制
- 移动GPU片上缓存（比如tile buffer）大小通常很有限，几百KB到几MB不等，远小于PC端的显存规模。
- 设计上必须在能耗、面积、发热等多方面折中，不能像PC GPU那样大规模堆叠高速片上缓存。
- 因此无法一次性存储全部顶点数据，也无法像PC GPU那样的大容量高速缓存体系。
3. PC平台使用IMR（Immediate Mode Rendering）架构的原因
- PC GPU大多采用IMR架构，也叫Immediate Mode Rendering，渲染过程中几乎不进行瓦片划分，而是直接将顶点和像素数据写入内存，依赖高速显存（GDDR SDRAM）和大容量缓存。
- PC GPU的显存容量数GB起步，具有大量快速缓存（L2 Cache、纹理缓存、顶点缓存等），可缓存更多顶点数据和DrawCall相关的状态。
- 这种设计也使PC GPU更擅长处理极度复杂的场景和大量DrawCall，且对顶点数量的压力相对没移动设备那么敏感。
- 由于功耗和面积没那么受限，PC GPU在设计时可以放更大容量、更高频率的缓存。
总结
| 特点 | 移动平台（TBR） | PC平台（IMR） |
|---|---|---|
| 架构 | Tile-Based Rendering（瓦片式渲染） | Immediate Mode Rendering（直接渲染） |
| 片上缓存 | 小容量，几百KB到几MB，限制多顶点存储 | 大容量缓存，依赖显存及多级缓存 |
| 对顶点数敏感度 | 高，顶点多带宽压力大，影响性能 | 低，拥有更大缓存可缓解带宽和缓存压力 |
| DrawCall 敏感度 | 高，频繁切换CPU-GPU调度成本高 | 低，适合处理大量DrawCall和复杂渲染 |
| 功耗和面积限制 | 严格，限制片上缓存大小 | 宽松，可支持大显存和高速缓存 |
我用一个生动形象的“餐厅厨房”案例来对比 移动平台的TBR架构 和 PC平台的IMR架构，帮助你更直观理解它们对DrawCall和顶点数量敏感性的原因。
餐厅厨房案例：移动GPU和PC GPU的渲染架构对比
背景设定
假设渲染就是做一道复杂的菜肴：
- “菜肴” = 一帧画面
- “食材” = 顶点数据
- “厨师” = GPU
- “刀工和装盘” = 几何处理和像素着色
- “厨房空间” = 片上高速缓存与内存系统
- “厨房储藏室” = 主存（内存）
移动平台（TBR）厨房
厨房特点
- 厨房很小，空间有限（片上缓存小），只有一个小岛台（Tile Buffer）
- 厨师会先将菜肴切成小块（分割画面成瓦片），每次专心处理一个小份
- 食材（顶点）主要放在储藏室（主存），厨师需要频繁来回搬运食材到厨房台面操作
- 厨师只能把手边能放下的食材拿来，食材多了，搬运次数就多，效率就低
- 厨师做菜时，必须等到所有相关食材都齐了，才能开始切割装盘（着色）
- 厨房小，不能把所有食材一次性放齐，必须“延迟写入”后续工序
由此引发的问题
- 食材（顶点）种类和数量多，搬运频繁，效率被搬运速度限制
- 厨师做多道菜（DrawCall多），厨房开关门（CPU-GPU交互）频繁，影响节奏
- 小厨房空间限制，无法同时处理大量顶点和复杂指令，导致性能瓶颈
- 必须分批处理，开销更大，且等待时间长（流水线停滞）
PC平台（IMR）厨房
厨房特点
- 大厨房，多个岛台和储藏柜（大容量缓存和显存）
- 食材种类丰富且有序存放，厨师可以随手取用，不用频繁跑到储藏室
- 厨师做菜时，可以同时处理完整菜肴，用流水线效率高的直接操作流程
- 厨房支持同时做多道菜（大量DrawCall）且协调高效，不易堵塞
大厨房允许大量食材和工具同时存在，无需等待或延迟写入工序
由此带来的优势
- 大容量缓存减少了寻材搬运时间，减少主存交互瓶颈
- 可以轻松处理大量顶点数据，流畅应对复杂场景
- CPU和GPU交互开销较小，流水线更稳定高效
- 性能更强，适合高复杂度渲染和高刷新率需求
生活化总结
| 方面 | 移动平台小厨房（TBR） | PC平台大厨房（IMR） |
|---|---|---|
| 厨房大小 | 紧凑、空间极度有限 | 宽敞、设备充足 |
| 食材存放 | 食材大部分藏在储藏室，只有少量能放厨房台面 | 食材大量存在厨房台面和储藏柜，随取随用 |
| 搬运成本 | 食材种类多且多次频繁搬运，效率低 | 食材直接放在身边，搬运次数少，效率高 |
| 并行处理能力 | 小厨房导致同时只能做小份菜，做多道菜很难流畅处理 | 大厨房支持多厨师同时做多菜，流水线运作顺畅 |
| 延迟和等待 | 必须等待食材齐全才动手，过程中有频繁停顿 | 各步骤衔接紧密，流水线连续无明显停顿 |
| 能耗和节约 | 设计节能，厨房小省电省空间，但效率受限 | 大厨房耗电高但效率强，适合高负载环境 |
结合DrawCall和顶点数
- 大量顶点数据相当于“菜所需的不同食材”。在TBR架构，越多食材意味着越多搬运，带宽压力上升，效率下降。
- 频繁DrawCall相当于“频繁切换做不同菜”，每次切换都让厨师调整准备，增加开销。
- 移动平台因为“厨房小”和“食材放外面”，导致DrawCall和顶点数异常敏感。
- PC平台厨房“空间大”、缓存“丰富”，更能容纳大量食材和切菜操作，不怕复杂场景。
版权声明：本文为CSDN博主「你一身傲骨怎能输」的原创文章，
遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_33060405/article/details/150724407
