本文是《深入Linux GPU AMD GPU渲染与AI技术实践》读书笔记，以通俗简洁的方式重述知识。

干货长文预警，建议您做好准备。

关键词： Linux GPU 计算机图形学

目录

• 导读
• 渲染
• 显示服务器
• X
• Wayland
• DRI
• DRI 1 / DRI 2 / DRI 3
• 显存接口
• FrameBuffer（fbdev）
• DumbBuffer（DRM）
• 合成与送显
• Linux内核
• DRM
• KMS
• VBlank与VSync

导读

从应用程序发出绘制请求，到图像最终呈现在屏幕上，整个过程涉及多个系统组件的协作。本文将完整梳理这一流程。根据实际经验，初次阅读时感到混乱属于正常现象，可随时返回本节回顾整体脉络。

为帮助理解，以下先提供一个简化的、非严格的技术路径概览，文中所有加粗术语均会在后续展开说明：

1. 应用通过其内部图形库向内核中的DRM发起绘图或显存分配请求；
2. 内核响应并利用KMS对显示设备进行配置；
3. 应用借助DRI机制绕过传统中间层（如使用X Server时），或在Wayland环境下直接与合成器交互，控制GPU执行渲染；
4. 完成绘制后，图像数据被提交至显示服务器（在Wayland中即为合成器）进行画面合成；
5. 合成后的最终帧由合成器交还给DRM，通过KMS在VSync信号同步下刷新至显示器。

渲染流程概述

现代Linux图形系统的渲染链路包含多个层级，核心目标是高效、低延迟地将应用内容输出到屏幕。不同显示架构在此过程中采取了不同的策略。

显示服务器：X 与 Wayland 的演进

在Linux系统中，“显示服务器”负责管理图形输出、输入事件和窗口布局。历史上以X Window System（简称X或X11）为主流，近年来逐渐被更现代化的Wayland取代。

X Window System（X11）

X作为传统架构，充当应用程序与硬件之间的中介角色。应用无法直接访问GPU，必须通过X服务器转发渲染指令。

典型渲染流程如下：

• 某个应用程序（例如浏览器）需要绘制UI元素（如按钮或文字），会将其操作封装为X协议请求（例如：“在坐标(100, 50)处绘制一个蓝色矩形”）；
• 该请求通过本地套接字（逻辑上视为网络连接）发送至X服务器；
• X服务器接收请求后，负责处理窗口管理、输入事件及资源调度，并将高级请求翻译成显卡可识别的低级绘图命令；
• 这些命令交由底层图形驱动和DRI/DRM架构执行，完成GPU渲染；
• 由于X本身不支持现代视觉效果（如透明、阴影、动画等），需依赖独立运行的合成管理器（如Compiz、Metacity）进行后期处理；
• 合成器从X服务器获取各窗口内容，进行叠加、特效处理后，将最终画面提交给显卡输出。

流程总结：

应用程序 → X协议请求 → X服务器 → 绘图命令 → 合成管理器 → 合成后画面 → 屏幕

主要缺点：

• 存在额外的协议翻译和通信开销；
• 窗口内容需被合成器复制一次才能处理，增加内存带宽占用；
• 多层传递导致延迟较高，难以避免屏幕撕裂问题。

Wayland

Wayland的实现高度依赖DRI2及3的特性，请继续往下读。

Wayland采用更为集成的设计理念，不再区分“显示服务器”与“合成器”。在该架构中，合成器（Compositor）本身就是显示服务器，代表实现包括Weston、KWin、Mutter等。

渲染流程如下：

• 应用程序（客户端）使用现代图形API（如OpenGL、Vulkan或Mesa）直接绘制到一块缓冲区中，该缓冲区位于显存或共享内存区域；
• 绘制完成后，应用不再发送绘图命令，而是通过Wayland协议通知合成器：“我已更新画面，请使用此缓冲区ID”；
• 合成器接收到引用信息后，借助DRI 3支持的零拷贝机制，无需复制数据即可直接访问该缓冲区；
• 随后，合成器整合所有可见窗口的缓冲区，完成最终画面的组装与合成；
• 合成结果直接提交至内核DRM模块，由KMS在垂直同步（VSync）时机输出至显示器。

