从今天开始，我准备给自己挖一个大坑：从零基础开始，系统地梳理下 Mesa 3D 驱动的内部实现，以及 Intel DRI 驱动的工作原理。之前虽然写过一些零散的博客，但始终缺少一次完整的整理。于是就有了这个系列，先从 Linux 图形栈说起，对整体框架做一个简要介绍。

要深入理解当今的 Linux 图形栈，首先需要回顾其历史背景及演进过程。这将为理解其架构和各个组成模块奠定基础。

一：2D图形阶段

在早期的设计中，只有 X 服务器能够直接与图形硬件交互。这种集中式的访问模式简化了整个图形堆栈的实现，因为无需在多个客户端之间协调对图形硬件的并发访问。

在这个时期，应用程序的所有绘制工作都是通过 X 服务器间接完成的。应用使用 Xlib 接口，通过 X11 协议向X 服务器发送渲染请求；X 服务器接收并解析这些请求，然后将其转换为底层图形硬件能够理解的命令并执行。需要注意的是，这一转换过程实际上由图形驱动程序完成：驱动接收一组与具体硬件无关的渲染指令作为输入，并将其翻译为目标 GPU 所期望的硬件指令。

由于 X 服务器是唯一能够与图形硬件直接通信的软件，这些图形驱动程序也都是专门为 X 服务器编写的，并作为其内部模块存在，成为 X 服务器架构中不可或缺的一部分。这类运行在用户空间的驱动程序在 X 服务器的术语中被称为 DDX（Device Dependent X）驱动。它们在图形堆栈中的主要职责，是为 Xlib 所导出的接口提供支持，实现 X 服务器所需的各类 2D 图形操作。例如，在早期的Ubuntu系统中，Intel GPU的DDX驱动通常由xserver-xorg-video-intel软件包提供，其他GPU供应商也有各自对应的DDX实现。

二：3D图形阶段

前面的设计架构主要针对2D图形绘制，因为X服务器最初正是为2D绘制而设计的。然而，随着3D图形硬件的出现，这一局面被彻底改变，接下来我们将对这一演进过程进行更详细的说明。在Linux系统中，3D图形通常通过OpenGL来实现，因此人们自然希望该标准的实现能够充分利用现代3D图形硬件，即使用硬件加速的libGL.so。然而，在早期的架构中，只有X服务器才能直接访问图形硬件，这使得应用程序无法通过libGL.so与3D硬件直接通信。

为了解决这一问题，人们提供了一种 OpenGL 的实现方式：通过 X11 协议的扩展，将 OpenGL 命令发送给 X 服务器，再由 X 服务器像处理 2D 绘制命令一样，将这些 OpenGL 命令转换为实际的硬件指令。这种渲染方式被称为“间接渲染”（Indirect Rendering），因为应用程序并不直接向图形硬件提交渲染命令，而是经由 X 服务器间接完成整个渲染过程。

然而，很快开发者便意识到，这种方案并不足以满足游戏等高强度 3D 应用的需求。这类应用需要在渲染大量 3D 场景的同时保持较高的帧率，而将 OpenGL 调用封装并通过 X11 协议传递，本身就引入了显著的开销，显然不是一种高效的解决方式。要在 3D 应用中获得可接受的性能，应用程序必须能够更直接地访问图形硬件，这也迫使人们重新审视并重构 Linux 图形栈中的很大一部分设计。

四：直接渲染架构（DRI）

正是在这样的背景下，直接渲染架构（Direct Rendering Infrastructure，简称 DRI）应运而生。DRI 引入了一种全新的架构，使得 X 客户端能够在受控的前提下直接与图形硬件进行通信。为了实现这一目标，Linux 图形栈的多个组成部分都需要进行相应的改造和配合，包括 X 服务器、内核，以及各类图形客户端程序。

尽管DRI一词通常用来指代整个直接渲染架构，但在很多语境下，它也被用来特指其中应用程序与 X 服务器交互的那一部分。因此，在查阅相关资料时，需要注意这一术语所具有的双重含义。DRI架构中的另一个关键组成部分是直接渲染管理器（Direct Rendering Manager，简称 DRM），它位于内核空间，构成了 DRI 的内核端实现。内核端负责处理诸如硬件访问控制、并发同步以及显存管理等敏感问题。与此同时，DRM 还向用户空间提供了一套 API，使用户空间程序能够以符合现代 GPU 要求的格式提交命令和数据，从而在受控的环境下实现与图形硬件的高效通信。

需要注意的是，许多底层操作都必须针对具体的硬件进行专门实现，因此每一种 GPU都对应着不同的 DRM 驱动程序，这些驱动构成了 GPU 的内核态驱动（Kernel Mode Driver，简称 KMD）。在 Ubuntu 系统中，以 Intel GPU 为例，其 DRM/KMS 内核模块由内核本身提供（如 i915模块），而用户空间则通过 libdrm提供的库接口与内核中的DRM 驱动进行交互。

五：引入Mesa

DRI/DRM 提供了必要的构建模块，使用户空间应用程序能够在高效且安全的前提下直接访问图形硬件。然而，要在此基础上使用 OpenGL，还需要额外的软件层来实现 OpenGL API。这个软件既要利用 DRI/DRM 提供的底层功能，又要满足 X 服务器的接口和规范要求，从而保证应用程序能够通过标准化的方式进行 3D 渲染。

Mesa 是 OpenGL 规范的自由软件实现，它提供了libGL.so库，使基于 OpenGL 的应用程序能够在 Linux 系统上渲染 3D 图形。Mesa利用 DRI 架构直接访问底层图形硬件，从而在实现OpenGL API 的同时，提供高效的 3D 图形性能。

当我们的 3D 应用程序在X11 环境中运行时，它会将图形输出到由 X 服务器分配的表面（窗口）。需要注意的是，在使用 DRI 的情况下，渲染过程无需 X 服务器直接参与，但为了确保显示正确，两者之间仍需进行必要的同步。X 服务器依然管理着 Mesa 渲染的窗口，并负责将其内容显示到屏幕上。OpenGL 应用程序与 X 服务器之间的这种同步机制，正是 DRI 架构的一部分。Mesa 对GLX（OpenGL 在 X11 平台的扩展接口）的实现正是通过 DRI 与 X 服务器进行通信，以完成这种同步操作。

Mesa 在执行许多操作时也依赖DRM。它与图形硬件的通信通常以发送命令（例如“绘制一个三角形”）和数据（如三角形的顶点坐标、颜色属性、法线等）的形式进行。为了让 GPU 能够访问这些信息并执行渲染任务，通常需要在图形硬件上分配一系列缓冲区，并将所有命令和数据复制到这些缓冲区中。DRM 驱动程序负责管理显存，并向用户空间（在本例中为 Mesa）提供 API，使其能够针对特定硬件执行这些操作。换言之，每当 Mesa 需要分配或管理显存时，都会调用 DRM 提供的接口；诸如创建纹理、上传数据到纹理、分配颜色缓冲区、深度缓冲区或模板缓冲区等操作，都依赖于针对目标硬件的 DRM API。

六：总结

至此，我希望读者对 Mesa 在 Linux 图形栈中的角色已经有了基本的理解，以及它如何依托直接渲染基础架构（DRI）来通过 OpenGL 实现高效的 3D 渲染。在下一篇文章中，我们将更深入地探究 Mesa 本身，了解它作为一个框架所包含的多个 OpenGL 驱动，包括硬件和软件实现。同时，我们会梳理其目录结构，识别核心模块，并介绍 Gallium 框架及其在 Mesa 中的作用，让大家对整个架构有更直观的认识。