原作者：Linux教程
原文地址：Linux图形显示系统之DRM：从底层逻辑到实践架构
在Linux显卡驱动领域，图形显示系统是绕不开的核心。今天我打算从DRM入手，结合wiki和自己的开发体会，跟大家拆解这个内核子系统。
Part1 为什么需要DRM？
在DRM出现之前，Linux图形系统可以说是大家各玩各的。那时候内核虽然有fbdev API负责管理图形帧缓冲，但它功能太基础，根本扛不住现代GPU的3D加速需求——现代显卡得在自己的内存里维护命令队列、打理缓冲区，可早期的用户空间程序（比如X Server），都觉得自己是唯一能使用GPU的“独苗”。
大家可以想象一下，两个程序同时抢GPU资源，一个要渲染视频，一个要处理3D图形，各自随便设置硬件参数、占缓冲区，最后大概率会出现显示错乱、程序崩溃，甚至硬件出问题的情况。这就像十字路口没有红绿灯，车子乱冲乱撞，最后肯定堵得水泄不通。
下图就很直观地展示了没有DRM时的混乱样子：两个用户程序（X Server、加速播放器）直接和显卡VRAM、GPU打交道，没有任何协调机制，缓冲区的占用也毫无规律可言。
DRM（Direct Rendering Manager）的出现，就是为了收拾这份混乱。作为Linux内核的核心子系统，它主动接管了GPU的“管理权”，独自拥有访问GPU的权限，统一初始化和维护命令队列、内存缓冲区这些资源。不管哪个程序想用到GPU，都得先跟DRM打报告，由这位“大管家”居中协调，避免冲突、合理分配资源，让每个程序的需求都能顺利实现。
从最开始作为X Server直接渲染架构的内核组件，到后来被Wayland等其他图形系统接纳，DRM的功能一直在慢慢升级，逐渐接手了原本由用户空间程序负责的帧缓冲管理、模式设置等工作。我们常听到的GEM（图形执行管理器）、KMS（内核模式设置），并不是独立的系统，而是DRM升级路上新增的“小助手”，帮这位“大管家”把管理工作做得更细致。
有了DRM之后，整个交互逻辑就清晰多了，用户程序不再直接碰GPU，而是通过系统调用跟DRM提需求，由DRM统一调度显卡资源，下图展示的就是这个核心逻辑，简单又高效。
Part2 DRM的架构
DRM最厉害的地方，就是它的“分层设计”。它藏在内核空间里，但凭借灵活的接口，让用户空间的程序能轻松调用——既守住了内核对硬件的管控权，又降低了应用程序的开发难度，完美契合Unix“一切皆文件”的设计理念，看得出来设计者的用心。
2.1 内核与用户空间的“桥梁”：从ioctl到libdrm
DRM待在内核空间里，用户空间的程序没法直接和它沟通，只能通过系统调用请求服务。但DRM没有搞特殊，没有自定义新的系统调用，而是遵循Unix的设计思路，通过/dev/dri/cardX（X是序列号）这样的设备文件，把GPU的功能开放给用户空间——每检测到一块GPU，DRM就会创建一个对应的设备文件，程序通过ioctl调用和DRM沟通，不同的ioctl对应不同的功能，就像一串串专属“指令码”，能精准传达需求。
不过，直接调用ioctl对应用程序来说太麻烦了，得手动处理很多底层细节，增加不少开发负担。于是，libdrm库就应运而生了，它就像一个“翻译官”，把复杂难懂的ioctl调用，包装成简单好懂的C语言函数，还附带了常量、结构体等辅助工具，帮应用程序少走弯路。这样一来，应用程序不用直接接触内核接口，只要调用libdrm的函数，就能和DRM顺畅沟通，既降低了开发难度，还能实现代码复用，提高效率。
如下图所示这种协作关系，用户程序通过链接libdrm库，借助ioctl调用，和内核空间的DRM实现无缝沟通，进而轻松掌控显卡资源，每一次交互都精准高效。
2.2 DRM的“双核结构”
DRM的设计一点都不“一刀切”，而是由“通用核心（DRM core）”和“专属驱动（DRM Driver）”两部分相互配合，就像“通用模板”加上“定制插件”，既保证了通用性，又能精准适配不同硬件，考虑得特别周全。
DRM core是整个子系统的“基础框架”，主要负责提供统一的接口规范，允许不同厂商的显卡驱动注册进来，同时给用户空间提供一套和硬件无关的通用ioctl集——不管是什么品牌、什么型号的显卡，只要遵循DRM core的规范，就能被系统顺利识别，实现互联互通。
而DRM Driver，就是为特定GPU量身定制的“专属插件”，针对具体的GPU型号，精准实现和硬件相关的API功能，补充DRM core没覆盖到的操作。如果某款GPU有特殊功能，它对应的DRM Driver还能扩展API，新增专属ioctl；与此同时，libdrm也会通过libdrm-driver扩展库，把这些专属接口开放给用户空间，确保应用程序能充分发挥硬件的潜力，物尽其用。
这种“通用+专属”的巧妙设计，让DRM能适配不同品牌、不同型号的显卡，下图也直观展示了用户空间程序、libdrm、DRM核心与驱动，以及显卡硬件之间的层级关系，脉络清晰，大家各司其职、互不干扰。
Part3 DRM的核心功能
DRM的所有功能，本质上都是为了解决一个核心问题——如何高效、安全地管理GPU资源。从内存管理到模式设置，从缓冲区共享到权限控制，每一个功能模块，都是为了让图形交互体验更完善。
3.1 权限管控
既然DRM掌管着GPU资源，那“权限分配”就成了关键问题——像模式设置这种敏感操作，肯定不能让所有程序随便调用，不然很容易导致系统混乱，得不偿失。DRM靠“DRM-Master”和“DRM-Auth”两大机制，搭建了一套精细的权限管控体系，守护系统安全。
DRM-Master就像GPU资源的“首席管理员”，手里握着调用所有敏感ioctl的绝对权限。第一个打开/dev/dri/cardX并调用SET_MASTER ioctl的进程，就能成为DRM-Master；其他进程如果想调用敏感ioctl，必须得到DRM-Master的授权，不然只会收到错误提示，没法执行操作。通常来说，X Server、Wayland合成器这类显示服务器，会一直担任DRM-Master的角色，负责管理整个图形显示的核心操作，确保系统稳定运行。
而DRM-Auth，就是给非DRM-Master进程开辟的“绿色通道”，让它们能合法访问敏感操作。流程很简单也很严谨：非管理员进程先通过GET_MAGIC ioctl，从DRM那里获取一个32位的令牌，再通过IPC机制，把这个令牌传给DRM-Master；DRM-Master通过AUTH-MAGIC ioctl，把令牌反馈给DRM，DRM验证通过后，就会给这个进程授予相应的操作权限。这套机制，既守住了系统安全的底线，又兼顾了操作的灵活性，设计得很贴心。
3.2 内存管理
GPU的内存管理，算是DRM最核心的功能之一——现代图形应用要用到大量内存，用来存储帧缓冲、纹理等数据，而内存的分配和共享效率，直接影响显示性能的好坏。DRM给我们提供了两种核心的内存管理方案：GEM和TTM，它们各有侧重、相互配合，适配不同的硬件场景，一起守护内存管理的高效和稳定。
GEM（图形执行管理器），是英特尔工程师为集成GPU设计的内存管理方案，主打“简洁高效”。它允许用户空间程序创建、操作GPU视频内存中的“GEM对象”——其实就是内存缓冲区，这些对象是持久存在的，不用在程序切换时重复加载，大大提高了操作效率。当程序需要内存时，只要通过GEM API向DRM驱动申请，驱动检测到空闲内存后，就会分配资源，并返回一个“句柄”，供程序后续操作内存时使用；当程序终止或关闭DRM设备时，没手动释放的GEM句柄占用的内存，会自动回收，从根源上避免内存泄漏。
GEM还支持进程间的内存共享：通过“GEM名称”——一个全局唯一的32位整数，进程可以把GEM对象传给其他进程，实现数据互通。但这种方式也有小缺点，存在一定的安全隐患——恶意进程可能会猜测32位整数，获取其他进程共享的缓冲区的GEM名称，进而访问、篡改里面的内容，破坏数据的安全性和完整性。后来，DMA-BUF的出现解决了这个问题，它把缓冲区变成文件描述符，让内存共享变得安全可靠，不用再担心被恶意篡改。
而TTM（Translation Table Maps），是更早出现的通用内存管理方案，主打“兼容性”。它能灵活管理多种类型的内存，既包括显卡专用的VRAM，也包括通过GART（I/O内存管理单元）访问的系统内存，还能妥善处理CPU无法直接寻址的VRAM部分，确保内存和缓存的一致性，适配各种硬件场景。TTM的核心是“缓冲对象”和“围栏”：缓冲对象是GPU能访问的内存块，是存储数据的核心；围栏则用来管理CPU和GPU的并发，精准跟踪GPU对缓冲对象的使用状态，确保操作有序进行。
不过，为了兼顾所有硬件场景，TTM的设计稍微复杂一些，API也有冗余，不够简洁。GEM出现后，凭借简洁高效的优势，很快被广泛使用，但TTM并没有被淘汰——对于AMD radeon、NVIDIA nouveau这类带有专用VRAM的独立显卡来说，TTM的设计更适配它们的硬件特性，所以这些驱动会在内部使用TTM，同时对外提供GEM API，兼顾兼容性和性能，设计得很灵活。
3.3 缓冲区共享
在复杂的图形场景中，多个设备（比如视频设备和显卡）经常需要共享数据，传统的“复制数据”模式，效率低还浪费资源。而DMA-BUF（DMA缓冲区共享API）的出现，彻底改变了这种现状——它实现了“零复制”共享，数据不用在不同设备间反复复制，直接通过缓冲区互通，大大提高了数据传输和共享的效率，为复杂图形场景提供了保障。
DMA-BUF最初在DRM中，主要用来实现PRIME（显卡交火）功能：在独立显卡和集成显卡之间，共享生成的帧缓冲，实现GPU卸载，大幅提升图形处理性能，让复杂的图形任务能顺畅运行。为了支持PRIME功能，DRM API新增了两个ioctl，一个用来把本地GEM句柄转换成DMA-BUF文件描述符，另一个则用来反向转换，实现两种格式的无缝切换。
后来，这两个新增的ioctl，还解决了GEM共享的安全隐患：文件描述符没法随便猜测，还能通过Unix域套接字安全传递，进程只要把GEM句柄转换成DMA-BUF文件描述符，就能安全地和其他进程共享内存，不用怕数据泄露或被篡改。比如DRI3协议，就是用这种方式，在客户端与X Server、Wayland之间实现缓冲区共享，确保图形交互顺畅又安全。
3.4 模式设置
显卡要正常显示，必须设置合适的显示模式——包括分辨率、颜色深度、刷新率等关键参数，这就是“模式设置”。早期，模式设置的工作由用户空间程序（比如X Server的DDX驱动）负责，这种方式有很多问题：不同程序重复实现模式设置代码，容易引发冲突；系统切换时（比如从图形界面切换到虚拟控制台），经常会出现闪烁，甚至显示损坏；挂起/恢复时，要依赖用户空间工具恢复模式，一旦工具崩溃，系统就会没法显示，特别麻烦。
为了解决这些问题，David Herman把模式设置功能从DRM中拆分出来，打造了KMS（内核模式设置）——把模式设置代码移到内核，由DRM统一管理。这样一来，所有进程（包括X Server），都要通过DRM发起模式设置请求，内核全程把控，确保并发操作不会冲突，同时删除了冗余的重复代码，彻底解决了系统切换闪烁、模式恢复失败等问题，让显示控制更稳定。
KMS的优势还有很多：它能在系统启动初期就开始工作，避免早期模式切换带来的闪烁；内核能充分利用中断等资源，简化挂起/恢复后的模式恢复流程，既提高了效率，又增强了安全性——不用再依赖有root权限的用户空间工具；它还支持显示设备热拔插，解决了长期困扰硬件适配的难题，让设备连接更灵活。值得一提的是，KMS不是独立的子系统，而是DRM的一部分，驱动程序只要注册DRIVER_MODESET标志，就能支持KMS API，实现模式设置的统一管控。
下图就清晰展示了KMS在整个Linux系统中的位置，它和DRM紧密结合、协同工作，和PulseAudio、Wayland、X.Org Server等组件配合，实现图形和音频的统一管理，搭建起完善的系统生态。
3.5 KMS设备模型
KMS把复杂的显示设备，抽象成四个核心模块，搭建起一条完整的“显示管道”，把难懂的硬件逻辑梳理得清晰易懂、便于管理，看得出来设计很用心。
1. CRTC：就像“扫描引擎”，主要负责读取帧缓冲中的像素数据，生成视频时序信号，它的数量决定了硬件能同时支持多少个独立显示设备——每台显示设备，至少需要一个独立的CRTC；多个CRTC也能工作在“克隆模式”，从同一个帧缓冲读取数据，把相同的图像传到多台显示器，实现多屏同步显示。
2. Connector：对应硬件上的物理接口（比如HDMI、DisplayPort、VGA等），负责把视频信号传到显示器，同时存储着显示器的相关信息——包括连接状态、EDID数据、DPMS状态以及支持的显示模式等，是连接显示管道和外部设备的核心纽带。
3. Encoder：主要负责“编码转换”，把CRTC输出的视频数据，编码成适合Connector的格式——比如数字输出常用的TMDS、LVDS，模拟输出常用的DAC模块等。需要注意的是，一个Connector一次只能接收一个Encoder的信号，而且受硬件限制，不是所有CRTC都能和所有Encoder连接，要遵循特定的适配规则。
4. Plane：不是实体硬件，而是存储图像数据的内存对象，分为主平面、光标平面和叠加平面。其中，拥有帧缓冲的Plane叫主平面，每个CRTC都必须关联一个主平面，因为它决定着显示模式的核心参数——分辨率（宽度和高度）、像素大小、像素格式、刷新率等；如果显示控制器支持硬件光标覆盖，CRTC还能关联光标平面；如果显示控制器能从其他硬件覆盖中扫描数据，实现图像合成与混合，生成最终的显示图像，CRTC也能关联叠加平面，多平面配合，能呈现更丰富、更细腻的显示效果。
3.6 原子显示
在多显示器、多平面切换等复杂场景中，传统的模式设置和页面翻转操作，经常会出现中间状态，导致显示错乱，影响使用体验。“原子显示”功能的出现，完美解决了这个问题——它确保模式设置、页面翻转等操作是“原子性”的，要么完整执行，要么完全不执行，没有中间状态，从根源上避免了显示错乱。
原子显示有“模式测试”功能，能提前验证显示配置是否可行，避免无效配置导致系统异常；测试通过后，通过一个不可分割的提交操作，把配置应用到系统，彻底避免了失败后状态回滚的风险。同时，原子页面翻转能让多个平面在同一VBLANK间隔内同步更新，有效避免显示撕裂，尤其适合移动设备和嵌入式设备，既能保证显示效果，又能节省功耗，兼顾性能和体验。
3.7 渲染节点
在DRM发展的早期，设备文件/dev/dri/cardX身兼数职，既负责模式设置等特权操作，也承担着渲染、GPGPU计算等非特权操作。这种设计带来了一个麻烦：普通程序想调用GPU进行渲染，必须得到DRM-Master的授权，哪怕不需要涉及显示操作（比如纯计算任务），也得依赖运行中的显示服务器，操作繁琐又不方便，大大限制了GPU功能的发挥。
“渲染节点”（Render nodes）的出现，彻底解决了这个问题，给非特权程序开辟了一条“绿色通道”：DRM为每一块GPU，额外创建一个设备文件/dev/dri/renderDX，专门处理非特权操作。普通应用程序不用拥有特权，只要有文件系统权限，就能通过渲染节点，调用DRM的非特权API，实现渲染或GPGPU计算，不用依赖显示服务器，灵活又方便。
需要注意的是，渲染节点禁止GEM flink操作，从根源上避免了不安全的内存共享，只能通过DMA-BUF文件描述符共享缓冲区，进一步保障系统安全。而显示服务器等需要执行特权操作的程序，依然可以通过/dev/dri/cardX，访问完整的DRM API，实现核心管控，两者各司其职、互不干扰。
Part4 DRM的硬件支持
DRM的硬件支持范围很广，涵盖了主流显卡品牌，其中对AMD、Intel显卡的支持最完善，NVIDIA则通过nouveau驱动，实现了和DRM的兼容，确保各种硬件都能顺畅接入系统。从下图中，我们能清楚看到DRM的核心定位：它介于用户空间应用（比如Mesa 3D、Wayland合成器）和硬件之间，是连接应用和显卡的核心枢纽——用户空间程序通过系统调用访问DRM，DRM再和显卡硬件深度交互，完成图形渲染、显示控制等一系列操作，串联起整个图形显示流程。
在开发维护方面，DRM是Linux内核的重要组成部分，源代码放在/drivers/gpu/drm目录下，由Dave Airlie担任主要维护者，其他维护者分工负责特定显卡驱动的开发和优化。它的开发流程和Linux内核一致：贡献者把新功能、bug修复的补丁，提交给DRM维护者，维护者整合校验后，再提交给Linus Torvalds，最终纳入Linux内核的新版本，实现升级迭代。
比较有意思的是，虽然libdrm是DRM的用户空间配套库，但因为历史原因，它的源代码没有放在DRM内核目录，而是属于Mesa项目。这种分离式的维护模式，既兼顾了历史传承，又体现了Linux开源生态的灵活性和包容性，让每个组件都能在最适合的环境中，高效升级优化。
好了，以上就是 Linux 图形栈里 DRM 的大致模样。其实它也没那么高深，DRM的本质，就是Linux内核为GPU资源管理量身打造的“统一解决方案”——它终结了早期图形系统资源冲突、权限混乱、效率低下的问题，凭借分层架构、精细管控和灵活的功能模块。
对于研究Linux显卡驱动的人来说，DRM不只是一个内核子系统，更是读懂Linux图形栈底层逻辑的“钥匙”——搞懂DRM的工作原理，就能清楚看到应用程序、内核和硬件之间的交互逻辑，为后续的驱动开发、性能优化打下坚实基础。
下次你玩游戏不卡、切桌面不闪、看视频不掉帧的时候，记得在心里给 DRM 点个赞。
)
