第1章 GPU调度器概述

1、GPU调度器概述：GPU计算模型、调度器在GPU架构中的位置、调度器的核心功能与性能指标

各位同学，咱们今天正式开讲GPU调度器。说实话，这个模块在GPU里就像人的大脑——它不直接干活，但所有干活的人都要听它指挥。我做了十几年芯片设计，见过不少团队把精力全砸在计算单元上，结果调度器设计得稀烂，最后性能惨不忍睹。嗯，咱们今天就把这块硬骨头啃下来。

要理解调度器，先得搞明白GPU是怎么算的。GPU用的是SIMT模型——单指令多线程。你想想看，CPU是单核单线程，一个核心跑一个线程；GPU不一样，它一个核心可以同时跑几十个线程。

为什么会这样？因为GPU的设计哲学是「用面积换吞吐」。CPU追求单线程性能，所以把大量面积给了缓存和分支预测。GPU追求并行度，所以把面积给了计算单元和寄存器。

我举个例子，一个典型的GPU warp（线程束）包含32个线程。这32个线程执行同一条指令，但操作不同的数据。说白了就是：

// 伪代码示意
for (int i = 0; i < 32; i++) {
    C[i] = A[i] + B[i];  // 所有线程执行同一指令
}

这里有个坑——分支发散。如果32个线程里有的走if分支，有的走else分支，那性能就惨了。我在项目中遇到过，一个简单的if-else语句，因为数据分布不均匀，导致warp执行时间翻了三倍。

避坑指南：我曾经在某个AI推理芯片项目中，发现调度器因为分支发散导致利用率只有40%。后来我们改了数据排布方式，把相同分支的线程尽量凑到一个warp里，利用率才提到85%。

咱们来看看调度器到底长在GPU的哪个位置。一个典型的GPU架构是这样的：

我个人习惯把调度器分成两级：全局调度器和局部调度器。全局调度器负责把线程块分配到各个SM，局部调度器负责在SM内部调度warp。

你想想看，一个GPU可能有几十个SM，每个SM又有几十个warp调度器。这调度层级一多，设计复杂度就上来了。我记得刚入行时，总觉得调度器不就是个状态机嘛，后来才发现——状态机只是表象，真正的难点在资源冲突管理和延迟隐藏。

核心要点：调度器是连接「软件线程模型」和「硬件执行单元」的桥梁。它决定了你的CUDA代码到底能发挥多少硬件性能。

调度器到底干哪些活？我总结了一下，主要有四个：

这里我重点说说warp调度。每个SM里都有多个warp，但执行单元有限。调度器需要决定：下一个时钟周期，哪个warp上执行单元？

最简单的策略是轮询调度——每个warp轮流上。但这样效率不高，因为有些warp可能在等数据。更好的策略是基于就绪状态的调度——只调度那些数据已经准备好的warp。

// 简化的warp调度逻辑
while (有活跃warp) {
    for (每个warp) {
        if (warp->状态 == 就绪) {
            发射该warp的指令;
            break;
        }
    }
}

嗯，这里要注意：warp的就绪状态取决于很多因素——数据是否从内存取回、前一条指令是否完成、寄存器是否够用等等。我建议在设计调度器时，把就绪判断逻辑做成流水线，不然一个时钟周期根本判断不完。

个人经验：我在做某款GPU时，发现warp调度器的就绪判断逻辑占了整个调度器面积的30%。后来我们做了个「预判机制」——提前一个周期预测哪些warp会就绪，这样调度延迟就降下来了。

调度器设计得好不好，不能光靠感觉。我一般看这几个指标：

你想想看，如果调度器吞吐量高但延迟也高，那说明它虽然能发指令，但发得慢。如果利用率低，那说明执行单元经常闲着——这钱就白花了。

我遇到过最头疼的问题是公平性。有些warp因为数据依赖，总是抢不到执行机会，结果整个kernel的执行时间被拖长。后来我们加了个「饥饿检测」机制——如果一个warp连续N个周期没被调度，就给它提权。

注意：性能指标之间往往有trade-off。比如提高吞吐量可能会增加延迟，追求公平性可能会降低利用率。我建议在设计初期就明确优先级——到底是吞吐优先，还是延迟优先？

好了，咱们今天把调度器的基本概念捋了一遍。说白了，调度器就是GPU的「交通指挥员」——它决定了计算资源怎么分配、什么时候分配、分配给谁。

我个人觉得，调度器设计最难的地方在于不确定性。你永远不知道下一个周期哪些warp会就绪，哪些资源会被释放。所以好的调度器设计，本质上是在做「概率预测」——根据历史行为，预测未来状态。

最后留个思考题：如果让你设计一个调度器，你会优先优化哪个指标？为什么？

下节课咱们聊Warp调度器的微架构设计，到时候我会拿一个实际项目中的调度器代码来拆解。记得提前预习一下warp的状态机模型。

公众号:蓝海资料掘金营，微信deep3321