第2章 Linux图形栈基础

第二章：Linux图形栈基础

各位同学，今天我们来聊聊Linux图形栈的底层。说实话，这部分内容我当年刚接触时也觉得头大——一堆缩写，DRM、KMS、DRI、GEM，看着就晕。但别怕，我们一层层剥开它。

DRM全称是Direct Rendering Manager，直接渲染管理器。它最早是作为X11的辅助模块出现的，后来逐渐演变成了Linux图形显示的核心框架。我个人习惯把它理解为「图形硬件的管家」——所有跟显示相关的硬件资源，都由它统一调度。

KMS呢，是Kernel Mode Setting的缩写。说白了，就是让内核来管显示模式切换。以前这事是X Server干的，但X Server一旦崩溃，屏幕就黑了。KMS把这活收归内核，稳定多了。我在项目中遇到过好几次，X Server挂了但屏幕还能亮，就是因为KMS在兜底。

核心要点：DRM负责管理GPU和显示控制器，KMS负责管理显示模式和分辨率。两者合在一起，构成了现代Linux图形显示的基石。

DRM/KMS的架构大致分三层：

你想想看，一个显示请求从应用程序到屏幕，中间要经过多少层？嗯，这就是我们接下来要讲的。

DRI，Direct Rendering Infrastructure，直接渲染基础设施。它解决了什么问题？说白了，就是让多个程序能同时访问GPU，而不会打架。

在DRI出现之前，所有图形操作都得经过X Server。这就像只有一个窗口的银行柜台，所有人都得排队。DRI引入了直接渲染的概念——应用程序可以直接跟GPU通信，不用每次都绕道X Server。效率提升是显而易见的。

GEM呢，Graphics Execution Manager，图形执行管理器。它是DRI的一部分，专门管显存分配。我曾经踩过一个坑：在某个嵌入式平台上，显存只有32MB，但应用程序一上来就申请了64MB的缓冲区。GEM会告诉你「不行」，但如果你没做错误处理，程序就直接崩了。

避坑指南：我在做车载仪表盘项目时，发现GEM的缓冲区分配策略对性能影响很大。建议在初始化阶段就预分配好所有缓冲区，避免运行时动态分配带来的延迟。

GEM的核心概念包括：

这里有个细节要注意：GEM的Handle只在同一个进程内有效。如果你想在两个进程间共享显存，得用Prime机制。我记得第一次做多进程渲染时，就因为这个吃了亏——两个进程各自申请了显存，结果内存直接翻倍了。

Mesa 3D，很多人以为它是个GPU驱动。其实不完全是。Mesa更像是一个「图形API的翻译官」——它把OpenGL、Vulkan这些上层API的调用，翻译成底层GPU能理解的指令。

Mesa的架构大致是这样的：

为什么需要Mesa？因为GPU厂商太多了，每个厂商的指令集都不一样。如果每个应用程序都要直接跟GPU打交道，那开发者得疯掉。Mesa提供了一个统一的接口，让开发者只需要写OpenGL代码，剩下的交给Mesa去适配。

注意：Mesa的软件光栅化（softpipe/llvmpipe）性能很差，只适合调试。生产环境中一定要用硬件加速驱动。我在一个项目里见过有人忘了装硬件驱动，结果Mesa自动回退到软件渲染，帧率直接从60fps掉到5fps。

说到Mesa，不得不提Gallium架构。Gallium是Mesa内部的一个模块化框架，它把驱动分成了两部分：

这种分离的好处是，如果你想支持一个新的GPU，只需要写一个管道驱动就行，状态跟踪器可以复用。嗯，这就是为什么Mesa能支持那么多GPU的原因。

好了，现在我们把DRM/KMS、DRI/GEM、Mesa串起来，看看一个完整的渲染流程是什么样的：

整个过程看起来复杂，但实际延迟只有几毫秒。我在车载系统上做过测试，从应用程序提交渲染命令到屏幕显示，最快能做到16ms以内——刚好满足60fps的要求。

实战建议：在车载Linux系统中，我建议使用DRM直接渲染，而不是走X11/Wayland的合成器。这样可以减少一层拷贝，延迟更低。当然，前提是你的应用程序不需要窗口管理功能。

最后说一句，这些底层知识虽然枯燥，但理解了它们，你才能真正掌握图形性能优化的精髓。下次遇到画面撕裂、帧率不稳的问题，你就知道该从哪里入手了。

好，这一章就到这里。下一章我们讲Wayland的架构设计，看看它怎么解决X11的遗留问题。