1
ARM Mali / Qualcomm Adreno / Apple GPU 的工作方式：
2

3
1. CPU 提交所有 DrawCall → GPU 先只跑顶点着色器
4
2. 将屏幕切成 Tile（通常 16×16 或 32×32 像素）
5
3. 对每个 Tile：
6
   a. 将 Tile 的帧缓冲加载到片上 SRAM（极快——~50 GB/s）
7
   b. 对这个 Tile 涉及的所有片元跑片元着色器 + 深度测试 + 混合
8
   c. 将 Tile 的最终颜色写回显存
9
4. 重复下一个 Tile
10

11
特征：
12
  - 帧缓冲在片上 SRAM 中——深度/颜色读写极快
13
  - 带宽极小（中端手机 ≈ 30-50 GB/s——PC 的 1/20）
14
  - 功耗敏感（靠电池，< 5W）
15
  - Overdraw = 直接的性能杀手（每个 Tile 的 SRAM 容量有限）

1
Tile-Based GPU 的核心优势是帧缓冲在片上 SRAM 中。
2
但这也带来了一个问题：每个 Tile 开始渲染之前，
3
GPU 需要把显存中的旧数据加载到 Tile SRAM（Load），
4
渲染完之后把 Tile 的最终颜色写回显存（Store）。
5

6
这两个操作本身就消耗带宽。如果你不需要旧数据，
7
或者最终颜色不需要写回，可以跳过这些步骤——
8
这就叫 Load/Store Action。
9

10
Vulkan:
11
  VkAttachmentDescription {
12
      loadOp  = VK_ATTACHMENT_LOAD_OP_CLEAR / LOAD / DONT_CARE
13
      storeOp = VK_ATTACHMENT_STORE_OP_STORE / DONT_CARE
14
  }
15

16
Metal:
17
  MTLRenderPassDescriptor {
18
      loadAction  = MTLLoadActionClear / Load / DontCare
19
      storeAction = MTLStoreActionStore / DontCare
20
  }
21

22
Unity (URP/HDRP 底层——Vulkan/Metal 平台自动映射):
23
  通常不需要手动设置，但理解它有助于理解性能：
24

25
  Load Action:
26
    Clear  = 不清除显存，直接清 Tile SRAM → 0 带宽（最优）
27
    Load   = 从显存加载旧数据到 Tile SRAM → 消耗带宽
28
    DontCare = 不保证内容——GPU 可以优化为 Clear
29

30
  Store Action:
31
    Store    = 写回显存 → 消耗带宽
32
    DontCare = 丢弃（如深度缓冲只在当前 Pass 使用 → 不用写回）
33

34
关键优化：
35
  - 深度缓冲在后续 Pass 不再使用时 → StoreAction = DontCare（省掉一次写回）
36
    1920×1080 × 32bit = 8MB 写回，60 FPS = 480 MB/s 的带宽省下来
37
  - 渲染第一帧 → 用 Clear（不加载显存上的随机数据）
38
  - 后处理 Pass 的中间 RT → LoadAction = DontCare（用上一 Pass 的输出，不需要显存旧数据）
39

40
移动端：合理使用 Load/Store Action 可以节省 20-30% 的带宽。
41
桌面端：也有用，但不如移动端关键（带宽充裕）。

1
移动端 GPU 的带宽极其有限。
2
一部中端手机的 GPU 带宽 ≈ 40 GB/s，高端 ≈ 60 GB/s。
3
作为对比，RTX 3090 ≈ 936 GB/s。
4

5
每帧带宽消耗的估算（1920×1080, 60 FPS）：
6

7
正常渲染：
8
  GBuffer 写入（4 张 RT × 32bpp）: 1920×1080×4×4 = 33 MB
9
  GBuffer 读取（Lighting Pass）: 33 MB
10
  Shadow Map（1024×1024, 32bpp）: 4 MB
11
  纹理采样（100 张贴图 × 平均 1MB/贴图, 50% Cache Hit）: 50 MB
12
  ─────────────────────────────────────────────────
13
  总计 ≈ 120 MB/帧 × 60 FPS = 7.2 GB/s
14
  占带宽的 18%（40 GB/s 的话）——还行
15

16
加了 HDR Bloom（降采样 + 升采样）:
17
  额外的 RT 读写 → +30 MB/帧
18
  总计 ≈ 9 GB/s——OK
19

20
加了 MSAA 4×:
21
  所有 RT × 4！→ GBuffer 从 33MB → 132MB
22
  总计 ≈ 15 GB/s——接近极限了，帧率会掉

1
桌面 GPU：Overdraw = 多余的片元着色器执行
2
移动 GPU：Overdraw = 多余的片元着色器执行 + Tile SRAM 被撑满
3

