GPU 指令格式 [下]

hdy

Dependency Counter

GPU 指令格式 [上]文中，older指令通过递增dependency counter，在写回或者读取完毕寄存器之后，递减dependency counter。younger指令通过判断dependency counter是否为0来判断目前指令之间的WAR和RAW依赖是否已经处理完毕。这个dependency counter每个warp都有，共计6个，用于track variable-latency的依赖关系。上文中依赖关系也是三条Load指令和IADD之间的依赖关系。LD指令因为访问memory，考虑到hit miss cache的不同情况，因此属于variable-latency 指令。

---

Stall Counter

那么如果older指令是ADD这样 fix-latency 的指令，指令之间存在依赖关系，是否存在更简单的做法呢？首先编译器可以通过指令重排序，将older指令和younger指令之间插入无关的指令，这样younger指令在执行时，older指令已经自动的释放了相关的依赖。如果找不到可以插入的无关指令呢？此时编译器会在指令中加入stall counter，下图中粉色所示内容。

编译器将这个counter设置为：producing instruction的latency 减去 producing instruction和first consumer指令之间的指令数目。GPU对于每个WARP都有自己的counter register。在producing instruction发射时，根据stall counter的数值增加warp的counter register。此后每个周期减1。后续属于该warp的任何指令在发射时，都检查该counter register是否为0，如果非0，则停止发射。这样存在依赖关系的后续指令一定要等待counter register为0，解决了依赖关系的判断。

---

Yield Bit

指令中还存在的一个bit即为yieldbit，该bit如果使能，则建议硬件在下一个周期不应当发射同一个warp中的下一条指令，即建议在下一个周期发射其他warp的指令。那么说了这么多，有什么用呢？

---

Deepseek

那么说了这么多，有什么用呢？我们知道deepseek的一个创新即为利用混合精度FP8-FP32计算降低了对算力的需求，【论文速递】deepseek 从 V3 到 R1。deepseek在开源日公布了其deepgemm矩阵计算：
https://github.com/deepseek-ai/DeepGEMM

其中有意思的是上面这一条：deepseek把相同的程序用NVCC12.2和NVCC12.3编译，发现性能提升。但是编译的二进制实际上只改变了1个bit。deepseek确定改变的这个bit为control yield bit。于是deepseek编写脚本，将二进制中对应的yield bit反转。在某些情况下，单单反转bin中的bit就带来了10%的性能提升。