¿Qué hace realmente LIBGL_ALWAYS_INDIRECT = 1?

KDE SC 4.5.0 tiene algunos problemas con algunas tarjetas de video, incluida la mía. Tras su lanzamiento, Arch recomendó varias soluciones alternativas . Uno de los cuales era

exportar "LIBGL_ALWAYS_INDIRECT = 1" antes de iniciar KDE

Decidí que era el mejor y más fácil método. Pero no sé qué hace ni cómo afecta mi sistema. ¿Es más lento que el predeterminado? ¿Debo recordar vigilar el problema y deshabilitarlo más tarde una vez que se solucione?

El renderizado indirecto significa que el protocolo GLX se usará para transmitir comandos OpenGL y X.org hará el dibujo real.

La representación directa significa que la aplicación puede acceder al hardware directamente sin comunicarse con X.org primero a través de mesa.

La representación directa es más rápida ya que no requiere el cambio de contexto en el proceso X.org.

Aclaración: en ambos casos, el procesamiento se realiza mediante GPU (o técnicamente, puede realizarse mediante GPU). Sin embargo, en la representación indirecta el proceso se ve así:

1. El programa llama a un comando (s)
2. Los comandos se envían a X.org por el protocolo GLX
3. X.org llama al hardware (es decir, GPU) para dibujar

En renderizado directo

1. El programa llama a un comando (s)
2. Los comandos se envían a la GPU

Tenga en cuenta que debido a que OpenGL fue diseñado de tal manera que puede funcionar a través de la red, la representación indirecta es más rápida que la implementación ingenua de la arquitectura, es decir, permite enviar una gran cantidad de comandos de una sola vez. Sin embargo, hay algo de sobrecarga en términos de tiempo de CPU gastado para cambios de contexto y protocolo de manejo.

Primero, LIBGL_ALWAYS_INDIRECThay una bandera relacionada con la implementación de OpenGL del lado del cliente de Mesa 3D (libGL.so). No funcionará con controladores binarios de otros proveedores (por ejemplo, NVIDIA).

En segundo lugar, para responder a su pregunta directamente, la última vez que miré el código de Mesa la bandera funciona así:

Antes de ~ 2008, cuando Mesa estaba trabajando con un servidor X indirecto (por ejemplo, si ssh -Xconfiguró su pantalla de forma explícita en un servidor no local), la lista de imágenes GLX proporcionadas por el servidor X remoto estaba disponible para su aplicación GLX. La aplicación llama, por ejemplo, glXChooseVisual () y Mesa encontraría algo razonable para que coincida, y las glFoo()llamadas posteriores se enviarían al servidor X remoto donde fueron ejecutadas por cualquier libGL al que se conectó el servidor X remoto (probablemente su GPU).

Alrededor de finales de 2008, Mesa cambió para que quisiera usar su software interno Renderizador OpenGL ( controlador Xlib ) para conexiones X remotas. (Algunas distribuciones como SuSE parchearon específicamente esto para volver al comportamiento anterior). Esto solo se activaría si el servidor X remoto ofreciera un visual GLX que coincidiera exactamente con uno de los renderizadores de software internos. (De lo contrario, obtendría el común " Error: no se pudo obtener un RGB, visual de doble búfer "). Si se encontrara tal visual, Mesa representaría todos los glFoo()comandos con la CPU local (a la aplicación) y presionaría resultado al servidor X remoto a través de imágenes ráster ( XPutImage()); Configuración LIBGL_ALWAYS_INDIRECT=1(antes de Mesa 17.3 cualquier valor funcionaría, ya que debe usar 1 o verdadero) le dice a Mesa que ignore el renderizado directo normal o el renderizador de software interno y use el renderizado indirecto como solía hacerlo.

Elegir la representación indirecta o la representación directa del software afectará dos cosas:

Versión OpenGL

• La representación indirecta generalmente está restringida a OpenGL 1.4.
• La representación directa del software admitirá lo que sea compatible con el rasterizador de software Mesa, probablemente OpenGL 2.1+

Actuación

• Si su aplicación está diseñada para conexiones indirectas (utiliza listas de visualización, minimiza las consultas de ida y vuelta), puede obtener un rendimiento razonable.
• Si su aplicación hace algo estúpido como glGetInteger()100 veces por fotograma, incluso en una LAN rápida, cada una de esas consultas ocupará fácilmente 1 ms, o 100 ms en total por fotograma, lo que significa que nunca podría obtener más de 10 FPS en su aplicación.
• Esa misma aplicación, si la carga de representación no es demasiado pesada, puede funcionar muy bien con la representación directa de software, ya que todas esas glGetInteger()llamadas se responden directamente en cuestión de micro o nanosegundos.
• Si su aplicación crea una lista de visualización de un millón de vértices y luego gira mucho, la representación indirecta con una GPU real en el otro extremo dará un rendimiento mucho mejor.
• Una aplicación también puede recurrir a una ruta de código diferente cuando solo tiene OpenGL 1.4 vs 2.x disponible, lo que también puede afectar el rendimiento.

Por lo tanto, puede ver sin los detalles exactos de su aplicación y las características de su red, es imposible decir si la representación directa del software o la representación indirecta es mejor para cualquier situación dada.

En su caso, parece que está ejecutando una instancia de kwin local, por lo que el efecto LIBGL_ALWAYS_INDIRECTes forzar el procesamiento indirecto a su servidor X local. Aparentemente, esto cambia kwinel comportamiento (solo OpenGL 1.4) o evita algún otro error.

Definitivamente desea eliminar este indicador cuando se soluciona el problema subyacente.