1. トップ
  2. 新着ニュース
  3. IT
  4. パソコン

Intel Arc & Ponte Vecchio Update - HotChipsで公開されたIntel GPUの詳報

マイナビニュース / 2021年9月28日 9時30分

写真

画像提供:マイナビニュース

●Intel Arc Update
ちょっと遅くなったが、Intel Architecture Day及びHotChips 33での話を基に、IntelのGPU周りについてのUpdateをお届けしたい。といっても、それほど大きなUpdateがあるわけではないのだが。
○Intel Arc

Architecture Dayではサラッと流してしまったので、もう少し細かくご紹介したい。Intel Arcも、この後紹介するPonte Vecchioも、基本となるのはXe-Coreであるが、その構造が実は異なっている。

まずXe-Coreの構造だが、Vector Engineの基本は2018年のHPC Developer Conferenceで発表されたこちら(Photo01)であるが、これはコンセプト的なもので実際のものとはちょっと違うように思われる。実際今回説明によれば、Vector Engineそのものは16個で、それぞれ256bit幅とされており(Photo02)、8bit幅ならEngine1つで32個、32bitで8個、(サポートされるかどうかは不明だが)64bit幅で4つという形だろう。この辺は2020年のArchitecture Dayで説明されたXe-LPのEU(Photo03)に近い。Photo03で言うところのEU(Execution Unit)=Photo01で言うところのVector Engineと考えれば辻褄が合う。つまり一つのXe-coreは16EU相当、と考えれば良い。

ではXe-LPとの違いは? というと、Matrix Engineを搭載した事だ。Matrix EngineはINT8/FB16/FP16の行列演算をサポートするUnit(Photo04)であるが、Photo02にある様にこちらはEngine毎に1024bitの演算が可能である。INT 8なら128演算/cycleとなり、つまり8×8の行列同士の乗算と加算を1cycleで行える、という事だと思われる。

Xe-HPGというか、Intel Arcの第一世代であるAlchemistの最小構成と思われるのがRender Slice(Photo05)で、各々のXe-Coreに一つづつRay Tracing UnitとSamplerが付き、更にRender BackendとかGeometory Engineなどが用意される格好だ。

Architecture Dayでは、このRender Sliceが8つ搭載されたものが示された(Photo06)が例として示された。ただこれが最大構成かどうかは現時点で不明である。実際Roger Chandler氏(VP&GM, Client Graphics Products and Solutions)によれば「現時点ではまだ製品SKUの詳細は公開できない(ので、Photo06が最大構成なのかどうかは答えられない)」としつつ、Xe-GPUの構成はスケーラビリティがあるため、実際の製品の使われ方に応じて自由に変更できるとしている。実際、これが製品SKUをそのまま反映しているかどうかは不明だが、少なくともAlchemistが2種類あるっぽい事を示唆しており(Photo07)、小さい方はGaming Mobile向け、大きい方がDiscrete向けなんて可能性もあるかもしれない。

ただ少なくとも8 Sliceというか512EU構成のダイそのものはおそらく実在する。今年6月にKoduri氏自身がそのダイの写真をTwitterに上げており、しかも"DG2-512 B0"なんて但し書きまでなされている訳で、まぁ存在する事そのものは疑う余地がなさそうだ。

話を戻すと、この8 Slice構成はどの程度の性能を持つのか? という話になる。実際にはメモリの帯域とかL2の容量などで性能は変わるからあくまでもざっくりした見積もりであるが、8Slice=512 EU=4096 FP32 Unitとなる。

これと実際の製品の公称値を比較してみると

