1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
|
`glxinfo` is a command-line tool that can help you diagnose problems with your 3D acceleration setup. It can also provide additional helpful information for developers. Use `man glxinfo` to get an overview of its options.
[[!toc ]]
### How to tell whether your setup is good
Run `glxinfo | grep render`. You should get two lines of output, for example:
direct rendering: Yes
OpenGL renderer string: Mesa DRI Intel(R) 945GM GEM 20090326 2009Q1 RC2 x86/MMX/SSE2
The OpenGL renderer string tells you which driver was used; it distinguishes between software rendering and hardware rendering. In the example above, an Intel driver is used for hardware rendering.
The first line tells you whether direct rendering is used. In this example, direct rendering is enabled, which means that all 3D rendering commands are handled by the client application, and the X server is not involved in the rendering. If _indirect_ rendering is used, all rendering commands are sent to the server, and the server may use either software or hardware rendering. Consider the following example:
direct rendering: No (LIBGL_ALWAYS_INDIRECT set)
OpenGL renderer string: Mesa DRI Intel(R) 945GM GEM 20090326 2009Q1 RC2 x86/MMX/SSE2
Here, OpenGL was forced to use indirect rendering using an environment variable, meaning that all rendering commands are sent to the X server. However, the X server actually uses hardware accelerated rendering. Now consider this example:
direct rendering: Yes
OpenGL renderer string: Software Rasterizer
This means that software rendering is used, but all software rendering is done in the client application, so that the X server is free to service requests from other applications.
As you can see, all four combinations of direct/indirect software/hardware rendering are possible. In terms of performance, direct hardware rendering is fastest, followed by (with a noticeable, but not completely horrible performance penalty) indirect hardware rendering. Software rendering is always pretty slow.
### Troubleshooting options
If you get software rendering and do not understand why, it might help to run `LIBGL_DEBUG=verbose glxinfo` to get additional debug output (actually, you can use this environment variable with any other OpenGL application as well). You should see some lines like:
libGL: OpenDriver: trying /usr/lib/dri/tls/r300_dri.so
libGL: OpenDriver: trying /usr/lib/dri/r300_dri.so
Surrounding these lines there may be additional messages indicating errors. In particular, if the driver is not found in the mentioned path, OpenGL will try to fall back to the software renderer called `swrast_dri.so`. This is an indication that the DRI drivers are not installed correctly.
### Source code and availability
`glxinfo` should be installed by default by all (desktop) distributions. `glxinfo` is part of Mesa, its source code residing in [[demos/src/xdemos/glxinfo.c|http://cgit.freedesktop.org/mesa/demos/tree/src/xdemos/glxinfo.c]].
|
