AMD、MI300Xで連続ロード13個超の発行ストールを検証

AMDのROCmブログは、AMD Instinct MI300X上でロック・ステップ実行されるカーネルを対象に、デバイスメモリロードの発行ストールを検証した記事を公開しました。4 waves per workgroupの構成では、1 waveあたり13個までの連続global_load_dwordx4ならストールなしで発行でき、14個で平均約5 cycles/operation(最大356 cycles)のストールが生じます。

AMD InstinctはAMDのデータセンターAI・高性能計算向けアクセラレーター製品群で、ROCmはAMDのGPU計算向けオープンソフトウェア群です。著者はAkash Dutta、Hideki Saito Ido、Michael Selehov、Lawrence Meadows、David Tannerの5名です。

何を検証したか

ベースラインは、各内側ループ反復の先頭に16個のglobal_load_dwordx4を集中させ、続けて依存するVALU・MFMA処理を置き、反復間をs_barrierで同期する構成です。dwordx4は128ビット(4 × 32ビット)のロードです。理想的には16ロードは64 cycles(SIMDあたりquad cycleで発行、16×4)で発行できますが、実測ではSIMD 2で最長704 cyclesの発行待ちが発生しました。VMEMロードは1 CUあたり各issue slotで最大1つしか発行できず、大量の連続ロードがVMEMサブシステムを過負荷にします。

バリアを外すとwaveの自然なずれが生じ、16ロードの発行は1反復あたり80〜152 cyclesまで縮みました。ただしバリアなしではLDSの読み書き順序が保てず、tiled GEMMの結果が誤るため、記事はバリアを維持したまま改善する方法を検討しています。観測結果はbuffer_load_dwordx4にも適用できるとしています。flat_load_dwordx4は対象外です。

13ロードの境界と性能カウンター

最初のs_barrier直後のループ先頭にs_waitcnt vmcnt(0)を置き、連続ロード数を16→14→13→12と減らすと、12と13ではストールが消え、14では残りました。この13ロードの限界は1または2 workgroups per CUのどちらでも同じでした。

指標(13→14ロード)	変化
SQ_WAIT_INST_ANY(命令発行待ちサイクル)	約2.6倍
TA_ADDR_STALLED_BY_TC(L1へのアドレス経路ストール)	約1.4倍
TCP_PENDING_STALL(L1の未完了リターン待ち)	約1.1倍
平均ロード発行ストール	約0 → 約5 cycles/op(最大356)

L1・L2ヒット率はそれぞれ約50%、約80%でほぼ一定でした。記事は、追加のストールがL1のリターン時間ではなく、ロードが発行として受け付けられる前に生じていると結論づけています。

試し方と対策

• ループ先頭の最初のs_barrier直後にs_waitcnt vmcnt(0)を置き、同時VMEMトラフィックを減らす
• 連続するglobal_load_dwordx4/buffer_load_dwordx4を1 waveあたり13個までに抑える
• ロードをループ先頭に集中させず、スケジューラがロードと計算をインターリーブできるようにする
• SQ_WAIT_INST_ANY、TA_ADDR_STALLED_BY_TC、TCP_PENDING_STALLで発行待ちやL1経路のストールを調べる。プロファイリングはrocprofv3のガイダンスを参照できる

実験では各シナリオのアセンブリを手動で変更・リンクしてGPU上の挙動を比較しています。