となっており、8 Sliceだと(動作周波数次第ではあるが)Radeon RX 6800 XTとかGeForce RTX 3080あたりと何とか勝負が出来るかどうか、という程度でしかない。余談ながら、GA102系のコアでは1個のSM:Streaming Multiprocessorに128個のCUDA Coreが搭載されているが、うち半分はFP32専用、残りの半分はINT32/FP32共用となっており、なのでINT演算の場合には表のCC数の半分が有効、ということになる。ただDirectXの描画パイプラインはINT32とFP32の混合であり、なので実効CC数というのは表の2/3位を想定しておくのが無難だろう。現実問題として例えばGeForce RTX 3080がRadeon RX 6800 XTと拮抗する性能、というあたりは結構FP32で動く部分が大きいという事でもある。

話を戻すと。そんなわけで8 Slice=512 EUというのはハイエンド向けというにはちょっと厳しいものがある。勿論仮にIntelがこれを3GHzとかでブン廻すことが出来れば、ハイエンド製品として十分な性能が出せるかもしれないが、TSMCのN6がそこまでぶん回せるとも思えない。となると8 Sliceというのはミッドレンジ~ハイエンドの下の方狙いであって、エンスージャスト向けにはもう少しSlice数が多くないと競争力が十分ではない様に思える。この辺りは現実問題としてどの辺をIntel Arcが狙っているか次第ではあるのだが、本気でマーケットを獲るつもりならラフに言っても12 Slice位のモデルが必要な気はする(あくまでメモリ構成とかL2の容量次第ではあるのだが)。

ちなみにメモリ構成などに関しては現時点で全く情報が無い。こちらは製品が出てくるまでお預け、ということらしい。また製造プロセスはTSMCのN6を利用している事は既に明らかになっているが、これはあくまで設計時点において利用できるプロセスのCapacity(どれだけの数を量産できるか)とPerformance、Costを勘案の上で決める、という話であった。

以前こちらで書いたが、Intel 7が予定通りに行けば今年後半に利用できる事にはなる。しかしIntel 7はTSMCのN7と大体同程度で、しかもまずAlder LakeやSapphire Rapids、更には後述するPonte Vecchioにも利用されるから、いくらIntelとはいえこれを供給するのは難しいだろう。そう考えれば、TSMCのN6を利用するのは賢明というか、現実問題としてIntel 7を待っていたら量産開始は来年後半になりかねないから、他に方法は無かったというべきだろう。ただXe-HPGの第2世代(Battlemage)に関しては、もしIntelが毎年1世代づつ新しい製品を投入するとすれば、ぎりぎりIntel 4が間に合うかもしれないというあたり。ただIntel 4の「2023年前半」が1月頭なのか6月末なのかでだいぶ話は変わる訳で、こちらも場合によってはIntel 4あるいはIntel 3にいずれは切り替えるとしても、当面はTSMCのN5あるいはN4という可能性もある(時期的に言えばTSMCのN3が既に利用可能になっている時期ではあり、IntelがこのTSMC N3の予約を既に入れているという話は流れてきているので、あるいはBattlemageはこのTSMC N3の可能性もあるが)。

ついでにいくつかの補足情報も。まずXeSS。これはNVIDIAのDLSS同様に、MLベースのSuperSamplingを行う技法であるが、なんと後方互換性がある、とされた。つまりXeベースの最初の製品であるDG1、あるいはやはりXeベースのGPUを利用するTigerLakeベースのCoreプロセッサでもXeSSは利用できるという話であった。

ただ疑問なのは、これらのコアはMatrix Engineを搭載しないことだ。この場合可能性は2つあり

CPU側でXeSSに必要なML処理を行う
Vector Engineで必要なML処理を行う

のどちらかになる。まずCPUに関して言えば、Xeon向けだとCascade Lake以降のCPUはAVX512の一部としてVNNIが実装されているが、コンシューマ向けのCoreプロセッサシリーズでVNNIが利用できるのはTiger Lake以降である(これはAVX512とは別に実装されている)。またIce Lakeの世代にはGNA 1.0というAI/MLアクセラレータが搭載され、Tiger LakeやRocket Lake世代ではGNA 2.0に切り替わっている。これを駆使すれば、あるいはCPUでも処理ができる「かもしれない」が、この場合CPUとGPUの間に猛烈なデータ転送が発生する事を考えるとあまり得策ではないだろう。

