¿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 . Una de las cuales fue
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 desactivarlo más tarde una vez que se solucione?
La representación indirecta significa que el protocolo GLX se utilizará para transmitir comandos de OpenGL y X.org hará el dibujo real.
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, la representación se realiza mediante GPU (o técnicamente, puede realizarse mediante GPU). Sin embargo, en la representación indirecta el proceso se ve así:
- El programa llama a un comando (s)
- Los comandos se envían a X.org por el protocolo GLX
- X.org llama al hardware (es decir, GPU) para dibujar
En renderizado directo
- El programa llama a un comando (s)
- 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 vez. Sin embargo, hay algunos gastos generales en términos de tiempo de CPU gastado para los cambios de contexto y el protocolo de manejo.
Primero, LIBGL_ALWAYS_INDIRECT Es un indicador relacionado 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 trabajaba con un servidor X indirecto (por ejemplo, usted hizo ssh -X O configuró explícitamente su pantalla en un servidor no local), la lista de imágenes GLX proporcionadas por el servidor X remoto está disponible para su aplicación GLX La aplicación llama, p. glXChooseVisual () y Mesa encontrarían algo razonable para que coincida, y las llamadas glFoo() 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 utilizar su procesador interno 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 una imagen RGB con doble búfer ".) Si se encontrara dicha imagen entonces Mesa representaría todos los comandos glFoo() con la CPU local (a la aplicación) y enviaría el resultado al servidor X remoto a través de imágenes ráster (XPutImage()); Establecer LIBGL_ALWAYS_INDIRECT=1 (Antes de Mesa 17.3 cualquier valor funcionaría, desde entonces debe usar 1 o verdadero ) le dice a Mesa que ignore el renderizado directo normal o el renderizador interno del software 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
- El renderizado indirecto generalmente está restringido 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 cuadro, incluso en una LAN rápida, cada una de esas consultas ocupará fácilmente 1 ms, o 100 ms en total por cuadro, 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 llamadas
glGetInteger()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 de LIBGL_ALWAYS_INDIRECT Es forzar el procesamiento indirecto a su servidor X local. Aparentemente, esto cambia el comportamiento de kwin (solo OpenGL 1.4) o evita algún otro error.
Definitivamente desea eliminar este indicador cuando se solucione el problema subyacente.