Sony Computer Entertainment America、Platform Research Manager、David Coombes氏

会場：San Jose McEnery Convention Center

　「Game Developers Conference (GDC) 2006」では、PlayStation Universityと題されたプレイステーション 3(PS3)のゲームソフト開発者向けの基本情報開示セッションが行なわれた。

　このセッションから垣間見られた、PS3の性能を考察すると供に、PS3時代のゲームの可能性について考えてみたい。

■ PS3システムで指揮者を務める「PPE」とは

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

　PS3のCPU「CELL」プロセッサは1基の「PowerPC 970」互換コアであるPPE(Power Processor Element)と、7基の128ビットSIMDベクトルプロセッサSPU(Synergistic Processing Element)を1コアにまとめた非対称型マルチコアCPUだ。

　PPEはPowerMac G5のCPUとして知られるIBM PowerPC 970(G5)と完全互換の命令セットを備えたプロセッサで、2ウェイのハードウェアマルチスレッディングに対応したインオーダー(In-Order)型スーパースカラ・アーキテクチャとなっている。

　PowerPC 970は命令実行にアウトオブオーダー(Out-of-Order)式に対応しており、命令間の依存性がない場合に順不同で命令を実行するような仕組みを持っているがPPEにこうした機構は盛り込まれていない。PowerPC 970“互換”であって“相当”ではないのだ。

　ちなみに「PowerPC 970“互換”」、「2ウェイ・ハードウェア・マルチスレッディング」、「インオーダー型」という特徴はXbox 360のCPUである「PX」と全く同じだ。なお、CELLのPPEとPXはIBMを父親とした異母兄弟CPUと言ってもいいかもしれないが、“双子ではない”。

　両者はパイプラインのステージ構成が若干異なっており、また、Power系CPUの特徴である128bit SIMD命令用コプロセッサのVMX(Vector Multimedia Extension)が、PXではベクトルレジスタが32本から128本へと増設され、3要素ベクトル同士の内積演算(DP3)関連の命令などの新設といった独自拡張が行なわれている。

　L1キャッシュは命令用が128バイトライン長の2ウェイ・セットアソシエイティブ方式で32KB、データ用が128バイトライン長のライトスルーのみの4ウェイ・セットアソシエイティブ方式で64KB。L2キャッシュは128バイトライン長の命令/データ統合型8ウェイ・セットアソシエイティブ方式で512KBでハードウェア・コヒーレントのライトバック対応型だ。命令実行形態がインオーダー型限定という仕様はやや古くさいイメージがあるが、キャッシュシステムはPC用の最新CPUと比較しても見劣りはしない。

　PS3システムにおけるPPEの役割としては、PS3-OSの実行や各種ハードウェアリソースの管理の他、ゲームの進行を司るゲームロジック(ゲームループ)の実行などが挙げられている。特に後述のSPEの動作管理はPPEの最重要任務とされる。

　メインメモリはMIC(Memory Interface Controller)と呼ばれるメモリインターフェイスを介してRambusの3.2GHz動作の256MBのXDR DRAMと接続される。セッションでは各記憶リソースへのアクセスの際のレイテンシーも公開された。

・レジスタ：1サイクル
・L1キャッシュ：8サイクル
・L2キャッシュ：32サイクル
・メインメモリ：140サイクル

　PPEは高クロック動作の最新のモダンCPUであるがゆえに、メインメモリとのレイテンシーギャップは増加していることを指摘。PPEプログラミングではキャッシュシステムの理解と徹底利用が必要不可欠とした。

　また、PPEのハードウェア・マルチスレッディング機能の活用がPPEのパイプラインストールやメモリレイテンシによりパフォーマンス低下を抑える手段であることも指摘。たとえば、ある一固まりのデータに同じ処理を適用する場合はデータセットを2つに分けて、2スレッドにて処理した方が速くなるという具体的なアドバイスも飛び出した。こうしたケースでは、片スレッドがメモリアクセスでストールしている場合にもう片スレッドが動ける可能性が増えるのに加え、ほぼ同ルーチンを2スレッドで実行することになるのでL1命令キャッシュの利用率も高くなって命令フェッチ速度も速くなる。

