TBR 瓦片式渲染解析：移动 GPU 的带宽与功耗架构优化

引言：用桌面经验优化移动 GPU 为何失效

中端 Android 设备上 GPU 占用居高不下、发热严重、监控显示带宽几乎打满，而 Draw Call 数量、纹理压缩、LOD 都检查过没有问题——这是移动端渲染开发的经典困境。问题通常不在某个资源，而在架构认知：移动 GPU 与桌面 GPU 的渲染执行模型根本不同，用立即模式（IMR）的思维做优化，方向从一开始就错了。

瓦片式渲染（Tile-Based Rendering, TBR）是理解移动 GPU 行为的钥匙。其核心思想可以概括为两步：先统计每个三角形覆盖哪些屏幕瓦片（Binning），再逐瓦片完成渲染，中间结果全部留在片上存储，最后只把成品写回主存。

一、IMR 与 TBR：两种渲染执行模型

1.1 IMR 的执行方式与带宽代价

桌面 GPU 普遍采用立即模式：每个 Draw Call 提交后，几何数据立即经过顶点着色、裁剪、光栅化，像素直接读写系统显存中的 Framebuffer。开发者无需关心帧的切分，硬件全程代劳。

代价是带宽。以 1080p 延迟渲染为例，G-Buffer 每像素数十字节、多次读写叠加，单帧 Framebuffer 流量轻松突破数百 MB。桌面卡有 GDDR6/HBM 的高带宽与充足的功耗预算支撑这种模式；移动 SoC 的 LPDDR 带宽有限，且整机功耗预算通常只有数瓦，留给 GPU 的更少——"每次写像素都过一遍主存"在移动端是不可持续的。

1.2 TBR 的两阶段模型

// IMR：每个 draw call 立即完成像