バーチャルGL
バーチャルGL
安定版リリース
2.6.5 / 2020年11月18日; 5年前 (2020-11-18)
プレビューリリース
2.6.90 (3.0 beta1) / 2021年6月16日; 4年前 (2021-06-16)
書かれたC、C++、Unixシェル
ライセンスGNU 一般公衆利用許諾書(GPL)、wxWindows ライブラリライセンス
Webサイトwww.virtualgl.org 

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

問題

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

ハードウェアアクセラレーションを使用して3Dアプリケーションをリモート表示するには、従来、「間接レンダリング」を使用する必要がありました。間接レンダリングでは、X Window System （「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のソリューション

VirtualGLは、アプリケーションサーバー上でOpenGLレンダリングを実行するために「GLXフォーク」を使用します。UnixおよびLinuxのOpenGLアプリケーションは通常、GLXコマンドと通常のX11コマンドの両方を同じXディスプレイに送信します。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のインターポーザエンジンは内部的に、ウィンドウとPbufferのマップを維持し、出力先のXディスプレイ（「2D Xサーバー」）と3D Xサーバー間の視覚属性をマッチングさせ、その他様々なハッシュ関数を実行してGLXリダイレクトがシームレスに行われるようにします。しかし本質的には、アプリケーションサーバーのXディスプレイ上でOpenGLコンテキストが確立されると、VirtualGLは処理を中断せず、後続のすべてのOpenGLコマンドがアプリケーションサーバーの3Dハードウェアに支障なく渡されるようになります。そのため、アプリケーションはアプリケーションサーバーのハードウェアとドライバによって提供されるOpenGLの機能と拡張機能を自動的に利用できます。

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

X11トランスポートをXプロキシと併用する場合、3Dレンダリングと2Dレンダリングの両方がアプリケーションサーバー上で実行されます。VirtualGLは、アプリケーションからの3Dコマンドを3Dアクセラレータハードウェアにリダイレクトし、レンダリングされた画像を読み込み、非圧縮ビットマップとしてXプロキシ（VNCまたは類似のシステム）に描画します。一方、アプリケーションからの2D描画コマンド（X11コマンド）はXプロキシに直接送信されます。Xプロキシは、画像の圧縮とリモートクライアントへの送信のみを担当します。

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

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

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

TurboVNCとTigerVNC

TurboVNCとTigerVNCはTightVNCから派生したものであり、TightエンコードとJPEGエンコードを高速化します。これらの高速化には、libjpegのSIMDアクセラレーション版であるlibjpeg-turboが一部使用されています。どちらのプロジェクトも、VNCサーバーとクライアントアプリケーションを提供しています。

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

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


VGLトランスポート

VGLトランスポートを使用する場合、3Dレンダリングはアプリケーションサーバーで行われますが、2Dレンダリングはクライアントマシンで行われます。VirtualGLは3Dアプリケーションからレンダリングされた画像を圧縮し、ビデオストリームとしてクライアントに送信します。クライアントはビデオストリームをリアルタイムで解凍して表示します。

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

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

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

VirtualGLを使用した商用製品

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

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

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

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

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

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

参照

参考文献

脚注

  1. ^ 「VirtualGLの簡単な紹介」VirtualGL.org . 2016年2月20日閲覧。
  2. ^ 「TurboVNCの簡単な紹介」TurboVNC.org . 2016年2月20日閲覧。
  3. ^ 「Stampede ユーザーガイド」. Texas Advanced Computing Center (TACC). 2016年3月10日時点のオリジナルよりアーカイブ。2016年2月29日閲覧。
  4. ^ “VirtualGL”. ArchLinux.org . 2021年6月25日閲覧。
  5. ^ 「TigerVNCって何？」VirtualGLプロジェクト。 2023年8月7日閲覧。
  6. ^ 「NoMachine 4以降でVirtualGLサポートを有効にする」NoMachine.com . 2016年2月20日閲覧。
  7. ^ “High Performance Computing (HPC)”. Hp.com. 2014年8月9日時点のオリジナルよりアーカイブ。2015年2月17日閲覧。
  8. ^ 「ThinLinc 4.5.0向けThinLinc管理者ガイド」ThinLinc.com . 2016年2月20日閲覧。
  9. ^ “Remote Visualization”. Nice-software.com. 2010年12月7日時点のオリジナルよりアーカイブ。2015年2月17日閲覧。
  10. ^ 「Open Text Exceed ユーザーズガイド バージョン14」（PDF） . Kb.berkeley.edu. 2012年6月12日. オリジナル（PDF）から2010年6月15日時点のアーカイブ。 2012年6月12日閲覧。

一般的な参考文献

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

公式サイト

Retrieved from "https://en.wikipedia.org/w/index.php?title=VirtualGL&oldid=1298981221#TurboVNC_and_TigerVNC"