「Boltzmann Initiative」を発表 – AMD GPU用C++とCUDAコンパイラー
2016年2月7日

Boltzmann Initiative
サーバーカード、FirePro SシリーズのHPC能力に焦点あてたるためのショーに専念するAMDから、SC15における重要な第2番目のアナウンスが発表されました。 我々が過去2週間傍聴した事前説明会のすべての中でも、本日のAMDの発表はこれまで最も重要なことです。そして、それは SCがAMDのホームグラウンド、テキサス州オースティンで開催された時にこれが発表されたことは当然のことといえます。
何がAMDを熱狂させたのでしょうか? 要約すると、同社はHPCソフトウェア計画の大規模な見直しに着手しようとしています。統計力学の父、ルードリッヒ・ボルツマンにちなんでボルツマン・イ ニシアティブと呼ばれています。NVIDIAとのギャップを埋めて競争(および互換性!)環境を提供するために、AMDは彼らのHPCソフトウェアエコシ ステムの再開発努力にもっと取り組むことになるでしょう。このことを念頭に置いて、先に進んでみましょう。
Why Boltzmann
ヘッドレスLinuxとHSAベースGPUの環境 お そらく、ボルツマン・イニシアティブの土台は、AMDの他の計画をサポートするために見直しと改善されたAMDのドライバーと共にあります。同社は、特に Linuxのヘッドレス操作のために専用の64-bit Linuxドライバーをビルドすることになるでしょう。AMDは実際、Linuxのヘッドレス操作(そのヘッドレスOpenCLに先立った実行環境はすこ しハッキング気味でしたが)と完成した新しいドライバに昨年からフォーカスしてきました。
Heterogeneous
し かしそのことよりも重要なのは、ヘッドレスLinuxドライバは、HSA拡張環境を実装するだろうことです。それは、AMDのFireProディスクリー トGPUにヘテロジニアス・システム・アーキテクチャ(HSA)の多くの利点をもたらすでしょう。AMDがHSA+と呼んでいるこの環境は、特にディスク リートGPUでHSAをサポートするための拡張機能を追加することで、正式なHSA規格を作り直します。拡張機能自体は標準規格にはならない予定ですが、 HSAファウンデーションは、APU風の真のインテグレートデバイスに焦点をあてているので、それらの拡張機能はすぐに主流のHSAとして上流で受け入れ られそうにはありません。このため、AMDは将来この拡張機能をオープンソースとしてリリースするでしょう。
ディスクリート GPU(dGPU)にHSAを拡張する目的は、以前の約束を満たす以外にも、dGPUに実用的なHSA実行モデルの利点を出来る限り多くを持ち込むことで す。AMDにとって、CPUとdGPUで積極的に作業を実行しているアプリケーション・プログラミングを著しく簡素化できる、単一のユニファイドアドレス 空間(CUDA6以降NVIDIAとのギャップを埋めている)に、CPUとdGPUを置くことができることを意味します。このドライバと共にHSAモデル を使用すると、クラスター内のノードを結合するために使用されるインフィニバンドのようなファブリックを持つ大規模クラスターのサポート/パフォーマンス を改善し、ディスパッチ・レイテンシを減少させるようなその他のニーズに、AMDは対応できることになります。新しいドライバの基本的な能力と組み合わせ ることで、AMDは競合と同等以上のクラスター機能セットを提供するいくつかの本当に必要な下地を本質において構築しています。
ヘテロジニアス・コンピュート・コンパイラー – OpenCLから分岐しC++に ボ ルツマン・イニシアティブの第2の部分は、HPC向けのAMDの新しいコンパイラ、ヘテロジニアス・コンピュート・コンパイラです。同社のHSAコンパイ ラを完成した作業を基盤に、HCCは、HPCユーザが必要とするプログラミングに対応するためにAMDが行った二つの努力の内の最初の一つです。ユーザは 概して、部分的に精彩を欠いたHPCソフトウェア環境をAMDのGPUに渡しています。
先に進む前の小さな背景として、NVIDIAと CUDAの最も初期の利点の一つは、OpenCLがCライク文法とOpenCLプログラミング用には明らかにローレベルの言語のみしかサポートできなかっ た時点で、CUDAは既にC++とその他のハイレベルプログラミング言語をサポートしていたと言うことがあります。AMDはその間オープンなエコシステム をサポートするために部分的にOpenCLを支援し続け、OpenCLが、ある意味で後の祭りであるが、今年、OpenCL 2.1の暫定リリースとOpenCL C ++カーネル言語で大きな進歩を遂げました。しかし、OpenCLはHPCスペースでの最小限の使用のみしか見ておらず、一部のベンダーしかOpenCL 2.xをサポートしていないと言うより複雑な事が起きています。その一部としてのAMDは、名前を氏名されるほどではありませんが、この時点では、 OpenCL1.2までしかサポートできないNVIDIAが出遅れていることはよく知られていることです(しかし、何か新しいことをサポートするにはサビ ていないように見えます)。
HCC
HPC ソフトウェアAPIニーズとしてOpenCLを当てにすることがもはやできないということを企業が明らかにした時、これらの開発の結果のようにAMDはソ フトウェア戦略を変更しています。AMDは、OpenCLからとにかく逃げ腰になっているとは言いませんが、我々向けの説明会でAMDは引き続き OpenCLをサポートする意向があるということを明らかにした時でも、彼らの態度とプレゼンテーションを元にすると、このことは波風を立てることを避け るために中身の無い企業約束の常套手段のようにみえました。しかし、OpenCLがAMDがこれまで欲した物全てを提供したとしても、APIのサポートが 断片化していることや、OpenCL C++の状況が今だに低いレベルにしか無いため、OpenCLを利用することは難しいということを実感します。このため、AMDは同時にかれら独自の APIと環境を整えていくことになるでしょう。
この環境は、ヘテロジニアスコンピュート・コンパイラを中心に構築されます。ある意味CUDAに対するAMDの答えとしてのHCCは、CPUとGPU両方 の単一のC/C ++/OpenMPコンパイラです。多くの最近のコンパイラプロジェクトのように、AMDはランタイム環境として機能するために以前説明したようにHSA の一部と同調するコンパイルを処理するためにClangとLLVMの一部を活用しています。
HCCの目的は、開発者が単一のソースファイル内に、単一の言語で、単一のコンパイラを使用してCPUとGPUのコードを書くことを可能にすることです。 最終的には、開発者が行うC++プログラミング内の並列コールを簡単に行えるMicrosoft C++ AMPのようなものになります。おそらく、AMDとAMDのHPC利用者の予測として最も重要なことは、HCCは、GPUカーネル専用の別ソース・ファイ ルやOpenCL++まで利用し続けないといけない制限が必要とされないことです。
HCC-SouceCode-sample