なので実際にはおそらくVector Engineの一部をXeSSの処理用に割り当てるという形での実装になるかと思うが、この場合には肝心の描画性能を犠牲にすることになるので、どの程度性能が改善されるのか、ちょっと微妙なところではある。まぁそれでもAMDのFSRの様にMLを利用せずにSuperSamplingを行える技法もあるので、このあたりは実装次第という感じである。いずれ性能を確認してみたいものだ。

またIntelとしてはWorkstation向けのSKUも少なくとも何かしらは考慮しているようだ。現時点で明確にラインナップを分けると明言したわけではないが、「勿論我々はWorkstation向けのマーケットをサポートするし、例えば3DS Maxの様なProfessional Applicationをサポートする」としたうえで、ただそれをどの製品SKUでサポートするかはまだ答えられないものの、Intel Arcそのものはそうしたハイエンド製品をサポートできる能力がある」とはしている。ただこれ、現実問題としてはむしろMobile Workstation向けの統合GPUに、こうしたProfessional Applicationのサポートを追加するというのが先であろう。現在こうした用途では、Mobile Workstation向けのSKUの内蔵GPUを無効化して、NVIDIAのQuadro for Mobile Workstationを搭載する、という形で販売されているものが殆どである。まずはこの用途を内蔵GPUで賄えるようにするのが先で、その先でDiscreteのWorkstationモデルが展開、という感じではないかと思う。

最後にドライバであるが、AMDやNVIDIA同様に定期的なDriver UpdateのRelease Scheduleを考えているとの事。もっともその頻度がどの程度か、は現時点では明らかになっていない。

●Ponte Vecchio Update
○Ponte Vecchio

Ponte Vecchioに関しても、アーキテクチャなどについてはこちらで説明した以上の話はHot Chips 33では出てこなかった。ただHot ChipsのTutorial Sessionの中でパッケージング技術に関するセッションがあり、そこで色々な話題が出てきたので、そのあたりをまとめてご紹介したい。

さてまずはXe-coreから。Ponte VecchioというかXe-HPC向けではXe-CoreではVector Engineの数は8つとXe-HPG向けに対して半減しているが、各々のEngineの扱えるデータ幅は倍増して512bitになっている。この画像のキャプションでは「粒度がHPC向けだと16コアでは大きすぎる、ということだろうか?」と書いたが、冷静に考えるとAVX512に合わせてデータ幅を512bitに広げたかったのだと思う。IntelはoneAPIを利用して、CPU/GPU/FPGAで統一されたプログラミング環境を構築しようとしているが、この際にデータの幅が異なるとこれをそろえるので一苦労することになる。512bit幅にしておけば、CPU側のAVX512で扱う事もできるし、Ponte Vecchioで扱う事も容易になる。実際にはCXL経由で煩雑にCPUとの間でデータのやり取りをすることを考えれば、512bit幅にそろえる方が得策と判断したのだろう。

またこちらの画像のキャプションで「やはりMatrix EngineはTF32は使えてもFP32は使えない模様。」と書いたが、とりあえず現時点でのMatrix EngineはPhoto04にもあるように、FP32はサポートされていない。ちなみにこのMatrix Engine、Raja Koduri氏によれば「別にAI/ML命令だけでなくoneAPI経由汎用の行列計算エンジンとして使える」との事だったが、扱えるデータ型がなにしろAI/ML命令向けのみなので、第3世代のTensor CoreでFP64をサポートしたNVIDIAのAmpereの様に、これで算術向け行列演算を行うというのは現実的には厳しいようだ。

