4. 驱动与显存交互：驱动如何管理显存、显存分配与释放、显存映射机制、DMA传输原理

显存，说白了就是GPU的“工作台”。驱动怎么管好这个台子，直接决定了你的显卡能跑多快。我这些年调过不少显存相关的bug，从分配失败到DMA传输卡死，踩过的坑能写一本小册子。今天咱们就把这块掰开揉碎了讲清楚。

4.1 驱动如何管理显存

驱动管理显存，核心就两件事：谁在用和用在哪。GPU内部有多个引擎——3D引擎、视频编解码引擎、显示引擎——它们都可能访问显存。驱动得像个交通指挥员，确保每个引擎拿到正确的内存地址，还不能互相踩踏。

我个人习惯把显存管理分成三层：

硬件层：GPU的MMU（内存管理单元）负责地址翻译。显存物理地址和虚拟地址的映射，全靠它。
内核层：驱动在内核空间维护一个显存分配器。它记录哪些区域空闲、哪些被占用。
用户层：应用程序通过API（如CUDA、OpenCL）向驱动申请显存。驱动再向下分配物理页。

举个例子，你在CUDA里写 cudaMalloc(&ptr, size)，底层发生了什么？

// 伪代码：驱动侧显存分配流程
1. 用户调用 cudaMalloc
2. 驱动检查请求大小是否合法
3. 驱动查询显存空闲列表
4. 找到足够大的连续物理块（或通过页表拼接）
5. 分配页表项，建立虚拟地址到物理地址的映射
6. 返回用户态虚拟地址
7. 记录分配信息到驱动内部链表

嗯，这里要注意：显存分配不是每次都能成功的。我在项目中遇到过显存碎片化导致分配失败的情况——明明总空闲内存够，但就是没有连续的大块。后来我们引入了预分配池和碎片整理机制，才解决了这个问题。

  核心要点：驱动管理显存的核心数据结构是drm_mm（Linux DRM子系统中的内存管理器）。它使用区间树（interval tree）来跟踪每个分配区域，支持快速查找和合并。

4.2 显存分配与释放

显存分配和释放，听起来简单，但细节里全是魔鬼。你想想看，GPU可能有几百个并发线程同时申请显存，驱动怎么保证效率？

常见的分配策略有三种：

策略	特点	适用场景
伙伴系统（Buddy）	按2的幂次分配，合并释放时自动合并相邻块	通用场景，Linux内核默认
SLAB分配器	预分配固定大小的对象池	频繁分配/释放小对象（如描述符）
CMA（连续内存分配器）	预留大块连续物理内存	DMA传输、显示帧缓冲

我曾经调试过一个性能问题：某个视频处理应用频繁分配和释放显存，每次分配都要扫描整个空闲列表，导致帧率抖动。后来改成SLAB分配器，预分配一批固定大小的缓冲区，性能直接翻倍。

释放时有个坑：必须确保GPU不再访问该内存。驱动需要先发送一个fence（栅栏）命令，等GPU执行完所有相关操作后，才能把内存标记为空闲。否则就会出现“野指针”式的显存错误——GPU还在读，驱动已经把内存回收了。

避坑指南：我曾经遇到过显存泄漏问题——应用退出时没有释放所有显存。驱动侧需要实现引用计数和垃圾回收机制。建议在驱动中维护一个“分配-释放”的日志，方便调试时回溯。

4.3 显存映射机制

显存映射，就是把GPU的物理显存地址，映射到CPU的虚拟地址空间。这样CPU就能直接读写显存了。但这里有个性能陷阱：映射方式不同，访问速度天差地别。

常见的映射方式：

WC（Write-Combine）映射：CPU写操作会合并到缓冲区，适合写多读少的场景。我一般用它来映射帧缓冲。
UC（Uncacheable）映射：不缓存，每次读写都直接访问显存。适合寄存器映射，但性能差。
WB（Write-Back）映射：带缓存，性能最好。但需要处理缓存一致性——CPU和GPU可能看到不同的数据。

