KDE SC 4.5.0 对某些显卡（包括我的显卡）存在一些问题。释放后Arch 推荐了几种解决方法。其中之一是
在启动 KDE 之前导出“LIBGL_ALWAYS_INDIRECT=1”
我认为这是最简单、最好的方法。但我不知道它的作用或它如何影响我的系统。它比默认的慢吗？我是否应该记得密切关注该问题并在问题修复后将其禁用？
答案1
间接渲染意味着GLX协议将用于传输OpenGL命令，而X.org将进行真正的绘制。
直接渲染意味着应用程序可以直接访问硬件，而无需先通过 mesa 与 X.org 通信。
直接渲染速度更快，因为它不需要将上下文更改为 X.org 进程。
澄清：在这两种情况下，渲染都是由 GPU 完成（或者从技术上讲 - 可能由 GPU 完成）。然而，在间接渲染中，该过程如下所示：
- 程序调用命令
- 命令通过 GLX 协议发送到 X.org
- X.org调用硬件（即GPU）进行绘制
直接渲染中
- 程序调用命令
- 命令被发送到 GPU
请注意，由于 OpenGL 的设计方式可以通过网络进行操作，因此间接渲染速度比简单的架构实现更快，即允许一次性发送一堆命令。然而，在上下文切换和处理协议所花费的 CPU 时间方面存在一些开销。
答案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 渲染所有命令，并通过光栅图像将结果推送到远程 X 服务器 ( XPutImage())；设置LIBGL_ALWAYS_INDIRECT=1（在 Mesa 17.3 之前，任何值都可以工作，从那时起你必须使用1或者真的）告诉 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），要么避免了一些其他错误。
当根本问题得到解决后，您肯定希望删除此标志。