そしてこちらの画像のキャプションで「HPC向けのXe HPCでRay Tracing Unitを搭載する理由は今一つ判然としない。」と書いたが、これについてはJeff McVeigh氏(VP&GM, Data Center XPU Products & Solutions)より「HPC向けにもRay Tracingは必要だ。例えば大規模なシミュレーションの結果の可視化などで利用される。Ray Tracingの技術も進化しており、単に高速でというだけでなく、超高精画質を得る方向性もある。単にVisualizationのみならずContents CreationとかAI/MLなどでも利用される可能性がある」という返事を頂いており、ちゃんと意味を持ってRay Tracing Unitが搭載されている事が明らかになっている。

ところでXe-HPCというかPonte VecchioではStackという構成が用意されるが、これがPonte Vecchioにおける最小単位となる模様だ。Ponte Vecchioはこちら(Photo08)の様に、2つのStackが間にEMIBで繋がる様な構成になっているが、さてHotChipsでこのPonte Vecchioのパッケージについて行われた説明がこちら(Photo09)。ダイサイズとかは後でまた触れるとして、問題はPVC 2Tというコード名である。これについてはMcVeigh氏曰く「我々は異なるPower Enveropeに対応するために、1 Stack版のPonte Vecchioを予定している」と明確に返事があった。

ちなみにPonte Vecchioのパッケージ写真自体は今年1月にKoduri氏がTwitterに上げており、その意味ではHotChipsが初出という訳ではない。またこちら(Photo10)には"47 Tiles"とあるが、その内訳も今年3月にKoduri氏がMentionしている。

こちらによれば

Compute Tile×16
Rambo Cache×8
Xe Base Tile×2
EMIB×11
Xe Link×2
HBM2e×8

となっており、つまりStack 1つあたり

Compute Tile×8
Rambo Cache×4
Xe Base Tile×1
EMIB×5
Xe Link×1
HBM2e×4

で、更に2つのStackを繋ぐのにEMIBが一つ使われる、という訳だ。さてこれを実際のダイ写真に当てはめると、ちょっと「?」となる。Photo11はKoduri氏がMnetionしたパッケージ写真の上半分に色々書き加えたわけだが、赤枠で囲った8つのTileが現時点で説明が皆無である。もっともPhoto10を見ると"Active Tile"が47とあるので、この赤枠で囲った部分は単に寸法合わせのPassive Die(つまり単に配線が繋がってるだけ)の可能性はある。縦方向はHBM2eメモリで寸法が決まるから、無駄でもなんでもHBM2eの分の高さを確保しないといけない。同様の理由で7nm世代のVegaはえらく無駄なダイの使い方になっていた訳で、そうした理由で無駄なTileが挟まっている可能性はありそうだ。

先のPhoto09の表示に戻ると、Max Active Top Die SizeというのはこのPhoto11で黄色く囲んだCompute Dieが1つの寸法、Base Dieというのは、Compute Tile×8+Rambo Cache×4、それにこの赤枠で囲った用途不明な8つのTile全体のサイズの事を指す。と思われる。つまりこれらが大きな一つ(650平方mm)のBase Dieの上に載り、ここはFoverosで垂直方向に接続される。そしてBase Dieの外に4つのHBM2eとXe-Linkが配され、これはBase Dieとの間でEMIBで接続されるという訳だ。この構造、断面図がPhoto09の左下にあるので判りやすいと思う。

ちなみに製造プロセスとして公開されているのは、Compute TileがTSMCのN5、Base TileがIntel 7となっている。また今回は公開されていないが、2020年のHotChipsで、Rambo Cacheは旧10nm Enhanced SuperFin、現Intel 7で製造されることが明らかになっている(Photo12)。Xe LinkはTSMCのN7であり、あとはEMIBのプロセスとPhoto11で示したPassive Tile(これはなんでもいいので、例えばIntelの14nmとかかもしれない)をあわせて5種類のプロセス、というあたりなのかもしれない。