4
Tile SRAM 的大小有限（通常 16-32 KB），存的是这个 Tile 的：
5
  - 颜色缓冲 × 采样数（MSAA 的话 ×4）
6
  - 深度缓冲
7
  - Stencil 缓冲
8

9
一个 32×32 的 Tile，RGBA8 + 32bit Depth：
10
  颜色：32×32×4 = 4096 bytes
11
  深度：32×32×4 = 4096 bytes
12
  ─────────────────────────
13
  总共：8 KB
14

15
如果 Overdraw = 5×（同一个像素被画了 5 次）:
16
  片元着色器跑了 5 次——每次都可能去显存取纹理 → 带宽消耗 ×5
17
  其中 4 次最终被深度测试丢弃了——但带宽和算力已经浪费了

1
桌面：
2
  硬件 MSAA 4× = 几乎免费（RDNA/GCN 架构的硬件优化）
3
  帧缓冲开销增加不多（子像素共享片元着色器的输出）
4

5
移动：
6
  MSAA 4× = Tile SRAM 消耗 ×4
7
  一个 Tile 存 4 个子像素的颜色 + 深度：
8
    颜色：32×32×4×4 = 16 KB（原来 4 KB）
9
    深度：32×32×4×4 = 16 KB（原来 4 KB）
10
    ──────────────────────────────────
11
    总计：32 KB → 可能超过 Tile SRAM 上限！
12

13
  后果：GPU 必须做"Tile 分拆"——一个大 Tile 拆成更多小 Tile
14
        更多 Tile = 更多 Tile 切换开销 = 性能下降
15

16
移动端策略：
17
  中低端设备：不用 MSAA，用 FXAA（后处理——几乎零开销）
18
  高端设备：MSAA 2× 或 4×（够强的话）

1
目标：30 FPS（开放世界/RPG）或 60 FPS（动作/射击）
2

3
60 FPS 预算（16.67ms/帧）：
4
  CPU 逻辑 + AI + 物理: < 8ms
5
  GPU 渲染: < 8ms
6
    - Shadow Map 渲染: < 1ms
7
    - 不透明物体:      < 4ms
8
    - 透明/粒子:       < 1ms
9
    - 后处理:          < 1ms
10
    - UI:             < 1ms
11

12
DrawCall 预算：
13
  高端手机（iPhone 14+ / S24）: < 200
14
  中端手机（2-3 年前旗舰）:     < 100
15
  低端手机:                     < 50
16

17
纹理内存预算：
18
  高端: < 800 MB
19
  中端: < 400 MB
20
  低端: < 200 MB
21

22
半透明 Overdraw：
23
  任意屏幕位置，半透明像素叠加不超过 3-4 层

1
打开抓帧后，左侧是 DrawCall 列表，按执行顺序排列：
2

3
1. 先找"异常"的 DrawCall：
4
   - 看预览窗口——这个 DrawCall 画了什么
5
   - 看 Mesh View——顶点的输入和输出
6
   - 看 Texture Viewer——输入/输出的纹理内容
7

8
2. 常见排查：
9
   Q: "为什么这个物体没画出来？"
10
   → 找到物体的 DrawCall → 看在它之后有没有东西覆盖了它
11
   → 打开深度缓冲预览——看深度值是否正确
12

13
   Q: "为什么合批断了？"
14
   → 看相邻两个 UI DrawCall
15
   → 检查 Material 是否相同、Texture 是否是同一张图集
16

17
   Q: "为什么这里颜色不对？"
18
   → 找到这个像素所属的 DrawCall
19
   → 看 Fragment Shader 的输入（Albedo/Normal/Roughness 贴图）
20
   → 看 Shader 常量的值（Light Color、Camera Position 等）
21

22
   Q: "为什么这个 DrawCall 这么慢？"
23
   → 看 Mesh View——顶点数是不是异常多？
24
   → 看 Texture Viewer——贴图是不是过大？
25
   → 看 Fragment Shader——Shader 复杂度如何？

1
"架构上的区别——桌面是 Immediate Mode，移动是 Tile-Based Rendering。
2

3
桌面 GPU 有巨大的显存带宽（500+ GB/s），帧缓冲在显存中，
4
Overdraw 只是多算了片元着色器。
5

6
移动 GPU 把帧缓冲放在片上 SRAM 中，一个 Tile（32×32 像素）的 SRAM
7
只有 16-32 KB。Overdraw 太多会撑满 Tile SRAM，
8
GPU 必须做 Tile 拆分——更多 Tile 切换开销，性能下降。
9

10
此外移动端的带宽只有 30-60 GB/s，是桌面的 1/15-1/20。
11
每次额外的纹理采样、RT 读写都在吃这个有限的带宽。
12

13
所以移动端要特别注意——
14
能不开的后处理不开、用前向渲染而非延迟渲染、
15
压缩所有纹理、用 FXAA 替代 MSAA。"