NVIDIAはSIGGRAPH Asia 2009において、「Languages, APIs and Development Tools for GPU Computing」と名付けられたコースを実施。その名のとおり、GPUコンピューティングのプログラミング手法を紹介するもので、内容はCUDAやOpenCLによるプログラミングの初歩からパフォーマンスチューニングまで幅広い。ここでは、このコースで紹介されたGPUコンピューティングの具体的な導入事例を紹介する。

東工大のスパコン「TSUBAME」。昨年、170個のTesla S1070(680GPU)を導入

　東京工業大学 学術国際情報センター(東工大GSIC)の青木尊之教授が説明したのは、同氏の研究室が進めている津波のリアルタイムシミュレーションに関するもの。東工大GSICといえば、国内でも屈指の性能を持つスパコン「TSUBAME」の存在を連想される読者もいるだろう。TSUBAMEは、10,000コアのAMD Opteronをベースとしたシステムで、昨年、NVIDIAのTesla S1070を170枚、GPUにして680個を追加搭載。GPUアクセラレーションを導入したスパコンとして世界的にも注目されている存在だ。

　青木氏の説明の主題である津波シミュレーションは、流体計算シミュレーション(CFD)となる。CFDは映画などでも当たり前に使われてきており、実写かと思うとCFDで生成された映像だったということもある。そこにGPUが使われることはインパクトが大きい。

　CFDにおいては、演算性能以上にメモリ帯域幅がボトルネックになりやすく、ここにローカルメモリを持つGPUに大きなメリットが出る。なお、ビデオメモリの容量はTeslaで4GB、GeForceだと2GBが最大ということは前提としてある。

　青木氏はまず、1GPUでの事例を基に、CFDをGPUで行なう際の基本的な手法、考え方を紹介。流体は密度変化の差によって圧縮性流体と非圧縮性流体に分けられるが、津波のシミュレーションは非圧縮性流体に該当する。ここで使用される方程式の1つがナビエ-ストークス(Navier-Stokes)方程式で、これに圧力を解くポアソン(Poisson)方程式というものがあり、これが非常に重い処理になるという。

非圧縮性流体の計算にはナビエ-ストークス方程式を使用。とくに圧力に関するポアソン方程式が重い処理となる	ポアソン方程式をマルチグリッド法で解くためにVサイクル法と呼ばれる効率のよいアルゴリズムを使用。修正方程式を行いながら格子を荒くしていき、再度格子を細かくして収束させていく手法となる

　ここではマルチグリッドのRed & Black法というものが使われる。CFDでは一定の範囲を格子状に分割し、どのように干渉し合うかを計算する。この格子を徐々に荒くして計算し、再度細かくしていくVサイクルを用いており、これはCPUでも使われる効率的な方法だ。Vサイクルを使うことでアルゴリズムレベルで高速化し、さらにGPUでどこまで高速化できるか、が課題となる。

　ちなみにCFDにおいてはメモリアクセスがキーになることは先述したが、マルチグリッドでも有限差分法を使うと連続的なメモリアクセスが多くなり、GPUの方が効率が良いという。ほかに有限要素法というものもあるが、こちらはランダムなアクセスが発生するため効率が悪い。とくにCompute Capability (CC)1.2までのNVIDIA GPUは非常に遅かったという。しかし、CC1.3のGPUでは性能が改善されており、有限要素法の高速化は成功例が少ないが、これから出てくるのではないかと青木氏は述べている。

　メモリアクセスについてもう1つキーとなるのが共有メモリの活用である。NVIDIA GPUのアーキテクチャではSP 8個と共有メモリで1つのSMを形成するが、この共有メモリを活用することが性能向上に欠かせないという。

　例えば、ある1点に対して3点先まで隣接する点を参照するとした場合、隣の点も同じように隣接3点ずつを参照するわけで、共通して参照するデータが多いことになる。各スレッドは独立しているのでお互いにデータ参照はできないが、共有メモリを利用することで、何十回ものグローバルメモリ(ビデオメモリ)へのアクセスを1回で済ますことができる。

マルチグリッド法で解く際、有限差分法を用いるとGPUが得意な連続的な(コアレスシング)なメモリアクセスとなる。CC1.3ならランダムアクセスが必要となる有限要素法もまずまずの性能が出せるという	隣接点は同じ点を参照するケースが非常に多い。そこでSMが持つ共有メモリに共有できるデータを持ってくることでグローバルメモリへのアクセスを減らす

