LIBGL_ALWAYS_INDIRECT = 1实际做什么？

KDE SC 4.5.0对于某些视频卡（包括我的视频卡）存在一些问题。在发行时，Arch建议了几种解决方法。其中之一是

在启动KDE之前导出“ LIBGL_ALWAYS_INDIRECT = 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时间而言，存在一些开销。

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

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

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

Mesa在2008年底左右进行了更改，因此它希望使用其内部软件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上，这些查询中的每个查询也很容易占用1ms或每帧总计100ms，这意味着您的应用程序永远不会获得超过10 FPS的速度。
• 如果渲染负载不太重，那么同一应用程序在直接软件渲染中可能会表现出色，因为所有这些glGetInteger()调用都将在微秒或纳秒的时间内直接得到答复。
• 如果您的应用程序创建了一个百万顶点显示列表，然后进行了很多旋转，那么在另一端使用真实GPU进行间接渲染将提供更好的性能。
• 当应用程序只有OpenGL 1.4 vs 2.x可用时，它也可能退回到不同的代码路径，这也会影响性能。

因此，在没有确切应用程序细节和网络特征的情况下，您将无法看到直接软件渲染还是间接渲染在任何给定情况下都更好。

就您而言，您似乎正在运行本地kwin实例，因此的作用LIBGL_ALWAYS_INDIRECT是强制向本地X服务器间接渲染。显然，这可以更改kwin行为（仅适用于OpenGL 1.4），或者可以避免其他错误。

您肯定想在基本问题解决后删除此标志。