「God Of War（GOW）」シリーズは、これまでに「GOW」と「GOW II」がPS2で発売されているアクションゲームで、特に欧米で人気の高いタイトルだ。その主人公クレイトスは、スキンヘッドの上半身マッチョという風貌ながら、欧米ではプレイステーションファミリーのアイコン的キャラクターとして認知されているほど。

セッションの様子

　ゲームプレイの楽しさはもちろんのこと、シリーズを通して一貫した過激なバイオレンス表現と、ハードウェアスペックの限界に迫るグラフィックス表現が人気の根幹となっている。

　昨年は、「GOW」の直前のストーリーを描いた外伝的作品「God of War：Chains Of Olympus」がPSPで発売され、こちらも大ヒットを記録。この作品はGDC2009 Game Developers Choice AwardsのBest Handheld Game賞を受賞するなど、評価が高い。現在は最新作の「GOW III」をPS3向けに開発中。

　GDC2009では、この開発中の「GOW III」におけるプログラミングテクニックが「Practical SPU Programming in God of War III」と題したセッションで披露された。

■ SPUは、CPUタスクとGPUタスク、両方の助っ人

　「GOW」シリーズは、どれもハイテク満載な出来映えで、テクノロジーリーダー的な作品として評価されてきた。今作「III」は初のPS3作品ということで、どんなテクニックが盛り込まれているのか、開発者たちからは熱い視線が寄せられている。セッションを聴講した結論から言えば、PS3におけるゲーム開発において、非常に堅実なアプローチのマルチスレッド・プログラミングを実装していたと思う。

Sony Santa Monica、Vassily Filippov氏	Sony Santa Monica、Jim Tilander氏

「GOW III」に限らず、一般的なゲーム処理の流れはこのような3フェーズからなる

　まず、語られたのは、ゲームプログラムの基本的な並列化アプローチについて。一般的なゲームアプリケーションでは、ゲーム進行やゲームルールを司る「シミュレーション」部、描画するオブジェクトのデータ収集や描画コマンド作成までの「シーン」処理、実際の「レンダリング」処理の3つの処理に分かれる。

　これを並列化する第1段階となるのが、ダブルバッファの概念の導入だ。ダブルバッファとはその名の通り出力先のバッファを2つにするもの。描画の場合にはレンダリング先のバッファをデュアル化することを意味する。あるフレームの描画を開始した直後から、次フレームのシミュレーションの処理を開始し、見かけ上、シミュレーションと1つ前のフレームのレンダリング（描画）をオーバーラップさせることができて、実質的にシミュレーション部の処理コストが隠蔽できる。

　CPUとGPUは個別に動けるので、最も基本的な並列化が実現される。だとすれば、CPUをさらにマルチコア化して、CPUで処理しているシミュレーション部とシーン処理部を2つのCPUに割り当ててオーバーラップさせて実行すれば、シーン処理の処理コストを隠蔽できる。これはちょうどCPUのパイプライン構造とよく似た考え方の並列化だ。

　ただ、各処理フェーズの処理時間は均等でない。シミュレーション処理とシーン処理が短くてもそこにオーバーラップしているレンダリングに時間がかかれば、それに足を引っ張られて、オーバーラップさせての並列実行が理想通りにはいかない。2人で一緒に歩こうとしても、速度の遅い同行者の方にペースが落ちてしまうのと似た理屈だ。

CPUとGPUとで処理をオーバーラップさせる最も基本形の並列化	マルチコアCPUならば、そのほかのCPU向けた宿毛オーバーラップできるはず	並列化してもうまくパフォーマンスが上がらないとき、並列化した作業のどれかが極端に時間が掛かっている可能性がある

　「GOW」チームが考えた、この状況の最もシンプルで短絡的な解決方法とは「処理時間のかかっている処理フェーズをなんとかして早く終わらせる」というきわめて単純なものだった。

　具体的にどうやるかというと、万能な「助っ人CPU」（Helper CPU）に、遅い方の処理を手伝ってもらって早く終わらせる。ではその万能な助っ人CPUとはなにかといえば、PS3においては「SPU」（Synergistic Processor Unit）だ。

