早朝の技術系セッションでありながら多数の聴講者を集めた「CELL:A New Platform for Digital Entertainment」

会場：Moscone West Convention Center

　GDC2005、開幕3日目の3月9日、プログラミング技術系セッションの中ではもっとも聴講者を集めたと思われる「CELL:A New Platform for Digital Entertainment」が行なわれた。「CELLプロセッサ」は、SCEの次世代ゲーム機、仮称プレイステーション3(PS3)のCPUとなることがアナウンスされているため、プログラマはもちろん、各メディア関係者の聴講者も多かったようだ。

　既に姉妹メディアであるPC Watch連載中の後藤弘茂氏の連載記事にて、CELLプロセッサの概要は解説されているが、GAME Watchではソフトウェア(ゲーム)の見地でこのテーマについて整理してみたいと思う。

■ マルチコアってなに?〜対称型のXbox2、非対称型のPS3

　PS3のCPUとなるCELLは、1チップに複数のCPUコアをまとめたマルチコアCPUだ。マルチコアCPUは今やプロセッサ業界のトレンドであり、この流れが次世代プレイステーションにも波及してきた……ということができる。

　この流れは、単純な高クロック化でCPU性能を向上させるのが、段々と難しくなってきたことが大きな要因であり、PCのCPUの代表格であるインテルのPentium 4系でも、最近発表された最新のSmithfield(スミスフィールド)コアのPentium 4では1チップでデュアル(2基)CPU構成のアーキテクチャを採用することとなっている。

　マルチコアCPUの存在意義は、複数のソフトウェアを並列同時実行して、パフォーマンスを稼ごうという目的にある。仕事を1人よりも複数人で同時にやった方が早く終わる……という理屈と同じだ。マルチコアCPUのトレンドとは、つまり、1人の性能向上に限界が見えてきたので、人を増やそうという発想になってきたもの……と思えばいい。

　ちなみに、マイクロソフトの次世代ゲーム機、仮称Xbox2(以下Xbox2)もマルチコアCPUを採用することがほぼ確実視されている。

　PS3とXbox2、共にマルチコアCPUを採用することになるわけだが、そのアーキテクチャ、およびコンセプトの面で両者は全く違う。

　Xbox2のCPUはPowerPC970を3基(2基という説もあり)1チップ化したCPUで、同じポテンシャルを持つCPUコアを3つまとめたものになるといわれている。これは対称型マルチコア(Symmetric Multi-Core)と呼ばれている。

　一方、これに対し、PS3のCELLはPowerPC970にSPE(Synergistic Processor Element)と呼ばれる128ビットSIMDベースのRISCプロセッサを8基1チップにまとめおり、異なるタイプのCPUを1チップ化していることから非対称型マルチコア(Asymmetric Multi-Core)と呼ばれている。

　対称型のメリットはソフトウェアの開発が透過的でわかりやすいところにある。結局、同じCPUが複数個あるわけだから、そのCPU向けに作ったプログラムをそれぞれのCPUで動かせるわけだ。もちろん、処理結果の調停などの面で、効果的な性能を発揮するためには、それ相応の工夫が不可欠だが、すくなくともプログラム技法を複数ある各CPUコアごとに変える必要がない。

　これに対し、非対称型は、それぞれが機能が異なるプロセッサを内蔵しているため、そのプロセッサごとに適切なソフトウェアを用意しなければ最大性能が得られない。しかし、各プロセッサは特定分野に圧倒的な高性能を発揮できるため、適切に仕事を振り分けられた場合の最大性能は対称型を容易に上回れる。

　対称型は人間にたとえれば、「自分の分身が複数人いる状態」を想像すればいい。

　そして非対称型は「才能の異なる者を一堂に会してチーム編成させた」ようなイメージだろうか。

Sony Computer Entertainment US Research and DevelopmentのMark Deloura氏	同じく、Dominic Mallinson氏が壇上に上がった

■ CELLプロセッサの概要

CELLプロセッサのブロックダイアグラム

　図はCELLプロセッサのブロックダイアグラムだ。

　CELLは1基のPPE(Power Processor Element)と8基のSPE(Synergistic Processor Element)からなるマルチコアCPUだ……といわれているが、これを見てもわかるように、外部デバイスやメモリとのインターフェイス機能などなどチップセット機能的な役割までも兼ね備えており、いわゆるSOC(System on a Chip)に分類されるプロセッサである。

　PS3搭載時の動作クロックは発表されていないが、現在実験室レベルで4.5GHz以上で動作しているという点、4.0GHz動作時のパフォーマンス値が公開された点、Xbox2のCPUが3.5GHz以上という情報がリークされたことを踏まえると、3.0GHz〜4.0GHz当たりに落ち着く可能性が高い。

