3、GPU调度与同步：从提交到显示的全链路
GPU调度与同步，说白了就是解决「谁先谁后」的问题。CPU提交了绘制命令，GPU什么时候开始执行？两个渲染任务之间怎么保证不打架？交换链又是怎么把画面送到屏幕上的？
我刚开始接触图形驱动时，总觉得这些机制离业务很远。直到有一次做动画优化，发现帧率死活上不去，最后定位到是CPU在等GPU完成——同步点放错了位置。嗯，从那以后我再也不敢轻视这块了。
3.1 GPU命令提交：CPU怎么跟GPU说话
CPU和GPU是两套独立的执行单元。CPU没法直接调用GPU的函数，它们之间靠的是命令缓冲区（Command Buffer）。
你可以把命令缓冲区想象成一张「待办清单」。CPU把绘制指令、状态切换、资源绑定等操作，一条一条写进这个缓冲区。然后通过一个系统调用，把整张清单提交给GPU去执行。
核心流程：
- CPU 填充命令缓冲区（Record）
- CPU 提交缓冲区到队列（Submit）
- GPU 从队列取出并执行（Execute）
- CPU 继续做下一帧的准备（Pipeline）
这里有个关键点：提交是非阻塞的。CPU把命令扔给GPU后，不会傻等它执行完，而是立刻返回继续干活。这就带来了同步问题——你没法确定GPU到底执行到哪一步了。
我的习惯：在驱动开发中，我会把命令缓冲区按帧预分配好。每帧用独立的缓冲区，避免上一帧还没执行完就被覆盖。这个做法在Vulkan和DX12里尤其重要，因为它们把内存管理完全交给了开发者。
3.2 Fence机制：GPU的「进度条」
Fence（栅栏）是CPU和GPU之间最基础的同步原语。它本质上是一个信号量，GPU执行到某个点后会把它置为「 signaled 」状态。CPU可以查询这个状态，或者阻塞等待它变成 signaled。
为什么会需要Fence？举个例子：
- CPU要读取GPU渲染好的画面做后处理——必须等GPU写完
- CPU要复用一块显存——必须等GPU用完
- CPU要提交下一帧的命令——必须确保上一帧的队列已经清空
Fence的使用模式大致是这样：
// 伪代码示例
Fence fence = CreateFence();
// CPU提交命令，并关联一个fence
CommandQueue->Submit(commandBuffer, fence);
// CPU继续做其他事...
UpdateGameLogic();
// 需要GPU结果时，等待fence
fence->Wait(UINT64_MAX); // 阻塞直到GPU完成
// 现在可以安全读取渲染结果了
ReadRenderTarget();我曾经踩过的坑：在某个项目中，我用了轮询方式检查Fence状态——每帧在循环里调用GetCompletedValue()。结果CPU占用率飙升，反而拖慢了整体帧率。正确的做法是用Wait()阻塞，或者用事件回调机制。别让CPU空转去等GPU。
3.3 CPU-GPU同步：三种常见模式
CPU和GPU的同步，说白了就是「谁等谁」的问题。我总结了三种常见模式：
| 模式 | 描述 | 适用场景 | 性能影响 |
|---|---|---|---|
| CPU等待GPU | CPU阻塞，直到GPU完成指定任务 | 读取渲染结果、资源回读 | 高（CPU空转） |
| GPU等待GPU | 两个GPU任务之间用Semaphore同步 | 计算着色器与渲染管线协作 | 低（硬件调度） |
| 无等待（异步） | CPU和GPU各干各的，靠Buffer交换链解耦 | 游戏渲染、实时动画 | 最低（理想状态） |
你想想看，最理想的情况当然是第三种——CPU和GPU像两条流水线并行跑。但现实往往需要你在关键节点上做同步，否则就会出现画面撕裂、资源竞争等问题。
我的建议：尽量把同步点放在帧边界上。比如在帧开始处等待上一帧的Fence，而不是在帧中间频繁同步。这样可以最大化CPU和GPU的并行度。
3.4 Buffer交换链（SwapChain）：画面怎么送到屏幕
交换链是连接渲染结果和显示设备的桥梁。它维护了一组后台缓冲区（Back Buffer），CPU/GPU往里面写画面，显示控制器从里面读画面。
最简单的交换链只有两个缓冲区——双缓冲（Double Buffering）。一个叫「前台缓冲区」（Front Buffer），正在被显示器扫描；另一个叫「后台缓冲区」（Back Buffer），GPU正在往里面画。画完后，交换链执行一次「翻转」（Flip/Present），把前后台互换。
但双缓冲有个问题：如果翻转发生在显示器扫描的中间，画面会上下半帧不一致——这就是撕裂（Tearing）。
解决方案是垂直同步（V-Sync）：让翻转只在显示器垂直消隐期（VBlank）发生。代价是帧率会被锁定在显示器刷新率（比如60Hz），如果GPU画不完一帧，就得等下一轮VBlank，造成卡顿。
现代交换链支持三重缓冲（Triple Buffering）：三个缓冲区轮流使用，CPU和GPU的等待时间更少，帧率更平滑。但代价是显存占用增加，输入延迟也会略微上升。
交换链的关键参数：
- 缓冲区数量：2（双缓冲）或3（三重缓冲）
- 同步模式：立即（Immediate）、垂直同步（VSync）、自适应（Adaptive）
- 格式：RGBA8、BGRA8、10位色深等
- 尺寸：通常匹配窗口或全屏分辨率
3.5 全链路流程图
下面这张图展示了从CPU提交命令到画面显示在屏幕上的完整流程。我把它画成了SVG，方便你理解各组件之间的关系。
3.6 实战中的避坑指南
讲完了理论，我分享几个实际项目中遇到的坑：
- Fence等待超时：我曾经在某个驱动里把Fence的等待时间设成了无限（UINT64_MAX），结果GPU崩溃后整个应用卡死。后来我加了超时机制，超时后主动重置GPU，至少能让应用恢复。
- 交换链尺寸变化：窗口大小改变时，交换链需要重建。如果重建期间还在提交旧缓冲区的命令，就会触发异常。我的做法是在窗口Resize事件中先等待所有GPU任务完成，再重建交换链。
- 三重缓冲的延迟：三重缓冲虽然帧率平滑，但输入延迟会比双缓冲高1-2帧。对于竞技类游戏，我建议用双缓冲+自适应VSync，兼顾延迟和画面完整性。
- 多队列同步：现代GPU支持多个命令队列（图形、计算、复制）。不同队列之间的同步需要用Semaphore，而不是Fence。我见过有人混用这两种原语，导致死锁。
重要提醒：交换链的Present()调用必须和VSync对齐。如果你在VBlank期间频繁调用Present()，显示器可能来不及处理，造成丢帧。我一般会在Present()前后加性能计数器，监控实际翻转频率。
3.7 小结
GPU调度与同步，核心就是三件事：命令怎么提交、进度怎么同步、画面怎么交换。Fence是CPU-GPU之间的握手信号，交换链是渲染结果到屏幕的桥梁。理解这些机制，你才能写出既高效又稳定的渲染代码。
嗯，这一章的内容就到这里。记住：同步点放对位置，比什么都重要。