大原雄介の半導体業界こぼれ話
Sapphire Rapidsにまつわる色々な謎
2023年1月19日 06:17
今月はちょっとホットな話題というか、実は筆者の中でもまだ完全に答えが見えていない謎がいくつかあるので、その話の話をさせて頂きたいと思う。対象はSapphire Rapidsであり、そもそも何でこんなに遅れたんだ? という話も謎であるが、そっちはIntelが詳細を明らかにしてくれるまでは分からないだろう。
ちなみにRobert P. Colwell氏がPentium Proの開発の経緯を書いたThe Pentium Chroniclesを出版したのは2005年のこと。つまり、少なくとも10年は出ないという話であり、筆者が生きてるうちには公開されないかもしれない(というか、この後Sapphire Rapidsが大成功を収めれば誰かがSapphire Rapids Chroniclesを書いてくれそうだが、そこまで成功しないと闇に葬り去られて終わりの可能性が高い)。
まぁその話はおいといて、んじゃお前は何が疑問なのだ? というと、1つめは「Sapphire Rapids、なんか無駄にサイズが大きくない?」という話である。
その1:ダイサイズの謎
Sapphire Rapidsはモノリシックダイ(タイル)のMCCと、4タイル構成のXCC、そのXCCの派生型のHBMの3種類があり、XCC(とHBM)の場合、400平方mmのタイルを4つつなぐ形の構成になる、という話は2021年のIntel Architecture Dayで公開された。
そしてこの4つのタイルは10個のEMIBで相互接続される、という話はHot Chip 33のTutorial Sessionで公開され(冒頭の図1)、「どうやって10個で接続するんだ?」という素朴な疑問が出てきた。そもそも図1の左図はもう全然実情に即してないというか、数すらあっていないわけで、単にイメージ図でしかない。
この疑問が解決したのは、1月10日の発表会のスライドである。要するに4つのタイル同士はUPIで接続されているのではなく、内部のリングバス同士を繋いでいる格好だ。
もともとSkylake-SP世代の初代Xeon Scalableから、内部のコアの接続はメッシュ構造になっていた。メッシュといっても縦方向と横方向はそれぞれリングバスで、これを組み合わせてメッシュにしていた。このスライドが分かりやすいかと思う。このリングバスを縦横に配したメッシュ構造は続くCascade Lake/Cooper LakeやIce Lake-SPにも引き継がれ、Sapphire Rapidsもこれを踏襲したわけだ。
図2はIntelが提供した、XCCのウェハ写真である。この中央部を拡大して縦横比を合わせたのが図3である。これは発表会のスライドで言えば、左側のXCCの構成の右上ないし左下のタイルにあたる。
さて、この中身に関するスライドの別の図版がこちら(図4)である。
ここで
- 各々のタイルは4×5で20個のブロックからなる。うち15個がCPU+L3キャッシュ(SFはSnoop Filter)で、ほかにDDR5 I/Fのブロック×1、UPI+DMIのブロック×1、PCIe/CXLのブロック×2、アクセラレータのとなっている
- 各々のタイルは5本(6本?)の横方向のリングバスと、2本の縦方向のリングバスでMesh構造となっている
- 横方向が5本か6本かは、例えば上側のタイルなら最上段ブロック、つまりUPI+DMIやCXL/PCIe、Acceleratorが並んでいるブロックの横方向のリングバスがシングルかダブルか、に起因する。図4だとこれはシングルリンクに見えるのだが、発表会のスライドの当該部分を無理やり引き伸ばしたもの(図5)をみると、リングストップが2つ重なっているように見える。ここからすると、ここのみデュアルリングの可能性が高い。これがデュアルリングだとすれば6本、実は単にシングルリンクだったとすると5本となる(ただ図5を見るとうっすらとだがリングが2つあるように見えるので、図4は概念図であって多分デュアルリングなのだと思う)
- 4つのタイルは、この縦方向及び横方向のリングで串刺しになっている。つまり縦方向は4本のリングをそれぞれ1つづつのEMIBで接続する形で、横方向は2本のリングをまとめて1つのEMIBで接続する(UPIやPCIeなどのI/Fブロックは、単独で1つのEMIBで接続する)形である。なので横方向のタイルの接続に6つ、縦方向のタイルの接続に4つで合計10個のEMIBが必要になる
と判断している。
さて、この内部構造を先ほどの図3に重ねたのが図6である。桃色が横方向のリングバス、緑色が縦方向のリングバスである。実際のXCCの写真を見ると、4つのタイルの間に明確に隙間があり、充填剤が挟まっていることが分かる。
タイルのギリギリから信号を出す、というのはちょっと難しいから、そう考えるとタイルを跨ぐEMIBでの配線長は最低でも1mmほどは必要になる(実際は2～3mmはありそう)。これは内部のリングバスの信号をそのまま出して通信するには厳しい距離で、それこそSynopsysのUSR(Ultra Short Range)PHYとか、UCIeを使いたくなるレベルである。こうした市販のPHYは実際には使ってないだろうが、外部出力用PHYなしで通信できる距離ではないのは間違いなく、何かしらのPHYを必要とする。図4でEMIB PHYと記した部分がここである。
もっともこれは逆説的な推定であって、コアの周りにこれだけ広いスペースがあり、無駄に空けてるのではないとすると、あり得るのはEMIBのPHY位しか考え付かないという話である。
ただいくら何でもこれはデカすぎる気もしなくはない。ちょっとPHYの大きさを広めにとったが、実際はもっと小さい気がする。そもそもタイルのサイズそのものをもう少し(18mm×18mmぐらいに)縮小しても問題はなさそうなきがするのだが、なぜこんなにデカいタイルサイズにしたのか? というのが1つめの謎だ。
その2:大きいPコアの謎
さて図4からCore+LLCの寸法を算出してみると、3.6mm×3.45mmというあたりで、おおむねね12.4平方mmになる。ちなみにこれは縦方向のリングバスの分(黄緑色の部分)は抜いて計算しており、これも加味すると4.2mm×3.45mmといったあたりになって、ほぼ13平方mmになるが、ここでは12.4平方mmの方の数字を取りたい。問題は「Intel 7によるPコア1個でこんなにデカかったっけ?」という話で、これが2つめの謎だ。
この謎を解消するためには、同じPコアを使う製品のダイを見てみればよい。要するにAlder Lakeだ。ダイ写真を探したところ、WikiChipにDavid Schor氏の撮影したものが上がっていた。ここからPコアとL3を切り出して(図7)、寸法を測定すると
- Pコア:2.24mm×3.27mm≒7.32平方mm
- LLC:2.24mm×0.84mm≒1.88平方mm
で、合計でも9.2平方mmにしかならない。もっともSapphire Rapidsの場合、PコアそのものはGolden Coveベースであるが、L2が1.25MB/コアから2MB/コアに増量されているので、この分を加味する必要がある。L2の領域は水色に示した部分で
- L2:1.60mm×1.00mm＝1.60平方mm
だが、これが1.25MB→2MBになると2.56平方mmほどになる。つまりPコアの合計サイズは8.28平方mmほどになる計算だ。
一方でL3はAlder LakeがPコア1個あたり3MBの容量なのに対し、Sapphire Rapidsは1.875MBでしかない。ということはLLCの面積は1.1平方mm程度になる計算だ。これを足しても9.38平方mmとなり、2.02平方mmほど計算が合わないことになる。Alder Lakeで言えばL3キャッシュのサイズよりもう少し広いぐらいのエリアだ。この差はどこから出たのか? というのが2つめの謎というわけだ。
ただこれに関して言えば、ある程度見えてはいる。この差分である2平方mm余りの面積を喰うものがAMXであろう、というのが筆者の推定である。
AMXはほかのアクセラレータと異なり、1つのPコアに1つずつ入っている(図10)。パイプラインとしてはPコアの外側にある格好だが、デコーダそのものはPコアのデコーダが実施し、その先は図9でいうところの“Tiles and Accelerator Commands”に放り投げる格好だ。
AMX命令として現状定義されているのは
- LDTILECFG：タイル構成のロード
- STTILECFG：タイル構成のセーブ
- TDPBF16PS：BF16を使ったdot-products
- TBPBSSD/TBPBSUD/TDPBUSD/TDPBUUD：INT8を使ったdot-products
- TILELOADD/TILELOADDT1：タイルのロード
- TILERELEASE：タイルの開放
- TILESTORED：タイルのセーブ
- TILEZERO：タイルの初期化
の12命令で、うちdot-productsの5命令はTMUL Engineで、残りはTile and Accelerator Command部でそれぞれ処理する形になるのだろう。先に図8の脚注で「Alder Lakeと『基本』同じ」と書いたのは、このAMX周りの命令をデコーダに追加するのと、CPUID周りにAMX対応の追加が入るからだが、それ以外はほぼ同じと考えて良い。
この主にデコード段の追加作業はデコード部のエリアサイズの増加はないと思われる。だから純粋にTMUL EngineとTILEが2平方mmの主な部分である。TILE自身はT0～T7まで8つあり、それぞれ1KB(8,192bit幅)である。レジスタだと思えばこれは結構デカいが、それでも合計8KBだから、AVX512のレジスタ(ZMM0～ZMM31まで、512bit×32で合計2KB)のほんの4倍に過ぎない。ということは、2平方mmの大半はTMUL Engineが占めているということになる。
まぁ8bitのMACエンジンを1,024個も並べば、そりゃ面積も食うだろうという話だが、本当にこれだけなのか、それともほかにもまだ何かあるのか、についてはもう少し詳細な情報がIntelから「出てくれば」もう少しクリアになるだろう。
その3:TMUL Engineの謎
これに絡む3つめの謎が「で、TMUL Engineはいくつずつ?」という話である。
先ほどの図9を見ると、TMUL Engineは2つ接続できることになっているが、「技術的には複数のアクセラレータを接続できる」と読むこともできる。そもそも、同じTMLUのアクセラレータを複数並べるというのが割と意味がないというか、リソースの無駄遣いな気もしなくはないし、図9にもアクセラレータ2はTMLUとは書いてないのだ。
技術的に言えば、例えばここにFFTのアクセラレータを入れるといったことも不可能ではないだろう(リソース的にはどうかと思うが)。
何でこんな疑問を抱いたか? というと、既にAMXのInstruction Referenceやサンプルコードが公開されているのだが、複数のアクセラレータを選択するようなコードが一切入っていないからだ。もちろん、例えばアウト・オブ・オーダー式に、Tiles and Accelerator Commandsブロックがうまく制御をしている可能性はある。ただサンプルソースの当該箇所を抜き出すと現在は
int8_t src1[MAX];
int8_t src2[MAX];
int32_t res[MAX/4];
:
(中略)
:
// Load tile rows from memory
_tile_loadd (2, src1, STRIDE); // 元データその1をsrc1からTILE 2にロード
_tile_loadd (3, src2, STRIDE); // 元データその2をsrc2からTILE 3にロード
_tile_loadd (1, res, STRIDE); // 加算前のデータをresからTILE 1にロード
// Compute dot-product of bytes in tiles
_tile_dpbssd (1, 2, 3); // dot-productsを計算(res+=src1×src2)
// Store the tile data to memory
_tile_stored (1, res, STRIDE); // 結果をTILE 1からresにストア
なんてソースになっている(日本語コメントは筆者が追加)。この_tile_loadd()とか_tile_stored()はIntelの提供するAMX用のInstinctで、例えば_tile_loadd()は
start := tileconfig.startRow
IF start == 0 // not restarting, zero incoming state
tilezero(dst)
FI
nbytes := dst.colsb
DO WHILE start < dst.rows
memptr := base + start * stride
write_row_and_zero(dst, start, read_memory(memptr, nbytes), nbytes)
start := start + 1
OD
zero_upper_rows(dst, dst.rows)
zero_tileconfig_start()
てな感じ。要するにタイルに8bitのINTをひたすら詰めてくだけのループで、これどう考えても_tile_dpbssd()よりも_tile_loadd()や_tile_stored()の方が時間が掛かっている。つまりTMUL engineを複数持つ性能上のメリットが皆無である。
もう1つ証拠を上げると、図10でAMXは“2048 INT8 ops/cycle/core”と書いてある。タイルのサイズは1KBだから、INT8なら1,024個格納できるわけだが、これのdot-productsだと乗算と加算がそれぞれ1,024回発生するわけで、これで2,048ops/cycleに相当する。
だから、タイルを512bitずつ2つのアクセラレータで分けて、それぞれdot-productsを実施して、その結果をまとめてタイルに書き戻すなんていうトリッキーな技を使わない限りは、2つで2,048ops/cycle/coreにならない。1つのTMULエンジンでまとめて1,024データのdot-productsを計算する(から2,048 INT8 ops/cycleになる)というのが普通の考え方だろう。
ということで、筆者はこのTMLU Engineは現在1つしか実装されていないと思うのだが、さてどうだろうか? というのが3つ目の謎である。この辺は今年(2023年)のISSCCかHot Chipsあたりで何か情報が出てくればスッキリするのだが。