HCCソースコード例
全 体的に、HCCは、2つの方法で並列処理を公開します。一番目は、C++ラムダコードを中心に構築された機能で、並列で実行でき、そしてどのようにその他 のプログラムと相互作用するかというコードセグメントをはっきりと設定するための、parallel_for_eachのような、開発者がコールできる並 列化可能な関数を持つ、C++ AMP式の並列処理の明示的な構文です。さらにハイレベルにある二番目の方法は、C++ 17への装備を今後予定しているパラレルSTL(標準テンプレートライブラリ)を、活用することになります。パラレルSTLは、GPU/アクセラレーター の実行のための多くの並列化の標準機能を含んでます。そして開発者はもはや並列実行の確かな様子をコントロールし明示的に説明する必要がないため物事を簡 素化できます。このため開発者は、修正/拡張のためのベースとしてSTL関数を使うことができるのです。
最終的にHCCは、AMD GPUのためのGPUプログラミングを改良することおよび、環境により必要な機能をもたらすことを意図しています。基本的な並列性と標準の並列関数の即時 追加に伴い、HCCもGPUやその他のアクセラレータのパフォーマンスを向上させるためにいくつかの機能を搭載します。これには、プリフェッチデータ、非 同期演算カーネル、さらにはスクラッチパッドメモリ(すなわち、AMD LDS ローカルデータシェア)のサポートが含まれています。これらの機能でAMDは、HPCユーザーが欲しているプログラミング環境の一種、新たなHPCプログ ラマーにより歓迎される環境、そして同様にCUDAプログラマーにも歓迎される環境を提供できることを期待しています。
ポータビリティーのためのヘテロジニアス・コンピュート・インターフェース (HIP) – AMD GPUでCUDAをコンパイル 最 後に、ボルツマンイニシアティブは、完全にCUDA開発者の世界に橋渡しをするAMDの取り組みです。CUDA開発者が望むことと同等以上のAMDのプロ グラミング環境を提供するためにHCCで、NVIDIAと同レベルでは必ずしも十分でないこと、CUDAの構文に慣れている開発者は何も変更したくないこ と、そしてCUDAは何時でもどこでもすぐに利用されるわけではないことにAMDは気付きました。その問題の解決策は、CUDA開発者にAMD GPUに移植するための必要なツールを簡単にもたらす、ポータビリティのためのヘテロジニアス・コンピュート・インターフェース(HIP)です。