　メインメモリは米Rambus社のXDR DRAMに対応。このインターフェイス機能をもたらしているのがMIC(Memory Interface Controller)だ。その帯域は25.6GB/secと、最新のインテルPentium 4システムの3倍に相当する。とはいえ、メインメモリはグラフィックスプロセッサとの兼用になるUMAになる可能性が高いため、それを考えると手放しで喜べるほど高い性能ではない(GeForce 6800 Ultraでは35.2GB/sec)。

　外部デバイスとのインターフェイスは、これまた米Rambusの「FlexI/O」と呼ばれる最新のパラレルI/Oインターフェイス技術が採用されている。そのバス幅は96ビット、帯域は6.4GHz、データレートで76.8GB/secだ。NVIDIAからライセンスを受けたGPU(グラフィックスプロセッサ)もここに接続される。

　そして、1PPEと8SPEそしてMIC、FlexI/Oの各機能ブロックはEIB(Element Interconnect Bus)によって相互に結びつけられている。図では2本の環状バスが描かれているが、この図の通り、EIBは「リングバス」とよばれる巡回型バス構造になっている。各機能ブロックがバケツリレー的にデータを隣に受け渡すようなバス構造で、すべてを相互に直結したクロスバー接続よりも性能面では劣るものの、構造がシンプルであるため、コストや高クロック動作の面で優位性がある。なお、EIBは右回り左回りが2本ずつあり、この中を64ビットのタグと128ビットのデータからなる計192ビットのパケットがバス内を走っている。

■ PPEとは?〜CELLがオーケストラならばPPEは指揮者である

　PS3に内蔵されるCELLプロセッサはPPEと呼ばれるPowerPC970完全互換プロセッサと8基のSPEからなると説明したが、それぞれどのような「才能」を持っているのか。

　PPEは命令/データL1キャッシュはそれぞれ32kB、L2キャッシュは命令/データ統合型で512kBを搭載したPowerPC970(G5)完全互換の命令/2Wayのインオーダー型スーパースカラプロセッサだ。VMX(Vector Multimedia Extension：128ビット SIMD命令用コプロセッサ)まで内蔵しており、新設計コアという説明はあったものの、アーキテクチャ的にはほぼ完全にPower Mac G5のCPUと同じと考えてもらってもいい。ハードウェアレベルで2タスクのマルチスレッディングにも対応。しかも論理的に複数のマシンがあるかのように振る舞う「Logical Partitioning」という特殊なマルチスレッド動作モードも備えている。

　PPEは、いわゆる模範生的なCPUであり、開発元のソニー/IBM/東芝側ではあまりこういう言い方はしていないが、あえていうならばメインプロセッサという位置づけになる。

　このPPEの仕事は2つ。それはOSを動作させること、そして後述するSPEの動作を制御することだ。

　「1基のPPEと8基のSPEからなるCELLプロセッサが、もし1オーケストラだとすればPPEは指揮者に相当する」とは壇上に上がったDominic Mallinson氏の弁。

■ SPEとは?〜SPEの得意分野と不得意分野

SPEはメインメモリへのアクセス能力があるが、実際の処理の実行はLS上で行なう

SPEの実行パイプラインの詳細。2命令同時発行型のパイプラインだが偶数パイプラインが演算系、奇数パイプラインが制御系という明確な分かれ方をしているので、2命令同時実行をキープするためにはコンパイラ側での事前最適化が不可欠

　SPEは前述したように128ビットのSIMDベースのRISCプロセッサだ。

　PPEを上でメインプロセッサと称してしまったことから、「SPEはサブプロセッサなのか」という誤解を与えてしまったかもしれないが、今回の発表でも「SPEは汎用用途に耐えうる」と明言されたように、ソフトウェアの見地からはポテンシャル的にPPEと比較して劣る部分はほとんどない。条件分岐/反復もあるし、レジスタ数だって128ビット長のものが128個もある。プログラミング言語においてもフルスペックのC/C++が用意されるという。

　ただし、上でCELLを「才能の異なる者を一堂に会してチーム編成させた」とたとえたように、SPEはPPEとは才能的には異なる資質を持っている。

