☰

Windows 10 (WSL) 上の Ubuntu で OpenGL をトラブルシューティングする方法

tag-icon • tag-icon windows-10 ubuntu windows-subsystem-for-linux opengl
Windows 10 (WSL) 上の Ubuntu で OpenGL をトラブルシューティングする方法

Windows Subsystem for Linux (WSL) を使用して Windows 10 に Ubuntu をインストールしました。OpenGL グラフィックスを動作させようとしています。最終的な目標は、OpenGL を必要とする Robot OS (ROS) 用の Gazebo シミュレーターを実行できるようにすることです。最初のステップとして、OpenGL グラフィックスが期待どおりに動作していることを確認しようとしています。

によるとこのチュートリアル他にも、ROS と Gazebo を実行するには、VcXsrv をインストールし、「ネイティブ OpenGL」オプションを無効にして X サーバーを実行する必要があるため、そうしています。

差し迫った問題は、OpenGL がうまく動作していないように見えることです。Mesa ユーティリティをインストールし、実行するとglxgearsグラフィック ウィンドウが表示されますが、アニメーションが非常に遅いです。ギアは 1 分間に約 1 回転していると思います。矢印キーを使用してギアの方向を変えることはできますが、更新も非常に遅いです。(時々、目に見える「ジャンプ」があります。これが問題になるかどうかはわかりません。)

比較のために、glxgearsVirtualBox マシンで実行している Ubuntu で実行してみました。驚いたことに、アニメーションがはるかに速くなりました。ギアは 4 秒ごとに 1 回完全に回転しますが、WSL を使用した Windows で実行している場合は 1 回 (おそらく 60 秒ですが、我慢できませんでした) です。VirtualBox はもっと遅いと思っていたので、これは大きな驚きです。

WSL を搭載した Windows では、glxgears800 ～ 1700 FPS と非常に高速に実行されていると主張しています。VirtualBox では、glxgears約 900 ～ 1000 FPS と報告されています。

glxgears と 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

WSL での実行がなぜglxgearsこんなに遅いのでしょうか? より高速に実行できるはずなのに、それを実現するにはどうすればよいのでしょうか?

アップデート

下の@allquixoticからの回答に基づいて、私はオプションで実行することをもう一度試みましたwgl。これは、2番目のチェックボックス「ネイティブOpenGL」をチェックしたままにすることで実行しました。私は以前にこれを試したことがありましたが、これを行う必要があることがわかりました。再起動後有効にするには、glxgearsこの設定で実行すると、コンソールに若干異なる表示が出ます。

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

今では、私のモニターは 1500Hz の垂直スキャン レートでは動作していないと確信しています。したがって、これは実際に何が起こっているかを示す指標である可能性があります。間接レンダリング システムの何らかの異常です。また、CTRL+C でプログラムを終了したとき、GL ウィンドウはプログラムを終了した後も 10 ～ 11 秒間動作し、アニメーションを続けます。これは、プログラムを 3 ～ 4 秒しか実行していない場合です。したがって、大量のメッセージがキューに入れられているか、何かそのようなものがあると推測する必要があります...?

答え1

実際にうまくいったこと:

理由はわかりませんが、@allquixotic からの (非常に賢明な) 推奨に反して実行したときに、私のシステムは機能しました。

1. 無効にするLIBGL_ALWAYS_INDIRECT:

これは本当に困難でした。なぜなら、それがどこに設定されているかを見つけなければならなかったからです。

  • フォルダ内に/etc/profile.dファイルがありましたwsl-integration.sh。
  • 上記のファイルは実際にはシンボリックリンクでした。実際のファイルは/usr/share/wslu/wsl-integration.sh
  • そのファイルでは変数がLIBGL_ALWAYS_INDIRECT設定されていたので、その行をコメントアウトしました。

2. 行うない-wglVcXsrv のコマンドライン引数 (または GUI の同等のもの)を使用します。

私は GUI クライアントから VcXsrv を起動していたため、「ネイティブ OpenGL」という 2 番目のオプション ボックスのチェックを外していました。

これらの変更を両方とも行った後 (そして、VcXsrv の古い設定が残っていないことを確認するために再起動を行った後)、ギアはglxgears通常の速度で回転し、矢印キーを使用して、想定どおりにギアの方向を変更できるようになりました。

答え2

実際に問題を解決しようとしている

  1. glxgears のようにハードウェア アクセラレーションが必要な Robot OS プログラムを実行する前に、 を実行しますexport LIBGL_ALWAYS_INDIRECT=1。
  2. VcXsrv (または Windows 上の任意の X サーバー) を起動するときに、-wglコマンド ライン引数をコマンド ライン引数としてサーバーに渡します。
  3. それでも問題が解決しない場合は、VcXsrv の代わりに Xming の有料版を使用してみてください。
  4. それでも問題が解決しない場合は、残念ながら残念ながら解決できません。理由については以下をお読みください。

ボンネットの下の説明

Windows Subsystem for Linux (WSL)またはHyper-Vゲスト内では、ハードウェアアクセラレーションによるOpenGLは、間接レンダリング。