流程总结：

应用程序 → 直接绘制到缓冲区 → 合成器（Wayland） → 零拷贝引用与合成 → 屏幕

核心优势：

• 去除了X Server的中间翻译层，减少通信延迟；
• 采用缓冲区引用而非数据复制，显著降低内存带宽消耗；
• 结合DMABUF等技术实现真正的零拷贝传输；
• 渲染效率更高，响应更快，且天然规避屏幕撕裂。

架构对比：X vs Wayland

对比维度	X Window System (X11)	Wayland
中央核心	X Server（独立中间服务）	Compositor（合成器兼显示服务器）
数据传输方式	复制（App → X Server → Compositor）	引用（App 与 Compositor 共享缓冲区）
绘图模式	基于命令：App 请求 X Server 画图	基于缓冲区：App 自主绘制后提交引用
屏幕撕裂控制	需合成器额外干预，难以根除	天然支持VSync同步，有效避免

DRI 发展历程

DRI（Direct Rendering Infrastructure）是Linux下实现应用程序直接访问GPU的关键机制，历经三个主要版本迭代：

• DRI 1：初期版本，允许多个客户端竞争性访问GPU，但缺乏协调机制，稳定性差；
• DRI 2：引入缓冲区对象管理和客户端隔离，提升了安全性和性能；
• DRI 3：进一步优化，支持持久化缓冲区句柄和DMA-BUF共享，为Wayland的零拷贝提供了底层支撑。

显存接口

操作系统与显存交互依赖特定接口：

• FrameBuffer（fbdev）：早期简单接口，提供线性显存映射，适合基本显示，但不支持现代GPU复杂功能；
• DumbBuffer（DRM）：DRM子系统提供的通用缓冲区分配机制，用于创建非加速但可共享的内存块，常用于光标、简单图层等场景。

合成与送显机制

合成器完成多窗口整合后，需将最终画面安全送显，避免撕裂。这依赖于内核层面的支持。

Linux内核图形子系统

核心组件包括：

• DRM（Direct Rendering Manager）：管理GPU资源、内存分配、命令提交及设备控制；
• KMS（Kernel Mode Setting）：DRM的一部分，负责设置显示模式（分辨率、刷新率）、管理扫描输出和多屏配置；
• VBlank 与 VSync：垂直空白期信号，用于同步帧提交与显示器刷新周期，防止画面撕裂。

当合成器准备好新帧时，通过KMS接口将缓冲区提交至DRM，在下一个VBlank期间触发VSync切换，确保平滑更新。

DRM（Direct Rendering Manager，直接渲染管理器）是 Linux 内核中的一个核心子系统，主要负责对图形硬件（尤其是 GPU）进行统一、安全的管理。其管理范围涵盖显存分配、显示模式设置以及 3D 渲染访问权限控制等关键功能。

在 DRM 出现之前，显卡厂商需在用户空间自行开发复杂的驱动程序来直接操控硬件。这种方式存在显著缺陷：

• 不稳定与不安全：多个应用同时操作显卡或显存时容易引发冲突，导致系统崩溃。
• 资源管理低效：难以有效协调共享资源（如显存），影响整体性能。

为解决上述问题，DRM 将图形硬件的核心控制权从用户空间转移至内核空间，从而实现更安全、稳定且高效的资源调度。

DRM 的核心组成模块

DRM 并非单一组件，而是由多个协同工作的部分构成：

• DRI（Direct Rendering Infrastructure）：提供应用程序直接访问 GPU 的架构支持。
• GEM（Graphics Execution Manager）：Intel 提出的轻量级显存管理机制。
• TTM（Translation Table Maps）：AMD 主导的通用显存管理框架，适用于复杂场景。
• KMS（Kernel Mode Setting）：负责显示器输出配置，包括分辨率、刷新率等。
• DMABUF：支持跨设备内存共享和高性能“零拷贝”数据传输的关键技术。

