移动端部光源延迟渲染和阴影计算共用同一个Framebuffer 会提升性能吗

这是一个非常专业且切中要害的问题。直接回答你的结论：

在绝大多数情况下，尝试让“阴影生成（Shadow Calculation）”和“延迟渲染的光照计算（Lighting Pass）”共用同一个 Framebuffer Object (FBO) 是不可行的，且不会带来性能提升，反而可能导致严重的逻辑错误或性能下降。

但如果你是指 “共用显存（Memory Aliasing）” 或者利用 “Tile-Based 架构特性（Subpasses/PLS）”，则有优化的空间。

我们需要把这个问题拆解开来，从原理和移动端硬件架构（TBDR）两个角度来分析。

1. 为什么不能简单共用 FBO？（逻辑与物理限制）

首先要明确两个阶段的工作内容：

  • 阴影计算 (Shadow Gen): 从光源视角渲染场景，输出到深度纹理 (Shadow Map)。
  • 光照计算 (Lighting Pass): 从相机视角渲染全屏 Quad（或光体积），读取 G-Buffer 和 Shadow Map，输出颜色。

A. 视角不同 (View Matrices)

  • 冲突： Framebuffer 对应一个特定的渲染视角。你不能在一个 Pass 里同时既从“相机”看，又从“灯光”看。
  • 后果： 你必须切换 View Matrix 和 Projection Matrix。这意味着你必须结束当前的 Draw Call 序列，这本质上就是两个独立的渲染流程。

B. 分辨率不同 (Resolution Mismatch)

  • 冲突：
    • Deferred Lighting: 必须和屏幕分辨率一致（例如 $1920 \times 1080$），或者是其缩放版（如 0.5x）。
    • Shadow Map: 通常是正方形的幂次方大小（例如 $1024 \times 1024$ 或 $2048 \times 2048$）。
  • 后果： 每次切换用途，你都需要调用 glViewport 并重新 Attach 只有特定大小的纹理。这比直接切换两个预设好的 FBO 开销更大（驱动层校验状态的成本）。

C. 附件需求不同 (Attachments)

  • Shadow Gen: 只需要 Depth Attachment（不需要 Color）。
  • Lighting Pass: 需要 Color Attachment（累积光照），且通常以 Texture 的形式读取 Shadow Gen 生成的 Depth Texture。
  • 死锁： 你不能一边往纹理 A 里写深度（生成阴影），一边在同一个 FBO 的 Shader 里采样纹理 A（计算光照）。这会触发 **Texture Loop (Feedback Loop)**，在 OpenGL ES 中是未定义行为，结果通常是黑屏或闪烁。

2. 移动端的真正痛点：带宽 (Bandwidth)

在移动端（Adreno, Mali, Apple GPU），性能杀手通常不是 Draw Call 数量，而是 System Memory Bandwidth（系统内存带宽）。

标准延迟渲染 + 阴影的流程：

  1. Shadow Pass (FBO A): 渲染几何 -> 写出深度到显存 (Store Action)。
  2. G-Buffer Pass (FBO B): 渲染几何 -> 写出 Albedo/Normal/Depth 到显存 (Store Action)。
  3. Lighting Pass (FBO B 或 C): 从显存读取 ShadowMap + G-Buffer (Load Action) -> 计算 -> 写出最终颜色。

共用 FBO 无法减少这些 Load/Store 操作，因为阴影图必须生成完，才能被光照阶段读取。

3. 可行的优化方向（你可能想问的是这些）

虽然“共用 FBO”不可行，但在移动端做延迟渲染和阴影，有以下几种真正有效的“共用”或“合并”优化技术：

方案 A：显存别名 (Memory Aliasing / Transient Attachments)

如果你想省内存（显存占用），而不是省 FBO 对象：

  • 原理： G-Buffer 的纹理通常很大（全屏）。如果 Shadow Map 生成后，在 Lighting Pass 使用完之后就不再需要了，你可以复用显存。
  • 但在延迟渲染中很难： 因为 Lighting Pass 同时 需要采样 G-Buffer 和 Shadow Map。你不能覆盖掉其中任何一个。
  • 唯一机会： 如果你有多个光源，且是串行计算的。
    • 计算 Light 1 的 Shadow Map -> 累积 Light 1 光照 -> 丢弃 Shadow Map 1。
    • 复用这块显存给 Light 2 的 Shadow Map。
    • 缺点： 频繁的渲染目标切换（Context Switch）在移动端是大忌，打断了 Tiler 的流水线，性能通常不如一次性生成好所有 Shadow Map。

方案 B：利用 TBDR 特性的 Subpasses (Vulkan) / PLS (OpenGL ES ext)

这是移动端延迟渲染的核心优化，但主要针对 G-Buffer 和 Lighting 的合并，而非阴影生成。

  • 技术： Pixel Local Storage (PLS) 或 Vulkan Subpasses。
  • 做法：
    • G-Buffer 生成后，不写出到系统内存，而是直接保留在 GPU 的 Tile Memory (On-chip buffer) 中。
    • 紧接着在同一个 Tile 上执行 Lighting Pass。
  • 对阴影的影响：
    • 阴影贴图（Shadow Map）依然必须 先在另一个独立的 Render Pass 中生成并写出到内存。因为阴影需要全局几何信息，而 Tile Memory 只能看到当前 Tile 的像素。
    • 提升点： 这样做节省了 G-Buffer 的 Load/Store 带宽，留给读取 Shadow Map 的带宽就更充裕了。

方案 C：聚光灯/点光源的阴影优化 (Shadow Mask)

如果你的场景有很多灯光。

  • 不要为每个灯光都在 Lighting Pass 里采样一遍 Shadow Map。
  • 优化： 先在一个屏幕空间的单通道纹理（Screen-space Shadow Mask）上，把所有阴影的遮挡关系算好（0 或 1）。
  • 共用： 这个 Shadow Mask 可以复用 G-Buffer 的一个通道（比如 Specular 的 Alpha 通道，如果没用的话），但这极度依赖具体实现。

4. 总结与建议

结论：
不要尝试让“阴影生成”和“光照计算”共用同一个 FBO。由于视角、分辨率和读写依赖的冲突，这是不可行的。

推荐的移动端高性能方案：

  1. 独立的 Shadow Pass FBO：

    • 使用 16-bit Depth (GL_DEPTH_COMPONENT16) 而非 24/32 位，减少带宽。
    • 如果可能，使用较小的分辨率（512/1024）。
    • 开启 Variance Shadow Map (VSM) 或 EVSM 可以尝试避免一些高频的 PCF 采样开销，但显存占用会变大，需权衡。

  2. 利用 Subpasses (Vulkan) / Framebuffer Fetch (GLES)：

    • 将 G-Buffer Pass 和 Lighting Pass 合并。这是提升移动端延迟渲染性能的“银弹”。
    • Shadow Map 依然作为外部纹理（Texture Input）被 Lighting Pass 读取。

  3. 剔除与级联 (Culling & Cascades)：

    • 严格控制 Shadow Pass 绘制的物体数量（Shadow Culling）。
    • 移动端尽量只用 1 级级联（CSM），或者仅对主角/近处物体产生阴影。

通过合并 G-Buffer 和 Lighting 阶段（利用片上内存），并精简 Shadow Map 的生成开销（分辨率、位数、物体数量），才是移动端正确的优化路径。

×