そんなときは誰かに助けてもらおう	PS3にはCELLプロセッサのSPUがあるじゃないか

　SPUとは、PS3のCPUのCELLプロセッサの中に7基（8基のうち1基は歩留まり向上のために無効化）搭載された128ビットSIMD型RISCプロセッサのこと。本来はSPUと呼ぶ場合は演算ユニット単体を指し、ローカルストレージメモリを含んだ全体を指す場合はSPE（Synergistic Processor Element）と呼ぶが、最近はあまり区別なく呼ばれるようで、セッション中のスライドもSPUと記載されているので本稿もこれに倣うものとする。

　SPUは“コ”プロセッサ的に捉えられることが多いが、汎用プロセッサでありしかも、1つ1つが他のプロセッサ（メインプロセッサのPPU:Power Processor Unitや他のSPU）から独立して動作できる。

SPUは、コプロセッサではなく立派な汎用プロセッサである。しかも超高速な！

　「GOW」チームでは、GPUで実行される処理内容、PPUで実行される処理内容、それぞれをSPUでも処理できるように、SPUの処理モジュールを開発。特にPPUのコードはSPUのコードと極力コンパチにして開発し、負荷状況に応じてリアルタイムにPPU版コードとSPU版コードを切り換えて実行する仕組みを実装した。

　つまり「GOW III」では、SPUに対して決まり切った「SPUの得意そうな仕事」を固定的にさせるのではなく、PPUやGPUが担当している処理内容を、必要に応じてSPUが肩代わりできるように処理系を設計したのだ。そしてPPUやGPUの負荷状況に応じてSPUで実装された、そうしたPPU/GPU応援モジュールを支援に駆けつけさせるというイメージだ。

こうなっている処理を……	こうしてしまおうという方針。SPUに、CPUタスクもGPUタスクも手伝わせる。これが「GOW III」のSPU活用方針だった

「GOW III」においてSPUを助っ人に起用したモジュール一覧

　ところで本連載の読者ならば、GPUのアーキテクチャに「統合型シェーダー」（Unified Shader）という概念があるのを知っていることだろう。汎用シェーダーユニットはフリーランスとしておき、頂点処理に負荷が高ければそのフリーランスな汎用シェーダーユニットを頂点シェーダーとして起用し、ピクセル負荷が高ければ、より多くの汎用シェーダーを今度はピクセルシェーダーに割り当てていく。これが、統合型シェーダーのアーキテクチャだ。

　「GOW III」ではそんな感じに、その時点でのシステム負荷に応じてSPUを、PPU支援に向かわせたり、GPU支援に向かわせたりさせたと言うことだ。

　ちなみに「GOW III」において、SPUで実装したPPUやGPUの支援モジュールは以下のようになっている。

● シミュレーション部
アニメーション
布のシミュレーション
衝突物理シミュレーション
プロシージャルテキスチャ生成

● シーン処理
カリング（描画不要ポリゴンの切り捨て）
影生成
プッシュバッファ生成
その他のタスク

● レンダリング処理
ジオメトリ処理各種
サウンド処理

　イメージ的にいえば、「GOW III」では支援にやってきたSPUによって、マルチPPUになったり、マルチGPUになったりするというイメージだ。これはシンプルだが独創的なSPU活用方法だと言える。

各タスクがどのくらい時間を要したかを可視化するデバッグツールを開発。上がPPUタスク。下がSPUタスクを表わしている	ボトルネックを探し出し、SPUを助っ人に向かわせるようにプログラムをモディファイ・チューニング

■ 「GOW III」のSPU最適化回想録

　シミュレーション部、シーン処理、レンダリング処理の各処理系においての、特殊な最適化ケースについても語られた。具体的には、処理系によってはSPU専任タスクとしてしまったり、PPU専任タスクを残したりというような細かいチューニング的な振り分けの話だ。まずはシミュレーション部について。

