AMDは、ソフトウェアデベロッパのための技術カンファレンス「AMD Fusion Developer Summit(AFDS)」で、同社が提案する今後のプログラミング&実行モデルの構想「Fusion System Architecture(FSA)」の全貌を明らかにした。FSAの目的は、GPUコアをCPUコアと同列に扱えるようにすることで、GPUのプログラミングを劇的に容易にすること。また、GPUコアとCPUコアの連携を容易にすることで、より小さな粒度の並列コードも効率的に実行できるようにすること。簡単に言えば、GPUコアを使ったアプリケーションが溢れるようにすることだ。

　具体的には、AMDはFSAソフトウェアスタックとして、従来のデバイスドライバとは異なるFSAランタイム(ユーザーモード)とFSAカーネルモードドライバ(カーネルモード)、それにFSA JIT(ジャストインタイム)コンパイラを提供する。また、FSAスタックのドメインスペシフィックライブラリをサードパーティと協力して構築する。さらに、CPUとGPUの両方にタスクをディスパッチできるタスクキューイングライブラリにFSAを対応してもらうか、またはAMDがディスパッチャを提供する。

　これらの実現のために、AMDはFSAをオープンアーキテクチャとして業界の協力を求めている。ツール&ミドルウェアベンダーだけでなく、OSベンダー、他のCPU/GPUメーカーを含むハードウェアメーカー、アプリケーションベンダーのパートナーを得ようとしているという。また、仕様も公開する。FSA JITコンパイラの中間言語レイヤーとなるFSAIL(インターミディエイトレイヤー:Intermediate Layer/Language)、FSAで新たに実現するCPUとGPUのメモリアーキテクチャであるFSAメモリモデル、さらにFSAのディスパッチャなどの仕様が公開される。

　では、FSAの全体像はどうなっており、AMDはどういうステップで実現しているのか。

AMDのPhil Rogers氏(AMD Corporate Fellow)

　AFDSのキーノートスピーチに登場したPhil Rogers氏(AMD Corporate Fellow)は、FSAについて、その背景から説明した。Phil Rogers氏は、FSAのリードアーキテクトであり、ATI TechnologiesでGPUのソフトウェア層のアーキテクトだった。

　Rogers氏はAFDSの壇上に登場して、まず「自分はプログラマー」だと宣言し、ソフトウェアエンジニアがほとんどを占める聴衆から拍手を浴びた。プログラマーの意向を無視して、ソフトウェアスタックを定義しないと、暗に示した格好だ。Rogers氏のスピーチのタイトル「The Programmer's Guide to the APU Galaxy」は、「銀河ヒッチハイクガイド(The Hitchhiker's Guide to the Galaxy)」をもじったものだ。プログラマーのプレゼンテーションでは、銀河ヒッチハイクガイドが引き合いに出されることが多く、こうした小技でもプログラマーの心情を掴もうとしているように見える。

　Rogers氏は、まず、プロセッサの進化を3つの時代に区分したスライドを示した。これは、AMDのChuck Moore氏(Corporate Fellow and CTO Technology Development)が過去に何回か見せているスライドと同じ内容だ。つまり、AMDのトップCPUアーキテクトが抱いているプロセッサの進化のビジョンを示したものだ。

プロセッサの進化の3つの時代	Chuck Moore氏が過去に見せたスライド	Analyst Dayで公開されたスライド

　このスライド中の最初の「シングルコアCPU時代(Single-core Era)」は、1986年から2004年までの18年間を示している。CPUがシングルコアのまま、マイクロアーキテクチャを強化してシングルスレッド性能の向上にフォーカスしていた時代だ。CMOSスケーリングによるムーアの法則が健在で、プロセスが微細化するとともに駆動電圧がスケールダウンしていた。しかし、シングルコア時代は、CPUコアの複雑度の増大と、電圧のスケールダウンが止まったことによる電力の急増に制約されてしまった。

　次が2004年から2010年まで6年間の「マルチコア時代(Multi-Core Era)」だ。これは、従来型の延長にあるCPUコアをモディファイして、ホモジニアス(Homogeneous:均質)なSMP(Symmetric Multi-Processing)マルチコア構成にする時代で、マルチスレッド性能の向上にフォーカスする。しかし、このアプローチも、パフォーマンスのスケーラビリティやソフトウェア側の並列化に制約された。

ヘテロジニアスシステム時代の課題

