TBR 架构下全屏 Resolve 的必要性解析

开场上个月给移动端项目做后处理优化，跑 Profile 时发现一个诡异的现象：后处理 Pass 明明只采样了一张全屏纹理，GPU 却把整个 framebuffer 重新 flush 到主内存，带宽直接飙到 800MB/s，功耗也跟着起飞。起初以为是 RenderTexture 格式选错了，换成 R16G16B16A16 也没用。直到翻 GPU 厂商的架构文档才发现，这个问题在 TBR（Tile-Based Rendering，分块渲染）架构下根本绕不开——任何一个跨 Pass 读取 framebuffer 的采样，都会触发一次 resolve。如果你在做移动端图形优化，理解 TBR 为什么要全屏 Resolve，基本是必修课。这篇文章按"为什么这么设计 → 机制怎么发生 → 工程上怎么躲"的顺序讲透。一、先回答"为什么"：移动 GPU 为什么选 TBR1.1 带宽就是功耗桌面 GPU 用的是 IMR（Immediate Mode Rendering，立即模式渲染）：画一个三角形，光栅化完直接读写显存里的 framebuffer。简单粗暴，但代价是每一次像素读写都要访问显存。移动 SoC 上这条路走不通。访问片外 DRAM 的能耗远高于访问片上 SRAM（业界常引用的量级是差一个数量级以上），而手机没有主动散热，功耗墙只有几瓦。后处理链那种"整张图读进来、写出去"的操作如果全走 DRAM，带宽和功耗双双爆炸。1.2 TBR 的核心思路TBR 的答案：把屏幕切成 N 个 Tile（典型 16×16 或 32×32 像素），每个 Tile 在片上内存