後藤弘茂のWeekly海外ニュース
AMDなどがHSAのアップデートをHot Chipsで行なう
（2013/8/26 12:30）
HSA Foundationのメンバーがチュートリアルを開催
AMDは、GPUなどCPU以外のプロセッサを混在させる、HSA(Heterogeneous System Architecture)のフレームワークを推進している。HSA構想は、パートナー企業を得て「HSA Foundation」を2012年6月から結成し、HSAの各種規格の策定を進めている。HSA Foundationは、今週、米スタンフォードで開催されているチップカンファレンス「Hot Chips 25」(8月25～27日、現地時間)において、HSAの概要についてのチュートリアルセッションを行なった。
HSA Foundationには、現在、ファウンダとしてAMD以外に、ARM、Imagination Technologies、MediaTek、Qualcomm、Samsung、Texas Instrumentsが加わっている。その他の顔ぶれを見ても分かるように、モバイルSoC(System on a Chip)またはモバイルにIPを提供しているベンダーが主流となっている。
HSAについての解説は、Hot Chips初日のチュートリアルデイの午前中を使い、行なわれた。HSA FoundationのプレジデントのPhil Rogers氏(AMD Corporate Fellow)は、HSAの進展について説明。高性能なCPUとGPUを載せたSoCデバイスが急速に増えていることで、オープンプラットフォームのHSAが、CPUとGPUの両方を活かすフレームワークになることを強調した。
HSAでは、従来のデバイスドライバベースのGPUなどのソフトウェア階層モデルに対して、新しいソフトウェア階層を提供する。例えば、GPUのグラフィックスドライバの階層と併存する形で、HSAのソフトウェア階層が提供される。HSAでは、このソフトウェアスタックを実現するため、バーチャルISA(Instruction Set Architecture)、メモリモデル、キューイングモデルなどを定義し、各HSAサポートベンダーが実装する。
LLVMベースになったHSAのコンパイラスタック
重要なポイントの1つは、複数のプロセッサメーカー間で、バーチャルISAを統合すること。GPUなどの実行モデルは、CPUのようにネイティブISAを露出させるのではない。ランタイムコンパイラがバーチャルISAから、GPU固有のネイティブISAへと変換する。HSAモデルでは、このバーチャルISAを「HSAIL(HSA Intermediate Language)」に統一する。つまり、HSAILをネイティブISAにコンパイルするためのランタイムをシステムに走らせる。これによって、異なるメーカーの異なるアーキテクチャのプロセッサ(例えば、AMDのGPUとARMのGPU)の間で、バーチャルISAレベルでの互換性を実現することができる。
Hot Chipsのチュートリアルでは、Ben Sander氏(AMD Senior Fellow)のセッションの中で、上位言語からGPUへのコンパイレーションのスタックが、大きく2つに分かれることが示された。下の図の、2つの赤とグレーの階層のうち、右側がシステム側の「Finalizer Flow」で、中間言語のHSAILをハードウェア固有のISAに変換する。左側が上流の「High-Level Compiler Flow」で、OpenCLのような上位の言語からHSAILバイナリを生成するまでを行なう。
一見して分かるように、左のスタックは、LLVM (Low-Level Virtual Machine)インフラストラクチャを活かす階層構造となっている。LLVMは、多種の言語を多様なハードウェアに適用できる、共通のコンパイラインフラストラクチャを作り上げつつあるプロジェクトだ。
図の中の「SPIR」は、OpenCLをLLVMに落とし込むためにKhronos Groupによって作られた「OpenCL Standard Portable Intermediate Representation(SPIR)」だ。つまり、コンパイラスタックの中に、HSAのために作られた中間言語が2層挟まっている。AMDがHSAの概要を発表した段階では、左側の上流のスタックは、LLVMに完全に依るものではなかったが、現在はLLVMベースとなっている。つまり、LLVMインフラストラクチャを使うことで、対応言語を広げようとする戦略が、より鮮明になっている。逆の見方をすれば、LLVMの重要性がますます高まっている。ちなみに、NVIDIAもCUDAをLLVMへと移行している。
Java Virtual MachineにHSAを統合
HSAのモデルは、一見して分かるように、ランタイムコンパイラベースの言語と相性がいい。そのため、Java Virtual Machine(Java VM)もHSAに取り込もうとAMDは取り組んでいる。AMDとOracleは、オープンソースプロジェクトとして「Sumatra」を進めており、2015年のJava 9をターゲットにしようとしている。JavaのHSAへの取り込みでは、第1段階として「Aparapi」と呼ばれるAPIを定義、OpenCLへの橋渡しとした。これを、HSAILを生成してHSAファイナライザに落とし込むようにし、さらに、最終的にはJava VM自身でHSAILを生成できるようにする。
HSAIL自体は、RISC(Reduced Instruction Set Computer)プロセッサのISAに類似しており、オペコードは136(HSAIL発表時には120)。レジスタモデルは32/64/128-bit SIMD(Single Instruction, Multiple Data)の3タイプで、このほかにコントロールレジスタがある。汎用の3種のレジスタで単一のレジスタプール(32-bit×128相当)を共有する。バーチャルISAに128-bitパックドがあるため、4-way SIMD型のGPUもカバーできる。ファイナライザは単純にHSAILのレジスタをハードウェアネイティブのレジスタにマッピングする。上位言語からのレジスタのアロケーションは上位のコンパイラ層で行なう。
HSAでの実行モデルは、SIMT(Single Instruction, Multiple Thread)型のモデルで、ハードウェア側はSIMDでプレディケーションを行なうことを想定している。ちなみに、HSA Foundationに加わっている他社のGPUには、ARM MaliやImagination Technologies PowerVR Series5のように、プレディケーションは行なわないものもある。しかし、これらのアーキテクチャは、個々の4-way SIMD毎に個別のプログラムカウンタを持つためSIMTモデルで問題は生じない。
※PDF版はこちら
HSAのメモリモデルとキューイング
Hot Chipsのチュートリアルでは、このほかにHSAのメモリモデルとキューイングモデルについても解説が行なわれた。メモリモデルはQualcommが、キューイングについてはARMが解説を担当した。HSA Foundationのメンバーで分担することで、AMDの独自ソリューションという色彩を弱めていた。
HSAのメモリモデルでは、従来はCPUとGPUの間で分断されていたバーチャルメモリアドレス空間を統合化することを前提としている。それによって、CPUとGPUそれぞれのメモリ空間の間での無駄なデータコピーをなくし、ポインタをCPUとGPUで共有できるようにする。HSAでは、32-bitシステムは当然32-bit、64-bitシステムでは最小で48-bitのバーチャルアドレッシングのサポートが決められている。
HSAモデルでは、CPUとGPUの間で、バーチャルメモリアドレスを共有し、メモリコヒーレンシを取ることで、CPUとGPUの間のムダで明示的なデータの移動をなくす。また、HSAエージェント間のコミュニケーションを行なうシグナリングと、HSAのジョブキューイングも定義した。
それによって、現在、非常に複雑でレイテンシが長い、GPUへのジョブの割り当てとその結果の受け取りを、簡略でレイテンシが短いソフトウェア構造にする。下の図のように、メモリコピーやバッファの転送、ジョブのスケジュールなどを全てバイパスして、ジョブキューに登録するだけで、GPUで実行できるようにする。