　Rogers氏は、この2つの時代を経て、今は「ヘテロジニアスシステム時代(Heterogeneous Systems Era)」に入ったと説明した。ヘテロジニアス(Heterogeneous:異種混合)型にプロセッサとGPUコアなどのアクセラレータを統合、システムレベルの機能をより統合し、オンチップのリソースの高度な管理機能を備える、新しい方向性のCPUの時代だ。GPUコアの洗練化と、データ並列性の高いアプリケーションへの展望によって、この時代が開けた。しかし、始まったばかりのこのヘテロジニアス時代にも、解決しなければならない問題があるとRogers氏は説明する。それは、プログラミングモデルと、コミュニケーションオーバーヘッドの解消だ。

ヘテロジニアスのプログラミング

　Rogers氏は、この問題をヘテロジニアスのプログラミングから見たスライドを見せた。

　GPUを汎用プログラムに使うヘテロジニアスコンピューティングは、初期のプロプラエタリなAPIを使う時代を経て、現在はスタンダードなAPIを使う時代になったと言うのがAMDの見方だ(NVIDIAからは異論があるはずだ)。しかし、現在でも、まだGPUをプログラムできるのはエキスパートプログラマーに限られており、言語ではC/C++のサブセットで、CPUとGPUの間での明示的なデータ転送が必要で、デバイスドライバを経由してGPUにアクセスしている。

　Rogers氏は、この現状を変える必要があると説明する。新しいヘテロジニアスコンピューティングモデルに合わせて、ソフトウェア層を再設計するべきだという。このアーキテクテッド時代の目的は、メインストリームのプログラマーにフルのC++言語でプログラムできる環境を整えることだ。

　GPUをCPUのコプロセッサとして扱えるようにし、CPUとGPUのメモリアドレススペースは統合してコヒーレンシを維持する。その上で、タスクパラレルランタイムからGPUへとタスクをディスパッチできるようにする。GPUのコンピュテーションを細粒度で切り替えるコンテクストスイッチを実現する。ネストした複雑なデータ並列プログラムでも問題なく実行できるようにする。

　この構想を実現するために、AMDが構築しようとしているのがFSAソフトウェアスタックだ。そして、AMDはFSAを実現するために、ハードウェアとソフトウェア層の両方で改革を進めている。

　AFDSでRogers氏は、4ステップでAMDはアーキテクチャ改革を進めると説明するスライドを見せた。このスライドは、AMDが昨年(2010年)のAnalyst Dayで使ったスライドと基本は同じだ。ただし、この2枚のスライドは微妙に違っていて興味深い。

FSAを実現するための4つのステップ	AMD Fusionの進化 PDF版はこちら	2010年のAnalyst Dayで使ったスライド

　どちらのスライドでも、ステップは大きく4つに分かれる。(1)CPUとGPUの物理的な統合、(2)プラットフォームの最適化、(3)アーキテクチャ上の統合、(4)システム統合の4フェイズだ。これらのうち、最初の2つのカラム(1と2)は、今週発表された「Llano(ラノ)」で実現された。次の2つのカラム(3と4)についても、AMDは今後数年のうちに実現すると説明していた。

　物理的な統合では、CPUコアとGPUコアを実際に1個のチップに統合し、両者を広帯域のオンチップメモリコントローラに接続する。プラットフォーム最適化では、GPUプログラミングでC++をサポートし、CPUコアとGPUコアで連携する双方向のパワー制御も行なう。

　重要なのは次のステップのアーキテクチャ上の統合だ。ここでAMDは、CPUとGPUのメモリアドレス空間の統合、それに伴うページャブルメモリのGPUへの実装、CPUコアとGPUコア間でのメモリコヒーレンシの実現などを挙げている。ただし、以前のスライドでは、ここにGPUコアへのハードウェアタスクスケジューラの搭載が記されていたのが、なくなっている。ただ、これは実際にはGPUに、ハードウェアタスクキューを入れ込むことを示していた可能性もあり、単に名前だけの問題かも知れない。

　最後のシステム統合のステップでは、汎用コンピューティング時のGPUの細粒度のコンテクストスイッチング、グラフィックス時のGPUの粒度の大きなプリエンプション、PCI Express経由での外部GPUとのメモリコヒーレンシ、サービス品質などを挙げている。

　以前のスライドでは、このシステム統合時代は、アーキテクチャとOSの統合となっていたが、OSという項目が抜けた。また、項目ではOSなどのタスクパラレルランタイムへの統合が抜けた。これが、OSのタスクディスパッチャへのFSAの統合が遅れることを示唆しているのかどうかは、まだわからない。タスクディスパッチャへの統合は、相手(OSベンダーなど)があるため、簡単には行かない可能性がある。

