☰

Cómo solucionar problemas de OpenGL en Ubuntu en Windows 10 (WSL)

tag-icon • tag-icon windows-10 ubuntu windows-subsystem-for-linux opengl
Cómo solucionar problemas de OpenGL en Ubuntu en Windows 10 (WSL)

Instalé Ubuntu en Windows 10 usando el Subsistema de Windows para Linux (WSL). Estoy intentando que funcionen los gráficos OpenGL. Mi objetivo final es poder ejecutar el simulador Gazebo para Robot OS (ROS), que requiere OpenGL. Como primer paso, estoy tratando de asegurarme de que los gráficos OpenGL funcionen como se supone que deben hacerlo.

De acuerdo aeste tutorialy muchos otros, para ejecutar ROS y Gazebo debo instalar VcXsrv y ejecutar el servidor X con la opción "Native OpenGL" deshabilitada, así que lo estoy haciendo.

Mi problema inmediato es que OpenGL no parece funcionar del todo bien. He instalado las utilidades de Mesa y cuando las ejecuto glxgearsveo la ventana gráfica, pero la animación es extremadamente lenta. Calculo que los engranajes giran aproximadamente a 1 revolución por minuto. Puedo reorientar los engranajes usando las teclas de flecha, pero nuevamente la actualización es extremadamente lenta. (De vez en cuando hay un "salto" visible, si eso importa).

A modo de comparación, intenté ejecutar glxgearsUbuntu en una máquina VirtualBox. Para mi sorpresa, se anima mucho más rápido; los engranajes hacen una rotación completa aproximadamente una vez cada 4 segundos, en comparación con una vez cada (tal vez 60 segundos, pero perdí la paciencia) cuando se ejecuta en Windows con WSL. Esto es una gran sorpresa ya que esperaría que VirtualBox fuera mucho más lento.

En Windows con WSL, glxgearsafirma que se ejecuta muy rápido: entre 800 y 1700 FPS. En VirtualBox glxgearsinforma alrededor de 900-1000FPS.

Información de versión en glxgears y OpenGL:

xxxx@DESKTOP-8U2MCOG:~$ glxgears -info
GL_RENDERER   = Software Rasterizer
GL_VERSION    = 1.4 (2.1 Mesa 19.2.0-devel (git-cdf42f5eaa))
GL_VENDOR     = Mesa Project
GL_EXTENSIONS = GL_ARB_depth_texture GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_occlusion_query GL_ARB_texture_env_dot3 GL_ARB_transpose_matrix GL_EXT_draw_range_elements GL_EXT_multi_draw_arrays GL_NV_depth_clamp GL_NV_fog_distance GL_NV_point_sprite GL_SUN_multi_draw_arrays
VisualID 183, 0xb7
20311 frames in 5.0 seconds = 4062.197 FPS

¿Por qué glxgearsva tan lento en WSL? Si debería poder funcionar más rápido, ¿cómo puedo hacer para que eso suceda?

ACTUALIZAR

Según la respuesta de @allquixotic a continuación, hice otro intento de ejecutar con la wglopción, lo cual hice dejando marcada la segunda casilla de verificación "Opengl nativo". Ya había intentado esto antes, pero resulta que necesitaba hacer esto.después de un reiniciopara que surta efecto. Cuando ejecuto glxgearsesta configuración, obtengo una lectura ligeramente diferente en la consola:

xxxx@DESKTOP-8U2MCOG:~$ glxgears
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
23633 frames in 7.5 seconds = 3147.913 FPS
10395 frames in 6.8 seconds = 1529.523 FPS
10395 frames in 6.9 seconds = 1512.829 FPS

¡Ahora estoy bastante seguro de que mi monitor no funciona a una velocidad de escaneo vertical de 1500 Hz! Entonces creo que esto podría ser un indicador de lo que realmente está pasando; Alguna rareza con el sistema de renderizado indirecto. También noto que cuando presiono CTRL+C para finalizar el programa, la ventana GL sigue ejecutándose y animando durante unos buenos 10 a 11 segundos después de haber finalizado el programa, y ​​eso si solo he ejecutado el programa durante 3 segundos. 4 segundos. Entonces, ¿tendría que adivinar que hay un montón de mensajes en cola, o algo así...?

Respuesta1

Lo que realmente terminó funcionando:

Por razones que no entiendo, mi sistema funcionó cuando ejecuté en contra de la recomendación (bastante sensata) de @allquixotic.

1. Desactivar LIBGL_ALWAYS_INDIRECT:

Esto terminó siendo realmente difícil, simplemente porque tenía que encontrar dónde estaba ambientado:

  • En la carpeta /etc/profile.dhabía un archivo wsl-integration.sh.
  • El archivo anterior era en realidad un enlace simbólico; el archivo real era/usr/share/wslu/wsl-integration.sh
  • En ese archivo LIBGL_ALWAYS_INDIRECTse configuró la variable, así que comenté esa línea.

2. hacernouse el -wglargumento de la línea de comando (o su equivalente GUI) para VcXsrv:

Como estaba iniciando VcXsrv desde un cliente GUI, esto significaba dejar la segunda casilla de opción, titulada "OpenGL nativo", sin marcar.

Solo una vez que hice ambos cambios (y reinicié de nuevo para asegurarme de que no persistieran las configuraciones anteriores para VcXsrv), los engranajes glxgearsgiraron a un ritmo normal y pude reorientarlos usando las teclas de flecha, tal como lo hacen. Se supone que debemos trabajar.

Respuesta2