　まず、SPEの優れているポイントは、128ビットのSIMDベースということで、(w,x,y,z)のような4要素の32ビット浮動小数点実数からなるベクトル演算に特化しているところ。1サイクル当たり、この4要素ベクトルの積和算をこなすことが出来るので、ソニーは4.0GHz動作時のSPE1基あたりの性能を32GFLOPS(=4要素×2演算×4.0GHz)としている。ちなみにPentium 4を仮に4.0GHz動作させた時を試算すると16GFLOPS(SSE使用時)。CELLプロセッサはSPE1基の時点で同クロックのPentium 4の2倍の128ビットSIMD演算性能というわけで、CELL全体では256GFLOPS(32GFLOPS×8基)にもなるのだ。卓越したベクトル演算性能こそがSPEの“才能”ということができるだろう。

　逆にSPEが不得意としている部分もある。

　条件分岐/反復処理に関しては、分岐/反復履歴を管理する機能がなく、構造プログラミングが可能とはいっても、あまりプログラムの流れが跳んだり跳ねたりするソフトウェアの実行には向かないと言うことだ(逆にPPEの方はそうしたソフトウェアの実行に長けている)。

　また、SPEはCELLに接続されたメインメモリへDMAを介してアクセス能力を持つものの、SPE自身はメインメモリにあるソフトウェアを直接実行することはできない。SPE各自がもっている256KBのローカルストア(LS:Local Store)と呼ばれる自己メモリ空間にソフトウェアやデータを持ってきてからしか実行できないのだ。つまり、一度に256KBの規模を超える巨大なソフトウェア実行やデータ処理は行なえない。256KBを超える場合は分割してLSに持ってくる必要がある。

　まとめると、SPEには、あまり大きくはなく、しかも複雑な分岐構造を持たないソフトウェアにて、ベクトル演算をさせるのが適していると言うことになる。

■ PS3:CELLのSPEとPS2:EmotionEngineのVU、両者の相違点と類似点

　PS2のCPUであるEmotionEngine(EE)にはMIPSベースのメインプロセッサに加えて、Vector Unit(VU)と呼ばれるコプロセッサがあり、SIMDベースのベクトル演算を得意としていた。

　このため、CELLのSPEをEEのVUの強化版とたとえ、「CELLはEEの再来だ」と懸念する声もある(EEのVUはプログラミングが困難としてPS2登場初期、あまり評判がよくなかった)。

　これは、たしかにこれはある側面においては正しい。EEではメインのRISC-CPUに対してVUが独立並列動作できるモードがあったし、たしかにCELLのSPEにイメージは近い。

　SPEに幾ら汎用のRISCプロセッサのポテンシャルがある……とはいっても、OSを動かしたりリソースのマネージメントはPPEしか行なえないので、SPEにはサブというイメージがつきまとい、この点でもSPEはEEのVUを連想させる。

SPEとVUの相違点。大局的にみれば確かにSPEはVUの拡張版だ。いずれにせよ、CELLの最大性能を引き出すにはSPEの積極活用が欠かせない

　VUの独立並列動作モードの実行は、VU内のメモリに格納されたプログラムに限定されていた。SPEのプログラム実行がLSに限定されているので似ている感じもする。まあVUが16KBの内蔵メモリ、SPEが256KBのLSという容量的な違いもあるにせよ、それよりもSPEの場合はDMAを介してメインメモリ側とやりとりができる点が大きい。DMAと言う仲介人を挟むが、常に外側の世界への門は開かれており、実行できるソフトウェアのレベルも全然違う。

　また、VUのプログラミングがアセンブリ言語に限定されていたのに対し、SPEのプログラミングはフルスペックのC/C++が利用できるという点も大きな相違点だ。

■ SPE、3つの動作モード〜どんな処理系をどのモードで実行させるのが適切なのか

　そして、相違点と言うよりもSPEならではの新要素とも言うべきなのが、1基のPPE、そして最大8基のSPE、そしてEIBやメインメモリの全てを使って高度な並列動作をさせられる動作モードがCELLプロセッサには備わっている。CELLの真骨頂を発揮するにはこの動作モードの活用が欠かせないと言ってもいい。

　2月にCELLプロセッサが正式に発表されて以来、この部分については謎だったのだが、今回のGDCで初めて明らかにされた。

●ジョブ・キュー(JOB QUEUE)モード〜サブプロセッサ的な役割を果たす

　PPEがリーダーとなり、各SPEにプログラムコンテナを配り、これを実行させるモード。 　各SPEは配られたプログラムをこなし、結果をDMAを介してメインメモリ側に出力していく。

　PPEは、仕事を終えて暇になったSPEを見つけると次のプログラムコンテナを渡して今度はそれを実行させる。

　それぞれのSPEは、メインメモリからデータをやりとりするが、PPEや他のSPEとの連携は必要なく、とにかく自分の仕事に集中すればいい。

　各SPE間で同期処理の必要のない、独立性の高いソフトウェアを並列実行させるのに向いており、PPEのオーバーヘッドも少ないのがこのモードの特徴だ。