　「GOW III」に登場する見上げるような巨大な敵キャラ「タイタン族」はまさしく動くゲームステージという感じで、その衝突判定処理は非常に高負荷でSPUでの支援が必要不可欠だったとしている。その巨大さ故に、相対的に小さい主人公へのカメラのズームインや、タイタン全体を捉えるズームアウトが頻繁に起こり、衝突判定用の形状モデルは、LODを駆使した低解像モデルで行なうのではなく高解像モデルで行なったため負荷が高くなってしまったようだ。そこで巨大なタイタンについての衝突判定は細かく分割してSPUに処理させる方策をとったとしている。この衝突判定の仕組みはレベルデザイナーやアーティストがタイタンが出てこないところ（例えば、絶壁に掛けられた縄ばしごなど）にも適用され、役に立ったと振り返っている。

タイタン族の衝突判定は分割してSPUに任せた

　布のシミュレーションについては、主人公クレイトスのスカートのほかにも無数の敵キャラの衣装に適用されるが、これらのシミュレーション結果は他の物理シミュレーションに影響を与えない、いわば独立した視覚効果用物理シミュレーションであるためリアルタイム性を必要としない。そこで、シミュレーション部の最初の頃に処理をSPUに依頼したあと、バックグラウンドでのんびりと実行させ、レンダリング開始時まで放置しておけるような実装にしたとしている。なお実行は、5基のSPUに発注するようにしている。

布のシミュレーションはゆったりとしたペースで処理

　シーン処理では、カリング処理のうち、視錐台内外チェック、表示モデルのリスト生成、可視/不可視ビット生成、遮蔽チェックなどはSPUタスクとして割り当てているが、遮蔽関係処理や可視ビット関連処理はPPUでも行なっている。

　シーン処理では、描画のための最終下準備ともいえるプッシュバッファ（メインメモリ側にGPUに実行させるコマンドリストを作成しておき、これを必要に応じてGPUに実行させる仕組み）の生成は当初はPPUで行なっていた。頂点バッファ設定、シェーダー定数、テクスチャ情報の設定、3Dモデルの取りまとめなど、膨大な数のポインタを渡り歩くようなデータ採集処理はPPUのL2キャッシュのスラッシングを引き起こし、パフォーマンスを引き下げてくれたため、こうした処理のSPU版は、小さな処理グループに分けてそれらを複数のSPUで取りかかるような処理系にしたとしている。

　また、あるモデル処理を行なっている間に並行して別モデルのフェッチを行なうようなダブルバッファDMAの仕組みを導入し、メモリアクセスコストの隠蔽を極力行なっている。このプッシュバッファ生成には5基のSPUで取りかかる実装としたが、デバッグ処理ではPPU版の処理系にスイッチできるようにしたとも述べている。これは、SPU版の処理系ではデバッグ用の処理系までがSPUのローカルストアに載らなかったためだ。

プッシュバッファ生成も基本的にはSPUで

　レンダリング処理では、不透明オブジェクトの頂点処理とそのライティングの負荷低減に取り組みそれらをSPUで処理するように設計している。ジオメトリ処理関連のSPU委任の定番と言えば、ソニー謹製のSPUベースのジオメトリ・プロセッシング・エンジン「Playstation Edge」（PS Edge）だ。「GOW III」では、頂点データはすべてPS Edgeで処理してしまい（≒SPUでの頂点シェダー処理）、PS3のGPU（RSX）に受け渡している。つまり、RSX側の頂点シェーダーは基本的に活用しない実装としたのだ。

　具体的な「GOW III」の頂点シェーダーのパイプラインは下図のようになっている。

「GOW III」の頂点シェーダーのパイプライン

「GOW III」では頂点シェーダーはSPUで代行。RSX側の頂点シェーダーは活用せず。実は、最近のPS3タイトルはこの実装が多い。RSXは評判が悪いが、SPU頂点シェーダーはすこぶる評判がいいのだ

