バーチャルGL

VirtualGL ( VGL ) はオープンソースのソフトウェアパッケージであり、 UnixおよびLinux OpenGLアプリケーションからの 3D レンダリングコマンドを専用サーバーの3D アクセラレータハードウェアにリダイレクトし、レンダリングされた出力をネットワーク上の別の場所にある(シン) クライアントに送信します。 ^[1]サーバー側では、VirtualGL はリダイレクトを処理するライブラリと、アプリケーションにこのライブラリを使用するように指示するラッパープログラムで構成されています。クライアントは、リモート X11 接続またはVirtual Network Computing (VNC) サーバーなどの X11 プロキシを使用してサーバーに接続できます。X11 接続の場合は、レンダリングされたグラフィック出力を X11 ストリームとは別に受信するために、クライアント側の VirtualGL ソフトウェアも必要です。VNC 接続の場合は、VNC クライアント自体以外の特定のクライアント側ソフトウェアは必要ありません。

OpenGL アプリケーションのパフォーマンスは、通常GPUに搭載されている専用のハードウェア アクセラレータでグラフィックスをレンダリングすることで大幅に向上します。GPU は一般的になったため、アプリケーションは許容できるパフォーマンスを得るために GPU に依存するようになりました。しかし、 Unix および Linux のVNCやその他のシン クライアント環境では、サーバー側のそのようなハードウェアにアクセスできません。そのため、 OpenGLアプリケーションをまったくサポートしないか、クライアント側またはサーバー上のソフトウェアでのレンダリングなどの低速な方法に頼っています。

ハードウェア アクセラレーションを使用して 3D アプリケーションをリモートで表示するには、従来、「間接レンダリング」を使用する必要がありました。間接レンダリングでは、 X ウィンドウ システム(「X11」または「X」) のGLX拡張機能を使用して、OpenGL コマンドをX11 プロトコル ストリーム内にカプセル化し、アプリケーションから X ディスプレイに送信します。従来、アプリケーションはリモートにあるアプリケーション サーバーで実行され、X ディスプレイはユーザーのデスクトップで実行されます。このシナリオでは、すべての OpenGL コマンドがユーザーのデスクトップ マシンで実行されるため、そのマシンには高速の 3D グラフィック アクセラレータが搭載されている必要があります。このため、この方法を使用して 3D アプリケーションをリモートで表示できるマシンの種類が制限されます。

間接レンダリングは、ネットワークが十分に高速 (たとえば、ギガビット イーサネット) で、アプリケーションがレンダリングされるオブジェクトのジオメトリを動的に変更せず、アプリケーションがディスプレイ リストを使用し、アプリケーションが大量のテクスチャ マッピングを使用しない場合に、適切に実行されます。ただし、多くの OpenGL アプリケーションは、これらの基準を満たしていません。さらに複雑なことに、一部の OpenGL 拡張機能は間接レンダリング環境では動作しません。これらの拡張機能の一部は、3D グラフィックス ハードウェアに直接アクセスする機能を必要とするため、間接的に動作させることはできません。その他のケースでは、ユーザーの X ディスプレイが必要な OpenGL 拡張機能を明示的にサポートしていないか、拡張機能がユーザーのデスクトップ マシンに存在しない特定のハードウェア構成に依存している可能性があります。

アプリケーション サーバーで OpenGL レンダリングを実行すると、間接レンダリングによって生じる問題を回避できます。これは、アプリケーションが 3D レンダリング ハードウェアへの高速で直接的なパスを持つようになるためです。3D レンダリングがアプリケーション サーバーで行われる場合、結果として得られる 2D 画像のみをクライアントに送信する必要があります。画像は、その生成に使用された 3D データのサイズに関係なく、同じフレーム レートで配信できるため、アプリケーション サーバーで 3D レンダリングを実行すると、3D パフォーマンスの問題が実質的に 2D パフォーマンスの問題に変換されます。問題は、1 メガピクセルから 2メガピクセルの画像データをネットワーク経由でインタラクティブなフレーム レートでストリーミングする方法になりますが、この問題は既に一般的なテクノロジ ( HDTVなど) で解決されています。

