☰

So beheben Sie Probleme mit OpenGL auf Ubuntu unter Windows 10 (WSL)

tag-icon • tag-icon windows-10 ubuntu windows-subsystem-for-linux opengl
So beheben Sie Probleme mit OpenGL auf Ubuntu unter Windows 10 (WSL)

Ich habe Ubuntu unter Windows 10 mit Windows Subsystem for Linux (WSL) installiert. Ich versuche, OpenGL-Grafiken zum Laufen zu bringen. Mein ultimatives Ziel ist es, den Gazebo-Simulator für Robot OS (ROS) ausführen zu können, der OpenGL erfordert. Als ersten Schritt versuche ich sicherzustellen, dass OpenGL-Grafiken wie vorgesehen funktionieren.

Entsprechenddieses Tutorialund viele andere. Um ROS und Gazebo auszuführen, sollte ich VcXsrv installieren und den X-Server mit deaktivierter Option „Native OpenGL“ ausführen, also mache ich das.

Mein unmittelbares Problem ist, dass OpenGL nicht richtig zu funktionieren scheint. Ich habe die Mesa-Dienstprogramme installiert und wenn ich sie ausführe, glxgearssehe ich zwar das Grafikfenster, aber die Animation ist extrem langsam. Ich schätze, dass sich die Zahnräder mit etwa einer Umdrehung pro Minute drehen. Ich kann die Zahnräder mit den Pfeiltasten neu ausrichten, aber auch hier ist die Aktualisierung extrem langsam. (Ab und zu gibt es einen sichtbaren „Sprung“, falls das wichtig ist.)

Zum Vergleich habe ich versucht, glxgearses unter Ubuntu auf einer VirtualBox-Maschine laufen zu lassen. Zu meiner Überraschung ist die Animation viel schneller; die Zahnräder machen etwa alle 4 Sekunden eine vollständige Drehung, verglichen mit einer Drehung alle (vielleicht 60 Sekunden, aber ich habe die Geduld verloren), wenn ich es unter Windows mit WSL laufen lasse. Das ist eine große Überraschung, da ich erwartet hätte, dass die VirtualBox viel langsamer ist.

Unter Windows mit WSL glxgearsläuft es angeblich sehr schnell – zwischen 800 und 1700 FPS. In VirtualBox glxgearswerden etwa 900–1000 FPS gemeldet.

Versionsinformationen zu glxgears und 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

Warum glxgearsläuft es in WSL so langsam? Wenn es eigentlich schneller laufen sollte, wie erreiche ich das dann?

AKTUALISIEREN

Basierend auf der Antwort von @allquixotic unten habe ich einen weiteren Versuch unternommen, die Option zu verwenden wgl, indem ich das zweite Kontrollkästchen "Native OpenGL" aktiviert gelassen habe. Ich hatte dies bereits zuvor versucht, aber es stellte sich heraus, dass ich dies tun musstenach einem Neustartdamit es wirksam wird. Wenn ich glxgearsdieses Setup verwende, erhalte ich eine leicht andere Anzeige auf der Konsole:

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

Jetzt bin ich mir ziemlich sicher, dass mein Monitor nicht mit einer vertikalen Abtastrate von 1500 Hz läuft! Ich denke also, dass dies ein Hinweis darauf sein könnte, was wirklich los ist: eine Merkwürdigkeit mit dem indirekten Rendering-System. Außerdem stelle ich fest, dass, wenn ich STRG+C drücke, um das Programm zu beenden, das GL-Fenster noch gute 10-11 Sekunden weiterläuft und animiert, nachdem ich das Programm beendet habe – und das, wenn ich das Programm nur 3-4 Sekunden lang laufen lasse. Ich würde also vermuten, dass sich eine Menge Nachrichten in der Warteschlange ansammeln oder so etwas in der Art …?

Antwort1

Was am Ende tatsächlich funktioniert hat:

Aus Gründen, die ich nicht verstehe, hat mein System funktioniert, obwohl ich der (durchaus vernünftigen) Empfehlung von @allquixotic zuwidergelaufen bin.

1. Deaktivieren LIBGL_ALWAYS_INDIRECT:

