在工作的过程中逐渐有了总结一下当前Gfx技术栈的想法,方便自己对Linux Gfx的整体结构有更好的理解。
总的来说,这一些列文章大部分会翻译自https://blogs.igalia.com/itoral/,这是在查资料的过程中发现的一个老哥的博客,其中对Linux Graphics的理解写的很好。中间根据我的理解会插入一些知识点的补充。
本篇文章会对Linux Graphics技术栈做一个简短的介绍,将着重于提供足够的背景知识来理解Mesa和3D驱动程序在技术栈的作用,以便后续文章中深入了解Mesa和Intel DRI驱动程序的本质。
为了理解当前Graphics技术栈的一些特性,理解Graphics技术是如何变化以适应这些年不断变化的需求和挑战是非常重要的。
正如你所知,现在的Graphics技术比过去要复杂得多,在早期只有一种软件可以直接访问图形硬件:X server。这种方法简化了Graphics Stack,因为它不需要在多个客户端之间同步对Graphics hardware的访问。
在早期,Application将通过X server间接完成所有绘图。通过使用Xlib,他们将通过X11协议发送渲染命令,X server将接收、处理并转换为套接字另一侧的实际硬件命令。请注意,此“转换”是driver的工作:它将一组与硬件无关的渲染命令作为输入,并按照目标GPU的预期将其转换为硬件命令。
由于X server是设计中唯一可以与Graphics hardware通信的软件,因此这些driver是专门为其编写的,成为X server本身的模块和其体系结构的一个组成部分。这些user space driver在X server argot中称为DDX driver,它们在Graphics Stack中的作用是支持Xlib导出的2D操作以及X server实现所需的2D操作。
例如在我的ubuntu系统中,Intel GPU的DDX driver就来自xserver-xorg-video-intel package,对于其他GPU厂商来说也有类似的package.
上述内容涵盖了2D Graphics,因为这正是X server过去的全部内容。然而,3D Graphics hardware的到来极大地改变了场景,我们现在将看到这一点。
在Linux中,3D Gpraphics是通过OpenGL实现的,因此人们希望该标准的实现能够充分利用3D Graphics hardware,即硬件加速(hardware accelerated)的libGL.so. 然而在一个只允许X server访问Graphics hardware的系统中,我们不能使用libGL.so直接与3D硬件进行沟通。相反,解决方案是提供一个OpenGL实现,它通过X11协议的扩展将OpenGL命令发送到X server,并让X server将这些命令转换为实际的硬件命令,就像之前对2D命令所做的那样。
我们把上述过程叫做间接渲染(Indirect Rendering),因为application没有直接把渲染命令发给graphics hardware,而是通过X server间接渲染。
不幸的是,开发人员很快就会意识到,这种解决方案不足以满足密集型3D application(如游戏)的需要,这些应用程序需要在保持高速率的同时渲染大量3D图形。问题很明显:在X11协议中包装OpenGL调用不是有效的解决方案。
为了在3D application中获得良好的性能,我们需要这些程序来直接访问hardware,这需要重新考虑大块的Graphics Stack。
Direct Rendering Infrastructure(DRI)是一种新的体系结构,它允许X client直接与Graphics hardware对话。实现DRI需要对Graphics stack的各个部分进行更改,包括X server、kernel 和各种client lib。
尽管术语DRI通常指的是完整的体系结构,但它通常也仅指中涉及application与X server交互的特定部分,因此在网上查阅相关资料时,尤其需要注意这一双重含义。
DRI的另一个重要部分是Direct Rendering Manager(DRM)。这是DRI体系结构中的kernel side。在这里,kernel处理诸如硬件锁定、访问同步、视频内存等方面。DRM还为用户空间提供了一个API,可用于以适合现代GPU的格式提交命令和数据,从而有效地允许user space与graphics hardware通信。
需要注意的时,许多操作都必须专门针对target hardware(目标硬件)进行,因此每个GPU都有不同的DRM驱动程序。在我的Ubuntu系统中,英特尔GPU的DRM模块是通过libdrm-intel1:amd64包提供的。
DRI/DRM提供了使user space application能够以高效和安全的方式直接访问图形硬件的构建块(building blocks),但为了使用OpenGL,我们还需要另一个software,该软件使用DRI/DRM提供的基础设施,在满足X服务器要求的同时实现OpenGL API。
Mesa是OpenGL规范的自由软件实现,它提供了一个libGL.so,使得Linux中基于OpenGL的application可以用libGL.so来输出3D图形。Mesa可以在其OpenGL API的实现(Implementation)中,利用DRI架构获取对底层Graphics hardware的直接访问,从而提供3D硬件加速。
当我们的3D应用程序在X11环境中运行时,它会将其图形输出到X server分配的surface(window)。但是,请注意,对于DRI,这将在没有X服务器干预的情况下发生,因此在这两者之间自然要进行一些同步,因为X server仍然拥有Mesa正在渲染的窗口,并且是负责在屏幕上显示其内容的窗口。OpenGL应用程序和X server之间的同步是DRI的一部分。Mesa对GLX的实现(针对X11平台的OpenGL规范的扩展)使用DRI与X server对话并完成此任务。
Mesa还必须在许多方面使用DRM。与Graphics hardware通信是通过发送命令(例如“绘制三角形”)和数据(例如三角形的顶点坐标、其颜色属性、法线等)实现的。这个过程通常涉及在图形硬件中分配一组buffer,在这些buffer中复制所有这些命令和数据,以便GPU可以访问它们并执行其工作。这是由DRM驱动程序实现的,DRM驱动程序负责管理视频内存,并向user space(本例中为Mesa)提供API,以便为特定的目标硬件执行此操作。当我们需要在Mesa中分配和管理视频内存时,也需要DRM,因此创建纹理、将数据上载到纹理、分配颜色、深度或模具缓冲区等都需要为目标硬件使用DRM API。
本篇解释了Mesa在Linux图形堆栈中的作用,以及它如何与DRI协同工作,通过OpenGL实现高效的3D Graphics。在下一篇文章中,我们将更详细地介绍Mesa,我们将看到它实际上是一个多个OpenGL驱动程序共存的框架,包括多种hardware和software,我们还将查看其目录结构并确定其主要模块,介绍Gallium框架等