1. GPU驱动架构概览：理解CPU与GPU的协作模型
各位同学好，我是老张。今天咱们开始第一讲，聊聊GPU驱动的整体架构。说实话，我见过太多性能问题，根源都在于开发者没搞懂驱动是怎么工作的。你想想看，连API调用背后发生了什么都不知道，怎么去优化它？
这一章我会带大家把CPU和GPU的协作模型、驱动栈的分层结构、以及一次API调用的完整生命周期，彻底讲透。嗯，这些都是后面所有优化方案的基础。
1.1 CPU与GPU的协作模型
先问大家一个问题：CPU和GPU到底谁听谁的？
答案是CPU是老大。GPU本质上是个协处理器，它自己没法独立干活。CPU负责下发指令，GPU负责执行。我习惯把这个关系比喻成「项目经理和施工队」——CPU是项目经理，GPU是施工队。项目经理把图纸画好、材料备齐，然后喊一声「开工」，施工队就开始干活。
具体到技术层面，协作模型是这样的：
- CPU端：负责应用逻辑、场景管理、资源准备。说白了就是决定「画什么」。
- GPU端：负责渲染计算、像素填充、并行处理。说白了就是「怎么画」。
- 通信桥梁：通过命令缓冲区（Command Buffer）和同步原语（Fence/Semaphore）来协调。
我在项目中遇到过一种典型问题：CPU提交命令的速度远快于GPU执行的速度，导致命令缓冲区爆满，驱动不得不阻塞等待。这就是CPU和GPU「节奏不匹配」的典型表现。
核心要点：CPU和GPU是异步工作的。CPU提交命令后不会傻等，而是继续干自己的事。但如果你不注意同步，就会出现数据竞争或者画面撕裂。
1.2 驱动栈的分层结构
GPU驱动不是一块铁板，它分了好几层。每一层都有自己的职责。我刚开始做驱动开发时，总觉得分层是多余的，后来踩了坑才明白——不分层，你根本没法维护。
典型的GPU驱动栈分为三层：
| 层级 | 名称 | 运行空间 | 主要职责 |
|---|---|---|---|
| 用户态驱动 | UMD (User Mode Driver) | 用户空间 | API翻译、命令缓冲、资源管理 |
| 内核态驱动 | KMD (Kernel Mode Driver) | 内核空间 | 内存管理、调度、权限控制 |
| 硬件抽象层 | HAL (Hardware Abstraction Layer) | 固件/硬件 | 寄存器操作、硬件指令下发 |
1.2.1 用户态驱动（UMD）
这一层是应用开发者直接打交道的。比如你调用的OpenGL、Vulkan、DirectX API，最终都会落到UMD里处理。UMD干的事包括：
- 把高级API调用翻译成硬件能理解的命令
- 管理命令缓冲区，把多个API调用打包成一批
- 管理资源（纹理、缓冲区、着色器）的生命周期
我个人习惯把UMD看作「翻译官」。它把程序员写的「画一个三角形」翻译成GPU能懂的「顶点数据+渲染管线配置」。翻译得好不好，直接决定了性能。
避坑指南：我曾经见过一个项目，每帧调用了几千次单独的API来设置状态。每次调用都要经过UMD翻译、打包、提交。后来改成批量提交，性能直接翻倍。记住：减少API调用次数，比优化单次调用更有效。
1.2.2 内核态驱动（KMD）
KMD是驱动栈里最「敏感」的部分。它运行在内核空间，拥有最高权限。KMD负责：
- GPU内存的分配和回收
- 命令提交的调度和优先级管理
- 中断处理和错误恢复
- 多进程间的GPU资源隔离
说白了，KMD就是「管家」。它管着GPU这个「施工队」的排班表、材料仓库、以及安全门禁。任何用户态程序想用GPU，都得通过KMD来申请权限。
嗯，这里要注意：KMD的调用开销非常大。因为每次进入内核态都需要上下文切换、权限检查、数据拷贝。所以好的驱动设计会尽量减少KMD的调用次数。
1.2.3 硬件抽象层（HAL）
HAL是最底层，直接跟GPU硬件打交道。它做的事情很「脏」很「累」：
- 读写GPU寄存器
- 操作DMA引擎进行数据传输
- 处理硬件中断
- 执行固件指令
HAL的存在让KMD不用关心具体硬件型号的差异。换一块GPU，只要换HAL就行，KMD代码基本不用动。这就是抽象的好处。
1.3 API调用的完整生命周期
好了，前面讲了分层结构，现在咱们串起来看看：一次API调用，到底经历了什么？
假设你写了一句代码：glDrawArrays(GL_TRIANGLES, 0, 3)。这一句话背后发生了什么？
- 应用层：你的程序调用OpenGL API，进入UMD。
- UMD处理：驱动把DrawArrays命令翻译成一条硬件命令，写入命令缓冲区。同时检查资源状态，确保顶点缓冲区、着色器都已经就绪。
- 命令提交：当命令缓冲区满了，或者你主动调用了
glFlush/glFinish，UMD会通过系统调用进入KMD。 - KMD调度：KMD收到提交请求，检查权限、分配GPU时间片，然后把命令缓冲区地址写入硬件寄存器。
- HAL执行：HAL把KMD下发的命令通过MMIO（内存映射I/O）写入GPU的硬件队列。
- GPU执行：GPU从硬件队列中取出命令，开始渲染。渲染完成后触发中断。
- 中断返回：KMD收到中断，更新同步状态，通知UMD「渲染完成」。
你看，一次简单的Draw调用，背后走了整整7步。每一步都有开销，每一步都可能成为瓶颈。
注意：很多人以为API调用是「瞬间完成」的。实际上，从CPU调用API到GPU真正开始执行，中间有几十微秒甚至几百微秒的延迟。这就是所谓的「驱动开销」。我们的优化目标，就是把这个开销压到最低。
1.4 驱动开销的构成
驱动开销主要来自三个方面：
| 开销类型 | 来源 | 典型耗时 |
|---|---|---|
| 用户态开销 | API翻译、命令打包、资源检查 | 0.1~1 μs |
| 内核态开销 | 系统调用、上下文切换、权限检查 | 1~10 μs |
| 硬件交互开销 | MMIO写入、中断处理、DMA传输 | 10~100 μs |
我建议你记住这个数量级。当你做性能分析时，如果发现某次API调用耗时异常，可以快速定位是哪一层出了问题。
1.5 小结
这一章我们讲了GPU驱动的整体架构。核心就三点：
- CPU是老大，GPU是小弟，通过命令缓冲区异步协作
- 驱动分三层：UMD（翻译官）、KMD（管家）、HAL（苦力）
- 一次API调用要走7步，每一步都有开销
下一章，我们会深入用户态驱动，看看UMD内部到底是怎么工作的，以及如何减少用户态的开销。嗯，到时候我会分享一些我实际项目中用过的优化技巧，保证干货满满。
今天就到这里。有问题随时交流。