02-memory-and-command-processor

第 2 篇：GPU 内存架构与命令处理器（GPU Memory Architecture and the Command Processor）

原文：Part 2

一句话定位

GPU 内存系统常常“带宽很高、单次访问延迟也很高”；硬件通过并发、批处理、缓存与预取隐藏延迟，而命令处理器负责顺序解释驱动提交的控制流。

高带宽不等于低延迟

• 带宽回答单位时间能搬多少数据；延迟回答一次依赖访问多久能返回。
• 宽总线、多通道和突发传输提高持续带宽，却不会自动缩短单次 DRAM 访问。
• GPU 适合同时保留很多互不依赖的工作：一批等待内存时，执行另一批。若工作缺少并行度，峰值带宽再高也可能喂不满执行单元。
• 连续、对齐、局部性好的访问更容易形成有效突发；随机小访问会浪费总线事务和 DRAM 行局部性。

内存层次的思维模型

执行单元/专用单元
      │  请求很多、粒度较小
      ▼
局部缓存 / 共享缓存 / 请求合并
      │  尽量形成连续事务
      ▼
内存控制器与分区
      │  调度 bank/row/channel
      ▼
显存或共享系统内存

对驱动而言，“资源格式 + tiling/swizzle + 压缩元数据 + 对齐”不是单纯存储细节，它决定哪些硬件单元能访问、如何形成局部性以及是否要做布局转换。

命令处理器为何特别

命令流包含状态更新、资源地址、draw/dispatch、同步和控制命令，必须在 API 可观察语义允许的范围内保持顺序。与成千上万的 shader invocation 不同，命令前端的控制流更串行，因此通常依赖：

• 取指缓冲和预取，减少等待内存；
• 紧凑、易解析的包格式；
• 将工作分派到不同引擎或流水线，并用同步包维持依赖；
• 在遇到等待条件时切换到其他可运行队列（能力取决于硬件和调度模型）。

“命令已被处理器读到”与“由它启动的工作已完成”是两回事。命令前端可以继续向后派发，而几何、像素、拷贝或计算工作仍在设备内部飞行。

状态寄存器与工作包

一种有用的抽象是：命令流先建立一组硬件状态，再发出引用这些状态的工作。真实硬件可能将状态内联进包、写寄存器、引用内存中的描述符，或缓存已构建状态对象。UMD 的关键任务是避免重复编码，同时确保状态切换与资源生命周期正确。

术语对照

英文	中文理解	易混点
bandwidth	带宽	不是单次访问速度
latency	延迟	可被并发隐藏，但不会消失
burst	突发传输	依赖连续性与对齐
memory controller	内存控制器	负责请求调度与通道/Bank 利用
command processor	命令处理器/前端	解释命令，不等于执行所有计算
packet	命令包	硬件定义的编码单元

面向 UMD/KMD 的阅读提示

• UMD：找 command stream builder、packet encoder、descriptor/state upload、ring space check。
• KMD：找队列 doorbell、ring buffer、IB（间接缓冲）提交、调度依赖和超时检测。
• 对每个“地址”问三次：这是 CPU 虚拟地址、GPU 虚拟地址还是物理/总线地址？谁负责建立映射？
• 看到 cache flush/invalidate 时，先确定可见性方向：哪个生产者写了什么，哪个消费者接下来要读什么。

自测

• 为什么小而随机的访问无法利用标称显存带宽？
• 为什么命令处理器需要强顺序，而像素着色可大规模并行？
• 一条 fence 信号命令排在 ring 尾部，能证明哪些先前工作已完成？答案取决于哪些引擎与屏障语义？

本篇总结

分析 GPU 性能时应把“数据能否批量流动”和“依赖链要等多久”分开；分析命令提交时应把“前端已派发”和“设备已完成”分开。