GPUをCPUと(できるかぎり)同じような簡易さでプログラムできるようにする。これがAMDの提示するプログラミング&実行フレームワーク「HSA(Heterogeneous System Architecture)」のゴールだ。AMDは昨年(2011年)の同社の技術カンファレンス「AMD Fusion Developer Summit(AFDS)」で、HSA(当時はFusion System Architecture(FSA)と呼ばれていた)の概要を明らかにした。そして、先週開催された1年後のAFDSでは、AMDでHSAを担当するPhil Rogers氏(AMD Corporate Fellow)が、同構想がほぼ順調に進捗していることを示した。

壇上に並んだHSA Foundationの参加企業

　今回のAFDS 2012では、まず、AMDは昨年の段階では青写真に過ぎなかったHSAの各要素の詳細を明らかにした。そして、構想だけだったHSAのアライアンスに加わるメーカーを紹介した。具体的には、HSAでハードウェアを抽象化する中間言語「HSAIL」と、CPUとGPUのメモリを統合するメモリモデル、そしてHSAでの実行/ディスパッチモデルについてより詳しく説明した。アライアンスでは、「HSA Foundation」を設立し、ARM、Imagination Technologies、MediaTek、Texas Instrumentsがファウンダーとして名前を連ねた。

HSA Foundationのファウンダー	HSA Foundationの概要	ARMはヘテロジニアスコンピューティングにコミット

　順調に行けば、AMD GPUコアだけでなく、ARM MaliコアやPowerVRなどのコアが、基本的にはHSAの中間コード(HSAIL)に落とし込まれたプログラムを共通に実行(HSAのファイナライザコンパイラが各プロセッサのネイティブコードに変換する)できるようになる。AMDは、HSAをより具体的に示し、HSAを支えるエコシステムの樹立を宣言したことになる。HSA Foundationを通じてオープン化することで、エコシステムを育てるのがAMDの戦略だ。

HSA Foundationの活動	AMDの構想からの貢献

　HSAは、AMDが生き残り、発展するためのカギとなるソフトウェアモデルだ。AMDは、ヘテロジニアス(Heterogeneous:異種混合)コンピューティングが、今後のコンピューティングのモデルだと強調している。しかし、GPUを汎用に使わせるGPUコンピューティングでは、これまで、NVIDIAに対して出遅れていた。

　しかし、AMDは現在のGPUコンピューティングの浸透度は、まだ極めて限定されたスキルの高いプログラマー(AMDはニンジャとこの層を呼んでいる)に対するものだと見ている。より広いプログラミングコミュニティに浸透するためには、プログラミングと実行の全体の構造を変革する必要があるというのがAMDの主張だ。また、より開かれたフレームワークにするためには、幅広いパートナーを巻き込んでエコシステムを作る必要があると考えている。

　AMDの主張をラフに言えば、「NVIDIAが掴んだ層は、まだごく一部で、勝負はこれから。より広いプログラマー層を掴んだ者が真の勝者」となる。そのため、従来のGPUコンピューティングコミュニティより、一般的なプログラマー層が、より多くのデバイスに対して、より簡易に並列プログラミングをできるようにしようとしている。

　具体的には、何百万人もの一般的なプログラマーが、AMDだけでなくARMのCPUやGPU、PowerPC GPU、TIのDSPなど多くのコアに対して、共通したプログラミングプラットフォームで、よりCPUに近い手法でプログラムを書いて、ハードの違いをほとんど意識せずに実行できるようにする。そうなれば、さまざまな分野でGPUアプリケーションが溢れるようになる、というのがAMDのビジョンだ。そのため、AMDは、より上手にGPUハードウェアを抽象化できるソフトウェア層を構築する必要がある。それを実現するのがHSAのフレームワークであり、そのHSAの目玉はCPUとGPUでメモリアドレスを共有させることにある。

　対NVIDIAで言うなら、現在のGPUプログラミングの次のステップに焦点を合わせることで、NVIDIAの今のアドバンテージを薄めさせようとしている。GPUコンピューティングが本格的に浸透する時代に向けて、勝負を賭けようとしている。そして、PC市場ではCPUを持たないNVIDIAにはできない、CPUとGPUのメモリアドレスの統合で、差別化しようとしている。