GLXは、X11クライアントサーバープロトコルのプロトコル拡張です。X11クライアントサーバープロトコルは、クライアントとサーバー間の通信に使用されるネットワークプロトコルです。クライアント(Xウィンドウを作成するプログラム)とサーバー(これらのウィンドウを物理または仮想の画面上にレンダリングするプログラム)。

の上デスクトップLinux では、GLX は OpenGL にアクセスするための標準的なメカニズムです。クライアント プログラムからは、基本的に 2 段階のプロセスです: (1) GLX と通信し、次に (2) OpenGL と通信します。2 番目のステップは、間接レンダリングを使用しているか直接レンダリングを使用しているか (つまり、間接 GLX または直接 GLX) によって異なります。

  • 間接レンダリング:

    • OpenGL バージョン 1.4 までしかサポートされません (GLSL などはサポートされません)
    • ほとんどのプログラムでは、これを使用するには環境変数が必要ですLIBGL_ALWAYS_INDIRECT=1。そうでない場合は、デフォルトで直接レンダリングされます。
    • GLXを使用してすべてのOpenGLコマンドをXサーバーに送信します。プロトコル。
    • X サーバー バックエンドは、X サーバーにローカルな OpenGL 実装を使用して、ウィンドウへのレンダリングを完了します。
    • ネットワーク透過的であるため、ローカルだけでなくネットワーク接続や UNIX ドメイン ソケットでも動作します。

  • 直接レンダリング:

    • グラフィック ドライバーがサポートする OpenGL のバージョンはすべてサポートされます。OpenGL の新しいバージョンがリリースされた場合は、OpenGL 4.x 以降までサポートされます。
    • 環境変数LIBGL_ALWAYS_INDIRECTが設定解除。
    • 動的ロードを使用して、すべての OpenGL コマンドを使用可能なシンボルに送信しますlibGL.so(末尾に適切なバージョンが付きます。libGL.so.1 など)。これらはネイティブ関数呼び出しです。
    • XサーバはOpenGLのレンダリングコマンドを直接「見る」わけではありません。Xサーバが見るのは、グラフィックスドライバがレンダリングするためにフレームバッファ内に確保する長方形の領域だけです。何レンダリングされるのは、どこ。
    • ネットワーク透過的ではないため、同じコンピューター上でローカルにのみ動作します。

そこにははGLX 直接レンダリングをサポートする OpenGL の実装ですが、X サーバーに知られることなく、ネットワーク経由でハードウェア アクセラレーション リモートに OpenGL 呼び出しをパイプします。この製品は VirtualGL と呼ばれます。ただし、VirtualGL には Windows サーバー コンポーネントがないため、Windows ホストで VirtualGL を使用する方法はありません。仮想化で Linux ホストと Linux ゲストを実行している場合は、ゲストからホストに VirtualGL を使用して、ホストのグラフィック カードを使用してゲストで直接レンダリングを行うことができます。

「Robot OS」が何なのかは分かりませんが、バージョン 1.4 以前の OpenGL コマンドのみを必要とする場合は、コマンドを使用して Windows ホストで X サーバーを実行すれば動作するはずです-wgl。X サーバーはこのフラグをサポートしている必要があります。私は VcXsrv で動作させたことはありませんが、Xming の有料バージョンは動作することが分かっています。

Windows で動作する X サーバーはいくつかあります。私は、非常に高価な商用実装を除いて、そのほとんどをテストしました。私の意見では、OpenGL に最適なのは Xming の有料版です。無料版はかなり古く、それほど良くありません。

しかし、存在しない――できない存在する - 間接レンダリングモード（WSLまたはHyper-Vクライアントから）でOpenGL 1.4以上をサポートするWindows Xサーバーの実装。GLXプロトコル自体バージョン 1.4 以上の OpenGL 呼び出しは指定しません。

したがって、Robot OSがOpenGL 1.4以上を必要とする場合は、絶対に無理WSL または Hyper-V で実行し、Windows X サーバー上でハードウェア アクセラレーションによるレンダリングを実現するには、VMware Workstation のようなものを使用する必要があります。

答え3

同じ問題に遭遇し、glxgears が描画要求を非常に速く送信して VcXsrv を圧倒し、何もレンダリングできない状態になっている可能性が高いことがわかりました。

詳細とフレームレート制限オプションを備えた glxgears の改造バージョンは、こちらを参照してください:

https://github.com/tobecodex/glxgears

このバージョンを使用すると、Surface Book 2 のギアで 800 fps 以上を簡単に実現できます。

最新のディスプレイに真の VSYNC レートがないため、glxgears が可能な限り高速にサーバーにスパムを送信し、VcXsrv が機能しなくなるのではないかと推測します。

MeshLab や類似のソフトウェアは問題なく動作し、Xming ではこの問題は発生しない (ただし、HW アクセラレーションは搭載されていない) ことに気付きました。

それで、あなたの質問に対する答えは、心配する必要はありません。Gazebo はおそらく問題なく動作します。この問題は glxgears とおそらく同様の年代のアプリにのみ発生します。

ちなみに、次のことを発見しました:export LIBGL_ALWAYS_INDIRECTと を -wglどの組み合わせでも、私にとってはほとんど効果がありません。結果は glxgears で見たものとはほぼ確実に異なるため、これらをもう一度試してみる価値があるかもしれません。

関連情報