　このモードの弱点としてはプログラムの複雑性がLSの容量の256KBに限定されるという点が挙げられる。

　「PPE1人でやるのは困難な仕事」を「複数のSPE達に振り分けて同時進行にやらせる」のだが、「面倒見役のPPEが各SPEの結果を取りまとめる」事が必要な処理系ということで、具体的には大局的な物理処理やAI処理などが適していると言えるだろうか。

PPEがメインメモリからSPEのLSに対してプログラムを転送。処理に必要なデータのポインタも受け渡す	SPEは自分の処理結果をDMAを介してメインメモリへ書き戻す	このモードにいくつのSPEを割り当てるかは自在に設定できる。この図では、SPE3基に対し、PPEがプログラムタスクを振り分けている様子を図解したもの。ヒマとなったSPEに対し、すかさずPPEが仕事を割り振るイメージだ。もちろん、この際のオーバーヘッドは皆無ではない

■ セルフ・マルチタスキング(SELF MULTI-TASKING)モード〜独自のパイプラインを形成するために

セルフマルチタスキングモードの概念図。高い並列性を維持したまま動作できる点が特徴

　丁度オフィスの共有机の上に、上司(PPE)からの司令書が積んであって、これを各社員(SPE)が机の上から1つ掴んで自分の机に持ち帰って仕事としてこなす……終わったらその仕事結果を「次は誰々さんへ」という引き継ぎ先などを書いて共有机へ戻す……というようなイメージだ。

　なお、各SPEには、共有机(共有メモリ)上の仕事を取ってきたり、終わった仕事をどこへ提出するか……などの動作を記述したミニOS(カーネル)みたいなのを走らせる必要がある。このカーネル自身もユーザーがプログラムが可能だ。

　このモードでは、SPE動作にPPEがほとんど介入してこず、また、JOB QUEUEモードとは異なり、SPE側で動作させるプログラムの入れ替えがないため、PPEとSPEの両方を高い並列性を維持したまま動作できる。

　共有メモリを媒介にして、データを流れ作業的に複数のSPE間でバケツリレー的に処理するのが得意なモードであるため、複数のSPEを使ったオリジナルのパイプライン処理系を形成するのにも適している。

　ただし、各SPE用に、共有メモリ上のデータを管理調停する仕組みや、タスクスイッチまで実装したカーネルを組まなければならず、ソフトウェア的には複雑にならざるをえない。

　具体的な用途としては、例えば、ソフトウェアでテッセレータ(特定のメソッドに従ってポリゴンを分割する処理系)やLOD(Level Of Detail:視点からの距離に応じて3Dモデルのポリゴン数を増減する仕組み)を実装するのがいいかもしれない。テッセレータを務めるSPEが頂点を増減して共有メモリへ出力、続いてこのデータを頂点シェーダを務める別のSPEで透視変換や光源処理などを行なう……と言った具合に、だ。

■ ストリームプロセッシング(Stream Processing)モード

　ある1つのシーケンシャルなデータ列を複数のSPEを使って共同で処理していくモード。

　1つの流れ作業を複数人で共同してこなしていくようなイメージだ。

　このモードに参加する複数のSPE間にはある程度協調性が必要な点、動作そのものにPPEが介在してこない点……つまりはSPEプログラム自体が自発的にデータを処理していくという点で、セルフマルチタスキングモードに似ている。

　しかし、各SPEにほぼ同一のプログラムを走らせ、他のSPEの処理結果を待つ必要もなく、どんどんデータを取ってきては処理して出すという……データの逐次処理性を追求している点がこのモードならではの特徴だと言える。

　ある大量のデータを、最低限の遅延でリアルタイムに処理して出力していかなければならない……といった用途にこのモードは向いている。

　PPEが指揮を執らないので、PPEは自身の仕事に専念できると言うメリットがあり、セルフマルチタスキングモードと同様に高い並列実行性が期待される。

　このモードにおけるSPE側のプログラムは、「入れて出す」を主体とした単純な設計でよいため、セルフマルチタスキングモードよりも難易度の低いモードといえるかもしれない。しかし、あくまでデータ駆動ベースの処理系に限定され、高度なインタラクティビティを実現するようなソフトウェアの実行には適さないといえる。

　このモードが具体的にはどんな処理系に向いているかと言えば、モード名が指し示しているようにストリームデータの処理……ということになる。もっといえば、音声データの加工や認識処理、画像/動画データのエンコードやデコード処理などがこれに当てはまる。

　まとめると、このモードはいわゆるDSPやメディアプロセッサ的な役割を果たすためのモードということができるだろう。