　対Intelでは、Larrabeeのつまづき以降、出遅れているIntelに、ソフトウェアフレームワークの構築でさらに差をつけようとしている。モバイル系のGPUコアやDSP、アクセラレータを持つベンダーをHSAのエコシステムに取りこむことで、Intelが攻めようとしているモバイルアプリケーションプロセッサ市場に、HSAのエコシステムを浸透させることも狙いだ。もちろん、NVIDIAとIntelが火花を散らしているHPC(High Performance Computing)の市場へもHSAを武器に浸透しようと伺っている。ただし、これは、HPC向けのAPU(Accelerated Processing Unit)が登場してから本格化することになるだろう。

　AMDは、今回、HSAの狙うところを、誰にでもわかりやすく説明した。下のスライドは、縦軸がソフトウェアによって得られるパフォーマンスや電力削減などの利点で、上に行けば行くほど利点が多い。横軸はそれに対してソフトウェア開発に必要な労力や時間、スキルなど。左下の、伝統的なCPUベースのソフトウェア開発は労力も少ないが、その代わり得られるパフォーマンスは少なく電力効率なども悪い。それに対して右上の現行のGPUベースのソフトウェア開発は、得られるパフォーマンスや電力効率は大きいが、開発に労力やスキルがかかる。

開発者の投資や労力と、利益や電力削減

　そのため、CPUソフトウェアには1,000万以上ものプログラマがいて400万ものアプリがあるのに、GPUソフトウェアは「プログラマーの数はずっと少なく、おそらくトータルで10万程度だろう」(Rogers氏)という状態でアプリは数百程度しかないとAMDは言う。しかし、左上のグリーンの枠のように、HSAフレームワークとライブラリを使えば、最終的に開発労力はぐっと少なくなる。その結果、数百万のプログラマーがコーディングするようになり、数十万のアプリが登場するだろうとAMDは見ている。グリーンのHSAの枠がちょっとだけ右にずれているのがミソで、AMDはCPUと同じ簡易さにはならないが、それに近いレベルに持って行けるとAMDは言いたいのがわかる。

　アプリケーション分野は、ナチュラルヒューマンインターフェイスや生体認証、AR(拡張現実)、画像や映像などAVコンテンツの検索、HD以上の解像度の映像や3Dグラフィックス、コンテンツをデバイスを選ばずシームレスに再生できるようにすることなど。GPUコンピューティングでよく言われる、“RMS”と呼ばれる「Recognition(認識)」、「Mining(分析&抽出)」、「Synthesis(合成)」のアプリケーション群だ。

HSAで想定するアプリケーション分野	ヘテロジニアスのシステムアーキテクチャ	AMDのPhil Rogers氏(AMD Corporate Fellow)氏

　上の図式を成功させるためのカギがHSAフレームワークのさまざまな要素だ。AMDのRogers氏は、今回はAMDの開発のスタイルを逆転させたと説明する。これまでは、まずハードウェアを開発し、そのハードにアクセスできるAPIを提供し、ソフトウェアには新たにAPIに対応してもらうという順番だった。しかし、今回は、既存のプログラミングモデルや既存の言語、既存のコードをできる限り活かせるようにして行かなければならないと判断し、それに合わせてソフトウェアとハードウェアの両方を同期させて開発しているという。

　そして、HSAで最も重要なポイントは、CPUとGPUのメモリの統合にある。「ソフトウェアプラットフォームについての希望リストのトップに挙がっているのは、CPUとGPUの、ユニファイドメモリアドレススペースだ。コヒーレンシが維持された共有メモリが実現できれば、GPUのプログラミングは容易になり、無駄なデータコピーを完全に削減することで電力も低減できる」とRogers氏は言う。

　HSAのロードマップの下のスライドのように、現在はGPUアーキテクチャがGCN(Graphics Core Next)に拡張されて、C++のサポートやHSAソフトウェアスタックからのダイレクトなタスクのディスパッチなどが可能になった。来年(2013年)になると、いよいよHSAのメモリ統合のフェイズに入る。CPUとGPUのアドレススペースを統合し、CPUポインタベースでシステムメモリにアクセスできるようにし、ハードウェアでCPUとGPUのメモリ空間のコヒーレンシを維持する。

ヘテロジニアスシステムアーキテクチャのロードマップ

　ただし、このチャートで示されているのは、あくまでも理論的な統合であって、物理的に完全にGPUとCPUの間でのメモリアクセスのペナルティがなくなることは約束はされていない。現在のAMD APUでは、それぞれのコアから互いのメモリ空間にアクセスする場合に、帯域面で大きなペナルティがある。下の図は1世代前のLlano(ラノ)のもので、レッドの矢印はメモリアクセスの帯域を示しており、かなりの制約があることがわかる。Trinityの数値は明らかにされていないが、Llanoと内部バスの構造が似通っているためペナリティがあるはずだ。これが完全に解消されるかどうかは、2013年のAPUを待たなければわからない。