　GPUの共有メモリは、CPUとは異なり自分でコントロールして利用しなければならない。逆に言えば、自分でコントロールして使えるということでもある。つまり、共通してアクセスするデータを積極的に共有メモリへ置くことで高いヒット率を実現できる。青木氏はGPUがCFDで高い性能を出せるのは、ここが大きなポイントだと思っているという。

　さて、いよいよ本題のマルチGPUにおけるCFDである。ビデオメモリへの高速なアクセスがGPUを使うメリットであるCFDにおいて、PCI Expressインターフェイス(しかもマルチGPU環境ではx8接続になったりする)を介して通信を行なう必要があるマルチGPU化は性能を活かせないことになる。

　ここでは格子ボルツマン法(Lattice Boltzmann Method)という流体計算手法が用いられている。この手法は空間内での要素数が少なく簡単なアルゴリズムで実現でき、かつ並列処理しやすいという特徴があるという。

　これをマルチGPUに適用するには、GPUの数に合わせて計算対象の空間を分割する。ただし、分割した空間の境目はお互いに相互参照する必要があり、隣のGPUからデータを持ってこなければならない。そこで、CPU側にバッファ領域を用意してデータの受け渡しを行なっている。これにより、1,536×768×768という広大な領域の計算を64GPUで実施した例を紹介。最近では2,000×1,000×1,000というさらに広大な空間でもテストをしており、これは「とても1GPUではできない」(青木氏)処理という。

CFDをマルチGPU処理させるにあたり、格子ボルツマン法と呼ばれる計算方法を使用	空間を分割しGPUへそれぞれ別の空間を割り当てて計算。隣接点のデータ交換のために、OpenMPもしくはOpenMPIのスレッドをCPU側に起ち上げ、バッファ領域として使用する	マルチGPU化することで使用できるメモリ領域が増すので、広大な空間のCFD処理が可能になる

　性能面では、1GPUがCPUに対して89倍。ただし、GPUが増えても性能はリニアに伸びない。通信がどうしてもボトルネックになってしまうからだ。同じサイズの問題をGPUの数を増やして処理する場合は、期待するほどは伸びない。一方で、複数のGPUを使うことで多くのメモリ領域を扱え、広大な空間を計算できるというメリットはあり、同じGPU数で問題サイズを増やした場合はかなり性能が伸びる。

　そこで違うアプローチを検討したことが紹介された。先ほどの分割は1次元分割であったものを、2次元や3次元に分割するという方法である。分割単位が増えることで1回当たりのデータアクセス量が減る一方で、分割面の数が増えることでアクセス回数は増えることになる。この結果、アクセス回数が増えることによるオーバーヘッドが発生することはあるものの、3次元分割を行なった場合はGPUの数が増えても性能の伸びが鈍化しにくい傾向があることを紹介した。

1次元分割した場合の性能変化。インターフェイス通信によるボトルネックがあるためGPUの数を増やしてもリニアには伸びない。ただし、同じ数のGPUで計算サイズを大きくした場合の性能向上は大きい	2次元/3次元で分割する手法を紹介。データアクセス回数は増えるが、隣接面接が小さいので1回当たりの転送量は減る	3次元化した場合に必要なデータ交換。各面のほか、コーナーも別のドメインとのデータ交換が必要になる
384×384×384のサイズでの結果。1次元分割は通信がかなりボトルネックになっていることが分かる。3次元分割はGPUの数が少ないうちはオーバーヘッドが大きいが、数が増えると2次元分割以上の性能を出せるようになる	768×768×768のサイズでの結果。同じようにGPUの数が増えたときに3次元分割が有効であることが分かる	3次元分割によるプログラムを実際にTSUBAMEを使ってCPUとGPUで比較した結果。「CPUのプログラムはチューニング不足」という前提はあるが、8GPUの性能が1,000CPUとほぼ同等の性能となった

