KDE SC 4.5.0 has some problems with some video cards including mine. Upon Release Arch recommended several workarounds. One of which was

export "LIBGL_ALWAYS_INDIRECT=1" before starting KDE

I decided that it was the easiest, best method. But I don't know what it does or how it impacts my system. Is it slower than the default? should I remember to keep an eye on the problem and disable it later once it's fixed?

2 Answers 2


Indirect rendering means that the GLX protocol will be used to transmit OpenGL commands and the X.org will do the real drawing.

Direct rendering means that application can access hardware directly without communication with X.org first via mesa.

The direct rendering is faster as it does not require change of context into X.org process.

Clarification: In both cases the rendering is done by GPU (or technically - may be done by GPU). However in indirect rendering the process looks like:

  1. Program calls a command(s)
  2. Command(s) is/are sent to X.org by GLX protocol
  3. X.org calls hardware (i.e. GPU) to draw

In direct rendering

  1. Program calls a command(s)
  2. Command(s) is/are sent to GPU

Please note that because OpenGL was designed in such way that may operate over network the indirect rendering is faster then would be naive implementation of architecture i.e. allows to send a buch of commands in one go. However there is some overhead in terms of CPU time spent for context switches and handling protocol.

  • Does this mean my CPU is doing the rendering atm instead of my video chip? Commented Aug 31, 2010 at 20:17
  • 3
    No. In both cases the GPU does the drawing if you have acceleration - however there is additional overhead. Not accelerated drawing is extreamly slow and no effects which would require LIBGL_ALWAYS_INDIRECT=1 would work with it (i.e. indirect rendering workaround is usually needed for advanced use of OpenGL such as composite wm). Commented Aug 31, 2010 at 20:43
  • Some hardware functions can't operate over indirect, or simply don't because doing so would be inefficient. The driver automatically determines which would be more efficient. Mesa has seen substantial improvement in the accuracy of these estimates, though, so it's no longer presuming all indirect connections are over a network. Previously, the vast majority of the time indirect rendering would result in Mesa believing software rendering was faster. This is why it there is the misunderstanding in thinking that indirect rendering is always CPU based. Commented Jan 10, 2020 at 20:08

First, LIBGL_ALWAYS_INDIRECT is a flag related to the Mesa 3D client-side OpenGL implementation (libGL.so). It won't work with binary drivers from other vendors (e.g. NVIDIA).

Second, to answer your question directly, last I looked at the Mesa code the flag works like this:

Pre ~2008 when Mesa was working with an indirect X server (e.g. you did ssh -X or explicitly set your display to a non-local server) it would make the list of GLX visuals provided by the remote X server available to your GLX application. The application calls e.g. glXChooseVisual() and Mesa would find something reasonable to match, and subsequent glFoo() calls would be sent to the remote X server where they were executed by whatever libGL the remote X server was hooked up to (likely your GPU).

Around the end of 2008 Mesa was changed so that it wanted to use its internal software OpenGL renderer (Xlib driver) for remote X connections. (Some distributions like SuSE specifically patched this to go back to the old behaviour.) This would only kick in if the remote X server offered a GLX visual that exactly matched one of the internal software renderer. (Otherwise you'd get the common, "Error: couldn't get an RGB, Double-buffered visual".) If such a visual was found then Mesa would render all glFoo() commands with the local (to application) CPU, and push the result to the remote X server via raster images (XPutImage()); Setting LIBGL_ALWAYS_INDIRECT=1 (prior to Mesa 17.3 any value would work, since then you must use 1 or true) tells Mesa to ignore normal direct rendering or the internal software renderer and use indirect rendering like it used to.

Choosing indirect rendering or direct software rendering will affect two things:

OpenGL Version

  • Indirect rendering is generally restricted to OpenGL 1.4.
  • Direct software rendering will support whatever the Mesa software rasterizer supports, probably OpenGL 2.1+


  • If your application is designed for indirect connections (it uses display lists, minimizes round-trip queries) then you can get reasonable performance.
  • If your application does something stupid like glGetInteger() 100 times per frame then even on a fast LAN each of those queries will easily take up 1ms, or 100ms total per frame, meaning you could never get more than 10 FPS in your application.
  • That same application, if the rendering load is not too heavy, may perform very well with direct software rendering, since all those glGetInteger() calls are answered directly in a matter of micro or nanoseconds.
  • If your application creates a million-vertex display list and then does lots of rotating then indirect rendering with a real GPU on the other end will give much better performance.
  • An application also may fall back to a different code path when it only has OpenGL 1.4 vs 2.x available, which also can affect performance.

So, you can see without the exact details of your application and your network characteristics, it is impossible to say whether direct software rendering or indirect rendering is better for any given situation.

In your case it seems that you're running a local kwin instance, so the effect of LIBGL_ALWAYS_INDIRECT is to force indirect rendering to your local X server. This apparently either changes kwin's behaviour (OpenGL 1.4 only) or avoids some other bug.

Definitely you want to remove this flag when the underlying issue is fixed.

  • As a Note: Other users may be able to do this with nVidia, with: __GL_ALLOW_UNOFFICIAL_PROTOCOL ... I am using this for gnome-session-wayland (3.18) remote app proof of concept. Commented Oct 14, 2015 at 18:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .