■後藤弘茂のWeekly海外ニュース■ GPU命令のx86体系への統合

●GPUのネイティブ命令セットの露出がカギ

　AMDは、2009年に投入するFUSIONプロセッサでGPUコアをCPUに統合しようとしている。しかし、FUSIONのポイントはハードウェア上でのGPUコアの統合ではない。その先に見える、命令セットレベルでの統合が、FUSIONの最大のポイントだ。AMDは、FUSION世代までに、GPUコアに、ソフトウェアがもっとダイレクトにアクセスできるように道を整えようとしている。

　それはGPUコアを、より汎用的なコンピューティングに使うためだ。

AMDのPhil Hester氏

　「いったんGPUが統合されると、GPUを汎用化して、より広いメディアプロセッシングや科学技術コードなどのかなりの部分を扱うことが可能になるだろう。グラフィックスだけでなく、より汎用的なアプリケーションを実行できるようになると考えている」とAMDのPhil Hester(フィル・へスター)氏(Senior Vice President & Chief Technology Officer(CTO))は語る。

　ビデオのエンコードに代表されるメディアプロセッシングや、物理シミュレーションのようなHPC的なタスク、データマイニングや音声などの合成などがGPUのアプリケーションとして期待されている。そのためには、GPUに現在よりダイレクトにアクセスできる方法が必要になる。

　では、AMDはFUSIONでは、GPU命令をどのような形態でビジブル(アクセス可能な状態)にするつもりなのだろう。FUSION世代のGPUプログラミングのオープン化のポイントは次の2つだ。

(1)GPUのネイティブ命令セットを完全にオープンにし、将来に渡って一貫性を維持するのかどうか
(2)GPU命令をx86命令セットアーキテクチャ(ISA:Instruction Set Architecture)に取り込むのかどうか

　現在のGPUは、世代毎にマイクロアーキテクチャを大きく変更している。そのため、GPUのネイティブ命令セットは、メーカー毎に異なるだけでなく、同じメーカーでもGPU世代によっても異なっている。GPUでは、ソフトウェア層でラップすることでネイティブ命令セットを隠蔽することを大前提としているから、こうしたモデルを採ることが可能だ。

　だが、こうした構造から、GPUへのダイレクトアクセスにも現状では限界がある。例えば、NVIDIAの「CUDA (クーダ:compute unified device architecture)」汎用プログラミングモデルの場合も、真にダイレクトというわけではない。グラフィックス用のDirectXなどよりも、薄く汎用的なランタイムソフトウェアをCPU上で走らせ、ダイレクトに近いアクセスを実現している。AMD(ATI)の「Close to the Metal(CTM)」のようにより低レベルで露出された場合も、その命令アーキテクチャが将来も継続されるかどうかが今1つ明確ではなかった。また、CPUのようにプログラミング情報が広く公開されているわけでもない。

　そのため、FUSIONではAMDがどんなアプローチを取るのかが大きなポイントとなる。

　もう1つのポイントは、GPUコアの命令セットを公開するとしたら、その命令セットをx86命令セットのフォーマットの中に取り込んでしまうのか、それとも独立した命令セットとして実装するのかという点。これもそれぞれ利点と不利点のトレードオフがあるので、難しい。

AMD Mobile Platform Roadmap(※別ウィンドウで開きます) PDF版はこちら

●GPU命令セットをビジブルにする

　AMDのFUSIONビジョンが優れているのは、これらのポイントについても、展望を持っている点だ。まず、2006年12月のAnalyst Dayでは、Hester氏はネイティブ命令セットの公開は明確にしている。

　「新たにネイティブモード命令セットを露出させると、アプリケーションがどんどんGPUの機能を使うようにリコンパイルされて行くだろう」

　また、Hester氏は2006年のインタビューでも答えている。

　「GPU機能を統合するなら、人々は(GPUコアに)もっとスタンダードな方法でアクセスしたいと考えるだろう。そこで、GPU機能を、ユーザーモード命令セットとして、適切にビジブルにすることができると思う。ビジブルなGPU命令を一貫性を持って将来にも提供する。それによって、x86アーキテクチャを、32-bitから64-bitへの前進の時と同じような方法で、前進させることができると私は信じている」(Hester氏)

　AMDは、方向性としてはGPUネイティブ命令セットの露出化へと向かっている。同じGPU命令セットを継続して提供・発展させることで、一貫したプログラミングモデルを提供しようとしている。従来のGPUとは明確な違いだ。

　このことは、GPUの方向性を大きく変える要素を持っている。というのは、従来のように命令セットの継続性を無視したGPUアーキテクチャの拡張ができなくなるからだ。CPUのように、命令セットの一貫性を保ちながら発展される方向へと、将来のAMD GPUコアは向かうことになりそうだ。つまり、GPUアーキテクチャの開発の手法が大きく変わるわけだ。

　その一方で、命令セットの一貫性が保たれることでソフトウェア層の開発が容易になる。あるGPU世代向けに開発したネイティブコードのソフトウェアが、そのまま将来のGPUでも走ることが保証されるからだ。コードの最適化も容易になる。

　そして、このことは次の命令セット戦争を予見させる。各社のGPUのネイティブ命令が異なっているため、例え全てのGPUベンダーが命令セットを公開したとしても、バイナリ互換性はない。そのため、アプリケーション側がGPUとネイティブ命令を使い始めたら、命令セット同士の戦いとなり始める。SSE対3DNow!のような命令セット争いが再び起こる可能性がある。しかし、今回は64-bit化でのx86-64(AMD64)対Yamhillの時にように、先行するAMDの側が有利になる可能性も高い。また、敵はIntelではなく、NVIDIAかもしれない。

●CPUのユーザーモード命令セットとして統合

　また、AMDのFUSIONでの命令セットのビジブル化では、CPUの命令セットアーキテクチャの中にGPU命令を取り込むことが適切だと考えていることもポイントだ。Hester氏のビジョンをもう少し詳しく説明すると次のようになる。

　「一般論として、コプロセッサの統合には2つの方法がある。1つは、CPUのユーザーモード命令セットアーキテクチャに統合してしまう方法、もう1つは一種のシステムリソースとして、デバイスドライバなどを経由して扱う方法。これらには、それぞれ利点と不利がある。

　まず、ユーザーモード命令セットの中に統合するためには、(CPUメーカーが)特定の機能とアーキテクチャについて、今後も発展させ続けることを(ユーザーに対して)正当化できなければならない。

　命令セットアーキテクチャに取り入れることの利点は、非常に低いオーバーヘッドコストでその機能を使うことができるようになること。一方、不利な点は、その命令を保証するなら、今後も常に(その命令で使える)機能をシリコンに入れ続けなければならないことだ。

　だから、統合するかどうかの判断は、非常に慎重に行なう必要がある。また、今後も、(統合するコプロセッサの)アーキテクチャを論理的に一貫性の取れた方法で進化させる必要がある。そうした条件が満たされれば、ユーザーモード命令セットに加えることを正当化できるだろう。

　場合によっては、正しい答えはTorrenza型のコプロセッサでのデバイスドライバ型構造となるケースもあると思う。特殊なアプリケーションがそのコプロセッサ命令でプロセッシングするものの、ベースアーキテクチャに命令を入れるほど正当化できないケースがあるだろう。そうした機能は、Torrenza型のコプロセッサで扱う要素の1つになると考えている。Torrenza型の場合は、デバイスドライバ型のストラクチャを通じて、ソフトウェアとコミュニケーションするだろう。

　どちらが適切かは、一種のティッピングポイント(Tipping Point:しきい値)の議論となる」

Non-Disruptive Software Transition (※別ウィンドウで開きます) PDF版はこちら

●GPUを命令セットレベルでCPUに統合して行く

　AMDは、どうせGPU命令セットを露出させるなら、x86のベースフォーマットの中に、ユーザーモードの拡張命令として組み込もうというビジョンを持っているようだ。これは、より基本的なレベルでのCPUとGPUの統合を考えていることを示している。このモデルでは、x86命令のストリームに組み込まれたGPU命令をデコーダがデコード、GPUコアに発行すると推測される。

　現在は、CPU上のランタイムがグラフィックス命令やGPU向け汎用命令をリアルタイムでGPUネイティブ命令に変換。変換の終わったネイティブ命令を、バスを経由してGPUに送り込んでいる。しかし、命令セットの統合後は、CPUの命令デコーダで直接GPUネイティブ命令がデコードされるようになる。その場合、最終的にはGPUコアは、CPUの中のGPU機能へと融合されて行くだろう。

　TorrenzaとFUSIONには、このようにオンチップかオフチップかという違い以上に、ソフトウェア面での違いがある。

　しかし、この構想では、ただでさえ複雑なx86命令セット体系をさらに複雑にし、その結果、命令デコーダの負担も増やすことを意味する。これは問題ではないのだろうか。

　「x86のユーザーモード命令セットフォーマットには、まだ十分なオペコードポイントが残されている。エクステンションで、命令を加えることが可能だ。また、命令デコーダは現状でもすでに複雑だ。だから、さらに複雑性を加えても、比較的小さい変化でしかない。エンジニアは十分に可能だと言っている。

　だから、我々は、この種の問題については、それほど心配していない。それよりも重要な問題は、どんな命令をユーザーモード命令セットに加えるべきかという点だ。いったん加えた(コプロセッサ)命令の機能は、常にサポートし続けることをコミットしなければならない。だから慎重に行なう必要がある」(Hester氏)

FUSION Processor Software Model (※別ウィンドウで開きます) PDF版はこちら

●x86 CPU側からは不可視のTorrenza型コプロセッサ

　AMDは、すでに複雑なx86アーキテクチャだから、それを拡張するなら問題はないと見ていることがわかる。実際、プリフィックス等で複雑化した可変長の命令セットは、現状でも命令デコーダにとってとてつもない重荷となっている。これを変革するには、x86命令セット自体を一新する以外の方法はない。それなら、現状の複雑度にさらにちょっと複雑性を加えても、大きな変化ではないという判断だと推測される。

　ただし、いったんサポートした命令は簡単に切り捨てられなくなってしまう。だから、x86命令セット体系に取り込む命令は、慎重に選ぶ必要がある。利点は大きいが、命令セットを統合できるコプロセッサは限られる。

　一方、Torrenzaのデバイスドライバモデルでは、オーバーヘッドはあるが、ソフトウェア的には容易な統合となる。コプロセッサ側の命令セットのフォーマットも、自由にできるという利点もある。例えば、コプロセッサではVLIW(Very Long Instruction Word)型命令セットを取ることもできる。

　「Torrenza型でデバイスドライバを経由する場合は、データは(ホストプロセッサから)コプロセッサにそのままパスされる。データフォーマットはコプロセッサ独自で構わないので、他との互換性について心配する必要はない。

　x86プロセッサ側から見ると、コントロールブロック(プログラム)は単にデータで、決してx86プロセッサ上で実行されることはない。(コプロセッサの)命令フォーマットやその他の要素は、x86プロセッサからは不可視で、コプロセッサからしか見えない。だから、コントロールブロックは、どんなフォーマットに定義することも可能で、コプロセッサとしてベストな設計にできる」とHester氏は説明する。

Continuum of Solution (※別ウィンドウで開きます) PDF版はこちら

●CPUとGPUの物理的な統合と命令レベルの統合の連携

　この場合、ポイントの1つはCPUとGPUのオンダイ統合が、命令セットの複合を意味するわけではないという点だ。単一ダイ上にまとめたとしても、両コアの命令セットをTorrenza型に別々に実装することはできる。システムオンチップ(SoC)アプローチで、単純にダイ上にCPUとGPUを配置するだけなら、命令レベルの統合は必要とされない。一方、逆にダイは別でも命令セット的には統合された形態もありうる。

　しかし、CPUとGPUのシリコン上での統合化が、命令セットの統合の重要なキーであるのは確かだ。

　「CPUとGPUを統合することで、初めて機能を(ユーザーに)保証して『よし、これで、ユーザーモード命令セットに入れ込むことを正当化できる』と決定できるようになる」とHester氏は語る。

　つまり、AMDはコプロセッサのオンダイ統合が、命令セットレベルの統合の条件と考えている。

　もっとも、実際の製品レベルでは、GPUコアの物理的な統合と、命令セット上の統合は時期がずれるかもしれない。また、GPUコアのマイクロアーキテクチャ上の統合も、命令セットレベルの統合にともなって、段階的に変化して行く可能性がある。最初は、GPUコアがCPUコアとは分離され内部クロスバーで接続された形態だが、将来は、もっと融合が進んだアーキテクチャへと変わって行く可能性がある。

　AMDのビジョンに沿って行くと、FUSION世代の将来のGPUコアのソフトウェアモデルは、CPUのそれに似てくる。ネイティブ命令セットがビジブルになっていて、x86フォーマットに取り込まれ、一貫性を持って命令が保持されて行く。当然、その上で各種ミドルウェアが成長し、アプリケーションがGPU機能を容易に使えるようになって行くことが予想される。

　PCのソフトウェアモデルの場合、こうしたミドルウェアが確立しないと、なかなか普及が進まない。そのため、標準的なAPIの整備などが重要となる。ここで、要となる存在が、Microsoftなのか、それともOpenGL ESなどを策定する団体Khronos Groupなのか、あるいはPeakStreamのようなベンチャーなのか、まだわからない。しかし、AMDは、リーダーシップを取って行く必要があることだけは確かだ。

　問題はここにある。AMDが苦手なことの1つが、ソフトウェア面でのリーダーシップを取って行くことだからだ。GPUコアの統合で、チップレベルの統合以上に困難なのは、おそらく、こうしたソフトウェア面の整備だ。FUSIONが、AMDにとって大きなチャレンジであるのは、この点だ。

The Efficiency Benefits of Silicon-Level Integration (※別ウィンドウで開きます) PDF版はこちら

□関連記事
【2007年2月27日】【海外】CPUとGPUの統合プロセッサのチャレンジ
http://pc.watch.impress.co.jp/docs/2007/0227/kaigai340.htm
【2007年2月15日】【海外】Intelの次世代CPU「Wolfdale」と「CPU+GPU」
http://pc.watch.impress.co.jp/docs/2007/0202/kaigai333.htm
【1月22日】【海外】AMDが“Fusion”プロセッサとオクタコアに進む理由
http://pc.watch.impress.co.jp/docs/2007/0122/kaigai330.htm

□バックナンバー

(2007年2月28日)

[Reported by 後藤 弘茂(Hiroshige Goto)]