☰

なぜ ssh は virgl OpenGL レンダラーを llvmpipe ソフトウェア レンダラーに戻すのでしょうか? virgl を ssh セッションに保持できますか?

tag-icon • tag-icon ssh qemu ubuntu-20.04 opengl x11-forwarding
なぜ ssh は virgl OpenGL レンダラーを llvmpipe ソフトウェア レンダラーに戻すのでしょうか? virgl を ssh セッションに保持できますか?

私はQemu VMを作成しました。ホストとゲストの両方がUbuntu 20.04です。次に、コマンドを使用してQemu VMを起動します。

qemu-system-x86_64 ubuntu-desktop.qcow2 -m 2G -smp 2 -device virtio-vga-gl -display gtk,gl=on -nic user,hostfwd=tcp::5555-:22

ゲストUbuntuのデスクトップを開いてターミナルに入力できる場合

glxinfo -B

出力には、OpenGL レンダラーが「virgl」であることが示されています。しかし、-Xオプションとタイプを使用してゲスト Ubuntu に ssh するとglxinfo -B、出力には OpenGL レンダラーがソフトウェア OpenGL レンダラーである「llvmpipe (LLVM 13.0.0、128 ビット)」であることが示されます。

では、なぜ ssh は virgl OpenGL レンダラーを llvmpipe ソフトウェア レンダラーに戻すのでしょうか? Qemu ウィンドウに表示されるように、ssh セッションで元の「virgl」OpenGL レンダラーを維持する方法はありますか?

答え1

出力には、OpenGL レンダラーが「virgl」であることが示されています。しかし、-X オプションを使用してゲスト Ubuntu に ssh し、glxinfo -B と入力すると、出力には OpenGL レンダラーがソフトウェア OpenGL レンダラーである「llvmpipe (LLVM 13.0.0、128 ビット)」であることが示されます。

では、なぜ ssh は virgl OpenGL レンダラーを llvmpipe ソフトウェア レンダラーに戻すのでしょうか? Qemu ウィンドウに表示されるように、ssh セッションで元の「virgl」OpenGL レンダラーを維持する方法はありますか?

この-XオプションはglxinfoがホストのXサーバのものであり、ゲストのものではありません。GLXは「GL over X11」なので、glxinfoはホストのXorgから利用可能な機能を表示します。ただし、通信しているという事実によって制限されます。ネットワーク経由で、したがって、直接 SHM または DRI アクセスはありません。(たとえば、最新の X11 プログラムは、MIT-SHM を介して X サーバーとビットマップを直接交換できることに大きく依存しています。)

ゲストのXサーバーを使用する場合は、使用しない-Xでください-Y代わりに、ゲスト内ですでに実行されている X サーバーを指すように を定義しますDISPLAY(場合によっては も定義します)。XAUTHORITY

(ほとんどの場合、ディスプレイは :0 ですが、Xauth パスは変更される可能性があるため、ゲスト内の「ローカル」端末から DISPLAY 値と XAUTHORITY 値を確認する必要があります。最近のバージョンでは、この情報も見つかる場合があります。systemctl --user show-environmentこれは信頼できるソースです。)

しかし、SSH 経由でホスト上の X ウィンドウを表示しながらゲストの仮想 GPU を使用したい場合は、GLX を使用できず、EGL ベースのソフトウェアが必要になる可能性があります ( eglinfovirgl GPU にアクセスできるかどうかを確認してください)。

あるいは、ゲスト上でアプリケーションを実行し、VNC (x0vncserver) または Qemu の SPICE リモート プロトコル (VNC/RDP と同様にネットワーク経由で使用可能) を介して制御します。

関連情報