1. 实时系统与GPU基础

大家好，我是你们这堂课的主讲。在正式开始之前，我想先聊聊我为什么要把「实时系统」和「GPU」这两个看似不搭界的东西放在一起。

几年前我参与过一个自动驾驶的项目。当时我们用的GPU算力很强，但车辆在紧急制动时，图像处理任务居然被一个后台的日志写入任务给「卡住」了。嗯，那次差点出事。从那以后，我就开始深入研究GPU的抢占延迟问题。

说白了，实时系统和GPU的结合，是当前嵌入式和高性能计算领域最头疼的问题之一。今天我们先打好基础。

1.1 实时系统定义与分类

什么是实时系统？我个人的理解很简单：系统必须在规定的时间内对外部事件做出响应。时间到了，结果没出来，那就是失败。

你可能会问：「那和快慢有什么关系？」

关系不大。实时系统不要求「快」，它要求「确定」。比如一个工业机器人，你让它0.1秒转一次关节，它就必须每0.1秒转一次，不能有时0.05秒有时0.2秒。确定性，才是实时系统的灵魂。

硬实时系统

硬实时系统，说白了就是「错过截止时间 = 系统崩溃」。我在做航空电子设备时遇到过：飞控系统的传感器数据如果延迟超过1毫秒，控制律就会发散，飞机直接失控。这不是开玩笑的。

典型场景：

• 飞行控制系统
• 汽车安全气囊触发
• 医疗除颤器
• 核反应堆安全保护

软实时系统

软实时就宽松一些。偶尔错过一次截止时间，系统不会崩溃，但用户体验会下降。比如视频播放，偶尔卡顿一下，你还能忍，但如果每秒钟都卡，那就没法看了。

典型场景：

• 视频流媒体播放
• 在线游戏渲染
• 语音识别处理
• 部分工业监控

特性	硬实时	软实时
错过截止时间后果	系统失效/灾难	性能下降/体验变差
设计方法	最坏情况分析	统计概率保证
GPU适用性	极难（需特殊设计）	可行（需优化调度）

1.2 GPU架构概述

好，聊完实时系统，我们来看看GPU。很多人觉得GPU就是「显卡」，其实在实时系统里，GPU是一个高度并行的协处理器。

我习惯把GPU架构分成三个层次来理解：计算单元、调度单元、存储层次。

SM（流式多处理器）

SM是GPU的核心计算单元。你可以把它想象成一个「小型的多核CPU」，但它的设计哲学完全不同。CPU追求单线程性能，SM追求的是「同时处理大量线程」。

一个典型的SM包含：

• 多个CUDA核心（几十到几百个）
• 共享内存（几十KB到上百KB）
• 寄存器文件（超大，每个线程都有私有寄存器）
• 调度器（负责分配Warp）

Warp（线程束）

Warp是GPU调度和执行的基本单位。在NVIDIA的架构中，32个线程组成一个Warp。这32个线程执行相同的指令，但处理不同的数据——这就是SIMT（单指令多线程）模型。

为什么会这样设计？你想想看，如果每个线程都独立取指令、译码、执行，那指令缓存和调度逻辑会爆炸。32个线程共享一套指令单元，效率高得多。

但这里有个坑：Warp发散。如果Warp内的线程走了不同的分支（if-else），那GPU只能串行执行这些分支。我在项目中遇到过，一个简单的条件判断让性能直接腰斩。

// 糟糕的写法：Warp内线程发散
if (threadIdx.x % 2 == 0) {
    // 偶数线程执行这里
    do_complex_math();
} else {
    // 奇数线程执行这里
    do_other_math();
}

// 好的写法：避免Warp内分支
// 让整个Warp执行相同路径
if (warp_id % 2 == 0) {
    // 整个Warp都执行这里
    do_complex_math();
}

内存层次结构

GPU的内存层次，说白了就是「容量越大，速度越慢」。但和CPU不同的是，GPU的内存带宽极高，延迟也极高。

内存类型	容量	延迟	作用域
寄存器	每个线程几十个	1个周期	线程私有
共享内存	每个SM几十KB	~20个周期	Block内共享
全局内存	几GB到几十GB	几百个周期	所有线程
常量内存	64KB	~10个周期（缓存命中）	只读，所有线程

1.3 GPU在实时系统中的挑战

好了，现在我们把实时系统和GPU放在一起。问题就来了：GPU天生就不是为实时系统设计的。

我总结了三大挑战：

挑战一：抢占机制缺失

CPU有成熟的抢占机制——一个高优先级任务可以打断低优先级任务。但GPU呢？它没有。一旦你把一个Kernel提交给GPU，它就会一直运行到结束。中间你想插个更紧急的任务？对不起，等着吧。

我记得有一次调试一个实时渲染系统，一个耗时的后处理Kernel占着GPU不放，导致关键的VSync信号错过了。画面直接撕裂。嗯，那感觉真不好。

挑战二：调度不可预测

GPU的线程调度是硬件自动完成的，开发者几乎无法控制。Warp什么时候被调度、什么时候被阻塞，完全是个黑盒。对于实时系统来说，不可预测 = 不可接受。

你想想看，如果你不知道一个任务什么时候能完成，你怎么保证它能在截止时间前结束？

挑战三：上下文切换开销巨大

就算你强行打断了GPU的Kernel，上下文切换的开销也大得吓人。GPU的寄存器文件巨大（每个线程几十个寄存器，一个SM上几千个线程），保存和恢复这些状态需要毫秒级的时间。对于微秒级响应的实时系统来说，这简直是灾难。

好，第一章的内容就到这里。我们打下了基础：理解了实时系统的分类，看透了GPU的架构本质，也清楚了GPU在实时系统中的三大挑战。下一章，我会带大家深入分析GPU抢占延迟的具体来源，以及如何用工具测量它。

记住：在实时系统中，确定性比性能更重要。这是我这十几年经验里最深刻的体会。