　データの独立性が高いストリーム処理ということで、例えば3Dモデルのスキニング/変形処理……いわゆる頂点シェーダ的な役割もこのモードで行なうのが適しているかもしれない。

(1)各SPEが3つのデータ処理が出来ると仮定した場合のストリームプロセッシングモードの動作概念図。まずは、各SPEに入力データバッファから最初のデータを取り込む	(2)各SPEの入力データスロットはまだ空いているので開いているところに次のデータを入れる。その間、各SPEは、最初のデータを処理中
(3)各SPEに最初に入力されたデータは処理完了。処理完了したデータは出力データバッファに出力。と、同時に空いている3番目のデータスロットに入力データバッファからデータを取得	(4)今度は(2)の時点で受け取ったデータ処理が完了、出力バッファにこれを出力。(3)の時点で最初の入力データスロットは空いているのでここにデータを入れ込む。あとは、この繰り返し

■ その他のPS3情報〜PS3のグラフィックスパイプラインはこうなる!

OpenGL/ESは組み込み機器向けのOpenGL。これがPS3のグラフィックプログラミングAPIと正式アナウンスされた

　今回のセッションで、このグラフィックス周りのことはほとんど語られなかったが、

　・そのグラフィックス・プログラミングのAPIとしてOpenGL/ESを採用する
　・そのプログラマブルシェーダを駆動するシェーダプログラムにはNVIDIAのC言語ライクなシェーダ言語「Cg」を採用する

という2点を正式に発表した。

　もう他に情報はないかと、筆者はGDC会期中、OpenGL/ESなどの規格策定をつとめるKhronos Groupのチェアマンを務めるニール・トレベット氏に取材を敢行したところ、今年のOpenGL/ESのロードマップを見せていただけた。

Khronos Groupのチェアマンを務めるニール・トレベット氏	OpenGL/ESのロードマップ。PS3も採用するOpenGL/ES2.0は2005年夏発表予定

　OpenGL/ESの“ES”とはEmbedded Systemの略であり、「組み込み機器向け」の意がある。ちなみに、“ES”のない素の「OpenGL」はPCやワークステーション向けと言う位置付けだ。

　「組み込み機器向け」のOpenGLであるこのOpenGL/ESは、携帯電話、PDA、医療機器、工業機械、計測機器、ゲーム機など、PCやワークステーションのように潤沢なハードウェアリソースのない機械で3Dグラフィックスを取り扱うためのAPIとして規格策定が行なわれているのである。

　さて、今年登場する2つのOpenGL/ESのうち、「1.2」は固定パイプラインベースのグラフィックスを取り扱うものであるため、携帯電話やPDAなどの小型で小規模な機器をターゲットにしたものだといえる。

　対する「2.0」はプログラマブルシェーダベースのグラフィックスを取り扱うものであり、これがPS3に採用されたわけだ。

　トレベット氏によれば、「PS3は、1.2でもなく2.1でもなくOpenGL/ES2.0だ」とのことだが、OpenGL/ES2.0とはどのようなものなのか。

　基本的にはOpenGL/ESはOpenGLのダイエット版という位置づけで、特にOpenGL/ES2.0は、昨年夏に発表されたばかりのOpenGL2.0のダイエット版であることが明言されている。

　どこをどうダイエットしているかと言えば、過去の化石と化した機能や、固定パイプライン機能などの削除などが該当する。

OpenGL2.0のパイプライン。OpenGL/ES2.0もこれに準じたモノになる

　このブロック図を見ると分かるが、

　・頂点シェーダがテクスチャメモリにアクセスできる
　・ピクセルパイプラインの出力結果を頂点パイプラインに戻せる

という点から、OpenGL2.0(及びES2.0)は、マイクロソフトのDirectX 9.0cのDirect3Dとほぼ同レベルの機能をサポートしているといえる。そう、プログラマブルシェーダ3.0ベースのデザインまでをサポートしているということができるわけだ。

　PS3のグラフィックスもこの図の処理系に準じたものになると予測できるわけだが、OpenGLには独自拡張仕様というのがあるため、万が一、あまりにもPS3のGPUが特殊な機能を携えていた場合はこの仕組みを利用するかもしれない。PS3-GPUの機能がOpenGL/ES2.0の機能に制限されてしまう心配はないのだ。

シェーダプログラミング言語としてはNVIDIAの「Cg」が採用されることが明らかに

　まぁ、NVIDIA-GPUを最も効果的に扱えるのは、NVIDIA製プログラミング言語であることは自明の理なので、この点については別段驚くべきことではないといえる。

(2005年3月16日)

[Reported by トライゼット西川善司]