HIP を通して、AMDは、開発者がCUDAのような方法でAMD GPUをプログラムすることを可能にするCUDAのような構文(様々なHIP APIコマンド)を開発者に提供することで、HCCとCUDA間のギャプを埋めようとしています。一方で、HIPは、自動的にCUDAコードからHIP コードに変換することで、ポーティングをより簡素化するツールセット(HIPifyツール)も含んでいます。そしてついに、ネイティブで書かれようが変換 されようが、一度コードがHIPになれば、NVCC(HIPサポートを追加するためにはHIPヘッダーファイルが必要ですが)でまたはHCC各々で、 NVIDIAまたはAMDのいずれかのGPU用にコンパイルすることができます。
ここで明確にしないといけないことは、HIPは、AMD のGPU上でコンパイルされたCUDAプログラムを実行するための手段では無いということです。CUDAはNVIDIAの技術以外の何者でもありません。 しかし、HIPはソース・ツー・ソース変換の手段で、そのため開発者はAMD GPUをターゲットにする場合でもはるかに簡単に時間をかけずに変換できます。開発者が通常自前で全てのコードを書き、そして特定のアーキテクチャー上で 動作するように調整するHPCマーケットを考慮すると、ソース・ツー・ソース変換は、AMDがまさに必要とする物の大部分をカバーし、そしてAMDの GPU用コードをより良く最適化することができるハイレベル言語をCUDAコードにコンパイルするための機能をAMDが持っていることを意味します。
anandtech
現 在、AMDがCUDA機能の追加と最新のHIPを維持するかどうかを含むいくつかの不明点がありますが、より重要なことは、NVIDIAの反応がどうなの かと言う問題です。CUDAはあらゆる点でNVIDIAの物であり、特にOracle vs GoogleのJava APIのケースのような観点から見て、NVIDIAの許可なくCUDA APIを実装した時に、AMDを告訴しようとするかどうかです。AMDの法務部門は広範囲に問題を調査し、そしてGPUCCでLLVMにCUDAサポート を持ち込もうとしたGoogle自信の取り組みをとり、彼らは訴訟リスクは無いと信じています。個人的には、AMDの取り組みは、直接の競合に少しばかり 挑発的なものを与えていると思いますが。最終的には、訴訟が起きた場合には、AMDとNVIDIAのみが処理することですが、指摘される必要がある何かで もあるわけです。
CUDAがマーケットを牽引して以来HPC企業の努力の妨げとなった、CUDAを実行できないと言う事実である最も大きな問題を、HIPを作成すること で、AMDは解決しています。誰もが標準C++でプログラムすることができ、実行できればAMDは確かに幸せになるかもしれませんが、独自APIに対して 互換性レイヤーは完璧な解決策になることはありません。しかし、CUDAで成長し、この時点でそれに定着したかなりのユーザーベースがあります。そして、 かれらがNVIDIAからHPCマーケットシェアを奪い取ることを願っているならば、単純にCUDA互換性を持っている必要があります。
6
ま とめると、ボルツマンイニシアティブでAMDは、HPCスペースで彼ら自身を再定義するための重要で非常に多くの必要なステップを踏んでいます。 LinuxのヘッドレスOSサポートやユニファイドメモリ空間のために改良したドライバーレイヤ、直接のコンパイラー、C++単一ソースのコンパイル実 行、そして確立されたCUDAユーザに届くためにCUDA互換レイヤを提供することで、AMDはついに問題のHPCサイドでかなり積極的になっており、そ して彼らは、長い間これを作成するに必要だったことを多く議論した上で移動しています。この時点では、AMDはプロセスにおける品質ツールを提供するため にロードマップを提供する必要があります。それでもNVIDIAは良い製品を通じてHPCスペースでその場所を獲得していますし、簡単には排除できないで しょう。CUDAは開発者がそれを必要とした時を確実に掴んでいます。しかし、AMDにとって、彼らがボルツマンを実行することができるならば、5年目に して初めて、利益の上がるそして高収益性のHPCマーケットに対して成功するチャンスを持つことになるでしょう。

詳しくは、ACUBEのウェブサイドで。

(Visited 1 times, 1 visits today)
関連記事
Translate »