VirtualGL は、UNIXやLinuxシステムで実行するOpenGLアプリケーションから専用サーバ上の3Dアクセラレータハードウェアへ3Dレンダリングコマンドをリダイレクトし、ネットワーク上のシンクライアントにその描画出力をインタラクティブに表示するオープンソースプログラムである。

一般的にVNCやUnix/Linux向けのその他シンクライアント環境は、OpenGLアプリケーションの実行に全く対応していないか、あるいはハードウェアアクセラレーション効果なしでOpenGLアプリケーションに描画を強制するかのいずれかである。3Dアプリケーションのリモート表示でハードウェアアクセラレーションを有効にするには、間接的なレンダリング手法を用いる必要があった。

間接レンダリングを実行する場合は、Xウィンドウシステム（"X11"や"X"）の拡張機能であるGLXを使用してX11プロトコルストリーム中にOpenGLコマンドをカプセル化し、アプリケーションからXディスプレイへと運ぶ。通常、アプリケーションは遠隔地のアプリケーションサーバーで実行され、Xディスプレイはユーザーのデスクトップで実行される。

このシナリオでは、OpenGLの全コマンドがユーザーのデスクトップマシンで実行されるため、そのマシンに高速な3Dグラフィックアクセラレータを必要とする。したがって、この方法で3Dアプリケーションをリモート表示できるマシンの種類は限られていた。

ネットワークが十分に速い場合（たとえばギガビットイーサネット）や、アプリケーションが描画されるオブジェクトのジオメトリーを動的に変更しない場合、アプリケーションがディスプレイリストを使う場合、アプリケーションが大量のテクスチャーマッピングを使用しない場合には、間接レンダリングでも優れた性能を発揮できる。しかしながら、OpenGLアプリケーションの実行環境が必ずしもこれらの条件を満たしているとは限らない。さらに、間接レンダリング環境では動作しないOpenGLの拡張機能があることも事情を複雑にしている。こうした拡張機能は3Dグラフィックスハードウェアに直接アクセスする必要があるため間接的に動作させようがないのである。他にも、ユーザのXディスプレイが必要なOpenGL拡張機能をサポートしていなかったり、あるいはその拡張機能がユーザーのデスクトップマシンに無い特定のハードウェア構成に依存する場合もある。

アプリケーションサーバー上でOpenGLレンダリングを実行すれば、アプリケーションから3Dレンダリングハードウェアへの高速で直接のアクセスが可能となり、間接レンダリングでの問題を回避できる。3Dレンダリングをアプリケーションサーバー上で実行すると、ユーザーのデスクトップに送信するのはレンダリング結果である二次元画像のみとなる。画像はその生成に使用された3Dデータの規模に関わらず同じフレームレートで配信できるため、アプリケーションサーバー上で3Dレンダリングを実行してしまえば、三次元描画の性能は問題ではなくなり、二次元描画の性能だけを気にすればよい。つまり、1〜2メガピクセルの画像データをインタラクティブなフレームレートでネットワーク越しに配信すればよいことになるが、たとえばHDTVのような普及している技術でこれは既に可能となっている。

VirtualGLはGLXの分岐（GLX forking）を使用して、アプリケーションサーバー上でOpenGLレンダリングを実行する。UnixとLinuxのOpenGLアプリケーションは、通常GLXコマンドと普通のX11コマンドの両方を同じXディスプレイに送信する。 GLXコマンドはOpenglレンダリングコンテクストと特定のXウィンドウとのバインディングや、Xディスプレイが対応するピクセルフォーマットリストの取得などに使用される。VirtualGLはアプリケーションへのライブラリのプレロード（preload）が可能であるというUnixとLinuxの特徴をうまく利用して、通常はアプリケーションがリンクされた共有ライブラリに対して実行する特定のファンクションコールを効果的に横取りする（これを「割り込み」（interposing）という）。

いったんVirtualGLが、UnixやLinuxのOpenGLアプリケーションにプレロードされると、VirtualGLはアプリケーションから発行されるGLXファンクションコールを割り込みによって取得し、それらを書き換えて、対応するGLXコマンドが3Dハードウェアアクセラレーターを搭載しているアプリケーションサーバのXディスプレイへ送信されるようにする。

したがってVirtualGLはユーザーのXディスプレイや、VNCなどのGLXに対応していない仮想Xディスプレイ（Xプロキシ）へ、GLXコマンドがネットワーク経由で送信されるのを防ぎ、GLXコールの書き換え時にOpenGLレンダリングの出力先をオフスクリーンピクセルバッファ（Pバッファ）へと変更する。その一方で、アプリケーションのユーザインターフェースを描画する通常のX11コマンドなど、アプリケーションが発行するその他のファンクションコールはそのまま通過させる。

また、VirtualGLの割り込みエンジンは内部処理としてウインドウとPバッファとのマップを保持し、送り先のXディスプレイと3Dレンダリングを実行するXディスプレイとの視覚特性を適合させ、GLXのシームレスな転送を確保できるようさまざまなハッシュ関数を実行している。原則的には、いったんOpenGLコンテキストがアプリケーションサーバのXディスプレイ上に確立されると、その後のOpenGLコマンドはすべてがアプリケーションサーバの3DハードウェアへVirtualGLを介することなく送信されるようになる。このようにして、アプリケーションサーバのハードウェアとドライバが提供している任意のOpenGL機能と拡張機能をアプリケーションが自動的に使用できるようになる。

