[机翻]Driver loading and querying in Mesa[翻译]

回顾

在我之前的文章中，我解释过 Mesa 是一个用于 OpenGL 驱动程序开发的框架。因此，它提供了可由多个驱动程序实现重用的代码。当然，此代码与硬件无关，但可以将驱动程序开发人员从做大部分工作中解放出来。该框架还为开发人员提供了钩子函数，用以添加处理实际硬件的代码。这种设计允许多个驱动程序共存并共享大量代码。

我还解释说，在 Mesa 提供的各种驱动程序中，我们可以找到利用特定 GPU 的硬件驱动程序，和完全在软件中实现的软件驱动程序（因此它们在 CPU 上工作，不依赖于特定 GPU ）。后者显然更慢，但正如我所讨论的，它们在某些情况下可能会派上用场。

 

驱动程序选择

那么，Mesa 提供了多种驱动程序，但是它如何选择适合特定系统要求的驱动程序呢？

您可能已经注意到 Mesa 部署在多个包中。在我的 Ubuntu 系统中，部署 DRI 驱动程序的是libgl1-mesa-dri:amd64。如果您检查其内容，您将看到该软件包为各种 GPU 安装了 OpenGL 驱动程序：

# dpkg -L libgl1-mesa-dri:amd64 
(...)
/usr/lib/x86_64-linux-gnu/gallium-pipe/pipe_radeonsi.so
/usr/lib/x86_64-linux-gnu/gallium-pipe/pipe_r600.so
/usr/lib/x86_64-linux-gnu/gallium-pipe/pipe_nouveau.so
/usr/lib/x86_64-linux-gnu/gallium-pipe/pipe_vmwgfx.so
/usr/lib/x86_64-linux-gnu/gallium-pipe/pipe_r300.so
/usr/lib/x86_64-linux-gnu/gallium-pipe/pipe_swrast.so
/usr/lib/x86_64-linux-gnu/dri/i915_dri.so
/usr/lib/x86_64-linux-gnu/dri/i965_dri.so
/usr/lib/x86_64-linux-gnu/dri/r200_dri.so
/usr/lib/x86_64-linux-gnu/dri/r600_dri.so
/usr/lib/x86_64-linux-gnu/dri/radeon_dri.so
/usr/lib/x86_64-linux-gnu/dri/r300_dri.so
/usr/lib/x86_64-linux-gnu/dri/vmwgfx_dri.so
/usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
/usr/lib/x86_64-linux-gnu/dri/nouveau_vieux_dri.so
/usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so
/usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
(...)

由于我有一个相对较新的 Intel GPU，我需要的驱动程序是 i965_dri.so 中提供的驱动程序。那么我们如何告诉 Mesa 这是我们需要的呢？好吧，答案是我们不知道，Mesa 足够聪明，可以知道哪个驱动程序适合我们的 GPU，并在您加载libGL.so时自动选择它。Mesa 负责处理这件事的部分称为'loader'。

但是，您可以让 Mesa 在默认目录以外的特定目录中查找合适的驱动程序，或者强制它使用使用各种环境变量的软件驱动程序。

Mesa 实际加载的是什么驱动程序？

如果您想确切地知道 Mesa 正在加载什么驱动程序，您可以通过指示LIBGL_DEBUG环境变量将此（和其他）信息转储到stderr：

# LIBGL_DEBUG=verbose glxgears 
libGL: screen 0 does not appear to be DRI3 capable
libGL: pci id for fd 4: 8086:0126, driver i965
libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/tls/i965_dri.so
libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/i965_dri.so

所以我们看到 Mesa 检查现有硬件并意识到i965驱动程序是使用的那个，所以它首先尝试加载那个驱动程序的 TLS 版本，因为我没有 TLS 版本，回落到某个我有的正常版本。

代码src /loader/ loader.c（loader_get_driver_for_fd）是一个负责（检测正确的驱动程序，以使用i965的在我的情况）。这将接收一个设备 fd 作为输入参数，该参数是之前通过调用DRI2Connect()作为 DRI 启动过程的一部分获取的。然后将实际的驱动程序文件加载到glx/dri_common.c (driOpenDriver) 中。

我们还可以通过使用mesa-utils包附带的glxinfo程序获得我们正在加载的驱动程序的更具描述性的指示：

# glxinfo | grep -i "opengl renderer"
OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile 

这告诉我我正在使用 Intel 硬件驱动程序，并且它还共享与我拥有的特定 Intel GPU ( SandyBridge ) 相关的信息。

强制使用软件驱动程序

我已经提到过，有时拥有可用的软件驱动程序会派上用场，但是我们如何告诉加载程序使用它们呢？Mesa 提供了一个我们可以为此目的设置的环境变量，因此在硬件驱动程序和软件驱动程序之间切换非常容易：

# LIBGL_DEBUG=verbose LIBGL_ALWAYS_SOFTWARE=1 glxgears 
libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/tls/swrast_dri.so
libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so

正如我们所见，设置LIBGL_ALWAYS_SOFTWARE将使加载程序选择一个软件驱动程序（swrast）。

如果我像以前一样强制使用软件驱动程序并调用glxinfo，这就是我得到的：

# LIBGL_ALWAYS_SOFTWARE=1 glxinfo | grep -i "opengl renderer"
OpenGL renderer string: Software Rasterizer

所以很明显，在这种情况下我使用的是软件驱动程序。

查询 OpenGL 功能的驱动程序

该glxinfo程序也派上用场，以获取有关具体的OpenGL特性在驱动程序中实现信息。如果您想检查硬件的 Mesa 驱动程序是否实现了特定的 OpenGL 扩展，您可以检查 glxinfo 的输出并查找该扩展：

# glxinfo | grep GL_ARB_texture_multisample

您还可以要求 glxinfo 包括某些 OpenGL 功能的硬件限制，包括-l开关。例如：

# glxinfo -l | grep GL_MAX_TEXTURE_SIZE
GL_MAX_TEXTURE_SIZE = 8192

接下来的是

在我的下一篇文章中，我将介绍 Mesa 存储库的目录结构，确定其主要模块，这应该为 Mesa 新手提供一些指导，指导他们在需要查找处理特定内容的代码时应该在哪里查找。然后，我们将讨论现代 3D 硬件如何改变 GPU 驱动程序的开发方式，并解释现代 3D 图形管道的工作原理，这将为开始研究 Mesa 的真正核心：着色器的实现铺平道路。