　意地悪な言い方をすれば、こうでもしないとPPEのパフォーマンスは稼げないと言うことでもある。そう、アウトオブオーダー未対応のツケはプログラムデザイン・テクニックでカバーせよ、というメッセージでもあるわけだ。

PS3のブロックダイアグラム	PPEはCELLプロセッサの「指揮者」的存在である

■ PS3に潜む働き者の小人さん達、それが「SPE」

SPEのダイ写真。これがCELLには8基(実稼働は7基)搭載されている

　PS3のCPU、CELLプロセッサに含まれるSPEは、前述したように128ビットのSIMD型ベクトルRISCプロセッサであり、PS3の場合は7基が実稼働する。製造段階では8基なのだが、製造不良のために一基が使えなかった場合にも、PS3のCPUとして利用できるよう、歩留まり率を向上させるために「7基」仕様としている。

　さらに今回のセッションでは「6基のSPEがアプリケーションで利用可能」と報告された。

　さらに1基歩留まり向上のために減らされたのか……というとそういうことではなく、7基のうち1基はOS/システム側で利用されるためにリザーブされているために、こうした言い方になったのだ。

　SPEは128ビットSIMD型ベクトルRISCプロセッサと前述したことからもわかるように、(x、y、z、w)のような最大4要素の32ビット浮動小数点からなるベクトル演算に特化したアーキテクチャとなっている。ということは3Dグラフィックスのジオメトリ処理、映像や音声のコーデック処理に向いていることになるが、実際にはC/C++のフルスペックプログラミングが可能で、高度な構造プログラミングが可能となっている。かなり大胆なたとえ方をするならば超ミニゲーム程度ならばSPE1基だけで動作させることも可能だろう。

C/C++でプログラミングが可能でPrintf、Mallocまでを含む標準ライブラリもサポートされる

　フルスペックC/C++が動作することからもわかるように、動的な条件分岐/反復処理にも対応するが、SPEは分岐/反復履歴の管理機構を絡めた予測分岐機構を持たないため、分岐ミスはSPEのパフォーマンスにクリティカルに響くとしている。

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

　メモリ管理の仕組みが特徴的で、L1やL2といったキャッシュシステムは存在しない。256KBのローカルストア(Local Store)というメモリ空間があり、これがSPEにとってのメインメモリとなり、一般的なCPUでいうところのL1キャッシュ相当の速度で動作する。

　SPEは基本的にはこのローカルストアにプログラムとデータの両方を入れ込んで動作することになり、メインCPUともいえるSPEのリソースやメインメモリからは、論理的には切り離されて動作する。なお、128個もの128ビット長の汎用レジスタファイルが用意されており、データの一時記憶領域としてはフルスピード動作するこちらを利用する。

　もちろんSPEからの256MBのXDR DRAMメインメモリに対する読み書きは可能だが、MFC(Memory Flow Controller)と呼ばれるメモリコントローラ内のDMA(Direct Memory Access)ユニットを介してバルク単位(複数個)のアクセスが基本となる。つまり、いわゆる通常のCPUのメインメモリアクセスとは異なり、多大なレイテンシ(非公開)の発生を覚悟して行なう必要がある。

　実際の動作形態は、PPEがSPEに対してプログラムとある程度まとまったデータをDMA経由で渡し、SPEはプログラムを実行し、終了したらその結果をPPEにDMA経由で戻す……という感じになる。演算処理させたいデータがローカルストアの容量を超えている場合は、SPEがPPEと連携を取って、処理したデータをDMAを介してメインメモリに戻し、新しいデータをDMAを介して受け取ってそのデータ処理に取りかかるといったパイプライン構造を形成すればいい。もちろん、データセットを分割して同一プログラムを複数のSPEに実行させて、並列処理をかけて実行効率を高めることも可能だろう。

　まとめると、SPEは、プログラムとデータがローカルストア容量である256KB内に収まり、プログラムは複雑な分岐構造を持たず、大量のデータに対してベクトル演算を行なうのに適したプロセッサである、ということになる。

7基のSPEのうち1基がシステムリザーブ。アプリケーションで利用できるのは6基	ローカルストアがSPEにとってのメインメモリ。メインメモリとはDMAを通信役にして持っていったり取ってきたりというイメージ	SPEは自分の仕事を集中して行なうのが得意。メインメモリへのランダムアクセスは禁じ手

■ PS3のグラフィックスチップ「RSX」の性能は十分なのか

PS3のグラフィックスチップRSXはGeForce7800GTXベース

　PS3のグラフィックスチップ「RSX」は公然の秘密としてNVIDIA GeForce 7800 GTXベースであることが知られているが、一般向け情報開示の機会としては今回、初めて内部アーキテクチャについての言及があった。

　RSXは改めてNVIDIAのGeForce 7800……NV47(G70)ベースであることが言及された。24基のプログラマブルピクセルシェーダと24基のテクスチャユニットを内包し、これが550MHzで駆動される。既にNVIDIAは、650MHzで動作するG70の後継のGeForce 7900 GTX(G71)を発表しており、RSXはPS3発売前に旧世代アーキテクチャのGPUとなってしまったのが残念ではある。

　プログラマブルシェーダは現在PCの現行仕様である3.0仕様(以下SM3.0:Shader Model3.0)に対応し、浮動小数点(FP)レンダーターゲットにも対応する。G70ベースであることからFPレンダーターゲットのアンチエイリアス機能は無いと推察される。

　ビデオメモリはデータレート1.4GHz(700MHz駆動)のGDDR3 SDRAM 256MBで、これがRSXと128ビットバスで接続される。NVIDIAのG70/G71は256ビットバス接続であり、RSXの帯域はのその半分であるのが不安材料だが、SCEは最大1,920×1,080ドットのプログレッシブ解像度である1080pのレンダリングにまで対応できるとする。実際にGDCに参加していた各国の開発者達のコメントを聞くと「シェーダフルに使って1080pはちょっと厳しいと思う」という声が多く、「グラフィックスに重きをおいたタイトルでは、1,280×720ドットの720pでレンダリングして、出力として1080pや1080iをサポートするパターンが多くなるのではないか」という具体的な実装を予測する開発者もいた。

■ OpenGL ES2.0は間に合わなかった……結局、独自路線で行くPS3!?

　PS3のグラフィックスのプログラミングモデルに関するアップデートも行なわれ、「PSGL」と「libgcm」という2タイプが用意されることがアナウンスされた。

　libgcmはRSXをハードウェアレベルで叩くためのローレベル・ライブラリで、自らグラフィックスエンジンを設計する場合や、よりRSXネイティヴなグラフィックス制御を行なうために利用する。自らのゲームエンジンと統合的な実装を図ることで最高パフォーマンスが得やすいが、高度な知識とそれなりの開発期間が必要になる。大手スタジオなどにおける開発期間を長期にとったビッグタイトルなどを除けば、当面のPS3のグラフィックス開発の主流はPSGLの方になるはずだ。

　PSGLはOpenGL ES1.0に、RSXをフル・サポートするための拡張が盛り込まれたスペシャル版だ。

Khronos Groupチェアマンを務めるNeil Trevett氏。元3DLabsで、現NVIDIA。NVIDIAではVice President Embedded Contentを務める	PS3のソフトウェアブロックダイアグラム

　もともとPS3のグラフィックスモデルはOpenGL ES2.0になるといわれていたのだが、結果的にいえばそうはならなかったわけだ。「スペシャル版」というと聞こえはいいが、OpenGL ESというオープンプラットフォームの仕様から外れた独自仕様ということになり、賛否はある。ただ、これはSCEとしてはPS3の発売時期とOpenGL ES2.0の正式リリースとのタイミングを考えると致し方ない裁定なのであった。

　RSXはSM3.0対応GPUであり、SM3.0をフルサポートするフル版OpenGL 2.0は既に2004年に発表となったが、その組み込み向け版となる(……実質的にPS3のグラフィックスに対応するはずだった)OpenGL ES2.0は2005年には暫定仕様が発表されただけでファイナライズされなかった。ファイナライズされなかった理由は不明だが、PS3のゲーム機として必要になるグラフィックスAPIのコンセプトと一般的な組み込み機器のための標準グラファックスAPIであるOpenGL ESとの折り合い点がうまく付かなかったためと推察される。

PSGLの拡張点一覧

　いずれにせよ、結果的にSCEは、OpenGL ES2.0の採用を断念し、既に仕様が確定しているOpenGL ES1.0に対して独自仕様拡張を行なった「PSGL」を自ら生み出すことにしたのだ。

　OpenGL ES1.0に対する拡張点は、同一モデルの効率化レンダリングに貢献するインスタンシングや、NVIDIA系GPUの特徴的な機能となっている頂点テクスチャリング(VTF)のサポート、マイクロソフトDirect3D 9.0の機能として標準採用されているステンシルシャドウボリューム技法をアクセラレートする2サイドステンシル機能などなど、多岐に及ぶ。イメージとしてはOpenGL ES1.0でサポートされる要素以外の、RSXの機能のほぼ全てを拡張仕様の形で実装した感じだ。

　OpenGL ES1.0は携帯電話やハンドヘルド機を想定したごく基本的な固定パイプラインをサポートするAPIであるが、PSGLがOpenGL ES1.0ベースであるということは、OpenGL ES1.0の範疇で開発したド派手なグラフィックスを活用しないカジュアルゲームであれば、PS3への移植は非常に容易ということになる。あるカジュアルゲームタイトルを携帯電話からPS3に渡って透過的にネット配信しようというベンダーにとってはPSGLがOpenGL ES1.0ベースというのはありがたいことかもしれない。

　一点、不思議に思え、物議を醸しそうなのはPSGLの標準シェーダ言語についてだ。

　OpenGLプラットフォームのシェーダ言語といえばOpenGL Shading Language、通称GLSLなわけだが、PSGLはOpenGL系列でありながらこれを採用せずに、NVIDIAのシェーダ言語Cgを採用したのだ。

PSGLに採用されたCgはバージョン1.5でPC用のよりも1バージョン新しい

　OpenGL ES系においてシェーダ言語がサポートされるのはOpenGL ES2.0からであり、PSGL開発スタート時にこれが仕様確定していなかったため、RSXの設計を行なったNVIDIAの開発したシェーダ言語「Cg」の方を採択したのだ。

　Cgは、PCゲームの開発に広く活用されており、マイクロソフトのDirect3Dのシェーダ言語「HLSL」のベースになったものであり、こちらもコードサンプルが多い。また、Cgベースでシェーダ開発が行なえるNVIDIAのFX COMPOSERといったツールが使えるというメリットもある。さらにSoftImage|XSIのような各種3Dグラフィックス開発ソフトウェアにおいてもCgのサポートは手厚い。またRSXはNVIDIA設計なので、NVIDIAのノウハウが享受できれば必要十分であり、シェーダ言語の策定においてOpenGL ARBやMicrosoftと連携せずとも最新技術を即座に仕様に取り込めるという、足回りの軽さもSCEにとってメリットとして映ったようだ。

OpenGL ES2.0のプログラミングパイプライン

　さて、気になるのはPSGLが将来的に、OpenGL ES 2.xと協調できるかという点だ。これについては、可能性はないとは言えないがそうなると断言できる状況でもないらしい。プログラミングパイプラインは全くOpenGL ES2.0と同じだがその実装形態が異なるため、そのままではOpenGL ES2.0準拠にはならない。対応するためには、GLSLのサポートをしなければならないし、その他の細かい独自拡張仕様をOpenGL ARBの要求に適応させる必要が出てくる。今の時点で言えるのは、「OpenGL ES1.0+独自拡張仕様」としてスタートしてしまったPSGLはこのまま進化を続け、OpenGL ES2.0への完全対応が必要と判断されたときはそうするかも……ということのようだ。

　もともとOpenGL ES2.0は現時点でも提供されていないわけだし、今年末に発売を予定しているPS3にとってPSGLのスタイルはこの動向の中では最適解であるとも言え、PS3のゲーム開発者にとっての不利益な要素は少ない。ただ、PS3を牽引車としてOpenGL ES2.0の発展を目論んでいたKhronosグループにとっては思わぬ誤算といったところだろうか。

OpenGL ESのロードマップ	OpenGL ES2.xとPSGLの関係は今後どうなるのか……

■ PS3の開発を支援するスキーマ、それがCOLLADA

COLLADAを利用することによりデータの透過性が向上する

　この他、PS3の開発では、開発規模が大きくなることが予想され、様々なツールにおいてそのデータセットの共用化とデータセットの管理のしやすさが課題となる。

