Context Roll 是 AMD GPU 中由命令处理器（CP）触发的硬件级流水线状态更新的一种机制。当图形流水线需要切换至新的渲染状态（如混合模式、顶点处理顺序等）时，CP 将当前 context register bank的内容复制至空闲的 context register bank，并在其中加载新状态参数，以确保后续绘制指令基于更新后的配置执行。该机制通过分布式register 的管理与 PM4 指令广播实现状态同步，其性能开销取决于 context register bank资源的空闲可用性及绘制指令的流水线占用时长。这篇文章主要用来介绍context roll 机制。
另外，"Context Roll"并不是 AMD 独有的技术，其他的 GPU 也有类似的概念来管理渲染状态切换，只是名字可能不一样，硬件资源（如寄存器组数量）也可能不同。高通 Adreno GPU 也有上下文管理机制，可能是 “State Bundles” 或 “Command Processor 上下文切换”。

关联原文关键句

1. “a ‘roll’ is when the CP asks the management block to start working on a new set of the registers because some pipeline state needs to be changed to draw correctly.”
2. “It does that by asking each block to take a copy of the current registers into a free bank, so that everything is ready to apply any new state updates by programming fresh register values.”
3. “There’s no performance impact as long as there’s a free logical context register bank to roll any new context into.”

1. 名词解释

上下文（Context）

• 定义 ：GPU 硬件为正确执行绘制操作所需的实时流水线状态集合
• 举例 ：
  • 顶点处理顺序（Primitive Order） ，比如如顺时针/逆时针判定剔除
  • 混合模式（Blend Mode） ，如透明效果如何混合新绘制的像素与framebuffer中的现有像素。
  • 纹理采样设置等，比如MSAA设置
  • 着色器的其参数，uniforms、纹理绑定位置等
• 在 Vulkan 里，大多数状态是在 Pipeline 创建时固定的，比如创建VkPipelineColorBlendAttachmentState 时填入blendEnable、cullMode、frontFace。还有一部分在Pipeline 创建时标注为动态设置， dynamicState，后面在command buffer 录制的时候提交，比较常见的比如vkCmdSetViewport、vkCmdSetBlendConstants、vkCmdSetFrontFace。
• 要注意的是，在讨论 Context Roll 时，“Context” 指的是 GPU 硬件当前所需的状态配置，而不是软件层面的 API 上下文（如 Vulkan/D3D 的 Context）。

上下文切换（Context Roll）

• 定义：GPU 切换至新流水线状态的过程，本质是将新状态加载到空闲寄存器组的硬件操作。

逻辑寄存器组（Logical Context Banks）

• AMD GPU 硬件维护 8 组上下文寄存器（实际上只有7 组可用，因为0号位置是用来存储是用来做clear的）。
• 每组存储一套完整的流水线状态，支持快速切换。

---

2. 硬件工作机制

分布式寄存器设计

• 物理分布：前面提到，这个context的“状态”存储在8 组上下文寄存器中，这些寄存器是逻辑上的概念，一组“状态”并不是真实地存储在某个寄存器里。在硬件上或者说物理是线上，一组“状态”是分散存储在 GPU 各功能模块（如计算单元、光栅化引擎）。
• 优势：降低访问延迟，提升并行性。

上下文切换流程

1. 请求切换：驱动通过 PM4 包发送状态更新指令（如 LOAD_CONTEXT_REG）。
2. 广播更新：命令处理器（CP）向所有相关模块广播新状态值。
3. 副本同步：各模块更新本地寄存器副本，确保全局状态一致性。

寄存器组占用规则

• 每个 in-flight draw（进行中的绘制指令）独占一个寄存器组，直至其完成流水线处理（End-of-Pipe, EOP）。
• 释放逻辑：EOP 阶段标记寄存器组为空闲，供新指令使用。

---

3. 性能影响与优化

性能瓶颈场景

• 大背景：只要GPU有空闲的逻辑Context寄存器组来存储新绘制的状态，就不会有性能损失。如果当需要更新context时所有逻辑context寄存器组都在使用中，就会发生停滞，需要等旧的任务完成后才会释放可用的context。
• 寄存器组耗尽：当所有 7 组均被 in-flight draws 占用时，新指令需等待空闲组。
• 场景举例：
  • 小工作量指令：当任务负载太轻，GPU 处理完当前指令后空闲，但是所有7组上下文寄存器均被占用，GPU无法立即启动新任务而空闲，导致停滞（stalls）。
  • 优化手段：
    • 批处理（Batching）（常用手段）：尽可能将使用相同材质和渲染状态的绘制任务合并提交，减少上下文切换的需求。

