移动端GPU Tile Buffer溢出在RenderDoc中的准确定位与量化分析实践

在移动端（TBDR 架构）GPU 性能优化中，Tile Buffer（或称 Adreno 的 GMEM、Mali 的 Local Memory）的溢出（Spill）是导致 GPU 内存带宽暴涨、芯片发热并最终引发降频掉帧的致命因素之一。

由于移动端 GPU 物理 SRAM 资源极其有限，一旦当前 RenderPass 的渲染目标（Render Targets）总像素位宽（BPP, Bits Per Pixel）超标，或者 Load/Store 操作配置不当，GPU 就不得不将中间数据临时写回到远离 GPU 核心的系统内存（DRAM）中。

RenderDoc 作为最主流的图形 API 调试器，虽然无法像硬件专有 Profiler（如 Arm Graphics Analyzer 或 Snapdragon Profiler）那样直接读取硬件性能计数器（HW Counters），但它能够完整还原 GPU 管线的 API 状态机、渲染目标格式、Attachment 生命周期以及 Subpass 依赖关系。通过 RenderDoc 的静态分析与数据推演，我们能够极其精准地定位并量化 Tile Buffer 的溢出问题。

一、 移动端 Tile Buffer 的物理开销边界

在开始使用 RenderDoc 分析前，必须建立清晰的硬件预算概念。不同的移动端 GPU 架构对 Tile Buffer 的最大无损容量有严格限制。

当一个 RenderPass 内激活的 Attachments 像素总位宽超过这一物理限制时，GPU 就会发生 Tile Buffer 降级（例如将 Tile 大小从 $16\times16$ 像素自动降级为 $16\times8$ 甚至 $8\times8$ 像素，导致顶点 Tiling 开销暴增），或者直接发生 Tile Spill（向物理 DRAM 频繁交换数据）。

常见格式的物理 BPP 对照表

• R8G8B8A8_UNORM: 32 bits
• R11G11B10_FLOAT: 32 bits
• R16G16B16A16_SFLOAT: 64 bits
• D24_UNORM_S8_UINT: 32 bits
• D32_SFLOAT: 32 bits

二、 在 RenderDoc 中准确定位 Tile Buffer 溢出的步骤

通过 RenderDoc 捕获（Capture）一帧后，按照以下步骤逐步排查。

1. 检查 Pipeline State 中的 FBO/RenderPass 配置

进入 Pipeline State 选项卡（以 Vulkan 为例，OpenGL ES 对应 Framebuffer 绑定），切换到 RP/FB (RenderPass/Framebuffer) 子页面。

• 观察点 A：Attachments 的数量与格式
  • 在 RenderDoc 中查看当前 Pass 绑定的所有 Color Attachments 以及 Depth/Stencil Attachment。
  • 计算公式：
    $$\text{Total BPP} = \sum (\text{Format_Size}{\text{color_0...n}}) + \text{Format_Size}{\text{depth_stencil}}$$
  • 案例分析： 如果你在一个 Pass 中同时绑定了：
    • RT0: R16G16B16A16_SFLOAT (64 bits)
    • RT1: R16G16B16A16_SFLOAT (64 bits)
    • RT2: R8G8B8A8_UNORM (32 bits)
    • Depth: D24_UNORM_S8_UINT (32 bits)
    • 总 BPP = 64 + 64 + 32 + 32 = 192 bits。这在绝大多数 Mali GPU 上都会导致 Tile 尺寸收缩，在 Adreno 上会显著增加 GMEM 的 Binning 切片开销。

2. 检查 Load/Store Operations (关键突破口)

在 Pipeline State -> RP/FB 面板下方的 RenderPass 表格中，重点查看每个 Attachment 的 Load Op 和 Store Op。这是决定数据是否强制进出 DRAM 的直接指令。

[RenderPass Config Area in RenderDoc]
Attachment 0: Format (R16G16B16A16_SFLOAT) -> LoadOp: LOAD,     StoreOp: STORE (危险！)
Attachment 1: Format (D24_S8)               -> LoadOp: CLEAR,    StoreOp: STORE (极度危险！)

