2. Warp与线程束调度：从概念到硬件实现
好，我们正式开始第二讲。Warp这个概念，说白了就是GPU执行指令的最小单位。很多刚接触GPU设计的同学，总觉得Warp是个很玄乎的东西。其实没那么复杂，我带你一层层剥开它。
2.1 Warp到底是什么？
Warp，中文叫线程束。你可以把它想象成一个“执行小组”。这个小组里，一般有32个线程。为什么是32？嗯，这是NVIDIA定下来的规矩，AMD那边叫Wavefront，一般是64个线程。我个人习惯用32，因为大部分项目都是基于CUDA架构的。
我在项目中遇到过一件事：有个同事把Warp大小设成了16，想省面积。结果呢？调度效率直线下降，性能反而更差了。所以啊，32这个数字是经过权衡的，别乱改。
Warp的核心特征：
- 一起取指：一个Warp里的所有线程，在同一时刻执行同一条指令
- 一起执行：但数据是各自的，每个线程有自己的寄存器
- 一起完成：除非遇到分支发散，否则步调一致
重要概念：Warp是软件概念，也是硬件概念。软件上，程序员看到的是线程；硬件上，调度器看到的是Warp。这个映射关系，是理解GPU架构的关键。
2.2 SIMT执行模型：不是你想的SIMD
很多人把SIMT和SIMD搞混。我刚开始做设计时也犯过这个错。SIMD是单指令多数据，所有单元必须执行完全相同的操作。但SIMT不一样——它允许每个线程有自己的程序计数器（PC），只是大部分时候它们恰好走同一条路。
为什么会这样？你想想看，如果所有线程都走同一个分支，那SIMT退化成SIMD。但一旦遇到if-else，有些线程走A路，有些走B路，这就叫分支发散。
SIMT执行模型的关键点：
- 锁步执行：Warp内所有线程在同一周期执行同一条指令
- 独立数据：每个线程有自己的寄存器文件和局部内存
- 分支掩码：用掩码控制哪些线程活跃，哪些被屏蔽
- 序列化发散：遇到分支发散时，硬件会先执行一路，再执行另一路
避坑指南：我曾经在一个项目里，没处理好分支发散。结果一个简单的if-else，让性能直接腰斩。后来我学乖了——在写Shader或者CUDA代码时，尽量让同一个Warp里的线程走相同的分支路径。
2.3 Warp调度器基本架构
好，现在说说硬件实现。Warp调度器，说白了就是决定“下一个该执行哪个Warp”的模块。它长什么样？我给你画个草图：
Warp调度器基本结构：
+------------------+
| Warp状态表 | ← 记录每个Warp的状态（就绪/等待/完成）
+------------------+
| 调度策略逻辑 | ← 轮询/优先级/最老优先
+------------------+
| 指令发射单元 | ← 从I-Cache取指令，发射到执行单元
+------------------+
| 分支掩码管理 | ← 处理分支发散时的掩码切换
+------------------+我个人习惯把调度器分成两级：
- 全局调度器：管理所有Warp的优先级和状态
- 局部调度器：每个SM内部，负责具体的指令发射
调度策略上，我见过三种主流做法：
| 策略 | 原理 | 优缺点 |
|---|---|---|
| 轮询（Round-Robin） | 按顺序轮流发射 | 公平，但可能浪费周期 |
| 最老优先（Oldest-First） | 优先发射等待最久的Warp | 延迟低，但实现复杂 |
| 贪婪（Greedy） | 哪个Warp就绪就发哪个 | 吞吐高，但可能饿死 |
注意：实际芯片里，调度器不是单打独斗的。它要和Scoreboard（记分板）、寄存器文件、内存系统紧密配合。我曾经见过一个设计，调度器跑得飞快，但寄存器文件读端口不够，结果指令发射出去后卡在读取阶段——白忙活。
2.4 Warp状态机：从生到死
每个Warp都有自己的生命周期。我习惯用状态机来描述：
Warp状态机：
+--→ 选择（Selected）
| ↓
空闲（Idle） → 就绪（Ready） → 执行（Executing）
↑ ↓
+--- 等待（Stalled） ←---+
↓
完成（Completed）状态说明：
- 空闲（Idle）：Warp还没开始，或者已经结束。等待被分配新任务
- 就绪（Ready）：指令和数据都准备好了，就等调度器选它
- 选择（Selected）：调度器选中了它，正在取指令
- 执行（Executing）：指令正在执行单元里跑
- 等待（Stalled）：遇到长延迟操作（比如访存），暂时挂起
- 完成（Completed）：所有指令执行完毕，等待回收
这里有个细节：等待状态是性能的关键。为什么？因为GPU靠大量Warp来隐藏延迟。一个Warp在等内存数据，调度器就切换到另一个就绪的Warp。这叫零开销上下文切换——切换Warp不需要保存恢复寄存器，因为每个Warp有自己的寄存器文件。
个人经验：我曾经优化过一个调度器，把等待状态的判断逻辑提前了一个周期。结果呢？流水线气泡减少了15%。有时候，一个周期的优化，就能带来明显的性能提升。
2.5 硬件实现中的几个坑
嗯，最后聊点实战经验。实现Warp调度器时，有几个地方容易出问题：
- 状态表大小：每个SM能容纳的Warp数量，决定了状态表的深度。我见过有人设了64个Warp，结果面积爆炸。后来改成32个，性能只降了5%，面积省了30%。
- 分支掩码的存储：分支发散时，每个Warp可能有多个活跃掩码。这些掩码要存起来，不然嵌套分支就乱了。我建议用栈结构，深度至少8层。
- 调度器与执行单元的握手：发射指令时，要确保执行单元有空闲槽位。不然指令发出去没人接，就浪费了。
- 死锁预防：如果所有Warp都在等待，调度器就空转了。需要设计一个超时机制，强制唤醒某个Warp。
曾经踩过的坑：有一次，我设计的调度器在分支发散时，掩码更新逻辑出了bug。结果某些线程永远执行不到正确的分支。查了三天，才发现是状态机里少了一个状态转移条件。从那以后，我写状态机都会画完整的转移图，再逐条对照代码。
好了，这一章的内容就到这里。Warp调度器是GPU的心脏，理解它的工作原理，对你后面理解内存系统、缓存一致性、甚至整个GPU架构都有帮助。下一章，我们聊聊指令发射和流水线控制——那又是另一番天地了。