VirtualGL は、アプリケーション サーバーで OpenGL レンダリングを実行するために「GLX フォーク」を使用します。Unix および Linux OpenGL アプリケーションは通常、同じ X ディスプレイに GLX コマンドと通常の X11 コマンドの両方を送信します。GLX コマンドは、OpenGL レンダリング コンテキストを特定の X ウィンドウにバインドしたり、X ディスプレイがサポートするピクセル形式のリストを取得したりするために使用されます。VirtualGL は、ライブラリをアプリケーションに「プリロード」できる Unix および Linux の機能を利用して、リンクされている共有ライブラリに対してアプリケーションが通常行う特定の関数呼び出しを効果的にインターセプト (別名「インターポーズ」) します。VirtualGL が Unix または Linux OpenGL アプリケーションにプリロードされると、アプリケーションからの GLX 関数呼び出しをインターセプトし、対応する GLX コマンドがアプリケーション サーバーの X ディスプレイ (「3D X サーバー」) に送信されるように書き換えます。この X ディスプレイには、3D ハードウェア アクセラレータが接続されていると考えられます。したがって、VirtualGL は、GLX コマンドがネットワーク経由でユーザーの X ディスプレイや、GLX をサポートしていない VNC などの仮想 X ディスプレイ (「X プロキシ」) に送信されることを防ぎます。GLX 呼び出しを書き換えるプロセスで、VirtualGL は OpenGL レンダリングをオフスクリーン ピクセル バッファ (「Pbuffers」) にリダイレクトします。一方、アプリケーションのユーザー インターフェイスを描画するために使用される通常の X11 コマンドを含む、アプリケーションからの残りの関数呼び出しは、変更されることなく VirtualGL を通過できます。

内部的には、VirtualGL のインターポーザ エンジンは、ウィンドウと Pbuffers のマップを維持し、宛先 X ディスプレイ (「2D X サーバー」) と 3D X サーバーの間で視覚属性を一致させ、GLX リダイレクトがシームレスであることを保証するさまざまなハッシュ関数を実行します。ただし、基本的に、アプリケーション サーバーの X ディスプレイで OpenGL コンテキストが確立されると、VirtualGL は邪魔をせず、後続のすべての OpenGL コマンドがアプリケーション サーバーの 3D ハードウェアに妨げられることなく通過できるようにします。したがって、アプリケーションは、アプリケーション サーバーのハードウェアとドライバーによって提供される OpenGL の機能と拡張機能を自動的に使用できます。

GLX コマンドのマーシャリングと Pbuffers の管理の他に、VirtualGL はレンダリングされたピクセルを適切なタイミングで (通常はglXSwapBuffers()または を監視することによってglFinish()) 読み取り、標準の X イメージ描画コマンドを使用してそれらのピクセルをアプリケーションの X ウィンドウに描画します。VirtualGL は GLX コマンドを 2D X サーバーからリダイレクトするため、X プロキシ (VNC など) に高速化された 3D サポートを追加したり、リモート X ディスプレイの使用時に間接的な OpenGL レンダリングが発生しないようにするために使用できます。

VirtualGL を VNC または別の X プロキシと組み合わせて使用​​すると、複数のユーザーが 1 つのアプリケーション サーバーで同時に 3D アプリケーションを実行し、複数のクライアントで各セッションを共有できます。ただし、VNC などのアプリケーションは、単色の領域が広く、色が少なく、フレーム間の差異が少ない 2D アプリケーションを処理するように調整されています。一方、3D アプリケーションは、きめの細かい複雑な色パターンを持つイメージを生成し、後続のフレーム間の相関性ははるかに低くなります。OpenGL アプリケーションからレンダリングされたイメージを X ウィンドウに描画することによって生成されるワークロードは、基本的にビデオ プレーヤーと同じワークロードであり、市販のシン クライアント ソフトウェアには、インタラクティブなフレーム レートでこのワークロードを処理できるほど 十分に高速なイメージコーデックが欠けているのが一般的です。

VirtualGL は、この問題を次の 2 つの方法で回避します。

1. ターボVNC
2. VGLトランスポート

TurboVNC とTigerVNCはTightVNCから派生したもので、libjpegのSIMD高速化バージョンである libjpeg-turbo を使用することで、Tight および JPEG エンコーディングを高速化します。どちらのプロジェクトも、VNC サーバーとクライアント アプリケーションを提供します。

TurboVNC は VirtualGL と同じチームによって開発されました。100メガビット イーサネットネットワークでは、知覚的にロスレスな画質で 50 メガピクセル/秒以上を表示できます。TurboVNC にはさらに最適化が加えられており、5 メガビットのブロードバンド リンクでは 10 ～ 12 メガピクセル/秒を表示できます。画質は明らかに劣りますが、実用的です。TurboVNC は TightVNC を拡張して、クライアント側のダブル バッファリングや、非アクティブ期間中に画面イメージのロスレス コピーを送信する機能など、3D アプリケーションを対象としたその他の機能も含めます。^[2] TurboVNC と VirtualGL は、テキサス大学オースティン校のTexas Advanced Computing Centerで使用されており、 TeraGridのユーザーがStampede ^[3] Visualization Cluster の 3D レンダリング機能にリモートでアクセスできるようにしています。