• 不必要的 STORE_OP_STORE (或 OpenGL ES 的 glInvalidateFramebuffer 缺失)

  • 深度缓冲（Depth Buffer）：在绝大多数情况下，深度缓冲（以及 Stencil）只在当前 RenderPass 内用于遮挡测试。如果 RenderDoc 中显示其 StoreOp 为 STORE，意味着 GPU 在绘制结束时，必须把整张尺寸庞大的 Depth 贴图从 Tile Buffer 写入 DRAM。这在移动端是极大的资源浪费。正确的设置应当是 STORE_OP_DONT_CARE。
  • 临时中间纹理（Transient Targets）：例如延迟渲染（Deferred Shading）的第一步 G-Buffer，在 Subpass 结束之后如果不再需要，必须设置为 STORE_OP_DONT_CARE。

• 不必要的 LOAD_OP_LOAD

  • 如果当前 Pass 会全屏清除（Clear）或完全覆盖写入，但 LoadOp 却被设置为 LOAD。这会导致 GPU 强制在渲染开始前，把旧的、无用的数据从 DRAM 加载到 Tile Buffer。正确的设置应当是 LOAD_OP_CLEAR 或 LOAD_OP_DONT_CARE。

3. 分析 Vulkan Subpass 依赖与合并状态

如果你的引擎使用了 Vulkan Subpasses，期待通过 Subpass Input 实现“零延迟”的 G-Buffer 交互（在 Tile Buffer 内直接读取，不走外部带宽），你需要利用 RenderDoc 验证驱动是否真正成功合并了 Subpass。

• 在 RenderDoc 的 Event Browser 中，展开你怀疑的 RenderPass。
• 检查内部的 vkCmdNextSubpass。
• 如果 RenderDoc 显示在 vkCmdNextSubpass 切换时，底部的当前绑定的输出贴图（Outputs）发生了中断、甚至隐式地重新开始了新的 RenderPass 动作（可以通过 API Calls 序列面板中的 vkCmdBeginRenderPass 数量来核对），说明 Subpass 合并失败。
• 合并失败的常见诱因（在 RenderDoc 中对照检查）：
  1. Subpass 之间的依赖 VkSubpassDependency 设置了非必要的 Pipeline Stage 屏障。
  2. 在 Subpass 1 中读取的 Attachment，其纹理采样器在 Subpass 2 中被以普通 SampledImage 的形式进行了非局部化（Non-local）采样（即采样了非当前像素坐标的 Neighbor 像素）。

三、 量化分析：如何推导 Tile Buffer 溢出带来的带宽损耗

RenderDoc 不直接提供 MB/s 物理带宽数据，但我们可以通过以下公式，基于 RenderDoc 捕获的贴图分辨率、格式规格以及 Load/Store 状态，计算出该 Pass 由 Tile Buffer 机制失效产生的理论 DRAM 额外带宽开销。

带宽损耗量化公式

对于一个给定的 RenderPass（分辨率为 $W \times H$，多重采样数为 $N$（如无 MSAA 则 $N=1$））：

$$\text{DRAM Write Bandwidth (Bytes)} = \sum_{i \in \text{StoreAttachments}} (W \times H \times N \times \text{BytePerPixel}_i)$$

$$\text{DRAM Read Bandwidth (Bytes)} = \sum_{j \in \text{LoadAttachments}} (W \times H \times N \times \text{BytePerPixel}_j)$$

注：若对应的 LoadOp / StoreOp 为 DONT_CARE，则对应的 $\text{BytePerPixel}$ 在公式中计为 0。

实战推算案例：

假设在 RenderDoc 中捕获到以下 RenderPass 状态：

• 分辨率 (W x H): $2400 \times 1080$ (2K 档位移动端主流分辨率)
• MSAA: 4x
• Color Attachment 0: R8G8B8A8_UNORM (4 字节/像素), LoadOp=CLEAR, StoreOp=STORE (需要 Resolve 并保留)
• Depth Attachment: D24_UNORM_S8_UINT (4 字节/像素), LoadOp=CLEAR, StoreOp=STORE (错误配置)

1. 错误配置下的 DRAM 理论读写吞吐（不考虑硬件压缩）：

• Color 写入 (Resolved, 1x 采样写入系统内存):
  $$2400 \times 1080 \times 1 \times 4 \text{ Bytes} \approx 10.37 \text{ MB}$$
• Depth 写入 (因 StoreOp=STORE，触发 4x MSAA 物理数据写回):
  $$2400 \times 1080 \times 4 \text{ MSAA} \times 4 \text{ Bytes} \approx 41.47 \text{ MB}$$
• 该 Pass 总带宽消耗：$10.37 \text{ MB} + 41.47 \text{ MB} = \mathbf{51.84 \text{ MB}}$

2. 正确优化后的理论吞吐（将 Depth 的 StoreOp 修改为 DONT_CARE）：