DRM 工作流程概述

1. 启动与初始化：系统启动时，特定 GPU 驱动模块（如 amdgpu、i915 或 nouveau）被加载进内核，并作为 DRM 子系统的一部分运行，接管相应硬件。
2. 应用请求处理：当用户空间程序（例如 Mesa 3D 图形库）需要执行绘制操作或申请显存时，会通过 /dev/dri/card0 等设备节点向内核 DRM 发起请求。
3. 内核资源调度：DRM 利用 GEM 或 TTM 完成显存分配，并通过 KMS 设置合适的显示模式，确保图形输出正确无误。

DRI 演进历程

DRI（Direct Rendering Infrastructure，直接渲染架构）是构建于 DRM 之上的关键技术，旨在提升 3D 图形渲染效率，使应用程序能够高效地直接使用显卡硬件进行绘图。

DRI 1

诞生于 2000 年左右，是最早的版本。其设计思想是允许客户端应用绕过 X Server 直接访问显卡硬件。

通俗类比：如同办公室员工跳过前台，直接将打印任务交给打印机。

早期的X Server对渲染性能影响较大，所以需要跳过。到了基于DRI 3的Wayland上就不存在这个问题了。

缺点：缺乏有效的资源协调机制，在多程序并发访问时易产生冲突，安全性差，需依赖复杂同步逻辑防止系统崩溃。

DRI 2

约在 2008 年推出，用于替代 DRI 1。核心改进在于引入 DRM 模块，由内核统一管理显存和图形上下文。

形象比喻：新增一位主管（即 DRM/内核），所有员工必须先提交任务给主管，再由其统筹安排打印机使用顺序，避免争抢。

DRM-DRI架构是现代Linux图形栈的基石，DRM在后文会详细介绍。

优势：有效解决了 DRI 1 的同步与安全问题，提升了整体性能，并采用现代内核内存管理机制，更加可靠。

DRI 3

发布于 2012 年前后，是当前主流版本。重点优化了数据传输路径，实现了“零拷贝”机制。

进一步比喻：主管不再要求员工重复提交文件副本，而是仅获取原始文件的位置指针，省去复制过程，大幅提高效率。

这一机制显著减少了内存带宽消耗和 CPU 开销，特别适合高帧率图形应用。

显存接口技术

FrameBuffer（fbdev）

FrameBuffer（简称 fbdev）是 Linux 内核提供的硬件无关图形显示接口，存在于系统内存或显存中，其布局与屏幕像素严格对应。

每个屏幕像素在 FrameBuffer 中都有唯一地址，存储着对应的颜色值。内核提供特殊设备文件（如 /dev/fb0、/dev/fb1），应用程序可通过读写这些文件直接修改显示内容。

显卡的显示控制器会持续扫描 FrameBuffer 数据，并据此驱动显示器实时更新画面。

DumbBuffer（基于 DRM）

Dumb Buffer 是 DRM 架构下的一种简单显存分配机制，设计目标是兼容性和普适性。它模仿 fbdev 的工作方式，允许应用程序通过标准方法（如 mmap 内存映射）直接访问分配的显存区域。

即使在驱动较新或环境受限的情况下，Dumb Buffer 也能提供一种通用且可靠的显存访问途径。

简单来说，fbdev是内核分配内存用以渲染，DumbBuffer是在DRM接口下分配显存。

综上所述，从 DRI 到 DRM，再到各类显存接口与合成机制的发展，Linux 图形栈逐步实现了从粗放式控制到精细化管理的演进，为现代桌面图形体验奠定了坚实基础。

DRM 提供了一个安全的通信通道，使应用程序能够通过直接渲染（DRI）机制将渲染指令直接发送至 GPU，避免了传统 X 服务器中需经由中间服务转发的架构。

