第一章：DRM 子系统概述：1.2 DRM 子系统专栏介绍—从显存管理到底层同步的全栈解析

原创已于 2026-08-13 15:20:43 修改 · 2.7k 阅读

3 GEO检测

于 2025-11-12 19:12:16 首次发布

Linux DRM 子系统显存管理核心机制与实现解析专栏收录该内容

98 篇文章 ¥89.90 ¥99.00

订阅专栏

0 开篇：先纠正一个流行的误解

一提到 DRM（Direct Rendering Manager），很多人第一反应是——“那不就是管显示的吗?”

这个印象来自两个原因：一是它的名字里有 “Rendering”，二是历史上 DRM 最初确实是为 X Server 的显示输出服务的。但如果我们顺着 DRM 子系统这些年的演进脉络去看，会发现这个认知早已过时。

事实上，DRM 内部大致可以分成两条主线：

一条是 KMS（Kernel Mode Setting），负责 CRTC、Plane、Connector、显示时序、热插拔——这才是真正“管显示”的部分；
另一条是 显存与资源管理：GEM、TTM、DMA-BUF、GPU 调度器，以及面向统一地址空间的 SVM——它负责的是显存怎么分配、怎么回收、怎么和 CPU 共享、命令怎么提交给 GPU。

关键在于：第二条主线和“显示”并没有必然联系。 今天数据中心里那些跑 AI 训练、跑 GPGPU 计算的加速卡，很多连显示接口都没有(headless)，一个像素都不往屏幕上送，但它们依然完整地运行在 DRM 的显存管理与调度框架之上。AMD 把计算驱动 KFD 构建在 DRM 之上，正是这一趋势的直接体现——AI 与计算负载的涌入，正在成为 DRM 子系统必须面对的新挑战，这也是本专栏把 KFD 纳入分析案例的原因。

所以，请先把这个观念校准过来：

显示只是 DRM 的出口之一，而非它的核心。DRM 的真正定位，是内核里对 GPU 资源——尤其是显存——的统一管理框架；显示（KMS）不过是构建在这套资源管理之上的一个“消费者”。

所以本专栏聚焦的，正是这套框架中最底层、也最容易“把人绕晕”的部分——显存管理。理解了它，你才能真正明白：显存为什么会泄漏、GPU 为何会调度死锁、GEM/TTM/SVM 各自在解决什么问题。下图是理解 drm 子系统的一个视角。

我想我在 drm 子系统的演进分析已经把这个进化讲清楚了。

1. 专栏核心定位

在发展中看drm子系统。从 drm 子系统的演进分析得到，AI驱动的加入是drm子系统需要应对的新挑战。顺应发展趋势，我把AMD/KFD驱动、Intel/XE驱动、以及NVIDIA的开源Linux驱动加入到了分析案例中。

本专栏聚焦 Linux 内核中DRM（Direct Rendering Manager）子系统，旨在打破图形/计算驱动开发的知识壁垒。通过系统化拆解核心对象与机制，为开发者、技术爱好者提供清晰易懂的底层原理解读与实现逻辑分析，助力开发者从 “知其然” 到 “知其所以然”。

2. 核心覆盖模块

GEM（Graphics Execution Manager）对象管理：梳理 GEM 作为 DRM 子系统核心对象的设计思路，包括对象的创建、销毁、命名机制，以及与显存分配、渲染命令提交的关联，通过详解 AMD 的 linux 内核驱动实现进行学习和实战。
TTM（Translation Table Manager）内存管理机制：详解内存的分配、迁移、回收核心逻辑，包括缓冲区对象（BO）的生命周期管理、内存域（memory domain）划分、页表映射原理，以及如何解决多 GPU 场景下的内存一致性问题；同时关联Linux 进程管理与内存管理底层机制，分析 TTM 与进程地址空间、页帧分配器的协同逻辑，结合实际代码片段解析关键数据结构与函数调用流程。
DMA-BUF 跨设备内存共享：剖析跨进程、跨硬件设备的内存共享核心原理，包括缓冲区对象的导出 / 导入机制、文件描述符传递流程、高速缓存一致性处理；重点关联anon_inode（匿名 inode）机制，解析 DMA-BUF 如何通过匿名 inode 实现无实体文件的跨进程资源传递，结合显卡与摄像头、GPU 与 AI 加速器的协同场景，解读 dma_buf 与进程间通信（IPC）底层逻辑的联动。然后给出了prime的应用介绍。
DMA-Fence 同步机制：深入分析同步原语的设计理念，包括 fence 对象的创建、信号量触发、等待队列管理，以及与 GPU 任务调度的协同逻辑；结合Linux 进程管理与同步机制，解读 fence 如何借助内核等待队列、信号量等底层组件实现异步渲染场景下的同步保障，对比不同类型 fence（如 dma_fence、sync_file）的适用场景与实现差异，同时剖析进程调度策略对 GPU 任务同步的影响。
DMA-Resv 资源reserve机制：讲解资源预定对象的核心作用，包括对缓冲区读写权限的管控、并发访问的同步策略、多线程 / 多设备竞争的解决方案，解析 dma_resv 与 dma_buf 的联动逻辑，以及在避免数据竞争中的关键作用。
DRM GPU Scheduler：— GPU 命令调度框架：drm_gpu_scheduler 是 DRM 子系统中负责 GPU 命令提交与执行调度的通用框架，该模块是理解 GPU 命令从用户态提交到硬件执行的完整链路的关键环节——GEM/TTM 解决"数据放在哪"，DMA-Fence/DMA-Resv 解决"何时安全访问"，而 GPU Scheduler 解决"何时执行、按什么顺序执行。本模块将结合 AMDGPU 驱动的实际实现（amdgpu_job、amdgpu_ring）进行深度解析。
libdrm 用户态接口解析：解析专栏中涉及的libdrm 接口。libdrm作为用户态与内核态桥梁，是理解内核实现技术和应用的必备技能。专栏会结合示例代码演示如何通过 libdrm 实现图形渲染、显存管理等基础操作。
HMM(异构内存管理)与SVM(共享虚拟内存)的机制解析：随着 AI/ML 工作负载的爆发式增长，传统的 GEM 对象管理模式已无法满足需求。GPUVM (2022) 和 DRM GPU SVM (2024) 的引入标志着 DRM 从"显式 Buffer Object 管理"转向"统一虚拟地址空间"的范式转变。GPUVM 负责 GPU 虚拟地址空间管理，GPU SVM 负责 CPU-GPU 统一地址空间，二者与 TTM、DMA-BUF、DMA-Fence 共同构建了现代异构计算的完整内存管理生态。专栏通过详细分析AMD/Intel SVM的实现来理解现代AI计算的存储管理范式（对该机制的解析全网独家）。
Linux 底层核心机制专项解析：单独拆解支撑图形系统运行的关键底层组件，包括进程管理（进程创建、调度策略、进程间通信的底层实现）、anon_inode（匿名 inode 的创建、挂载逻辑，及其在无文件实体资源管理中的应用）、epoll（事件驱动模型的底层原理、红黑树与就绪链表的设计、高效 I/O 监听的实现），揭示这些底层机制如何为 DRM 子系统提供基础支撑，以及二者的协同工作逻辑。这部分看似基础，却是drm系统的基石。