　また違ったアプローチとして、演算とデータ転送のオーバーラップについても紹介。CUDAのアーキテクチャは演算とデータ転送を非同期に行なうことが可能になっている。空間を分割した場合に別のGPUが参照しなければならないデータは、空間の端のほうなどに限られるわけで、そこを先に計算してデータ転送を開始。データ転送が行なわれている間は、そのGPUで独立して処理可能な範囲を演算していくことで、データ転送のボトルネックを隠蔽するのである。これを行なうことでCPUとGPUの差がさらに広がることが紹介された。

CUDAでは演算とデータ転送を非同期に行えるアーキテクチャを備えており、CUDA Streamと呼ばれる	別のGPUとデータ交換が必要な範囲を先に計算しデータ転送を実施。データ転送中に単一GPUで独立して計算可能な範囲の処理を進めることで、データ転送のレイテンシを隠蔽する	Infinibandで接続されたTSUBAMEでテストした結果。GPUが増えても、リニアに近い性能の伸びを示していることが分かる
オーバーラップを行った際のCPUとGPUの比較。先の比較よりも差は広がっている	樹枝状凝固成長と呼ばれるモデルのシミュレーションの結果も紹介	樹枝状凝固成長を複数GPUで処理した際の性能。実線がオーバーラップを行なった場合の結果で、サイズが大きい問題で効果を見せている。サイズが小さいときの実線が途中で頭打ちになるのは通信が完全にボトルネックになってしまうためで、点線は絶対的な性能は低いものの、通信レイテンシを隠蔽していないのでそうした極端な頭打ちは発生していない
計算時間をより詳細に見た結果。GPUの数が増えるごとに計算時間は減るが、データ通信の時間はほぼ一定。そのため、GPUの数が増えたとき、どこかのタイミングで通信がボトルネックとなって、それ以上は性能が向上しないという転換点がある

　ちなみにGPU処理のメリットとしてもう1つ挙げられたのが、消費電力の低さである。1GPUはせいぜい200W程度。さまざまな手法を駆使してGPUがCPUの100倍の性能を出せるケースを想定し、TSUBAMEにおける100GPUと1,000CPUで比較すると前者が20kW、後者が1,000kWと、50分の1の消費電力で済む。ちなみに青木氏の研究室では、実行する関数ごとに消費電力を調べるなど、かなり詳細にテストを行ない、グローバルメモリへのアクセスがかなり大きな電力を消費することが分かっているという。

　このTSUBAMEは来年リプレースの予定。GPUへの依存度をより高め、3PFLOPSのピーク性能を持つスパコンへと生まれ変わる予定だ。青木氏はこのリプレースについて「来年の今ごろはきっと大騒ぎになってるはず」と述べている。

　この研究のきっかけとなった津波シミュレーションについても紹介があった。気象庁が出している津波警報は、過去のデータベースを参照する方式となっている。地震が発生したら、過去の事例と照らし合わせて、一番近い事例を参考に警報を出すというものである。これでは高い精度は期待できない。過去には2mの津波が来るというのに実際には20cmしか来なかった、といったことも珍しくなく、最近は津波の高さを予報として発表することもなくなっているという。

　CFDを用いた津波シミュレーションの目的は、地震が発生したあとにシミュレーションを行ない、海岸に到達するまでに計算を終わらせ、警報を発するというもので、高い精度が期待される。海岸で起きた地震はともかく、津波が発生して海岸に到達するまでには多少の時間があるので、地震発生から5分で計算を終わらせるのを目標にしている。デモが行なわれたのは512×512の格子のもので、CPUに対して62倍ぐらいの性能になっている。

　とくに目標となっているのが、昔から津波の被害が多い三陸沖のエリアをシミュレートすることで、400×800kmを100mごとに分割して4,000×8,000のメッシュとして計算すというもの。広大な領域であるため1GPUでは無理であり、これを実現するためにはマルチGPUによるCFDが不可欠なのである。

GPU処理における消費電力面でのメリットを示したスライド	津波シミュレーションの目標。右が日本で津波の被害が多い三陸沖のエリアを想定したもの。左はスマトラ沖地震をシミュレーションで必要なエリアを示している

　スクウェアエニックス研究開発部の藤井栄治氏が説明したのは、同社が開発を進める開発環境へのCUDA適用である。3Dゲームの高クオリティ化が進む一方で出荷数は伸び悩んでいる。開発コストだけがかかる状況を打破するために、高速なマシンとプログラミングによって、作業量(手数)を増やさずに高クオリティなものを作りあげようというコンセプトのシステムだ。