渲染完成后，图像数据会借助 KMS（Kernel Mode Setting，内核模式设置）机制，结合 VSync 信号实现同步输出，确保画面稳定地传输到显示设备上。

KMS 简介

KMS，全称为 Kernel Mode Setting（内核模式设置），是 Linux 内核的一项核心功能，主要用于管理视频输出配置，包括分辨率、刷新率等视频模式参数，以及显示器连接状态和布局等显示信息。

核心作用：统一控制显示配置

在 KMS 出现之前，系统使用的是用户模式设置（UMS）。此时，诸如分辨率、色彩深度等关键显示参数由运行在用户空间的程序（如 X Server）负责配置。这种设计存在多个缺陷：

• 稳定性风险： 若用户空间进程崩溃，可能导致显示设置异常甚至屏幕黑屏。
• 视觉干扰： 在切换分辨率或从文本控制台进入图形界面时，常因模式重置延迟而出现闪烁现象。
• 代码冗余： 显卡厂商需要分别在内核与用户空间重复实现模式设置逻辑，增加维护成本。

KMS 的引入解决了上述问题，它将显示模式的控制权集中到 Linux 内核中，实现了更高效、安全和一致的显示管理。

KMS 的三大核心组件

KMS 将整个显示输出流程抽象为三个相互协作的基本单元：

CRTC（阴极射线管控制器）：代表一个抽象的显示源，用于指定哪一块显存缓冲区（FrameBuffer 或 Buffer Object）的内容应当被扫描输出至屏幕。

Connector（连接器）：对应显卡上的物理接口，例如 HDMI、DisplayPort、VGA 或 DVI，表示当前连接了何种显示设备。

Encoder（编码器）：负责将 CRTC 输出的数字信号转换成适合特定 Connector 所需的传输格式，完成信号适配与编码。

模式设置的工作流程

当图形环境（如 Wayland 合成器）需要更改显示输出时，会触发以下步骤：

1. 用户请求发起：例如，Wayland 合成器决定将显示模式从 1024x768 调整为 1920x1080。
2. 调用 DRM 接口：合成器通过 ioctl 系统调用向内核中的 KMS 模块提交模式变更请求。
3. 内核实例验证：KMS 模块依据连接器的 EDID 数据判断目标分辨率是否被支持。
4. 原子化更新（Atomic Update）：现代 KMS 支持原子操作，可同时提交 CRTC、Encoder 和 Connector 的配置变更。在此过程中，CRTC 被重新编程以匹配新的分辨率及时序参数，Encoder 也可能被重新配置以满足新连接需求。

Wayland的实现高度依赖DRI2及3的特性，请继续往下读。

VBlank 与 VSync 的协同机制

VBlank 是一种基于硬件的定时机制，指显示器完成一帧画面扫描后、开始下一帧前的一段短暂空白期。这段时间内，屏幕不进行像素绘制，处于“垂直回扫”状态。

在 Linux 的 AMDGPU 驱动中，每当 VBlank 发生时，硬件会产生一个中断信号。该信号成为驱动程序及上层图形系统（如 Wayland 合成器）进行时间同步的关键参考点。

VSync 则是一种利用 VBlank 信号实现的软件同步技术，其主要目的是协调 GPU 渲染节奏与显示器刷新频率，防止出现画面撕裂（Tearing）。

VSync 的工作原理如下：

• 等待时机： 当应用或合成器提交新帧渲染任务时，GPU 驱动会暂停操作，直到接收到下一个 VBlank 中断信号。
• 安全翻转： 只有在 VBlank 期间（即屏幕未扫描画面时），驱动才会将已渲染完成的新帧缓冲区“翻转”为当前显示内容。
• 帧完整性保障： 通过这种方式，每一帧都被完整显示，不会在扫描中途被替换，从而彻底消除画面撕裂现象。

早期的X Server对渲染性能影响较大，所以需要跳过。到了基于DRI 3的Wayland上就不存在这个问题了。