优化策略

策略	实施方法	目标
批量提交（Batching）	合并相同状态的绘制指令，减少切换次数（如使用 Instancing/Indirect Draw）。	降低上下文切换频率
增大单次工作量	增加单次绘制的几何复杂度或覆盖范围。	延长寄存器组占用时间，掩盖切换开销
状态分组管理	将高频切换的状态（如纹理、混合模式）分组，集中提交。	减少随机切换导致的组耗尽风险

---

4. 工具支持（Radeon GPU Profiler, RGP）

关键功能

1. 上下文切换分析：
   • 统计每帧的上下文切换次数。
   • 标记因寄存器组耗尽导致的 CP Stall（命令处理器停滞）。
2. 可视化诊断：
   • 时间线染色：不同颜色标识寄存器组使用状态，彩虹色表示频繁切换。
   • Wavefront 持续时间分析：识别过小的绘制指令。

操作示例

• 定位问题：
  若时间线中出现密集的彩虹条纹，说明上下文切换频繁，需检查相邻绘制调用的状态差异。
• 验证优化：
  优化后对比切换次数和 CP Stall 事件，确认性能提升。

---

5. 开发者行动清单

1. 编码阶段：
   • 使用 Material Sorting 对材质/状态排序，减少切换。
   • 避免在相邻绘制调用中切换高频状态（如 PSSetShaderResources）。
2. 调试阶段：
   • 在 RGP 中检查 Context Rolls Per Frame 指标，目标值 ≤ 绘制调用数的 10%。
   • 若发现 CP Stall，优先合并小绘制指令或调整状态提交顺序。

---

6. 总结与核心原则

• 核心逻辑：上下文切换的性能影响取决于 GPU 流水线的连续性，而非单纯寄存器组数量。
• 黄金法则：
  “让 GPU 保持忙碌，让寄存器组释放与新指令到达的节奏同步。”
• 终极目标：最大化 GPU 利用率，最小化流水线气泡（Bubbles）。

---

附：术语中英对照表

英文术语	中文术语
Context Roll	上下文切换
In-flight Draws	进行中的绘制指令
Command Processor (CP)	命令处理器
End-of-Pipe (EOP)	流水线末端
Banked RAMs	分组寄存器

---

Context Roll 过高的宏观原因

核心原理

Context Roll = GPU 硬件状态切换的开销

在移动 TBDR GPU（Adreno/Mali）上，每次切换 PSO 都可能触发：

• Tile memory 重新配置
• Shader core 重新加载程序
• Rasterizer/Blender 硬件单元重新设置
• 可能的 GMEM flush

---

三大宏观原因

1. PSO 数量过多

问题：项目中存在太多不同的 Pipeline State Object

根源：
├─ Material 变体爆炸
│  ├─ 每个 mesh 用不同的 material
│  ├─ 混用 Opaque/Masked/Translucent
│  ├─ 不必要的 shader 功能组合
│  └─ Two-sided、Pixel Depth Offset 等特性随意使用
│
├─ Vertex Factory 多样化
│  ├─ StaticMesh、SkeletalMesh、Foliage、Landscape 混杂
│  └─ 每种类型都生成独立的 PSO 变体
│
└─ 渲染 Pass 配置差异
   ├─ Depth prepass、BasePass、Shadow pass 配置不一致
   └─ 移动端特有 feature（HDR、MSAA）的组合

举例：
- 50 种不同 material × 3 种 blend mode = 150 个 PSO

2. PSO 切换过于频繁（排序混乱）

问题：相同的 PSO 没有批量使用，而是反复切换

根源：
├─ Draw Command 排序不当
│  ├─ 没有按 PSO hash 排序
│  ├─ 按距离排序破坏了 PSO 连续性（半透明物体）
│  └─ 场景物体摆放混乱（树、草、石头交替出现）
│
├─ Mesh 放置问题
│  └─ 你的例子：树叶纹理太分散
│     不同纹理的树 → 可能是不同 PSO → 交替绘制
│     Tree_Oak → Grass → Tree_Birch → Rock → Tree_Oak
│     (PSO_A)   (PSO_B)   (PSO_C)    (PSO_D)  (PSO_A again!)
│
└─ 动态物体插入
   └─ 角色、特效穿插在静态场景中
      破坏了静态物体的 batching