Das war am Ende wirklich schwierig, weil ich erst herausfinden musste, wo es eingestellt war:

  • In dem Ordner /etc/profile.dwar eine Datei wsl-integration.sh.
  • Die obige Datei war eigentlich ein Symlink; die eigentliche Datei war/usr/share/wslu/wsl-integration.sh
  • In dieser Datei LIBGL_ALWAYS_INDIRECTwar die Variable festgelegt, deshalb habe ich diese Zeile auskommentiert.

2. Tun Sienichtverwenden Sie das -wglBefehlszeilenargument (oder das GUI-Äquivalent) für VcXsrv:

Da ich VcXsrv von einem GUI-Client aus startete, bedeutete dies, dass ich das zweite Optionsfeld mit der Überschrift „Native OpenGL“ deaktiviert lassen musste.

Erst nachdem ich diese beiden Änderungen vorgenommen hatte (und einen Neustart durchführte, um sicherzustellen, dass keine alten Einstellungen für VcXsrv bestehen geblieben waren), glxgearsdrehten sich die Zahnräder wieder mit normaler Geschwindigkeit und ich konnte sie mit den Pfeiltasten neu ausrichten, so wie es sein soll.

Antwort2

Tatsächlich versuchen, Ihr Problem zu lösen

  1. Bevor Sie Robot OS-Programme ausführen, die hardwarebeschleunigt werden müssen (z. B. glxgears), führen Sie aus export LIBGL_ALWAYS_INDIRECT=1.
  2. Übergeben Sie beim Starten von VcXsrv (oder einem beliebigen X-Server unter Windows) das -wglBefehlszeilenargument als Befehlszeilenargument an den Server.
  3. Wenn das nicht funktioniert, versuchen Sie, die kostenpflichtige Version von Xming anstelle von VcXsrv zu verwenden.
  4. Wenn das immer noch nicht funktioniert, haben Sie größtenteils Pech gehabt. Lesen Sie weiter, um zu erfahren, warum.

Erklärung zu „Unter der Haube“

Innerhalb eines Windows Subsystem for Linux (WSL) oder Hyper-V Gasts ist hardwarebeschleunigtes OpenGL nur möglich durchindirektes Rendern.

GLX ist eine Protokollerweiterung für das X11-Client-Server-Protokoll. Das X11-Client-Server-Protokoll ist das Netzwerkprotokoll für die Kommunikation zwischenKunden(Programme, die X-Fenster erstellen) undServer(Programme, die diese Fenster auf einem Bildschirm rendern, ob physisch oder virtuell).

AnDesktop-ComputerUnter Linux ist GLX der Standardmechanismus für den Zugriff auf OpenGL. Von einem Client-Programm aus ist es im Grunde ein zweistufiger Prozess: (1) mit GLX kommunizieren, dann (2) mit OpenGL kommunizieren. Der zweite Schritt variiert, je nachdem, ob Sie indirektes oder direktes Rendering verwenden (also indirektes oder direktes GLX).

  • Indirektes Rendern:

    • Unterstützt nur bis OpenGL Version 1.4 (kein GLSL usw.)
    • Erfordert die Umgebungsvariable LIBGL_ALWAYS_INDIRECT=1für die Verwendung durch die meisten Programme, andernfalls wird standardmäßig das direkte Rendering verwendet.
    • Sendet alle OpenGL-Befehle an den X-Server unter Verwendung des GLXProtokoll.
    • Das X-Server-Backend verwendet die lokale OpenGL-Implementierung des X-Servers, um das Rendering im Fenster abzuschließen.
    • Ist netzwerktransparent, d. h. es funktioniert über Netzwerkverbindungen und UNIX-Domänen-Sockets sowie lokal.

  • Direktes Rendern:

    • Unterstützt jede OpenGL-Version, die der Grafiktreiber unterstützt. Dies kann bis zu OpenGL 4.x oder höher sein, wenn OpenGL jemals eine neue Version herausbringt.
    • LIBGL_ALWAYS_INDIRECTErfordert die Umgebungsvariablenicht gesetzt.
    • Sendet alle OpenGL-Befehle mithilfe des dynamischen Ladens an die verfügbaren Symbole libGL.so(mit der entsprechenden Version am Ende, wie libGL.so.1 usw.) – dies sind native Funktionsaufrufe.
    • Der X-Server „sieht“ die OpenGL-Rendering-Befehle nicht direkt. Er sieht lediglich einen rechteckigen Bereich, den er im Frame-Buffer für das Rendering durch den Grafiktreiber reserviert. Er weiß nicht,Waswird nurWo.
    • Ist nicht netzwerktransparent, d. h. es funktioniert nur lokal auf demselben Computer.