为什么会有这些区别？说白了，CPU和GPU的缓存系统是独立的。如果CPU通过WB方式写显存，数据可能还留在CPU的L1/L2缓存里，GPU根本看不到。这时候就需要手动刷缓存（flush）或者用WC映射绕过缓存。

我建议在驱动初始化时，根据用途选择合适的映射类型：

// Linux内核中映射显存的典型代码
void *vaddr = ioremap_wc(phys_addr, size);
// 或者使用dma_alloc_coherent()自动处理一致性

嗯，这里有个细节：ioremap_wc返回的是虚拟地址，但CPU访问这个地址时，写操作会被合并到写缓冲区（Write Combine Buffer），然后一次性刷到显存。这对帧缓冲特别友好——你写一个像素，它不会立即触发一次总线事务，而是攒一批再发。

个人经验：如果你在做GPU计算（如CUDA），建议使用cudaHostRegister注册主机内存，让驱动自动选择最优映射方式。手动映射容易踩缓存一致性的坑。

4.4 DMA传输原理

DMA（Direct Memory Access）是显存交互的“高速公路”。没有DMA，CPU就得亲自搬数据，那效率低得没法看。DMA传输的核心思想是：让硬件自己搬数据，CPU只负责发指令。

DMA传输的典型流程：

CPU准备源地址、目的地址、传输长度
CPU配置DMA引擎（或GPU内部的DMA控制器）
CPU启动DMA传输（写一个寄存器）
DMA引擎独立搬运数据，CPU可以干别的事
DMA完成后触发中断，通知CPU

你想想看，如果每次传输都要CPU参与，那GPU的并行计算能力就全浪费了。DMA让CPU和GPU可以“流水线”工作——CPU在准备下一批数据，GPU在算当前数据，DMA在搬上一批结果。

我曾经优化过一个AI推理管线，瓶颈就在DMA传输上。原始实现是同步DMA——CPU等DMA完成才继续。改成异步DMA + 双缓冲后，吞吐量提升了40%。

// 异步DMA传输伪代码
// 使用两个缓冲区交替传输
buffer_A = alloc_dma_buffer(size);
buffer_B = alloc_dma_buffer(size);

while (有数据) {
    // 启动DMA传输到buffer_A
    dma_start(buffer_A, data, size);
    
    // 同时处理buffer_B中的数据
    process(buffer_B);
    
    // 等待DMA完成
    dma_wait();
    
    // 交换缓冲区
    swap(buffer_A, buffer_B);
}

  关键指标：DMA传输的性能取决于三个因素——带宽（总线宽度和频率）、延迟（启动DMA的开销）、以及传输粒度。我建议单次DMA传输不要小于64字节，否则启动开销占比太大，得不偿失。

还有一个容易被忽略的点：DMA地址对齐。大多数DMA控制器要求源地址和目的地址按4字节或8字节对齐。如果不对齐，要么硬件报错，要么性能暴跌。我在项目中遇到过因为地址未对齐导致DMA传输速度只有理论值1/10的情况——排查了两天才找到原因。

避坑指南：我曾经在调试PCIe DMA时发现，某些GPU的DMA引擎对非对齐访问会触发“拆分传输”（split transaction），导致带宽利用率下降。解决方案是在驱动层做地址对齐检查，必要时用memcpy做一次中转。

最后说一句：DMA传输的调试工具很重要。我常用perf和trace-cmd来监控DMA的延迟和带宽。如果发现DMA传输时间异常，先检查中断处理函数是否被其他高优先级中断抢占——这是多核系统上常见的性能杀手。

这张图展示了驱动与显存交互的三层架构。从上到下，用户层的请求经过驱动层的分配、映射、调度，最终落到硬件层的显存和DMA控制器上。每一层都有各自的职责和优化空间。

📚 课程目录

4. 驱动与显存交互：驱动如何管理显存、显存分配与释放、显存映射机制、DMA传输原理

4.1 驱动如何管理显存

4.2 显存分配与释放

4.3 显存映射机制

4.4 DMA传输原理