GLXコマンドの整理とPバッファの管理以外にも、VirtualGLは適切な時間で描画されたピクセル（通常はglXSwapBuffers()やglFinish()によってモニタリングされる）を読み戻し（reads back）、標準的なXの画像描画コマンドを使用してアプリケーションのXウインドウにそのピクセルを描画する。

VirtualGLはGLXコマンドを目的のXディスプレイからアプリケーションサーバへとリダイレクトするため、VNCのようなXプロキシに3Dアクセラレーションのサポートを追加するだけではなく、リモートXディスプレイ使用時に間接的なOpenGLレンダリングが発生するのを防ぐこともできる。

VirtualGLをVNCなどのXプロキシと連携させると、ひとつのアプリケーションサー上で複数のユーザーが3Dアプリケーションを同時に実行したり、複数のクライアントでセッションを共有したりできる。しかしながらVNCなどは無地の広い領域を持ち、色数が少なく、フレーム間の差異が少ない2Dアプリケーションを扱うように最適化されている。3Dアプリケーションはその反対に緻密な画像を作成し、複雑な色パターンを持ち、フレーム間の相関もとても少ない。OpenGLアプリケーションでレンダリングされた画像をXウィンドウに描画する負荷は、基本的にはビデオプレイヤーのそれと等しい。しかし、市販のシンクライアントソフトウェアにはこうした負荷をインタラクティブなフレームレートで処理するのに十分高速なイメージコーデックが備わっていない。

VirtualGLは二つの方法でこの問題に対処している：

1. TurboVNC
2. VGL画像トランスポート

TurboVNCはTightVNCの派生物であり、部分的にインテルとサン・マイクロシステムズが独自にチューンアップしたマルチメディア関数を活用してTightとJPEG符号化パスを高速化している。

TurboVNCは、100メガビットイーサネットを介してほぼロスレスなフルスクリーン画像（1280x1024ピクセル）を毎秒20フレーム以上で表示する能力がある。また、最適化によってやや劣化が目立つが実用範囲内の画像を毎秒7〜10フレームで表示することもできる。TurboVNCはTightVNCを拡張してクライアント側にダブルバッファリングを持たせ、ソラリス用に最適化されたバイナリも用意されている。TurboVNCとVirtualGLはユタ州のテキサス大学計算機センターで使用されており、Marverickテラスケール可視化スーパーコンピューターが有する3Dレンダリング能力をテラグリッドユーザーがリモートから利用できるようになっている。

VGL画像トランスポートの利用時、レンダリングされた3D画像の圧縮にVirtualGLが使用するコーデックは、TurboVNCが使用するのと同じ最適化済みのJPEGコーデックである。VirtualGLはクライアントマシンで実行中のアプリケーションに専用TCPソケットを介して圧縮画像を送信する。VirtualGLクライアントは画像の展開と適切なXウィンドウへのピクセル描画を担当する。その一方、アプリケーションの表示でOpenGLに関係しない要素については、標準のリモートX11プロトコルを用いてネットワーク経由で送信され、クライアントマシン上で描画される。

このアプローチはクライアントマシン上にXディスプレイを必要とし、2Dレンダリングの実行はリモートX11プロトコルに依存することから、高遅延ネットワーク下でVGLイメージトランスポートを利用すると実行性能が低下するアプリケーションが増えてしまう。さらにVGL画像トランスポートは本質的にコラボレーション（セッションを複数のクライアントで共有）をサポートしていない。これはユーザーマシンに対して画像がpull型ではなくpush型で配信されているからである。しかし、VGL画像トランスポートはあらゆるアプリケーションウインドウを単一のデスクトップウインドウに対応させる完全シームレスなアプリケーション体験を提供できる。VGL画像トランスポートはまたサーバのCPU負荷を軽減する。これは2D描画がクライントで発生することと、クアッドバッファーステレオのようなOpenGLの高度な機能を使用可能なためである。

VirtualGLの開発者はVGL画像トランスポートの主なユーザーとして、アプリケーションサーバへの接続に802.11gや高速イーサネットが使用できるラップトップユーザーを想定している。

VirtualGLとTurboVNCは2009年4月に開発終了となったサン・マイクロシステムズの製品『Sun Visualization System』のコアコンポーネントであった。両オープンソースパッケージはクローズドソースのプラグインやパッケージとの組み合わせで、VirtualGLからSun Rayシンクライアントへが圧縮画像を送信できるようになっていたほか、Sun Grid Engineでリモート3Dジョブのスケジューリングやリソース管理が可能であった。これらのパッケージの組み合わせは「Sun Shared Visualization」と名づけられ、無償ダウンロードで利用できた（有償サポートがSunから提供されていた）。

HPのソフトウェアScalable Visualization Arrayのv2.1でもVirtualGLとTurboVNCを統合するコンポーネントを含んでおり、可視化クラスタで3Dジョブをスケジューリングしたり、可視化クラスタからリモート表示したりできるようになっている。

このほか、ThinLincのv3.0.0はVirtualGLと組み合わせて動作するように設計されている。

• X Window System
• Xgl
• AIGLX
• OpenGL
• VNC

• 公式サイト