Llanoのメモリアクセス(PDF版はこちら)

　ちなみに、GPUのコンピュートコンテクストスイッチングや、グラフィックス処理のプリエンプティブなタスク切り替えは、さらにその先の2014年となっている。現在のAMD GPUでは、シェーダコードを実行している最中にコンテクストをスイッチできず、CPUのような細粒度での切り替えはできない。2014年に、そこまでを実現して、HSAは一応の完成を見ることになる。

　HSAでは、従来のグラフィックスドライバとは別ルートで、GPUや他のアクセラレータにアクセスするソフトウェア層を用意する。グラフィックスドライバはオーバーヘッドが大きいが、HSAスタックはより少ないオーバーヘッドでGPUに直裁的にタスクをディスパッチできるようにする。とはいえ、GPUのネイティブ命令セットをランタイムコンパイラで隠蔽することは変わらない。

　下のようにHSAではランタイムが2階層に分かれている。図中でHSAランタイムとされているスタックの中のHLC(High Level Compiler)と、HSAファイナラザ(HSA Finalizer)だ。HLCで、中間言語のHSAILに落とし込み、ファイナライザがハードウェアのネイティブ命令セットに変換する。HSAILは、NVIDIAのソフトウェアスタックの「PTX」に当たる中間言語で、その意味ではようやくNVIDIAに追いついたとも言える。ちなみに、従来のAMDILベースのドライバ側のソフトウェアスタックも併存する。

HSAソリューションのスタック	HLCからHSAIL、ファイナライザがネイティブコードに変換

　HSA Foundationの参加ハードウェアベンダーは、このソフトウェアスタックに自社のプロセッサを据えることができる。GPUコアならHSAILコードをコンパイルするファイナライザを実装すれば対応ができる。HSAIL自体もベンダースペシフィックな拡張を認める仕様となっている。もし、HSAILでカバーできないアクセラレータがあった場合も、上位のHSAランタイムでサポートできる。AMDは、HSAスタックをオープンソース化することを約束している。

HSAへのオープンソースコミットメント

　上位では、OpenCLとC++ AMPのための並列プリミティブライブラリであるHSA BOLTを用意する。プログラミングを容易にするためには、リッチなライブラリが欠かせないため、AMDは急いでいる。また、AMDは、C++ AMPやHSA Boltでのパフォーマンスゲインのチャートも示した。

並列プリミティブライブラリ「HSA Bolt」	C++ AMP、HSA Boltでの性能上昇チャート

　JavaでのGPUコンピューティングのためのAPIセットである「APARAPI」とHSAの今後の展開も示した。このロードマップでは、最終的にJavaバーチャルマシンへのHSAランタイムの統合を目指していることがわかる。つまり、Java VMからダイレクトにHSAILをはき出して、薄いファイナライザ越しにターゲットハードウェアで実行させようとしている。オーバーヘッドを最小化しようというビジョンだ。

Java、APARAPIとHSAランタイムの展開	APARAPIによるJavaの動作

　ぱっと見ただけでも、AMDのHSAは非常に野心的なフレームワークで、AMDがかなり長期的なビジョンを持っていることもわかる。しかし、まだ、HSAの完成系には、足りない要素がある。例えば、HSAを業界の標準的なタスクディスパッチャに統合させるというビジョンは、まだ進展がない。これが実現すると、CPUとGPUの両方のタスクを、シームレスにディスパチャから発行できるようになる。下は、HSAのビジョンを発表した2010年のAnalyst DayでAMDが示したスライドだ。Appleの「Grand Central Dispatch(GCD)」、Microsoftの「Concurrency Runtime (ConcRT)」、Intelの「Threading Building Blocks(TBB)」などの名前がある。

2010年のAnalyst Dayで示したHSA構想

　しかし、今回もこの部分は空白のままで、HSA Foundationの設立メンバーにも有力OSベンダーやソフトウェアベンダーの姿がない。昨年のAFDSでキーノートスピーチを行なったMicrosoftもメンバーにならなかった。ソフトウェアフレームワークを作って行こうという話であるにも関わらず、まだ有力なソフトウェアパートナーを引き込むことができていない。この点は、今後の進展を見る必要がある。