　AMDのRogers氏は、こうしたAMDのFusionハードウェア側の革新を土台に、FSAを実現すると説明する。AMDがオープンにするのは冒頭で述べた3分野の仕様。FSAIL(Intermediate Layer/Language)、FSAメモリモデル、FSAディスパッチだ。

Fusionのシステムアーキテクチャ	FSAILの概要	FSAのメモリモデル

　FSAILは基本的にデータ並列コンピューティングのためのバーチャルISA(命令セットアーキテクチャ)だ。つまり、ソフトウェア実装された中間ISAで、実際にはコンパイラインターフェイスだ。NVIDIAのPTXに近い。GPUは通常はネイティブ命令を露出させない。それは、GPUアーキテクチャの変更の自由度を残しておくためだ。実際、AMDはGPUコアのネイティブ命令を現在のVLIW(Very Long Instruction Word)命令からスカラ命令へと転換しようとしている。そのため、CPU側で走るJITコンパイラのインターフェイスが、GPUの露出させるバーチャルISAとなる。

　もっとも、FSAILは、GPUだけでなくCPUも抽象化する、つまり、CPUとGPUの両方に対するバーチャルISAとなる。高級言語からコンパイルしてFSAILにはき出せば、それをアンダレイヤーのJITコンパイラがGPUやCPUのネイティブコードに変換する。当然だが、FSAILのレベルでは明示的なデータ並列コンピューティングのための並列性を仕様の中に持っている。

FSAとOpenCL

　AFDSでは、AMDがOpenCLをFSAの上に載せることを明らかにしたほか、Microsoftが発表したC++の拡張「C++ AMP(Accelerated Massive Parallelism)」のコンパイラもAMDが作ることを表明した。OpenCLやC++ AMPからFSAILへと持って行けることになる。

CAL(左)とFSA(右)の違い

　AMDは、これまでも同レベルのインターミディエイトレイヤーとして「AMD Compute Abstraction Layer(CAL)」を提供して来た。FSAILが異なるのは、まず、従来のドライバモデルとは異なるソフトウェアスタックに属している点だ。AMDは、FSAILを含むFSAソフトウェアスタックによって、現在のドライバを経由したGPUアクセスから抜け出そうとしている。右がAMDが示したスタックの図だ。図の左が従来のデバイスドライバモデルのスタック、右がAMDが提案しているFSAソフトウェアスタックとなっている。

　これをもう少し詳しく見たスライドは下のようになる。Todayとなっているのが今日のドライバモデル、Futureとなっているのが、FSAで提案しているモデルだ。

今日のドライバモデル	将来のドライバモデル

　FSAソフトウェアスタックは、タスクキューイングランタイムでタスクをプロセッサにディスパッチすることを主眼として構成されている。ソフトウェアは、タスク単位でCPUコアとGPUコアそれぞれにディスパッチされ実行される。タスクキューイングランタイムからは、CPUコアもGPUコアも同等に見えるようにすることが、FSAのポイントだ。

　もっとも、FSAソフトウェアスタックでGPUで実行するコードはネイティブコードではなくFSAILなので変換する必要がある。FSA JITコンパイラがタスクキューと連携してGPUのネイティブコードに変換し、GPUへとディスパッチされる仕組みだ。そして、そのコードをCPUコア側で実行する場合は、FSA JITのレベルでCPUのネイティブコードに変換すると見られる。

FSAのソフトウェアスタック

　このタスクキューイングライブラリ&ディスパッチャについては、AMDは自社で作るというより、他のソフトウェアベンダーとの提携を想定していると見られる。タスクキューイングランタイムが、すでにOSやミドルウェアに組み込まれているからだ。AFDSでのスライドにはないが、AMDは今年(2011年)1月には右のようなスライドで説明している。

　下の図では、タスクキューイングライブラリの例として、Appleの「Grand Central Dispatch(GCD)」、Microsoftの「Concurrency Runtime (ConcRT)」、さらにはIntelの「Threading Building Blocks(TBB)」などの名前を挙げられていた。ところが、AFDSではこの部分がブランクになっている。このあたりは、明らかになるとしても、パートナーとの交渉がまとまってからとなるだろう。

タスクキューイングのライブラリ	FSAプラットフォームにおけるタスクキューイング