DRM 子系统演进分析

1. 概述

DRM (Direct Rendering Manager) 子系统经历了从图形显示 → 图形渲染 → 异构计算/AI 的三阶段演进。这种演进反映了 GPU 硬件能力的发展和应用场景的扩展。

2. 三阶段演进时间线

// 早期 GEM 设计：简单的显存对象
struct drm_gem_object {
    struct kref refcount;
    struct drm_device *dev;
    struct file *filp;
    // 最初就这么简单!
};

// GPU Scheduler: 多队列并发调度
struct drm_gpu_scheduler {
    struct drm_sched_entity *entities;
    struct drm_sched_rq     sched_rq[DRM_SCHED_PRIORITY_COUNT];
    atomic_t                hw_rq_count;  // 硬件队列深度
    // 远比第一阶段复杂
};

// GPU SVM: 统一虚拟内存框架 (2024)
struct drm_gpusvm {
    struct drm_device *drm;           // DRM 设备
    struct mm_struct *mm;             // 进程地址空间
    struct maple_tree root;           // 区间树管理
    struct mmu_notifier notifier;     // 页表同步
    const struct drm_gpusvm_ops *ops; // 驱动回调
    // 统一框架，所有驱动受益!
};

关键技术与证据

图：DRM 子系统三阶段演进概览 — 从图形显示到异构计算

3. 功能对比表

4. 演进驱动力

4.1 应用需求变化

• 2000 年代：办公和基础图形
• 2010 年代：高品质游戏和专业渲染
• 2020 年代：深度学习、大语言模型、自动驾驶

4.2 API 标准演进

• Vulkan 引入计算着色器和稀疏资源
• ROCm/CUDA 推动 GPU 通用计算生态
• SYCL/OpenCL 等异构编程标准

5. 结论

DRM 子系统的演进清晰地体现了三个阶段，三个阶段的核心特征：

1. 显示时代的基础设施建设（KMS/Framebuffer）
   • 解决多进程访问冲突
   • 建立显示硬件抽象
2. 渲染时代的性能优化（GEM/调度器/同步机制）
   • 复杂的内存对象管理
   • 高效的任务调度和同步
3. 计算/AI 时代的范式转变（GPUVM/HMM/GPU SVM/统一内存）
   • CPU-GPU 统一虚拟地址空间
   • 按需页面迁移和自动内存管理
   • 标准化的 SVM 框架减少驱动重复工作

关键技术演进标志

这种演进不是简单的功能堆叠，而是架构层面的适应性重构。特别是：

• GPUVM 框架：明确提到 Vulkan Sparse Resources 和 VM BIND
• GPU SVM 框架：提供标准化的共享虚拟内存实现，避免每个驱动重复开发
• 设计原则统一：migrate_to_ram 路径、notifier 锁机制、重试循环处理竞态

从各驱动的实现规模可以看出演进的必要性：

• AMD SVM 实现：kfd_svm.c + amdgpu_hmm.c
• Intel 实现：i915_gem_userptr.c + 正在迁移到 GPU SVM
• 未来驱动：直接使用 drm_gpusvm.c 框架，大幅减少开发工作

Linux 内核在积极适配 GPU 异构计算的新需求，这种演进仍在持续进行中。