Xe-LinkについてはPhoto13に示すように、最大8本のXe-Linkが出る形になる。ちなみにこのLinkは最大8つのStackを相互接続する以上の事は想定されておらず、より大規模なシステム向け(Scale out構成)の場合は、外部に別途Interconnectを利用する事になる。これもMcVeigh氏曰く「現状のXe-Linkは用途が限られており、またXe-HPC向けでしか利用されない」(つまりXe-HPG向けのマルチGPU接続などに使う事は出来ない)とはっきり明言している。

さて、Ponte VecchioはAurora向けに、2つのSapphire Rapidsと4つのPonte Vecchio OAM(=8 Stack分)を一つのモジュールとして提供するとしており、つまりXe-Linkはこのモジュール内のSliceの相互接続に利用される形になるのだが(Photo14)、自身を含めて8つのStackを相互接続するには、7本のLinkがあればよい。では残り1本のLinkは何だろう? という話である。

当初筆者はこれ、PCIe/CXL Bridgeに接続されるものと考えていたが、ANL(米アルゴンヌ国立研究所)のAuroraのInterconnectページを見ると、"Aurora will use Slingshot fabric connected in a Dragonfly topology with 8 fabric endpoints per node."なる文言がある。Auroraは主契約者こそIntelだが副契約者(つまりIntelの下請け)にCray Inc(現HPE)が入っている。Intelは個々のノード(つまりこれだ)内の接続には責任を持つが、ノード間の接続はCrayのSlingshotと呼ばれる独自Interconnectを利用する形だ。ここで出てくるDragonFlyは、複数のLocal Cluster同士を相互接続する、いわばInterconnectのバックボーンのアーキテクチャである(Photo15)。このDragonFryへのアクセスポイントがノード(つまりAurora Subsystem)に8つある、というのはおそらく8本のXe-Linkのうち1本はSlingShotのI/Fに接続される形になっているのではないかと思われる。Photo16は以前も紹介したスライドだが、この中で囲った赤枠の部分がSlingShotのI/Fではないかと筆者は推定している。

ちなみに実際にAuroraがどういう形でクラスタを組むのかはまだ明確ではないが、仮にFP64で1 ExaflopをPonte Vecchioだけで実現しようとすると、2500余りのノードが必要になる。Sapphire Rapidsの分も加味するともう少しノード数は減りそうだが、2000未満とう事はないだろう。これをフラットに相互接続するのは自殺行為なので、例えば40ノード位を一つのグループ(この中もDragonFlyで相互接続)し、そのグループ同士を別のDragonFlyで相互接続といった事が考えられる(あるいは3階層かもしれないが)。Auroraでは、Rosettaと呼ばれる64ポートのSlingShot Switchを利用するそうで、8ノードを相互接続できることになるが、おそらくは4~5ノードをノード同士の接続に、残りをDragonFlyを利用しての相互接続に割り当てる、という感じかと思う。

ところで性能。Photo16にも出ているが、A0 Siliconを利用しての結果だとFP32で45TFlops以上の性能とされる。1枚のOAMというのはつまり2 Stack/8 Slice/128 Xe-Coreであり、1個のXe-Coreが256 FP32 Ops/Cycleであることから逆算すると、このA0 Siliconの動作周波数はおよそ1.37GHz前後とされる。とりあえず1.4GHzほどで動いているので、45TFlops「以上」とされているのだと思われる。HotChips 33ではこれに加えてResNet-50を実施した場合の性能も示された(Photo17)が、これはIntelが2019年に買収したAIプロセッサベンダーであるHabana LabsのGoya(Inferenceが15000 image/sec以上)やGaudi(Trainingが1600 image/sec以上)を軽くぶっちぎる性能になっており、逆にこれらのInference向けプロセッサの存在意義が問われかねないところだ。

ということで、遅くなったがIntelのGPUに関する動向である。これ以上細かい話は、おそらく製品発表時まで出てこない気はするのだが、10月末に開催されるIntel Innovationイベントでもう少し位は何か出てくる事を期待したいところだ。
(大原雄介)

この記事に関連するニュース

トピックスRSS

ランキング