　これに応えるべくSCEが開発したスキーマがCOLLADAだ。COLLADAは2005年にKhronosグループにその仕様策定の実行権がSCEより移管され、ゲーム開発だけでなく、様々なメディアアプリケーション開発の共通スキーマとして利用されていく見込みだ。

　何のことかわかりにくいと思うのでもうちょっと詳しく解説しよう。

様々なデータをXML言語で表現してデータの透過性を維持しようというのがCOLLADAのコンセプト

　ゲーム開発において、3Dグラフィックスソフトなどを使って3Dモデルやシェーダを作成した際、そのデータを別のソフトで利用しようとしたり、あるいは実際のゲームエンジンに実装しようとしたときには、そのデータ構造の理解が必要であり、市販のコンバータソフトを自前でコンバータを制作して用意しなければならない。

　COLLADAではゲーム開発を取り巻く、3Dグラフィックス、物理、アニメーションといったデータセットに対して、業界共通のパラメータ名やデータ構造をXML言語の形で規定していこうというものだ。 　XML言語なので、データは全てテキストであり、可読性が確保される。最終的なゲームへの実装ではバイナリに変換することになるだろうが、開発途中では、こうしたテキストベースでデータをやりとりすることで、データの一部変更によるカットアンドトライもやりやすくなる。また、オープン仕様なのでコンバートの開発にライセンシーも発生せず、なおかつ自前のコンバータも作りやすい。異なる開発チームへのデータの共有や流用も各段にやりやすくなるのだ。

　COLLADAは当初3Dグラフィックスのデータセットのために提唱されたが、2006年1月にリリースされたばかりの最新COLLADA 1.4では、シェーダのやりとりのためのCOLLADA FX、物理のためのCOLLADA PhXといったものまでが組み込まれている。

最新のCOLLADA 1.4。現在、COLLADAのプロジェクトではサウンドのデータを取り扱うための共通仕様について検討しているという	既に主要の3Dグラフィック開発(DCC:Digital Content Creation)ソフトがCOLLADAを利用してエクスポート、インポートが可能となっている
シェーダ開発ツールFX COMPOSERもCOLLADAに対応。ここで開発したシェーダをDCCソフトに取り込むこともできる	最新COLLADAでは物理ミドルウェアのデータセットのやりとりも可能

■ まとめ～PS3は幻想か現実か

　PS3が、あまりにも急ピッチなスケジュールで推し進められていることが、先日開催された「PS Business Briefing 2006 March」で明らかとなったが、それだけに競合やサードパーティからは「PS3は幻想だ」という陰口が叩かれることもしばしばだ。

　これに応えるべく、SCEでは、コンプリート・ゲームエンジンとしてEPICのUnreal Engine3.0の存在や、活用が難しそうなSPEを効果的に駆動するための物理ミドルウェアとしてHavokやAGEIA PhysXが用意されていることをアピールした。

　すでに2,900台もの開発キットが昨年夏よりリリースされていること、そして100社以上の開発チームがタイトル開発に向けて動き出していることを告げて、PS3が「現実」のものであることを強調した。

　次回は、実際にPS3が、どの程度のパフォーマンスなのかという視点に立ったレポートをお届けする。

豊富なミドルウェアの存在がPS2の時とは違う	EPIC GAMES、Founder and Presidentであり、エンジンのアーキテクトも務めるTIM SWEENEY氏。EPIC GAMESのUnreal Engine3.0はこのレベルの映像がリアルタイム表示できる次世代ゲームエンジン。PS3とXbox 360の両方をサポートするのも特徴
展示会場にはPS3開発機が10台近く展示されており、開発機が多数用意できていることをアピール		PS3は「現実」に向けて走り出した……のか? 答えは2006年末に出る

□Game Developers Conference(英語)のホームページ
http://www.gdconf.com/
□Game Developers Conference(日本語)のホームページ
http://japan.gdconf.com/
□ソニー・コンピュータエンタテインメントのホームページ
http://www.scei.co.jp/
□「PlayStation」のホームページ
http://www.playstation.jp/
□関連情報
Game Developers Conference 2006 記事リンク集
http://game.watch.impress.co.jp/docs/20060324/gdclink.htm
「プレイステーション 3」記事リンク集
http://game.watch.impress.co.jp/docs/backno/news/ps3link.htm

(2006年3月29日)

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