• Color 写入: $10.37 \text{ MB}$
• Depth 写入: $0 \text{ MB}$（4x MSAA 的深度数据只在 Tile Buffer 内部存在，绘制结束直接丢弃）
• 该 Pass 总带宽消耗：$\mathbf{10.37 \text{ MB}}$

量化结论：仅通过修改 RenderDoc 中定位出来的这一处 Depth StoreOp 漏洞，即可为这一帧画面减少约 41.47 MB 的物理 DRAM 写入带宽。如果游戏运行在 60 FPS，这相当于挽救了 2.48 GB/s 的带宽红线！

四、 深度排查：利用 RenderDoc 规避 Tile Buffer 溢出的优化策略

通过 RenderDoc 定位问题后，在引擎或应用层可针对性实施以下优化：

1. 严格落实 Vulkan 延迟分配（Transient Attachment）

对于只在 RenderPass 内部作为中间产物（如 G-Buffer、MSAA Target）的纹理，在 Vulkan 中创建其 VkImage 时：

• 必须声明 VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT。
• 分配内存（VkDeviceMemory）时，必须指定 VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT。
• 这样，物理驱动在分配时只会给它分配虚拟地址，而不分配实际的物理显存。只要配置了 DONT_CARE，这些数据终其一生都只会保留在 Tile Buffer（SRAM）中，彻底避免内存占用与 Spill。

2. G-Buffer 压缩与重构（Bits Budget Control）

如果在 RenderDoc 的 Pipeline State 中发现 G-Buffer BPP 超过了 128 bits，可以考虑采用以下重构方案降低单像素位宽：

3. 高效处理 4x MSAA Resolve

移动端上进行 MSAA 渲染时，若想零带宽开销，必须在同一个 RenderPass 结束时利用物理硬件的 Resolve Unit（通常直接集成在 Tile Buffer 外围）完成降采样，然后直接丢弃多重采样（Multisampled）的原始 Attachment：

// 移动端完美的 MSAA RenderPass Attachment 配置示意
VkAttachmentDescription attachments[2];

// 0: 多重采样中间缓冲 (MSAA Image)
attachments[0].format = VK_FORMAT_R8G8B8A8_UNORM;
attachments[0].samples = VK_SAMPLE_COUNT_4_BIT;
attachments[0].loadOp = VK_ATTACHMENT_LOAD_OP_CLEAR;
attachments[0].storeOp = VK_ATTACHMENT_STORE_OP_DONT_CARE; // 关键：千万不要写入系统内存！

// 1: 最终呈现的单采样缓冲 (Resolve Target)
attachments[1].format = VK_FORMAT_R8G8B8A8_UNORM;
attachments[1].samples = VK_SAMPLE_COUNT_1_BIT;
attachments[1].loadOp = VK_ATTACHMENT_LOAD_OP_DONT_CARE;
attachments[1].storeOp = VK_ATTACHMENT_STORE_OP_STORE;     // 只将 Resolve 后的结果存盘

在 RenderDoc 的 Resource Manager 中，确认多重采样的 Attachment 确实没有任何其他的 vkCmdCopyImage、vkCmdResolveImage 或外界采样（Descriptor Sets）行为。如果有，说明你的 Resolve 没有在 Tile Buffer 内部安全闭环，而是走了解析到外部再二次拷贝的“慢速通道”。

五、 总结与排查清单

利用 RenderDoc 抓取帧数据后，请按照以下速查清单快速审阅：

1. 核算 BPP：当前 RenderPass 内绑定的所有 RT 的位宽之和是否控制在 128 bits（中低端机型）或 256 bits（高端机型）以内？
2. 清扫 StoreOp：是否有临时贴图（尤其是 Depth/Stencil 缓冲）在不需要保留的情况下，其 StoreOp 被误设为了 STORE（或 OpenGL 中漏掉了 glInvalidateFramebuffer）？
3. 清扫 LoadOp：是否有能够被 Clear 或完全 Coverage 覆盖的 RT，其 LoadOp 被误设为了 LOAD 从而引入了多余的 DRAM 读取？
4. 检测 MSAA：多重采样贴图的 storeOp 是否被设置为 DONT_CARE？Resolve 过程是否与 Draw Pass 位于同一 RenderPass 内部？
5. 验证 Subpass 合并：检查 Vulkan 中需要依赖 Tile 内数据共享的 Subpass，其数据格式是否为 TRANSIENT，驱动是否因不当的 Barrier 阻断了 Subpass 的物理合并？