Realmente estoy tratando de resolver tu problema.

  1. Antes de ejecutar programas de Robot OS que necesitan ser acelerados por hardware, como glxgears, ejecute export LIBGL_ALWAYS_INDIRECT=1.
  2. Al iniciar VcXsrv (o cualquier servidor X en Windows), pase el -wglargumento de la línea de comando al servidor como argumento de línea de comando.
  3. Si eso no funciona, intente utilizar la versión paga de Xming en lugar de VcXsrv.
  4. Si eso aún no funciona, casi no tienes suerte. lea a continuación para ver por qué.

Explicación de debajo del capó.

Dentro de un subsistema de Windows para Linux (WSL) o un invitado Hyper-V, OpenGL acelerado por hardware solo es posible a través derenderizado indirecto.

GLX es una extensión de protocolo para el protocolo cliente-servidor X11. El protocolo cliente-servidor X11 es el protocolo de red utilizado para la comunicación entreclientela(programas que crean ventanas X) yservidores(programas que representan esas ventanas en una pantalla, ya sea física o virtual).

EnescritorioLinux, GLX es el mecanismo estándar para acceder a OpenGL. Desde un programa cliente, es básicamente un proceso de dos pasos: (1) hablar con GLX, luego (2) hablar con OpenGL. El segundo paso varía dependiendo de si está utilizando renderizado directo o indirecto (es decir, GLX indirecto o directo).

  • Representación indirecta:

    • Solo admite hasta OpenGL versión 1.4 (sin GLSL, etc.)
    • Requiere la variable de entorno LIBGL_ALWAYS_INDIRECT=1para que la mayoría de los programas la utilicen; de lo contrario, utilizan de forma predeterminada la representación directa.
    • Envía todos los comandos OpenGL al servidor X usando GLXprotocolo.
    • El backend del servidor X utiliza la implementación OpenGL local del servidor X para completar la representación en la ventana.
    • Es transparente para la red, lo que significa que funciona a través de conexiones de red y sockets de dominio UNIX, así como localmente.

  • Representación directa:

    • Admite cualquier versión de OpenGL que admita el controlador de gráficos, que podría ser hasta OpenGL 4.x o superior si OpenGL alguna vez lanza una nueva versión.
    • Requiere que la variable de entorno LIBGL_ALWAYS_INDIRECTseadesarmado.
    • Envía todos los comandos OpenGL mediante carga dinámica a los símbolos disponibles libGL.so(con la versión apropiada al final, como libGL.so.1, etc.): estas son llamadas a funciones nativas.
    • El servidor X no "ve" directamente los comandos de renderizado de OpenGL. Todo lo que ve es una región rectangular que reserva en el búfer de fotogramas para que el controlador de gráficos la represente. no lo sabequése representa, sólodónde.
    • No es transparente para la red, lo que significa que sólo funciona localmente en la misma computadora.

Alláesuna implementación de OpenGL que admite la representación directa GLX pero, sin que el servidor X lo sepa, canaliza las llamadas OpenGL a través de la red a un control remoto acelerado por hardware. Este producto se llama VirtualGL. Pero VirtualGL no tiene un componente de servidor de Windows, por lo que no hay forma de utilizar VirtualGL con un host de Windows. Si estuviera ejecutando un host Linux y un invitado Linux en virtualización, podría usar VirtualGL del invitado al host para obtener representación directa en el invitado usando la tarjeta gráfica del host.

No sé qué es "Robot OS", pero si solo requiere comandos OpenGL de la versión 1.4 o anterior, debería funcionar si ejecuta un servidor X en su host de Windows usando el -wglcomando. El servidor X debe admitir este indicador. Nunca logré que funcione con VcXsrv, pero sé que la versión paga de Xming funciona.

Hay varios servidores X que se ejecutan en Windows. He probado la mayoría de ellos, excepto las implementaciones comerciales realmente costosas. En mi opinión, lo mejor para OpenGL es la versión paga de Xming. La versión gratuita está bastante desactualizada y no es tan buena.

Sin embargo, no existe...no puedoexiste: una implementación de un servidor Windows X que admitirá más que OpenGL 1.4 en modo de renderizado indirecto (desde un cliente WSL o Hyper-V) porque el GLXprotocolo en síno especifica llamadas OpenGL superiores a la versión 1.4.

Entonces, si Robot OS requiere más que OpenGL 1.4, hayde ninguna manerapara ejecutarlo en WSL o Hyper-V y obtener renderizado acelerado por hardware en un servidor Windows X. Tendrías que usar algo como VMware Workstation.

Respuesta3

Me encontré con el mismo problema y descubrí que es probable que glxgears simplemente esté abrumando a VcXsrv con solicitudes de extracción tan rápido que nunca logra renderizar nada.

Detalles y una versión modificada de glxgears con una opción de limitación de velocidad de fotogramas aquí:

https://github.com/tobecodex/glxgears

Con esta versión puedo obtener fácilmente > 800 fps para engranajes en un Surface Book 2.

Supongo que la falta de una tasa VSYNC real en las pantallas modernas hace que glxgears envíe spam al servidor lo más rápido posible, lo que mata a VcXsrv.

Noté que MeshLab y similares funcionaron bien y que Xming no tiene este problema (aunque tampoco tiene aceleración HW).

Entonces, en respuesta a tu pregunta: no te preocupes por eso. Probablemente Gazebo funcionará bien. El problema solo existe para glxgears y probablemente aplicaciones de estilo similar.

Por cierto, descubrí que: export LIBGL_ALWAYS_INDIRECTy -wglen cualquier combinación tienen poco efecto para mí. Podría valer la pena volver a jugar con estos, ya que es casi seguro que los resultados serán diferentes a los que vio con glxgears.

información relacionada