後藤弘茂のWeekly海外ニュース

AMDなどがHSAのアップデートをHot Chipsで行なう

HSA Foundationのメンバーがチュートリアルを開催

 AMDは、GPUなどCPU以外のプロセッサを混在させる、HSA(Heterogeneous System Architecture)のフレームワークを推進している。HSA構想は、パートナー企業を得て「HSA Foundation」を2012年6月から結成し、HSAの各種規格の策定を進めている。HSA Foundationは、今週、米スタンフォードで開催されているチップカンファレンス「Hot Chips 25」(8月25〜27日、現地時間)において、HSAの概要についてのチュートリアルセッションを行なった。

Phil Rogers氏(AMD Corporate Fellow, HSA Foundation President)
Ben Sander氏(AMD Senior Fellow)

 HSA Foundationには、現在、ファウンダとしてAMD以外に、ARM、Imagination Technologies、MediaTek、Qualcomm、Samsung、Texas Instrumentsが加わっている。その他の顔ぶれを見ても分かるように、モバイルSoC(System on a Chip)またはモバイルにIPを提供しているベンダーが主流となっている。

HSA Foundationのメンバー

 HSAについての解説は、Hot Chips初日のチュートリアルデイの午前中を使い、行なわれた。HSA FoundationのプレジデントのPhil Rogers氏(AMD Corporate Fellow)は、HSAの進展について説明。高性能なCPUとGPUを載せたSoCデバイスが急速に増えていることで、オープンプラットフォームのHSAが、CPUとGPUの両方を活かすフレームワークになることを強調した。

HSAの概要

 HSAでは、従来のデバイスドライバベースのGPUなどのソフトウェア階層モデルに対して、新しいソフトウェア階層を提供する。例えば、GPUのグラフィックスドライバの階層と併存する形で、HSAのソフトウェア階層が提供される。HSAでは、このソフトウェアスタックを実現するため、バーチャルISA(Instruction Set Architecture)、メモリモデル、キューイングモデルなどを定義し、各HSAサポートベンダーが実装する。

HSAが提供するソフトウェア階層

LLVMベースになったHSAのコンパイラスタック

 重要なポイントの1つは、複数のプロセッサメーカー間で、バーチャルISAを統合すること。GPUなどの実行モデルは、CPUのようにネイティブISAを露出させるのではない。ランタイムコンパイラがバーチャルISAから、GPU固有のネイティブISAへと変換する。HSAモデルでは、このバーチャルISAを「HSAIL(HSA Intermediate Language)」に統一する。つまり、HSAILをネイティブISAにコンパイルするためのランタイムをシステムに走らせる。これによって、異なるメーカーの異なるアーキテクチャのプロセッサ(例えば、AMDのGPUとARMのGPU)の間で、バーチャルISAレベルでの互換性を実現することができる。

バーチャルISA「HSAIL」により異なるアーキテクチャ間での互換性を実現する
HSAILで提供される機能

 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は、多種の言語を多様なハードウェアに適用できる、共通のコンパイラインフラストラクチャを作り上げつつあるプロジェクトだ。

HSAILのコンパイラスタック

 図の中の「SPIR」は、OpenCLをLLVMに落とし込むためにKhronos Groupによって作られた「OpenCL Standard Portable Intermediate Representation(SPIR)」だ。つまり、コンパイラスタックの中に、HSAのために作られた中間言語が2層挟まっている。AMDがHSAの概要を発表した段階では、左側の上流のスタックは、LLVMに完全に依るものではなかったが、現在はLLVMベースとなっている。つまり、LLVMインフラストラクチャを使うことで、対応言語を広げようとする戦略が、より鮮明になっている。逆の見方をすれば、LLVMの重要性がますます高まっている。ちなみに、NVIDIAもCUDAをLLVMへと移行している。

LLVMベースのコンパイラスタック
HSAILとSPIRそれぞれの特徴

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を生成できるようにする。

JavaからOpenCLへの橋渡しとなる「Aparapi」
段階に進められるJavaのHSA対応
AMDとOracleで推進されるSumatra

 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のレジスタをハードウェアネイティブのレジスタにマッピングする。上位言語からのレジスタのアロケーションは上位のコンパイラ層で行なう。

HSAILの命令セット
HSAILのレジスタ仕様

 HSAでの実行モデルは、SIMT(Single Instruction, Multiple Thread)型のモデルで、ハードウェア側はSIMDでプレディケーションを行なうことを想定している。ちなみに、HSA Foundationに加わっている他社のGPUには、ARM MaliやImagination Technologies PowerVR Series5のように、プレディケーションは行なわないものもある。しかし、これらのアーキテクチャは、個々の4-way SIMD毎に個別のプログラムカウンタを持つためSIMTモデルで問題は生じない。

HSAILは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ではバーチャルメモリアドレス空間へ統合する
HSAでの共有バーチャルメモリの概要

 HSAモデルでは、CPUとGPUの間で、バーチャルメモリアドレスを共有し、メモリコヒーレンシを取ることで、CPUとGPUの間のムダで明示的なデータの移動をなくす。また、HSAエージェント間のコミュニケーションを行なうシグナリングと、HSAのジョブキューイングも定義した。

ジョブキューイング

 それによって、現在、非常に複雑でレイテンシが長い、GPUへのジョブの割り当てとその結果の受け取りを、簡略でレイテンシが短いソフトウェア構造にする。下の図のように、メモリコピーやバッファの転送、ジョブのスケジュールなどを全てバイパスして、ジョブキューに登録するだけで、GPUで実行できるようにする。

メモリアドレス空間の共有やジョブスケジューリングによりGPUのジョブ実行を簡略化

(後藤 弘茂 (Hiroshige Goto) E-mail