　とくに同氏が強調したのは、プログラミングによって出てきた結果が、そのまま使えるような自然なものであることが重要という点である。計算によって出てきた映像に修正を加えようと思うと、やはりコストがかかる。例えばモーションキャプチャの修正を自然に見えるようにする、といった作業はとくに手間とコストがかかるものだという。

　同氏が開発を進めるのは、「WORLD」と呼ばれる開発環境。今回はこのうち、グローバルイルミネーション(GI)レンダラであるORANGE、汎用モーションデータセット、モーション自動生成の3つについて説明がなされた。この3つにCUDAを適用済み、もしくは今後適用を考えているからである。

スクウェアエニックス 研究開発部 デベロップメントディレクターの藤井栄治氏	開発環境のプロジェクト「WORLD」の全体図。今回は黄色で示された箇所の説明がなされた

　GIレンダラのORANGEは、昨年の今ごろから開発を開始。それ以前にCPUで実行していたときも十分に高速だったが、GPUを使ってさらに高速化したという。基本的にはMAYAからエクスポートされたデータをGPU上でGIレンダリングしていく。

　現在までにレイ・三角形の交差判定、基本的なマテリアル、フォトンマッピング、ヘア・ファーなどが実装されており、GIベイク、ボリュームレンダリング、モーションブラーはプロトタイプにある。

　そして、将来的にはプロシージャルテクスチャの実装も考えているという。プロシージャルテクスチャとは、テクスチャを自動生成する手法のこと。単純に手書きのテクスチャを使い続けていくと高クオリティ化する一方のゲームにおいて膨大な量が必要になる。自動生成することで使用するメモリの抑制が可能となる。これは理論は出来ており、今後実際の開発を進めるとのことだ。

　いくつかのサンプルも提示された。Mental Rayでは20分もかかる処理が6GPUを使って30秒で終了するといったレイのサンプルや、他のソフトではメモリオーバーで計算できないようなファーレンダリング、開発中のボリュームフォグやモーションブラーの画面が紹介されている。

ORANGEの実装状況。プロシージャルテクスチャは注目を集めている手法で、将来的な実装が予定されている	ORANGEを使うとCPUに対して6倍の性能を出せる。6GPUを使った場合は30秒でレンダリング可能で、これをMental Rayで実行すると20分はかかるという

　モーションに関する2つの仕組みは、ノンキーフレームアニメーションを生成するのが1つの目的となっている。キーフレームを作っていく作業の手間を軽減するためで、ここで紹介された汎用モーションデータセットやモーションの自動生成は、1万～10万に及ぶ群衆アニメーションや、キャラクタのボディアニメーションに適用していきたいとしている。

　汎用モーションデータセットは、基本的な動きのひな形を作っており、ここからモーションを生成していくというものだ。従来のモーションキャプチャでは、ちょっとした動きの違いでモーションキャプチャをやり直すという手間のかかる作業を行なっているという。

　そこで、同社のこれまでの履歴から、よく使う動きを選定して、ひな形のライブラリを作成。そのひな形を補間合成して動きを生成することで、PCの上でモーションキャプチャを行なうような環境を作るのがこのツールの役割となる。手足の長さや身長、体格、感情などを合成することで、さまざまなキャラクタの動きを作り出せる。

　モーションの自動生成については、この汎用モーションを利用し、周囲の環境や状況に合わせてモーションを作るというもの。人間や物体との生得、感情の変化、爆発や火事といった事象に対する反応などを含めてモーションを自動生成する。デモでは階段と傾斜を歩行するキャラクタのモーションを自動生成したサンプルが紹介された。

　このモーションに関する2つの仕組みは現状でCUDAは使われておらず、現在実装が進められている状況とのこと。また、WORLDについて、今回は来年3月までの予定が示されているが、すでに5年先程度までは計画があるという。

ファーレンダリングのサンプル。ほかのツールではメモリオーバーになる規模のグラフィックスを、GPUを使って90秒で処理	その足の部分を拡大しても、すべての毛に対してエフェクトが適用されていることが分かる。これも約90秒ほどでレンダリングされているという
ボリュームフォグやモーションブラーもORANGEでレンダリングできるよう開発が進められている