DortIsteine Implementierung von OpenGL, die GLX-Direktrendering unterstützt, aber – ohne Wissen des X-Servers – die OpenGL-Aufrufe über das Netzwerk an eine hardwarebeschleunigte Remote-Instanz weiterleitet. Dieses Produkt heißt VirtualGL. VirtualGL hat jedoch keine Windows-Serverkomponente, sodass es keine Möglichkeit gibt, VirtualGL mit einem Windows-Host zu verwenden. Wenn Sie einen Linux-Host und einen Linux-Gast in der Virtualisierung ausführen, können Sie VirtualGL vom Gast zum Host verwenden, um im Gast Direktrendering mithilfe der Grafikkarte des Hosts zu erhalten.

Ich weiß nicht, was „Robot OS“ ist, aber wenn es nur OpenGL-Befehle ab Version 1.4 oder älter erfordert, sollte es funktionieren, wenn Sie mit dem Befehl einen X-Server auf Ihrem Windows-Host ausführen -wgl. Der X-Server muss dieses Flag unterstützen. Ich selbst habe es nie mit VcXsrv zum Laufen gebracht, aber ich weiß, dass die kostenpflichtige Version von Xming funktioniert.

Es gibt mehrere X-Server, die unter Windows laufen. Ich habe die meisten davon getestet, mit Ausnahme der wirklich teuren kommerziellen Implementierungen. Meiner Meinung nach ist die kostenpflichtige Version von Xming für OpenGL am besten geeignet. Die kostenlose Version ist ziemlich veraltet und nicht so gut.

Es gibt jedoch keine --kann nichtexistieren -- eine Implementierung eines Windows X-Servers, der mehr als OpenGL 1.4 im indirekten Rendering-Modus unterstützt (von einem WSL- oder Hyper-V-Client), da die GLXProtokoll selbstgibt keine OpenGL-Aufrufe über Version 1.4 an.

Wenn Robot OS mehr als OpenGL 1.4 erfordert, gibt esauf keinen Fallum es in WSL oder Hyper-V auszuführen und hardwarebeschleunigtes Rendering auf einem Windows X-Server zu erhalten. Sie müssten etwas wie VMware Workstation verwenden.

Antwort3

Bin auf dasselbe Problem gestoßen und habe herausgefunden, dass glxgears VcXsrv wahrscheinlich so schnell mit Zeichenanforderungen überlastet, dass es nie dazu kommt, etwas zu rendern.

Details und eine modifizierte Version von glxgears mit einer Option zur Frameratebegrenzung hier:

https://github.com/tobecodex/glxgears

Mit dieser Version kann ich auf einem Surface Book 2 problemlos > 800 fps für Gears erreichen.

Ich vermute, dass das Fehlen einer echten VSYNC-Rate auf modernen Displays dazu führt, dass glxgears den Server so schnell wie möglich mit Spam überflutet, was VcXsrv zerstört.

Mir ist aufgefallen, dass MeshLab und ähnliche Programme problemlos laufen und dass Xming dieses Problem nicht hat (allerdings auch keine Hardwarebeschleunigung hat).

Also, als Antwort auf Ihre Frage: Machen Sie sich keine Sorgen. Gazebo wird wahrscheinlich einwandfrei laufen. Das Problem besteht nur bei glxgears und wahrscheinlich bei Apps ähnlichen Alters.

Übrigens habe ich festgestellt, dass: export LIBGL_ALWAYS_INDIRECTund -wglin jeder Kombination wenig Wirkung auf mich haben. Es könnte sich lohnen, noch einmal damit herumzuspielen, da die Ergebnisse mit ziemlicher Sicherheit anders sein werden als die, die Sie bei glxgears gesehen haben.

verwandte Informationen