发帖
雷达卡
本文是《深入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
导读
从应用程序发出绘制请求，到图像最终呈现在屏幕上，整个过程涉及多个系统组件的协作。本文将完整梳理这一流程。根据实际经验，初次阅读时感到混乱属于正常现象，可随时返回本节回顾整体脉络。
为帮助理解，以下先提供一个简化的、非严格的技术路径概览，文中所有加粗术语均会在后续展开说明：
- 应用通过其内部图形库向内核中的DRM发起绘图或显存分配请求；
- 内核响应并利用KMS对显示设备进行配置；
- 应用借助DRI机制绕过传统中间层（如使用X Server时），或在Wayland环境下直接与合成器交互，控制GPU执行渲染；
- 完成绘制后，图像数据被提交至显示服务器（在Wayland中即为合成器）进行画面合成；
- 合成后的最终帧由合成器交还给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 工作流程概述
- 启动与初始化：系统启动时，特定 GPU 驱动模块（如 amdgpu、i915 或 nouveau）被加载进内核，并作为 DRM 子系统的一部分运行，接管相应硬件。
- 应用请求处理：当用户空间程序（例如 Mesa 3D 图形库）需要执行绘制操作或申请显存时，会通过 /dev/dri/card0 等设备节点向内核 DRM 发起请求。
- 内核资源调度：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 合成器）需要更改显示输出时，会触发以下步骤：
- 用户请求发起：例如，Wayland 合成器决定将显示模式从 1024x768 调整为 1920x1080。
- 调用 DRM 接口：合成器通过 ioctl 系统调用向内核中的 KMS 模块提交模式变更请求。
- 内核实例验证：KMS 模块依据连接器的 EDID 数据判断目标分辨率是否被支持。
- 原子化更新（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上就不存在这个问题了。
京公网安备 11010802022788号
