关于MIO/L1TEX的“长”和“短”记分板是什么？

Question

最近的NVIDIA微架构中，有一个新的warp stall原因/ warp调度器状态的分类 （taxonomy） 。

该分类有两个条目：

- 短暂的分数牌（Short scoreboard）- 分数牌依赖于MIO队列操作。 - 长期的分数牌（Long scoreboard）- 分数牌依赖于L1TEX操作。

这里的“分数牌”被用于乱序执行数据依赖跟踪的意义（例如参见这里）。

我的问题是：

- “短”或“长”形容词描述的是什么？是单个分数牌的长度还是针对两种不同类型的操作使用了两个不同的分数牌？ - MIO和 L1TEX 操作之间这种看似不符合直觉的二分法的含义是什么？它只关于stall原因还是实际硬件？

- einpoklum

Answer 1

NVIDIA GPU有两种指令分类：

1. 固定延迟 - 数学、位运算、寄存器移动等
2. 可变延迟 - ld/st到shared、local、global和texture，以及较慢的数学运算

在依赖于从可变延迟指令返回数据的指令上报告了“短记分板”和“长记分板”。短记分板报告来自不会离开SM的可变延迟指令（例如缓慢的数学运算，如倒数平方根或共享内存）的依赖关系。长记分板则报告可能离开SM的依赖关系，例如全局/本地内存访问和纹理获取。

详细描述来自Nsight Cmpute v2020.3.1 Kernel Profiling Guide

长记分板

Warp由于等待对L1TEX（本地、全局、表面、纹理）操作的记分板依赖而被阻塞。为减少等待L1TEX数据访问所需的周期数，请验证内存访问模式是否针对目标架构最佳，尝试通过增加数据局部性来提高缓存命中率，或通过更改缓存配置，并考虑将经常使用的数据移动到共享内存。

短记分板

Warp由于等待对MIO（内存输入/输出）操作（不是L1TEX）的记分板依赖而被阻塞。导致短记分板高数量的主要原因通常是与共享内存的内存操作有关。其他原因包括频繁执行特殊数学指令（例如MUFU）或动态分支（例如BRX、JMX）。请验证是否存在共享内存操作并减少银行冲突（如果适用）。

MIO与L1TEX

MIO和L1TEX是NVIDIA SM中的分区。MIO单元负责共享执行单元（由一个或多个SM子分区共享），包括较低速率的数学单元（例如在GeForce芯片上的双精度）和内存输入/output。存储器子系统包含L1、TEX单元、共享内存单元和其他面向特定领域（例如图形）的接口到SM。MIO子系统的实现，包括L1、TEX和共享内存，在Kepler、Maxwell-Pascal和Volta-Ampere之间有很大差异。SM子分区（warp调度器）通过指令队列而不是直接分派向共享执行单元发出指令。对于SM 7.0+，如果这些单元的指令队列已满，则会出现阻塞原因（mio_throttle、lg_throttle和tex_throttle）。

MIO的定义因架构而异。L1TEX在技术上属于MIO分区。由于L1TEX有两个输入接口，因此它很复杂：

1. LSU接口用于共享内存、本地/全局内存（带标记）以及特殊操作（例如洗牌和特殊寄存器）。
2. TEX接口用于纹理获取，而在7.0-8.x上，还包括一部分慢速数学运算（例如GeForce卡上的FP64）。后者有点令人困惑。慢速数学单元存在于二进制兼容性，不应与纹理获取同时使用。

MIO这个术语可能会让人感到困惑。 L1TEX这个术语也可能令人困惑，因为存在两个不同的接口。虽然有两个接口（本地/全局和纹理/表面），但它们共享相同的缓存查找阶段、相同的缓存RAM和相同的SM到L2接口，因此在许多指标中，术语L1TEX用于指代该单元。

- Greg Smith

---

编译器是否已经展开循环以隐藏慢指令的延迟（或架构是否通过从不同线程运行指令隐式地完成了这一点）？还是尝试进行软件流水线以隐藏慢操作的延迟，而不是立即尝试使用它们的结果，能否发挥作用？这将有助于流水线内顺序处理器。 - Peter Cordes

答案的第一部分很有帮助；从我刚刚链接的分析指南中引用-不太有用，特别是因为它没有提供问题和/或您的答案已经提供的信息。 - einpoklum

编译器通常会积极尝试展开循环，主要目的是为了独立指令重新排序，以允许长延迟指令首先发出。可以参考这里。通过二进制分析工具和适当的代码，这很容易在实验中观察到。即使没有循环展开，编译器也会尝试尽早重新排列独立的负载。 - Robert Crovella