TigerVNCはTightVNCの最近のフォークであり、ほとんどの場合TurboVNCと同様のパフォーマンスを提供しますが、プロジェクトの目標と機能は異なります。^{[4] [5]}

VGL トランスポートを使用する場合、VirtualGL は TurboVNC が使用するのと同じ最適化された JPEG コーデックを使用して、レンダリングされた 3D イメージをプロセス内で圧縮します。次に、VirtualGL は、圧縮されたイメージを専用の TCP ソケット経由でクライアント マシンで実行されている VirtualGL クライアント アプリケーションに送信します。VirtualGL クライアントは、イメージを解凍し、適切な X ウィンドウにピクセルを描画する役割を担います。一方、アプリケーションのディスプレイの非 OpenGL 要素は、標準のリモート X11 プロトコルを使用してネットワーク経由で送信され、クライアント マシンでレンダリングされます。

このアプローチでは、クライアント マシンに X ディスプレイが存在している必要があり、2D レンダリングを実行するためにリモート X11 プロトコルに依存するため、高遅延ネットワークで VGL トランスポートを使用すると、多くのアプリケーションのパフォーマンスが低下します。さらに、VGL トランスポートは、イメージがユーザーのマシンにプルされるのではなくプッシュされるため、本質的にコラボレーション (セッションごとに複数のクライアント) をサポートしていません。ただし、VGL トランスポートを使用すると、すべてのアプリケーション ウィンドウが 1 つのデスクトップ ウィンドウに対応するため、完全にシームレスなアプリケーション エクスペリエンスが提供されます。また、VGL トランスポートでは、2D レンダリングがクライアントで行われるため、サーバーのCPU負荷が軽減され、クアッド バッファ ステレオなどの高度な OpenGL 機能を使用できるようになります。

VirtualGL の開発者は、VGL トランスポートの主なユーザーとして、アプリケーション サーバーへの 802.11gワイヤレスまたは高速イーサネット接続を備えたラップトップ ユーザーを想定しています。

VirtualGL と TurboVNC は、2009 年 4 月に製造中止となったSun MicrosystemsのSun Visualization System製品のコア コンポーネントでした。この 2 つのオープン ソース パッケージは、VirtualGL がSun Rayシン クライアントに圧縮画像を送信できるようにするクローズド ソースプラグインと、VirtualGL をSun Grid Engineと統合してリモート 3D ジョブのリソース管理とスケジュールを提供する別のクローズド ソース パッケージと組み合わされていました。これらのパッケージの組み合わせは「Sun Shared Visualization」と呼ばれ、無料でダウンロードできました。Sun はサポート料金を請求していました。

NoMachineのv4.xxはVirtualGLをサポートしており、ユーザーはNoMachineデスクトップセッションで3Dアプリケーションを実行できます。^[6]

HPのScalable Visualization Arrayソフトウェアのバージョン2.1には、VirtualGLおよびTurboVNCと統合するコンポーネントが含まれており、3Dジョブを視覚化クラスター上でスケジュールし、リモートで表示することができます。^[7]

ThinLincのv3.0.0はVirtualGLと連携して動作するように設計されています。^[8]

EnginFrame Viewsのv2010は、リモートプロトコルオプションの1つとしてVirtualGLをサポートしています。^[9]

OpenTextのExceed onDemandおよびExceed Freedom製品は、VirtualGLのコードを使用してサーバー側レンダリングを実装しています。^[10]

• Xgl
• AIGLX

• 「VirtualGL の背景」。VirtualGL.org。2016年2 月 20 日閲覧。
• 「VirtualGL 2.5 ユーザーズ ガイド」。VirtualGL.org。2016年2 月 20 日閲覧。
• 「TurboVNC 2.0.1 ユーザーズガイド」。TurboVNC.org 。 2016年2月20日閲覧。

• 公式VirtualGLウェブサイト
• SourceForgeの VirtualGL
• GitHub上の VirtualGL
• TurboVNCの公式ウェブサイト
• SourceForgeの TurboVNC
• GitHub上の TurboVNC