LIBGL_ALWAYS_INDIRECT=1 实际上是做什么的？

Question

KDE SC 4.5.0 有一些视频卡的问题，包括我的。发布后Arch 推荐了几种解决方法。其中之一是

在启动 KDE 之前导出“LIBGL_ALWAYS_INDIRECT=1”

我决定这是最简单、最好的方法。但我不知道它做什么或它如何影响我的系统。它比默认值慢吗？我应该记得密切关注问题并在问题解决后将其禁用吗？

Answer 1

间接渲染意味着将使用 GLX 协议来传输 OpenGL 命令，而 X.org 将进行真正的绘制。

直接渲染意味着应用程序可以直接访问硬件，而无需先通过 mesa 与 X.org 通信。

直接渲染速度更快，因为它不需要将上下文更改为 X.org 进程。

澄清：在这两种情况下，渲染都是由 GPU 完成的（或者从技术上讲 - 可能由 GPU 完成）。但是在间接渲染中，过程如下所示：

1. 程序调用命令
2. 命令通过 GLX 协议发送到 X.org
3. X.org 调用硬件（即 GPU）来绘制

在直接渲染中

1. 程序调用命令
2. 命令被发送到 GPU

请注意，由于 OpenGL 的设计方式可以通过网络运行，因此间接渲染比架构的幼稚实现更快，即允许一次性发送大量命令。然而，在用于上下文切换和处理协议的 CPU 时间方面存在一些开销。

Answer 2

首先，LIBGL_ALWAYS_INDIRECT是与 Mesa 3D 客户端 OpenGL 实现 (libGL.so) 相关的标志。它不适用于其他供应商（例如 NVIDIA）的二进制驱动程序。

其次，为了直接回答您的问题，最后我查看了 Mesa 代码，该标志的工作方式如下：

大约 2008 年之前，当 Mesa 使用间接 X 服务器（例如，您ssh -X已将显示设置为或明确设置为非本地服务器）时，它将使远程 X 服务器提供的 GLX 视觉列表可用于您的 GLX 应用程序。应用程序调用，例如 glXChooseVisual() 和 Mesa 会找到一些合理匹配的东西，随后的glFoo()调用将被发送到远程 X 服务器，在那里它们由远程 X 服务器连接到的任何 libGL（可能是您的 GPU）执行。

大约在 2008 年底，Mesa 发生了变化，因此它希望使用其内部软件 OpenGL 渲染器（Xlib 驱动程序）进行远程 X 连接。（像 SuSE 这样的一些发行版专门对此进行了修补以恢复旧的行为。）只有当远程 X 服务器提供与内部软件渲染器之一完全匹配的 GLX 视觉效果时，这才会启动。（否则，您会得到常见的“错误：无法获得 RGB、双缓冲视觉效果”。）如果找到这样的视觉效果，那么 Mesa 将glFoo()使用本地（应用程序）CPU呈现所有命令，并推送通过光栅图像 ( XPutImage()) 将结果发送到远程 X 服务器；设置LIBGL_ALWAYS_INDIRECT=1（在 Mesa 17.3 之前，任何值都可以使用，从那时起您必须使用1或true) 告诉 Mesa 忽略正常的直接渲染或内部软件渲染器，并像以前一样使用间接渲染。

选择间接渲染或直接软件渲染会影响两件事：

OpenGL 版本

• 间接渲染通常仅限于 OpenGL 1.4。
• 直接软件渲染将支持 Mesa 软件光栅器支持的任何内容，可能是 OpenGL 2.1+

表现

• 如果您的应用程序是为间接连接设计的（它使用显示列表，最小化往返查询），那么您可以获得合理的性能。
• 如果您的应用程序glGetInteger()每帧执行 100 次这样的愚蠢操作，那么即使在快速 LAN 上，每个查询也很容易占用 1 毫秒，或每帧总计 100 毫秒，这意味着您的应用程序永远不会超过 10 FPS。
• 同样的应用程序，如果渲染负载不是太重，直接软件渲染可能会表现得很好，因为所有这些glGetInteger()调用都会在微秒或纳秒内直接得到应答。
• 如果您的应用程序创建了一个百万顶点的显示列表，然后进行了大量旋转，那么在另一端使用真正的 GPU 进行间接渲染将提供更好的性能。
• 当应用程序只有 OpenGL 1.4 与 2.x 可用时，它也可能回退到不同的代码路径，这也会影响性能。

因此，如果没有应用程序的确切细节和网络特性，就无法判断直接软件渲染还是间接渲染在任何给定情况下都更好。

在您的情况下，您似乎正在运行本地 kwin 实例，因此 的效果LIBGL_ALWAYS_INDIRECT是强制间接渲染到您的本地 X 服务器。这显然改变了kwin的行为（仅限 OpenGL 1.4）或避免了其他一些错误。

当根本问题得到解决时，您肯定要删除此标志。