web-dev-qa-db-ja.com

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

Linux（WSL）のWindowsサブシステムを使用してUbuntuをWindows 10にインストールしました。私はOpenGLグラフィックスを機能させることを試みています。私の最終的な目標は、OpenGLを必要とするロボットOS（ROS）のGazeboシミュレーターを実行できるようにすることです。最初のステップとして、OpenGLグラフィックスが想定どおりに機能することを確認します。

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

私の差し迫った問題は、OpenGLが正しく機能していないように見えることです。 Mesa utilsをインストールし、glxgearsを実行するとグラフィックスウィンドウが表示されますが、アニメーションが非常に遅くなります。私はギアが毎分約1回転で回転していると推定します。矢印キーを使用してギアの方向を変更できますが、更新は非常に遅いです。 （それが重要な場合、時々目に見える「ジャンプ」があります。）

比較のために、VirtualBoxマシンで実行しているUbuntuでglxgearsを実行してみました。驚いたことに、それははるかに速くアニメートします。 WSLを搭載したWindowsで実行しているときは、ギアが4秒ごとに1回フル回転します（60秒かもしれませんが、忍耐力を失いました）。 VirtualBoxの速度が非常に遅くなることを期待しているので、これは大きな驚きです。

WSLを備えたWindowsでは、glxgearsは800〜1700 FPSの非常に高速で実行されていると主張しています。 VirtualBoxではglxgearsは約900-1000FPSを報告します。

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番目のチェックボックス[Native 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秒しか実行しなかったので、キューに入れられているメッセージが大量にあるか、またはそのようなものがあると思います...？

windows-10ubuntuwindows-subsystem-for-linuxopengl
3
Mr. Snrub

自分の質問への回答を投稿する「あの男」になりたくないのですが、物事がうまくいくように少し苦労しました。次の男に同じ量のトラブルを救いたいと思います。だから、ここに

実際に機能するようになったもの

私が理解できない理由により、@ allquixoticからの（かなり賢明な）推奨に反して実行した場合、私のシステムは機能しました。

1）無効にするLIBGL_ALWAYS_INDIRECT

これが設定された場所を見つける必要があったからといって、これは本当に難しい作業です。

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

2）VcXsrvには-wglコマンドライン引数（または同等のGUI）を使用しないでください。

GUIクライアントからVcXsrvを起動していたので、これは2番目のオプションボックスである「Native opengl」のタイトルをオフのままにすることを意味しました。

両方の変更を加えた後（およびVcXsrvの古い設定が保持されていないことを確認するために再起動して）、glxgearsのギアは通常の速度で回転し、矢印を使用して方向を変えることができました動作するはずのキーと同じように。

4
Mr. Snrub

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

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

内部の説明

Linux（WSL）またはHyper-Vゲスト用のWindowsサブシステム内では、ハードウェアアクセラレーションOpenGLは間接レンダリングを介してのみ可能です。

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

desktop Linuxでは、GLXはOpenGLにアクセスするための標準メカニズムです。クライアントプログラムから、それは基本的に2つのステップのプロセスです：（1）GLXと話し、次に（2）OpenGLと話します。 2番目のステップは、間接レンダリングを使用しているか、直接レンダリングを使用しているか（つまり、間接GLXまたは直接GLX）によって異なります。

  • 間接レンダリング：

    • OpenGLバージョン1.4までをサポート（GLSLなどはサポートしていません）
    • ほとんどのプログラムで使用するには、環境変数LIBGL_ALWAYS_INDIRECT=1が必要です。それ以外の場合は、デフォルトで直接レンダリングが行われます。
    • GLX protocolを使用して、すべてのOpenGLコマンドをXサーバーに送信します。
    • Xサーバーバックエンドは、XサーバーにローカルなOpenGL実装を使用して、ウィンドウへのレンダリングを完了します。
    • ネットワーク透過的です。つまり、ネットワーク接続とUNIXドメインソケット、およびローカルで機能します。

  • 直接レンダリング：

    • グラフィックドライバーがサポートするOpenGLのすべてのバージョンをサポートします。OpenGLが新しいバージョンをリリースする場合は、OpenGL 4.x以上になる可能性があります。
    • 環境変数LIBGL_ALWAYS_INDIRECTをnsetにする必要があります。
    • ダイナミックロードを使用して、すべてのOpenGLコマンドをlibGL.soで利用可能なシンボルに送信します（末尾に適切なバージョン（libGL.so.1など））。これらはネイティブ関数呼び出しです。
    • XサーバーはOpenGLレンダリングコマンドを直接「参照」しません。表示されるのは、グラフィックスドライバーがレンダリングするフレームバッファー内に確保する長方形の領域だけです。 whatが表示されるのはわかりませんが、-whereのみが表示されます。
    • ネットワーク透過ではありません。つまり、同じコンピューターでローカルにのみ機能します。

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

「ロボットOS」が何であるかはわかりませんが、バージョン1.4以前のOpenGLコマンドのみが必要な場合は、-wglコマンドを使用してWindowsホストでXサーバーを実行すれば機能します。 Xサーバーはこのフラグをサポートする必要があります。自分でVcXsrvを使用できるようにしたことはありませんが、Xmingの有料版は動作します。

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

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

したがって、Robot OSがOpenGL 1.4以上を必要とする場合、WSLまたはHyper-Vで実行し、Windows Xサーバーでハードウェアアクセラレーションレンダリングを取得するためのまったくないがあります。 VMware Workstationなどを使用する必要があります。

2
allquixotic

同じ問題に出くわし、glxgearsが描画要求でVcXsrvを圧倒しているため、何もレンダリングされないほど高速であることがわかりました。

詳細とフレームレート制限オプションを備えたglxgearsの改造バージョンはこちら：

https://github.com/tobecodex/glxgears

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

最新のディスプレイに真のVSYNC=レートがないと、glxgearsが可能な限り速くサーバーにスパムを送信し、VcXsrvを強制終了させます。

MeshLabと同様のものは問題なく動作し、Xmingにはこの問題がありません（ただし、ハードウェアアクセラレーションもありません）。

だからあなたの質問に答えて：それについて心配しないでください。ガゼボはおそらく正常に動作します。問題はglxgearsとおそらく同じようなヴィンテージのアプリにのみ存在します。

ところで、私はそれを見つけました：export LIBGL_ALWAYS_INDIRECTおよび-wglどんな組み合わせでも、私にはほとんど効果がありません。結果はほぼ確実にglxgearsで見たものとは異なるため、これらをもう一度試す価値があるかもしれません。

0
tobecodex