举例：
- 理想：PSO_A × 100 次 → PSO_B × 50 次 = 2 次切换
- 现实：A→B→A→B→A→B... = 150 次切换

3. PSO 缓存缺失（异步编译打乱顺序）

问题：PSO 编译延迟导致排序被破坏

根源：
├─ 首次运行或缓存未命中
│  ├─ 第一次启动游戏
│  ├─ 更新了 shader/材质
│  └─ 驱动版本变化导致缓存失效
│
├─ 异步编译的副作用
│  ├─ Frame N: PSO_X 正在编译 → 用 Fallback PSO
│  ├─ Frame N+1: PSO_X 编译完成 → 插入队列
│  └─ 原本连续的批次被打断
│
└─ 预编译不完整
   └─ 开发阶段收集的 PSO 不全
      运行时遇到新的组合 → 临时编译

举例：
- 有缓存：[PSO_A×100, PSO_B×50] = 稳定排序
- 缺缓存：[PSO_A×70, Fallback×30, PSO_B×50, PSO_A×30] = 乱序

---

你的树叶例子分析

场景描述

“画太多不同纹理的树叶”

问题拆解

假设：1000 棵树，10 种树叶纹理

潜在的 Context Roll 来源：

原因 1：每种纹理用不同 Material
├─ 10 种纹理 → 10 个 Material Instance
├─ 每个 Material 可能编译成不同 PSO
├─ 特别是如果它们有细微差异：
│  ├─ 有的开启 Two-Sided
│  ├─ 有的用 Masked、有的用 Opaque
│  └─ 有的有 Wind Animation、有的没有
└─ 结果：10 个 PSO

原因 2：树的摆放导致交替绘制
├─ 场景布局：Oak→Birch→Maple→Oak→Birch...
├─ 绘制顺序：PSO_Oak→PSO_Birch→PSO_Maple→PSO_Oak...
└─ Context roll 次数 ≈ 树的数量（最坏情况）

原因 3：纹理切换本身
├─ 即使是同一个 PSO
├─ 如果每棵树绑定不同 descriptor set（纹理）
├─ 在某些移动 GPU 上也可能触发轻微的 context roll
└─ （相比 PSO 切换影响小很多）

解决方案

优化 1：统一 Material
├─ 用 Texture Atlas 或 Texture Array
├─ 所有树叶用同一个 Material
└─ 通过 UV offset 或 array index 区分纹理
   → PSO 数量：10 → 1

优化 2：按材质排序/分组放置
├─ 关卡设计时，相同树种放一起
├─ 或用 Instanced Static Mesh
└─ 让相同 PSO 的物体连续绘制
   → PSO 切换次数：1000 → 10

优化 3：确保 PSO 预编译
├─ 完整收集所有树叶 PSO
└─ 避免运行时编译打乱顺序

---

总结：宏观检查清单

当你发现 Context Roll 过高时，依次检查：

✅ 第一步：PSO 数量

// RenderDoc 或 Snapdragon Profiler 查看
Unique PSOs in BasePass: ???

- 如果 > 100 个 → Material 过于分散，需要合并
- 如果 < 50 个 → PSO 数量合理，看下一步

✅ 第二步：PSO 切换频率

// Profiler 查看 Pipeline State Changes
Pipeline Changes / Frame: ???

- 如果 > 200 次 → 排序有问题，需要优化 batching
- 如果 < 100 次 → 切换频率合理，看下一步

✅ 第三步：PSO 缓存命中率

// UE5 log
LogShaderPipelineCache: Cache hit rate: ???%

- 如果 < 90% → 缓存缺失，需要完善预编译
- 如果 > 95% → 缓存良好

✅ 第四步：场景组织

- 检查同类物体是否集中放置
- 检查是否有不必要的材质变体
- 检查透明物体是否过多（必须按深度排序）

---

最终答案

宏观上导致 Context Roll 过高的是：

1. 太多不同的渲染状态组合（PSO 数量多）
2. 这些状态切换得太频繁（排序差、场景混乱）
3. 状态准备不及时（PSO 缓存缺失）

你的树叶例子：

• 不同纹理 → 可能是不同 Material → 不同 PSO（原因 1）
• 树的摆放交替 → PSO 交替切换（原因 2）
• 首次运行 → PSO 编译延迟（原因 3）

核心优化思路：减少 PSO 种类 + 让相同 PSO 连续使用 + 预编译所有 PSO

清楚了吗？

参考链接：https://gpuopen.com/learn/understanding-gpu-context-rolls/