Hola, tenemos la solución a lo que buscas, continúa leyendo y la encontrarás a continuación.
Solución:
Si bien odio ser “ese tipo” que publica una respuesta a su propia pregunta, pasé por más de un pequeño dolor para que las cosas funcionen, y me gustaría evitarle al próximo tipo la misma cantidad de problemas. Entonces, aquí está
Lo que realmente terminó funcionando
Por razones que no entiendo, mi sistema funcionó cuando funcioné 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
etcprofile.dera un archivowsl-integration.sh. - El archivo anterior era en realidad un enlace simbólico; el archivo real fue
/usr/share/wslu/wsl-integration.sh - En ese archivo la variable
LIBGL_ALWAYS_INDIRECTse estableció, así que comenté esa línea.
2) No utilice el -wgl argumento de línea de comando (o su equivalente GUI) para VcXsrv
Dado que estaba lanzando VcXsrv desde un cliente GUI, esto significó dejar la segunda casilla de opción, títulos “Native opengl”, sin marcar.
Solo una vez que hice ambos cambios (e hice un reinicio nuevo para asegurarme de que no hubiera persistido ninguna configuración anterior para VcXsrv), entonces los engranajes en glxgears giraban a un ritmo normal, y podía reorientarlos usando la flecha keys, como se supone que deben funcionar.
Realmente tratando de resolver tu problema
- Antes de ejecutar programas de Robot OS que necesitan ser acelerados por hardware, como glxgears, ejecute
export LIBGL_ALWAYS_INDIRECT=1. - Al iniciar VcXsrv (o cualquier servidor X en Windows), pase el
-wglargumento de línea de comando en el servidor como un argumento de línea de comando. - Si eso no funciona, intente usar la versión paga de Xming en lugar de VcXsrv.
- Si eso aún no funciona, en su mayoría no tiene 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 invitado Hyper-V, OpenGL acelerado por hardware solo es posible a través de renderizado 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 entre clientela (programas que crean ventanas X) y servidores (programas que renderizan esas ventanas en una pantalla, ya sea física o virtual).
Sobre escritorio Linux, 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 indirecto o directo (es decir, GLX indirecto o directo).
-
Representación indirecta:
- Admite solo hasta la versión 1.4 de OpenGL (sin GLSL, etc.)
- Requiere la variable de entorno
LIBGL_ALWAYS_INDIRECT=1para que la mayoría de los programas lo utilicen, de lo contrario, utilizan el renderizado directo de forma predeterminada. - Envía todos los comandos OpenGL al servidor X usando GLX protocolo.
- El backend del servidor X usa la implementación de OpenGL local al 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 a nivel local.
-
Representación directa:
- Admite cualquier versión de OpenGL que admita el controlador de gráficos, que podría ser hasta OpenGL 4.xo superior si OpenGL alguna vez lanza una nueva versión.
- Requiere la variable de entorno
LIBGL_ALWAYS_INDIRECTser desarmado. - Envía todos los comandos de OpenGL mediante carga dinámica a los símbolos disponibles en
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 aparta en el búfer de fotogramas para que el controlador de gráficos lo procese. No sabe qué está renderizado, solo dónde.
- No es transparente para la red, lo que significa que solo funciona localmente en la misma computadora.
Allí es una 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 usar VirtualGL con un host de Windows. Si estaba ejecutando un host Linux y un invitado Linux en virtualización, podría usar VirtualGL desde el invitado al host para obtener una 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 -wgl mando. El servidor X debe admitir esta bandera. Yo nunca he conseguido 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 caras. 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 poder existe: una implementación de un servidor Windows X que admitirá más de OpenGL 1.4 en modo de representación indirecta (desde un cliente WSL o Hyper-V) porque el GLX protocolo en sí no especifica las llamadas OpenGL por encima de la versión 1.4.
Entonces, si Robot OS requiere más de OpenGL 1.4, hay de ninguna manera para ejecutarlo en WSL o Hyper-V y obtener renderizado acelerado por hardware en un servidor Windows X. Tendría que usar algo como VMware Workstation.
Me encontré con el mismo problema y descubrí que es probable que glxgears simplemente abrume a VcXsrv con solicitudes de extracción tan rápido que nunca llegue a 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.
Voy a adivinar la falta de un true La tasa de VSYNC en las pantallas modernas hace que glxgears envíe spam al servidor tan rápido como sea posible, lo que mata a VcXsrv.
Me di cuenta de que MeshLab y similares funcionaron bien y que Xming no tiene este problema (aunque tampoco tiene aceleración de HW).
Entonces, en respuesta a su pregunta: No se preocupe. Gazebo probablemente funcionará bien. El problema solo existe para glxgears y probablemente aplicaciones de una antigüedad similar.
Por cierto, encontré que: export LIBGL_ALWAYS_INDIRECT y -wgl en cualquier combinación tienen poco efecto para mí. Podría valer la pena volver a jugar con estos, ya que los resultados serán casi con certeza diferentes a los que vio para glxgears.
Calificaciones y reseñas
Si estás de acuerdo, tienes la habilidad dejar un escrito acerca de qué le añadirías a este artículo.