1. 概述
DRM (Direct Rendering Manager) 子系统经历了从图形显示→图形渲染→异构计算/AI的三阶段演进。这种演进反映了GPU硬件能力的发展和应用场景的扩展。
2. 三阶段演进时间线
2.1 第一阶段：图形显示时代 (2000-2010)
核心目标：解决多进程安全访问显卡硬件，实现基本的图形显示
关键技术：
- KMS (Kernel Mode Setting): 内核态显示模式设置
- Framebuffer管理: 基础显存缓冲区管理
- CRTC/Encoder/Connector抽象: 显示硬件管道建模
特征：
- 以显示输出为中心
- 解决X Server的权限和稳定性问题
- 主要处理2D显示任务
// 早期 GEM 设计:简单的显存对象structdrm_gem_object{structkrefrefcount;structdrm_device*dev;structfile*filp;// 最初就这么简单!};2.2 第二阶段：图形渲染时代 (2010-2020)
核心目标：支持复杂的3D渲染，满足游戏和专业图形应用需求
关键技术：
- GEM (Graphics Execution Manager): 图形内存对象管理
- GPU调度器: 命令队列和任务调度
- Fence/Syncobj: 跨进程GPU同步机制
- DMA-BUF: 跨驱动/子系统的缓冲区共享
特征：
- 以渲染性能为中心
- 支持OpenGL/Vulkan等现代图形API
- 引入复杂的内存管理和调度机制
2.3 第三阶段：异构计算与AI时代 (2020-至今)
核心目标：将GPU作为通用计算加速器，特别是AI/ML工作负载
关键技术与证据：
1. **GPUVM **
- 代码文件:
drm_gpuvm.c(Copyright 2022 Red Hat) - 用途: 管理GPU虚拟地址空间，支持现代计算API
- 关键特性:
- VM BIND模式支持Vulkan Sparse Memory Bindings
- 细粒度的虚拟内存管理
- Split/Merge算法优化内存映射操作
2.HMM集成 (Heterogeneous Memory Management)
- 典型实现: AMD SVM (Shared Virtual Memory)
- 功能: CPU和GPU共享统一虚拟地址空间
- 优势: 简化异构编程模型，零拷贝数据共享
3.DRM GPU SVM 框架
- 代码文件:
drm_gpusvm.c(Copyright 2024 Intel, ~1633 lines) - 核心目标: 为 DRM 驱动提供统一的共享虚拟内存抽象层
设计理念：
- CPU 和 GPU 共享统一虚拟地址空间，按需页面迁移
- 基于 MMU Notifier + HMM 机制跟踪和管理内存
- 使用重试循环处理竞态，避免复杂锁嵌套
核心组件：
- Notifier: 跟踪内存区间变化（基于区间树）
- Range: 表示 GPU 映射的内存范围（动态分配）
- Operations: 驱动回调接口（分配、释放、失效）
解决的问题：
在此之前，每个驱动独立实现 SVM（AMD ~6000+ lines、Intel、NVIDIA 各自实现），导致代码重复、行为不一致、难以维护。
框架价值：
- ✅ 统一抽象，代码复用
- ✅ 标准化设计原则（migrate_to_ram 路径、锁机制）
- ✅ 框架级性能优化惠及所有驱动
适用场景：OpenCL/SYCL USM、CUDA/HIP Unified Memory、Vulkan 系统分配器、AI/ML 零拷贝数据管道
4.面向AI的优化
- Prefetch操作: 数据预取优化AI推理性能
- 内存驱逐管理: 处理大模型训练中的内存超额订阅
- 多GPU共享优化: 通过dma-resv实现高效的多卡协同
5.Vulkan计算支持
GPUVM代码中明确提到：
“required by the Vulkan API to implement Vulkan ‘Sparse Memory Bindings’”
这表明DRM已深度适配现代计算API需求。
3. 功能对比表
| 维度 | 显示时代 | 渲染时代 | 计算/AI时代 |
|---|---|---|---|
| 主要应用 | 桌面显示 | 3D游戏/CAD | AI训练推理/科学计算 |
| 内存模型 | 简单framebuffer | GEM对象 | GPUVM + HMM + GPU SVM统一地址空间 |
| 地址空间 | 物理地址 | GPU虚拟地址 | CPU-GPU统一虚拟地址 |
| 内存管理 | 静态分配 | 显式BO管理 | 按需页面迁移 |
| 同步机制 | 简单fence | dma-fence/syncobj | MMU notifier + fence |
| 调度复杂度 | 低 | 中等 | 高（多队列/异步执行） |
| API支持 | X11/DRI | OpenGL/Vulkan图形 | Vulkan计算/CUDA/ROCm/SYCL |
| 内存容量需求 | MB级 | GB级 | 数十GB（大模型） |
| 典型代码 | KMS核心 | GEM/调度器 | GPUVM/HMM/GPU SVM/Prefetch |
4. 演进驱动力
1. 硬件能力提升
- GPU从固定管线 → 可编程着色器 → 通用计算核心
- 显存容量从MB → GB → 数十GB
- 互连技术从AGP → PCIe → NVLink/Infinity Fabric
2. 应用需求变化
- 2000年代：办公和基础图形
- 2010年代：高品质游戏和专业渲染
- 2020年代：深度学习、大语言模型、自动驾驶
3. API标准演进
- Vulkan引入计算着色器和稀疏资源
- ROCm/CUDA推动GPU通用计算生态
- SYCL/OpenCL等异构编程标准
5. 结论
DRM子系统的演进清晰地体现了三个阶段：
图形显示 (Framebuffer) ↓ 图形渲染 (GEM, Fence/Syncobj) ↓ 异构计算/AI (GPUVM, HMM, GPU SVM)三个阶段的核心特征：
显示时代的基础设施建设（KMS/Framebuffer）
- 解决多进程访问冲突
- 建立显示硬件抽象
渲染时代的性能优化（GEM/调度器/同步机制）
- 复杂的内存对象管理
- 高效的任务调度和同步
计算/AI时代的范式转变（GPUVM/HMM/GPU SVM/统一内存）
- CPU-GPU统一虚拟地址空间
- 按需页面迁移和自动内存管理
- 标准化的SVM框架减少驱动重复工作
关键技术演进标志：
- 2004: DRM合并进Linux内核
- 2007: Intel开发GEM框架
- 2009: KMS子系统引入
- 2016: Vulkan 1.0发布，推动计算图形融合
- 2018: AMD开始HMM集成工作
- 2022: GPUVM框架合并，标志全面转向计算时代
- 2024: DRM GPU SVM框架引入，统一SVM抽象层
这种演进不是简单的功能堆叠，而是架构层面的适应性重构。特别是：
- GPUVM框架：明确提到Vulkan Sparse Resources和VM BIND
- GPU SVM框架：提供标准化的共享虚拟内存实现，避免每个驱动重复开发
- 设计原则统一：migrate_to_ram路径、notifier锁机制、重试循环处理竞态
这充分证明DRM已从“图形显示管理器”转型为“通用GPU资源管理器”，这正是AI时代的必然要求。
从各驱动的实现规模可以看出演进的必要性：
- AMD SVM实现：
kfd_svm.c+amdgpu_hmm.c - Intel实现：
i915_gem_userptr.c+ 正在迁移到 GPU SVM - 未来驱动：直接使用
drm_gpusvm.c框架，大幅减少开发工作
Linux内核在积极适配GPU异构计算的新需求，这种演进仍在持续进行中。
技术交流和投稿，欢迎加入社区：GPUers。
