TBR架构下RenderPass切换的性能开销与优化策略

开场：Profiler 里那根看不懂的带宽柱子移动端项目做到中后期，几乎每个团队都会撞上一次这样的翻车：Profiler 里 DrawCall 没多少、三角形也控制得很好，但带宽占用居高不下，帧率在某些场景直接跳水。翻到最后，罪魁祸首往往是同一个——为了实现 Bloom、景深、级联阴影这些效果，渲染管线里塞进了太多 RenderPass，每次切换渲染目标（RT）都在悄悄烧钱。在 PC 的 Immediate Mode 渲染器上，多切几次 RT 可能无关痛痒；但在移动端主流的 TBR（Tile-Based Rendering，基于图块的渲染）架构下，频繁切换渲染目标会遭受成倍的带宽惩罚。这篇文章把这件事从"经验之谈"拆到"硬件账本"：RenderPass 切换到底在消耗什么、为什么 TBR 对它如此敏感、以及工程上怎么止血。一、先立地基：RenderPass 与 TBR 到底是什么1.1 RenderPass 的生命周期在 Vulkan/Metal 这类现代图形 API 的语言里，一个 RenderPass 是一次边界明确的渲染操作：它有明确的开始（vkCmdBeginRenderPass）和结束（vkCmdEndRenderPass），操作一组明确的附件（attachment：颜色、深度、模板缓冲），并且每个附件都带两个关键语义——开始时怎么处理旧数据（Load Action），结束时怎么处理新数据（Store Action）。一条典型的移动管线长这样：Pass 1：阴影贴图（从光源视角渲染深度）/