　青いマスがPS Edgeをコールしているもので、緑のマスは「GOW III」オリジナルのカスタム頂点陰影処理になる。PS Edgeが採用する圧縮頂点データを解凍し、スキニング、カリングもPS Edgeを利用する。この後、頂点単位の法線ベクトル生成と、これを用いた特別な頂点単位のライティングは「GOW III」チームのカスタムメイドだ。これをRSXに受け渡す書式にまとめる処理をPS Edgeで行なって、頂点シェダー処理が完了する。なお、「GOW III」では、1描画コールあたりを1ジョブとし、およそ1フレーム辺り3,000個のジオメトリ・ジョブを発行しているとのこと。

　「GOW III」では、ピクセル単位のポストプロセスフェーズでもSPUを活用している。レンダリング後のフレームの各ピクセルからキューブマップを参照して色補正をする特殊なポストプロセスを「GOW III」では採用しているという。これはDefferred Shadingとか、あるいはキューブマップを活用した疑似的なイメージベースドライティング（IBL）のようなテクニックのようだが、主題はそこではなく、このポストプロセスに用いる動的なキューブマップの生成にSPUを活用したと述べている。シーン内の指定した場所から6面分の動的な環境マップをレンダリングするようなイメージになるが、これは6個のSPUを起用して生成しているという。こちらも布のシミュレーションの時と同じで、急がないタスクなので、実際にはSPUがあいているときにゆっくりと計算させているとのこと。

「GOW III」特製の色補正に用いるキューブマップ生成にもSPUを起用

■ 「GOW III」チームからPS3開発者へ贈る言葉

講演最後には、開発中の「GOW III」のデモ映像も公開。発売日は未定。オフィシャルサイトはこちら

　講演の最後にTilander氏とFilippov氏は、「GOW III」の開発経験から学んだ教訓を、これからPS3の開発に挑戦するデベロッパーに向けて述べている。

● 並列プログラミングを大前提としたPS3のポテンシャルを活かせ
　CELLプロセッサは非対称マルチコアプロセッサにカテゴライズされ、CELLプロセッサ内のメインCPUのPPUと、その配下のSPUは機能/スペックが異なる。確かにそうなのだが、「GOW III」チームの両氏はSPUを汎用プロセッサとして捉え、直面した負荷/ボトルネックをSPUによる支援で低減するような設計方針にすれば、難しそうな並列プログラミングも幾分か簡単になるのではないか、こう言いたいわけだ。

● 早まった最適化をするな
　「CELLプロセッサのパワーはSPUの活用にあり」。このソニー側のメッセージに囚われて、ゲーム設計の初期からSPUをどう活用するか悩むべきではない。「ユーザーのゲームプレイ体験をどう面白くするか」に注力してゲームを設計し、必要になったら最適化を考えればいい。こう両氏は述べている。確かにマルチプラットフォームでなくPS3専用でゲームを開発する場合にはこのアプローチは理にかなっているかもしれない。

● 速度を測れ
　SPUは、データをローカルストアに持ってきた後の処理がめちゃくちゃに高速。だから、一見速くなりそうにないやり方でもSPUで実装してみるといい。そしてSPUでの実行結果とPPU、GPUだけとの結果を比較してみよう。やってみる価値はある。これが両氏のメッセージだ。

　「GOW III」の開発においては、口悪く言えばSPUを行き当たりばったり的に活用していったわけだが、それでも十分な成果が得られたようだ。SPUはそういう使い方でも十分威力を発揮してくれるということを言いたいのだろう。

　非対称型マルチコアCPUであるPS3のCPU、CELLプロセッサは、確かにこれまでのメインストリームなコンピューター製品には無かったものだ。それだけに手強い印象があるし、非対称マルチコアCPUだから「非対称な特性を効果的に活用しなければならない」という先入観を開発者たちに与え、もっと言えばそうした強迫観念のようなものすらPS3からでていたように思う。

　「GOW III」開発チームは、こうしたCELLプロセッサのイメージをまったく気にせずに、SPUを汎用プロセッサとして活用し、そうした使い方として十分成り立つということをこの講演で主張してきた。

　まだ発売前のタイトルなので、彼らの今回の主張は、実際に発売された「GOW III」を触れてみるまでは信じられないかもしれないが、それでも「そういう発想もある」ということは広く伝えられたのではないかと思う。