＊ここに掲載するのは、マンチェスター大学のGeorge Leaver, Martin Turner両博士によるHECToRレポート「Massive Remote Batch Visualizer, Porting AVS/Express to HECToR, George Leaver, Martin Turner, Research Computing Services, Devonshire House, University of Manchester, Manchester, UK, M13 9PL, 20 July 2010」を要約したものです。
概要
このプロジェクトの目標は、AVS/Express DDRをHECToR フェーズ2のCray XT4へ移植することです。これにより、現状のGPUベースの可視化システムの性能を超える大きなデータセットの可視化が可能になります。材料科学の研究には、50から500GBサイズのデータを扱う必要があります。このデータは、CTスキャン装置（マンチェスター大学のHenry Moseley X線装置が含まれます）から得られた物質の密度データです[6]。さらにRALのダイアモンド光装置のI12 JEEPビームラインからもデータを得る予定です。AVS/Express DDRは、こうしたデータのみに限られるものではなく、異なるタイプのデータを扱う研究者も利用可能です。AVSは、アプリケーションへ読み込み記述が可能な多くのデータ形式を可能にするAVSフィールドリーダを備え、特にNetCDF[7]およびHDF5[8]形式も扱うことが可能です。
プロジェクトには2009年5月から10人月を予定され、その期間中にnAG CSEサポートによる最適化作業に2か月が予定されました。しかしながらこのオプションは、アプリケーションのインタラクティブ性から不要と見なされたため行われませんでした。
中心となる作業は、AVS/Express DDRをHECToRの実行環境で動作するように修正することでした。この作業は以下のように詳細化されました：
・AVS/Expressのメインアプリケーション（ネットワークエディタ、モジュールユーザインターフェイス、可視化ウィンドウ）をログインノードで動作させる。ここではX11は動作可能で、バックエンドノードで実行する並列モジュールとレンダリングプロセスを通信可能である。AVSソースへの修正は最小限にして、他のプラットフォームに影響を与えるような重大なアーキテクチャの変更は避ける。こうしてAVS/Expressは構造的にオープンソースParaView[9,10,11]に似た形式になる。
・AVS/Express内の既存のMPI通信を最適化する。並列レンダラーは1対1通信を用いているが、これは大きなプロセッサ数においてスケーラビリティを減じることが判っている。
・AVSネットワークを用いて、ユーザが実行するであろう共通的な可視化実行をデモンストレーションする。
AVS/Expressは、ログインノードのX11からsshを通じてユーザのXサーバへ接続して実行します。XサーバはGLXプロトコルをサポートしなくてはなりません。これは、X11アプリケーション実行では各段有効な方法というわけではなく、全レンダリングフレームレートは並列レンダリングで改善できない上限を持ちます。この制約は、ログインノードからXサーバへイメージを転送する時間によるものです。AVSレンダラーの場合上限は、LINUXのテストデスクトップシステムへリモートレンダリングする場合、512x512ウィンドウで約5.0fps、1024x1024で1.1fpsです。これは低い値のように見えますが、ユーザが可視化においてインタラクティブに操作するのに十分な応答を残しています。問題は、可視化するデータサイズの増加に対して、メモリー効率をスケールアウトする能力です。
AVS/ExpressのソースはデフォルトのGNUコンパイラ（4.4.2）でコンパイルされています。これは64bit LINUXプラットフォームを用いたAVSビルドでサポートされるコンパイラの一つです（この他にIntelコンパイラもサポートされます）。マンチェスター大学グループは、幾つかのコンポーネントをライブラリとしてアクセスする以外、AVS/Expressソースを利用する旨AVSと契約しました。ビルドプロセスにおいては、 実行形式：baseがコンパイルされ、次にこれがVモジュール記述ファイルを読み込みます（AVS/Expressは、Vという名称のモジュール記述言語を用います）。Vファイルを処理するとそのモジュールのC/C++/Fortran言語コードが生成され、これらはビルドプロセスの中でコンパイルされます。こうして最終的に実行形式：expressが生成されます。
MPIフォワーディング
既存のDDRアーキテクチャ
既存の可視化コードは、複数の実行形式から成るMPIアプリケーションです。メインの実行形式はexpressで、これはAVSネットワークエディタ、モジュールユーザインターフェイス、可視化ウィンドウを提供します。これはMPIジョブで常にランク0です。この他のコンポーネントはpstnodeとmpunodeの2つのタイプに分けられます。
pstnodeプロセスは可視化ネットワーク内のモジュールに対応する並列モジュールコードを実行します。その鍵となるコンセプトは、データはexpressプロセスにより直接アクセスされることはないということです。実際にはデータはより小さなサブ領域に分割され、それぞれが一つのpstnodeプロセスに対応します。expressプロセスは、pstnodeにそのサブ領域で行う処理を指令します。例えば、min/maxフィルタモジュールは、そのパラメータ（最小値、最大値）をpstnodeプロセスへ渡します。そしてこれらは担当するサブ領域をフィルタリングします。各pstnodeからexpressへ少量の情報が返却されて、ユーザインターフェースが更新されます。例えば各サブ領域内の実際の最小/最大データ値は、ユーザインターフェースのデータ全体の最小値/最大値の表示に用いられます。同様に、並列等値面モジュールはユーザインターフェイスからパラメータ（例えば計算すべき等値面レベル）を受取りますが、計算はpstnodeの担当サブ領域上で行われます。サブ領域は固定されたままです。このデータ分割とpstnode内のカプセル化がAVS/Expressに大規模データ処理を可能にさせます。メインのexpressプロセスでは、サブ領域を集めて再構成しません。そうすることで、expressプロセスが実行中のノードのメモリリソースをほぼ確実に超えることになります。
可視化ネットワークは、どのモジュールがレンダリングするジオメトリーを生成するかを決めます。pstnodeが生成した如何なるジオメトリーも、割り当てられたmpunodeプロセスへ直接渡されます。mpunodeのMPIプロセスはAVS/Expressのレンダリングを並列に実行します。これらは、expressからグローバルシーングラフデータを受取り、割り当てられたpstnodeから受信したジオメトリーへシーングラフを埋め込みます。こうして各mpunodeは、シーン内の全ジオメトリーの一部をレンダリングします。mpunodeが生成したイメージは、（デプステストとアルファブレンドを用いて）合成され、最終的なイメージがユーザインターフェイスのディスプレイ用にexpressまで送り返されます。MPIプロセス間の全通信は、メッセージが領域特定なのか全領域に共通なのかに依ってMPIの1対1通信か集団通信で実行されます。しかしながらこの段階では、合成においては、AVSが用いるオープンソース合成ライブラリがMPIを用いないことからtci/ip通信が用いられています。
MPIプロキシー
ユーザインターフェイスプロセスexpressをHECToRのログインノードで稼働させるには、AVS/Expressに多くの修正が必要です。最も重大なことは、これをMPIjobとは別に動作させるために、全てのMPI機能を削除する必要があることです。このために、最初に、別の通信機能を実装して、MPI機能を削除することが考えられましたが、膨大な修正量が必要となるためこの方法は除外されました。採用した場合はさらに、ユーザが開発した並列モジュールも同様な修正が必要になってしまうでしょう。このプロジェクトで実装された2番目の方法は、別のMPIライブラリを用意することです。これはCray MPIレイヤーを用いず、なおかつ大きなコード変更なしにexpress実行形式へリンク可能です。
この置換されたMPIライブラリーをXPMTと呼ぶこととします。expressソースには（mpi.hではなく）xpmt_nonpi.hを含め、libxpmt.soをリンクするようにします。そして、デュアルコアプログラミング環境でログインノードのシリアル実行形式としてコンパイルします。libxpmt.soは、標準的なtcp/ipソケットを用いてMPIプロセスプロキシーとして通信する「MPI関数」を含んでいます。このプロキシープロセスは、バックエンドノード上で実行するCray MPIプロセスです（常にランク0）。非MPIのexpressは、プロキシーxpnodeが動作する計算ノード上でMPI関数が呼ばれるようにリクエストを送信します。このプロセスは、そのリクエストとMPI関数に必要な引数を受信します。例えば、MPI_send()へのリクエストには、buffer, count, datatype, destination rank, tagおよびコミュニケータ引数が必要です。リクエストを受信したら、xpnodeプロセスはこれらの引数と共にCray MPI関数を呼び出します。リターン型やバッファ内容など全ての結果はsocketによりexpressプロセスへ返却されます。つまり、非MPIexpressプロセスは、それがプロキシ経由でMPI関数を呼び出すことを知る必要がありません。
MPIプロキシープロセス(xpnode)はxpmt mpi.hとmpi.hを含み、libxpmt mpi.aとCray MPIライブラリをリンクします。これは、MPI型のXPMT表現をCray MPI型へマッピングすることを許します。ここでの実装では、MPI型のXPMT表現は全て整数型で、xpnodeプロキシープロセス内の実Cray MPI型のテーブルインデックスとして振る舞います。expressが新たなMPIオブジェクト（コミュニケータ、データ型、ステータスなど）を生成すると、プロキシーはCray MPIレイヤーを用いて同値なオブジェクトを生成することで、2つの表現の間のマッピングを行います。
pstnodeとmpunodeプロセスに変更はなく（これらは標準的なCray MPI実行形式です）、これらはexpressプロセスですがxpnodeと通信します。この理由は、これらがランク0プロセスをexpressであると認識しており、expressから呼ばれるMPI関数に対する応答において通信するのみであるからです。例えば、expressがMPI_Recv()を発行する際は、プロキシーxpnodeはランク0から同等の関数を呼び出します。pstnodeかmpunodeプロセスが呼応したMPI_Send()を呼び出す際は、プロキシーxpnodeはデータを受信してそれを非MPI expressへ渡します。つまり送信プロセスはxpnodeプロセスがexpressのプロキシーであることを全く感知しません。
pstnodeとmpunodeプロセスは、Cray MPIレイヤーを経由して互いに通信するので、その最適化ライブラリーとCrayインターコネクトの優位性を維持します。最大のデータ転送は、ジオメトリーがレンダリングに渡される際にpstnodeとそれに関連するmpunodeの間に生じます。この通信にはプロキシーxpnodeは一切関与せず、全てCray MPI領域内で生じるため、expressユーザインターフェイスからCらyMPIを削除しても性能に劣化は生じません。非MPI expressプロセスによりソケットで送信されるデータ量は、その内容が主にコマンドであるため一般に少量です。expressからmpunodeレンダリングプロセスへ送られるグローバルシーングラフ情報も少量です。これは、ジオメトリーのほとんどがpstnodeプロセスで生成されるためです。
XPMTの性能
MPIプロキシーの使用は、expressとのMPI通信に性能上の劣化を生じさせます。MPIプロキシーとCray MPIレイヤーを用いた場合の様々なテストを行いました。Cray MPI実行形式がバックエンドノード全体で用いられます。同じテストをXPMT置換ライブラリに対して行い、ランク0がログインノード上で実行され、xpnodeプロキシープロセスを介して通信します（これはMPIジョブ内ではランク0になります）。残りのランクは標準的なCray MPI実行形式です。テストはAVS/Expressで用いられる共通の通信呼出しを実行します（MPI_Bcast, MPI_Gather, MPI_Send, MPI_Recv, MPI_Isend, MPI_Irecv, MPI_Waitall）。これらは、MPI_INT配列で送受信し、そのサイズを64, 128, 256, 512, 1024, 1024^2, 2x1024^2, 8x1024^2と変化させました。その結果、MPIプロキシーを用いると、場合によっては3倍遅くなる場合が生じました。AVS/Express内では、expressからの殆どのメッセージは、サイズにして1Kより小さなものです。計算ノードからexpressプロセスへ返却される最大のメッセージは、通常は最終的にレンダリングされた合成イメージで、512x512ウィンドウで1Mbサイズです（ここでピクセル当たり4byteを仮定しています）。AVS/Expressがインタラクティブなアプリケーションですが、この性能劣化は受容できるレベルと考えられます。
まとめ
バックエンドノード上で並列モジュール処理とレンダリング処理を行うように、ログインノード上のAVS/Expressユーザインターフェイス実行の方式を実装しました。ログインノードからMPI関数呼び出しを行うためにexpressプロセスを作成し、AVSソースコードへの影響を最小限にしました。これは、MPI関数呼び出しをバックエンドノード上で実行するランク0プロセスのプロキシーへフォワーディングします。プロキシーを介した様々なAVS/Expressプロセス間の通信は、こうしたプロセスに透過的です。この機構による性能劣化はありますが、インタラクティブ性には致命的ではありません。
X11ユーザインターフェイスをHECToRへsshを介してフォワーディングすることは、これとは別の性能劣化を生じさせます。expressプロセスをユーザのローカルアデスクトップで（クライアントとして）走らせ、HECToRログインノードからユーザのデスクトップへsshトンネルを確立することは可能です。これはログインノードからX11接続をフォワーディングするよりも効率的です（HECToRシステムでは許可されていません）。
イメージ合成
AVS/Expressは現在オープンソースの（最初にHPにより開発された）Paracomp[13]合成ライブラリを利用しています。このライブラリはダイナミックリンク（そのフレームワークにはdlopen()が必要です）が必要で、tcp/ip、InfiniBand、Mellanoxネットワークレイヤーをサポートします。さらにネットワークや制御、イメージ操作に対してマルチpthreadも用います。その基本となる合成法はScheduled Linear Image Compositing[14]です。これは、InfiniBandやMellanoxネットワークを持つレンダリングクラスタ上で効果的な合成ライブラリですが、MPIサポートがなく、マルチpthreadとダイナミックリンクを使用することから、HECToRのAVS / Expressから削除することとしました 。そこでコアとなるイメージ合成ルーチンのみからなるライブラリをコンパイルしました。これは、デプステストとアルファブレンディングによる2つのイメージの合成を行う静的ライブラリで、全ての合成において必要となる基本的なイメージ操作を行うものです。
ここで、2-3 Swap Image Compositing法[15]を実装しました。これにより、（合成操作を実行する）レンダリングプロセス間のすべてのイメージの通信が、Cray MPIレイヤー内で行われます。この方法はBinary-Swap Compositing [16]と似ていますが、レンダリングプロセス数が2のべき乗である制約がないものです。これは、MPIプロキシープロセスを用いるAVS/Expressにおいて重要な性質です。
並列イメージ合成は、各レンダリングプロセスからの生成されたサブ領域イメージをブレンドする時間を削減します。フルサイズのイメージを各プロセスから直接一つのプロセスへ送信すると、そのプロセスがボトルネックになります。各プロセスにおいてそのスクリーン空間内でイメージを分割し（例えばピクセルの列で）、これらサブイメージを交換することで全プロセッサはブレンド操作を行うことが出来ます。最終的に各プロセッサは、完全にレンダリングされたデータを含むサブイメージを持つことになります。最後に、これらサブイメージを一つのプロセスに集め、これをイメージバッファへコピーします。このステップはボトルネックにはなりません。何故なら、スクリーン空間のサブイメージは、この段階では小さいからです（各サブイメージは、nをレンダリングプロセス数として、最終的なイメージの1/nのピクセル数を含みます）。この通信全体はバックエンドノードで行われます。最終的なイメージはMPIプロキシを介してexpressプロセスへ送信され、ユーザインターフェイスで表示されます。
イメージ合成の性能
任意のプロセスで行われた512x512と1024x1024ピクセルサイズの（デプステストを用いた）イメージピクセルのブレンドに掛かった時間を計測しました。これは、イメージ合成中の特定のプロセスの振舞いを示すスナップショットです。
最も遅い合成プロセスでさえ、512x512ピクセルでのフレームレートは90fps、1024x1024では30fpsです。
MPIプロキシーを介してexpressプロセスがイメージを受信する時間と、一つのレンダリングプロセスがイメージをプロキシーへ送信する時間も計測しました。この送信処理はCray MPIレイヤーで動作するため短時間で動作します。受信時間は大きく、レンダリングの全フレームレートを劣化させます。このイメージ通信は、expressとMPIプロキシープロセスの通信で用いられるtcp/ipソケットで生じます。
ここで、Paracompライブラリのイメージ合成ルーチンにOpenMPラッパーを追加しました。これにより、大きなイメージの合成操作におけるブレンド時間が削減されます。一つのノード上で実行するpstmpunodeプロセス数（通常は2か4）と、イメージブレンドでのOpenMPスレッド数はトレードオフ関係にあります。しかしながら、MPIプロキシーからexpressプロセスへのイメージ通信がボトルネックであるため、OpenMPスレッドを1にすることが推奨されます。つまり一つのノード上のpstmpunodeプロセス数を大きくするほうが有効です。
並列レンダリング処理の通信
AVS並列レンダリングコードでは、集団通信がより有効な場合においても1対1通信が用いられています。レンダリング内のMPIパターンは当初、非MPI通信ライブラリーを用いていたコードセクションに合わせて開発されました。このライブラリは集団通信を提供していませんでした。この通信スタイルが発生するレンダリング処理内の主な内容は、expressプロセスからpstmpunodeレンダリングプロセスへのシーングラフの配布と、プロセスキャッシュを更新するためのメッセージ送信です。
シーングラフは、一般的な情報（カメラ位置や、ライティング、背景色など）と並列モジュールプロセスpstmpunode(p)により最終的に生成される全てのレンダリング対象オブジェクトを表現するプレースホルダーを含みます。これらオブジェクトは、例えば等値面のためのの三角要素列やボリュームレンダリング用のテクスチャーデータです。これらは、レンダリングプロセス内でキャッシュ内、およびキャッシュ内のシーングラフ参照オブジェクト内のプレースホルダーに格納されます。シーングラフは、pstmpunodeレンダリングプロセスへ送信されます。これは、これらのプロセス内で、キャッシュ上の更新操作メッセージ（例えばデータ外ジオメトリーオブジェクトの削除メッセージ）の役割を果たします。これはシーングラフの通信であり、これらメッセージは最適化可能です。
画像をレンダリングする場合、expressは、新しいオブジェクトとジオメトリを含むシーングラフを生成する必要があるかどうか、またはカメラ位置の変更などによって既存のシーングラフを単純に再描画するかどうかを決定します。前者の場合は、例えば、ユーザが等値面レベル値を変更したり、ボリュームレンダリング伝達関数を変更したりする場合に発生します。レンダラーは、既存のキャッシュされたオブジェクトを削除し、モジュールプロセスから新しいオブジェクトを受け取る必要があります。メッセージをすべてのレンダリングプロセスに送信して、すべてのキャッシュがレンダリングプロセス全体で一貫するように、キャッシュを更新するように要求する必要があります。後者の場合については、新しいジオメトリが生成されない場合は、はるかに単純なシーングラフをレンダーノードに配布することができ、キャッシュの変更を要求するメッセージは必要ありません。この場合には、シーングラフはレンダーノードの既存のジオメトリを参照しますが、カメラ位置などの新しい設定が含まれます。
テストの結果、MPI_Bcastへの置き換えは、単純ですが有効な最適化であることが示されました。 この変更は、HECToRだけでなく、他のプラットフォームのAVS/Express DDRにも役立ち、AVSソースツリーに提供されました。
データセット例
データセットは、ディメンション7150x7150x7369の１バイトデータ（0~255範囲の密度値）を含むデータです。レンダリングを512x512および1024x1024イメージサイズで行いました。サブドメイン数127及び255を用いた場合、フレームレートは1.3から2.5fpsが最速でした。低いフレームレートですが、対話的に可視化操作ができます。これには、ボリュームレンダリング伝達関数の操作が含まれ、ボリューム内の詳細が表示されます。HECToRでAVS/Expressを実行することで、初めてこのデータセットのレンダリングが可能になりました。
並列レンダリング処理の通信
AVS/Expressを使用して、ユーザーインターフェイスを用いずにイメージをレンダリングすることは可能です。write_imageモジュールを用いて、レンダラからの画像キャプチャが可能です。-offscreenフラグを指定して起動すれば 、ユーザーインターフェイスが表示されないようにすることが出来ます。
結論
AVS/Express DDRコードをHECToR Cray XT4アーキテクチャに移植しました。このプラットフォームを用いて、GPUハードウェア上でレンダリングできなかったCT X線スキャンデータを可視化しました。このシステムにおいてはユーザは、多くの場合約5フレーム/秒でインタラクティブな可視化が可能です。新しい合成レイヤーの追加とパラレルレンダリングコードの改良により、AVS/Expressは以前よりもはるかに大きなプロセッサ数で使用することができるようになりました。
MPIフォワーディングレイヤーとプロキシーの利用により、AVS/Express内の通信コードの大幅な改造が不要になり、並列モジュールとレンダリングプロセス間の通信をベンダーMPIドメイン内に収めることが可能になりました。これにより、ユーザーは既存のAVSフレームワークを使用して独自のAVSパラレルモジュールを開発し、変更なしにHECToRへインストールすることができます。ユーザが開発したアプリケーションの一例は、ParaFEM Viewer [17]です。これはHECToRで利用可能なParaFEMライブラリ[18] によって生成された有限要素解析データを視覚化するために使用されています。
この仕事は下記の論文として公開されています。
・Proceedings of the Theory and Practice of Computer Graphics Conference 2010 (EGUK)(accepted)
・All Hands Meeting 2010, Philosophical Transactions of the Royal Society A(submitted)
・JISC vizNET 2009 Conference [19]
謝辞
このプロジェクトは、nAG Ltd.が運営するHECToRの分散計算科学および工学(CSE)サービスの基に実行されました。英国の国立スーパーコンピューティング・サービスである、HECToR：英国リサーチ・カウンシル・ハイエンド計算サービスは、リサーチ・カウンシルを代行するEPSRCが管理しています。そのミッションは英国学術界の科学および工学の研究支援です。HECToRスーパーコンピューターは、UoE HPCx Ltd.およびnAG Ltd.のCSEサポートサービスにより管理運営されています。
文献
1. AVS website http://www.avs.com
2. Haber R., McNabb D.: Visualization idioms: A conceptual model for scientific visualization systems. In Visualization in Scientific Computing (1990), Shriver B., Neilson G., Rosenblum L., (Eds.) IEEE Computer Science Press, pp. 74-93.
3. Molnar S., Cox M., Ellsworth D., Fuchs H.: A sorting classification of parallel rendering. IEEE Computer Graphics and Applications, 14(4), July 1994, pp. 23-32.
4. MesaGL: Open source software OpenGL implementation. Website http://www.mesa3d.org
5. OpenGL website http://www.opengl.org
6. Henry Moseley X-Ray Imaging Facility website http://www.materials.manchester.ac.uk/research/facilities/moseley/
7. Network Common Data Format http://www.unidata.ucar.edu/software/netcdf
8. Hierarchical Data Format http://www.hdfgroup.org/HDF5
9. ParaView website http://www.paraview.org
10. Bethune, I. Parallel Visualization on HPCx. Tech Report, STFC, 2009. http://www.hpcx.ac.uk/research/hpc/technical_reports/HPCxTR0803.pdf
11. Moreland K., Rogers D., Greenfield J., Geveci B., Marion P., Neundorf A., Eschenberg K.: Large scale visualization on the Cray XT3 using ParaView. In Cray User Group (May 2008), Shriver B., Neilson G., Rosenblum L., (Eds.). http://www.cs.unm.edu/~kmorel/documents/PVCrayXT3/PVCrayXT3.pdf
12. Eduserv CHEST Agreement website http://www.eduserv.org.uk/licence-negotiation/agreements
13. Paracomp Open Source Compositor Library, HP. http://paracomp.sourceforge.net
14. Stompel A., Ma K.-L., Lum E., Ahrens J., Patchett J.: SLIC: Scheduled Linear Image Compositing for Parallel Volume Rendering. In Proceedings of the IEEE Symposium on Parallel and Large-Data Visualization and Graphics (2003) IEEE Press, pp. 33-40.
15. Yu, Hongfeng and Wang, Chaoli and Ma K.-L.: Massively parallel volume rendering using 2-3 swap image compositing. In SC '08: Proceedings of the 2008 ACM/IEEE conference on Supercomputing (2008) IEEE Press, pp. 1-11.
16. Ma K.-L., Painter J. S., Hansen C. D., Krogh M. F.L: Parallel Volume Rendering Using Binary-Swap Compositing. In IEEE Computer Graphics and Applications, 14(4), 1994, pp. 59-67.
17. ParaFEM Viewer website http://wiki.rcs.manchester.ac.uk/community/Projects/ParaFEM-Viewer
18. ParaFEM Library website http://www.rcs.manchester.ac.uk/research/Parafem
19. vizNET 2009 Conference website http://www.viznet.ac.uk/viznet2009/