B200流水线模型的案例研究 方法学说明：本文中的一切基于我对直接在B200硅片上执行的微基准测试的分析。Nvidia并未发布其GPU的指令延迟、流水线深度或记分板编码细节。这里描述的数字和机制代表了我最好的经验理解。读者应自行尽职调查，并对照自己的硬件进行验证。在处理现代的深流水线GPU（如Nvidia B200）时，静态分析是必要的，但不足以验证指令调度。看到调度器报告100%依赖关系跟踪测试覆盖率，却在实际硅片上看到发出的代码默默失败，这是一种谦卑的经历。这是怎么发生的呢？硬件流水线本身是正确性的最终裁决者。当调度器过早释放一个依赖关系时，它允许一个消费指令在生产者的结果尚未可靠地提交到寄存器文件之前进入流水线。硬件不会引发异常。相反，它执行调度，读取过时的状态，并将不正确的值传播到其余计算中。这些并不是硅片中的缺陷。它们是调度违规，硬件暴露了编译器的不正确假设。在编译器后端，编译器工程师通常遵循以下规则：过早释放是性能错误，但过迟释放是静默的正确性错误。为了捕捉这些问题，我构建了一个硬件危险登记册，1 基于最小的、可重复的硅片测试。 先决条件和术语 在深入探讨具体的B200危险之前，建立一些基本背景是有帮助的： 指令调度：编译器后端的一个阶段，重新排序指令以最大化硬件利用率。它必须显式编码延迟（停顿）或依赖指令之间的同步（记分板）。 流水线深度：指令通过的阶段数（取指、解码、执行、写回）。更深的流水线完成指令所需的时间更长。 RAW（读后写）危险：一种情况，在这种情况下，一个指令试图在前一个指令写入完成之前读取一个寄存器。 可变延迟操作：执行时间不是固定的操作。这包括全局存储加载（LDG）、共享存储操作（LDS）、原子操作（ATOM）和多功能单元（MUFU）。 硅片不会说谎 现代GPU流处理单元（SMs）被设计为极大的吞吐量。为了实现这一点，流水线很深。硬件依赖编译器显式编码依赖性信息。考虑一个简单的数据流路径，其中指令A生成一个指令B使用的值。流程图： 子图“生产者（指令A）”：取指A[取指] --> 解码A[解码] --> 发射A[发射] --> 执行A1[执行阶段1] --> 执行A2[执行阶段N] --> 写回[写回到寄存器] 子图“消费者（指令B）”：取指B[取指] --> 解码B[解码] --> 发射B{等待停顿/记分板} --> 读取寄存器[读取寄存器] --> 执行B1[执行阶段1] 写回 -->|数据转发/寄存器文件| 读取寄存器 发射A -.->|静态延迟L| 发射B 如果指令B过早发射，其读取寄存器阶段会在写回完成之前获取寄存器的旧内容。在CPU上，复杂的乱序执行引擎动态掩盖这些延迟。在GPU上，哲学是最大化ALU的芯片面积。这将指令调度的复杂性推向编译器。这让人想起VLIW架构，这种架构的哲学是将调度决策从硬件推卸给编译器。这种架构权衡意味着编译器工程师必须对流水线深度和屏障编码等低级约束非常严格。 条件消费者的过早释放 最难的错误往往会在严格的静态检查中溜走。最近，在修改B200时，我发现一个涉及指令调度器中的谓词评估的关键错误。尽管静态指标声称在测试套件中的完整RAW覆盖，但这仍然发生。该模式涉及一个整数集谓词指令（ISETP），该指令计算一个条件。它将其写入一个谓词寄存器，该寄存器随后被一个分支指令读取。这在通常的后边缘分支定义一个循环的场景中是经典的。 // 1. 根据某个条件生成谓词P1。// R0和R1进行比较；布尔结果写入P1。ISETP.GE.AND P1, PT, R0, R1, PT; // 2. 将P1作为分支目标条件进行使用。// P0是执行保护（线程是否活跃？），P1是分支条件。@!P0 BRA P1, target; 错误机制 这个错误在我修改B200的谓词处理时浮出水面。编译器正确地记录了守护谓词P0作为分支的使用，但遗漏了分支条件操作数P1。