[論文レビュー] Transparent Checkpoint-Restart for Hardware-Accelerated 3D Graphics

Samaneh Kazemi, Rohan Garg+1 more|arXiv (Cornell University)|Dec 23, 2013

Parallel Computing and Optimization Techniques参考文献 4被引用数 6

ひとこと要約

本論文は、記録・ pruning・再実行アプローチを用いて、ハードウェアアクセラレーテッド3Dグラフィックスのための透過的でGPUに依存しないチェックポイント再起動メカニズムを提案する。これにより、VMGLの78,000行からOpenGL 1.5では4,500行にコードの複雑さが削減され、OpenGL 3.0への対応が拡張され、アプリケーションのオーバーヘッドを最小限に抑えながら、ネイティブパフォーマンスの80–100%を達成する。

ABSTRACT

Providing fault-tolerance for long-running GPU-intensive jobs requires application-specific solutions, and often involves saving the state of complex data structures spread among many graphics libraries. This work describes a mechanism for transparent GPU-independent checkpoint-restart of 3D graphics. The approach is based on a record-prune-replay paradigm: all OpenGL calls relevant to the graphics driver state are recorded; calls not relevant to the internal driver state as of the last graphics frame prior to checkpoint are discarded; and the remaining calls are replayed on restart. A previous approach for OpenGL 1.5, based on a shadow device driver, required more than 78,000 lines of OpenGL-specific code. In contrast, the new approach, based on record-prune-replay, is used to implement the same case in just 4,500 lines of code. The speed of this approach varies between 80 per cent and nearly 100 per cent of the speed of the native hardware acceleration for OpenGL 1.5, as measured when running the ioquake3 game under Linux. This approach has also been extended to demonstrate checkpointing of OpenGL 3.0 for the first time, with a demonstration for PyMol, for molecular visualization.

研究の動機と目的

• 長時間にわたるGPU集約的3Dグラフィックスワークロードにおける透過的でアプリケーションに依存しないフェイルセーフの欠如に対処する。
• 複雑なグラフィックスパイプラインにおけるアプリケーション固有の状態保存ソリューションの高い開発および保守コストを克服する。
• VMGLのようなモノリシックなシャドウデバイスドライバアプローチを、ログベースの再実行に基づくモジュラーで保守可能な代替手段に置き換える。
• OpenGL 1.5およびOpenGL 3.0の両方に対して透過的なチェックポイントを可能にし、プログラマブルシェーダーおよび現代的なレンダリング機能をサポートする。
• Linux環境下でのioquake3およびPyMolといった実世界のアプリケーションにおいて、本アプローチの実現可能性とパフォーマンスを実証する。

提案手法

• アプリケーションが行うすべてのOpenGL関数呼び出しをインタセプトし、ログに記録するDMTCPプラグインを実装する。
• フレーム境界での状態の一貫性に基づき、冗長なOpenGL呼び出し（例：glEnableClientStateなど）をすべて除去する、pruningアルゴリズムを適用する。
• チェックポイント前のGPUドライバ状態を正確に再構築するために、prunedされたOpenGL呼び出しログを再実行する。
• 仮想マシンスナップショットを必要とせず、ユーザー空間での透過的チェックポイントを可能にするために、DMTCP上にプラグインアーキテクチャを構築する。
• 複数のウィンドウングラフィックツールキット（GLUT、SDL、GLX）をサポートし、シェーダーおよびプログラマブルパイプライン処理を含むOpenGL 3.0への拡張を実現する。
• 将来のバージョンにおいて、バイナリログストレージ、メモリ内ログ記録、C言語ベースのログpruningによるパフォーマンス最適化を計画する。

実験結果

リサーチクエスチョン

• RQ1 アプリケーションの変更なしに、透過的でGPUに依存しないチェックポイント再起動を実現するための記録・pruning・再実行アプローチは可能か？
• RQ2 本アプローチのコード複雑さは、VMGLのような従来のシャドウデバイスドライバベースのソリューションと比較してどの程度か？
• RQ3 正しさと透過性を維持しながら、パフォーマンスのオーバーヘッドをどの程度まで最小限に抑えられるか？
• RQ4 本アプローチは、プログラマブルシェーダーやOpenGL 3.0といった現代的なOpenGL機能をサポートするように拡張可能か？
• RQ5 ログ表現（ASCII対バイナリ）およびストレージ（ディスク対RAM）の選択が、チェックポイントおよび再起動のパフォーマンスに与える影響は何か？

主な発見

• 記録・pruning・再実行アプローチにより、VMGLの78,000行からOpenGL 1.5ではたったの4,500行に実装の複雑さが削減され、コードサイズが94%削減された。
• ioquake3では、ネイティブハードウェアパフォーマンスの80–100%を達成し、チェックポイント時間は2秒未満、再起動時間は18秒未塔であった。
• 本手法はOpenGL 3.0へも成功して拡張され、シェーダーおよびプログラマブルパイプラインをサポートし、合計実装サイズは6,500行であった。
• PyMolでは、DMTCPプラグインのログ記録により9%のパフォーマンスオーバーヘッドが生じ、チェックポイント時間は1.4秒、再起動時間は10秒であった。
• 現在のパフォーマンスオーバーヘッドは、ディスク上へのASCII文字列ログ記録に起因している。将来のバイナリログ記録およびメモリ内ストレージの導入により、このボトルネックは解消される見込みである。
• 本アプローチは透過的でベンダーアウェアであり、DMTCPおよびVNCベースのリモートレンダリングとの統合により、異種GPUアーキテクチャおよびクラスタ環境への拡張性を有する。