SDMA is Triton-only, and no collective uses it

オープン
  • 何か問題がありますか？
#593 コメント 2 件 リアクション 0 件 担当者 1 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@ariscript がすでに取り組んでいます。

2026年10月16日 から。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
18/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
python
領域
distributed-systems, hpc

調査の方向性

Start by comparing how copy_engine_ctx and use_copy_engine are threaded through put in iris/mem/triton/ops.py (around line 280) with the Gluon put in iris/mem/gluon/context.py, then read the all-gather kernels in iris/ccl/triton/ and iris/ccl/gluon/. The first step is the Gluon signature mirror. Done means the Gluon call accepts the same arguments and the SDMA all-gather matches torch.distributed on 2, 4 and 8 ranks. The design choices (a Config engine axis versus a variant name) need maintainer input before coding.

索引モデルが issue の本文から書いたものです。

説明

enhancement gluon help wanted iris

SDMA is Triton-only, and no collective uses it

Checked on main @ 6462f028.

Where SDMA exists today

iris/mem/triton/ops.py exposes copy_engine_ctx / use_copy_engine on four
entry points:

op def at
put 280
atomic_add 511
atomic_cas 638
quiet 964

Where it does not

Gluon has no SDMA surface. iris/mem/gluon/context.py mirrors the Triton RMA
set — load, store, get, put, copy, and nine atomics — but none of them
take a copy-engine argument, and sdma appears nowhere under iris/mem/gluon/.

No collective uses SDMA on either backend. grep -r "sdma\|copy_engine" iris/ccl/ returns nothing. Every kernel under iris/ccl/triton/ and
iris/ccl/gluon/ moves bytes with CU loads and stores.

So SDMA is available to someone hand-writing a Triton kernel against the RMA
primitives, and to nobody else. ctx.ccl.* cannot reach it.

Note the shape this leaves us in: the Gluon backend does have TDM
(iris/ccl/gluon/all_gather_tdm.py, #585, gfx1250), so Gluon got the newer
data-movement engine but not MI300-series copy engines, and the collectives got
neither.

Scope

Two pieces, in order:

  1. Gluon copy-engine surface — add copy_engine_ctx / use_copy_engine to
    IrisDeviceCtx.put (and the atomics that have it on the Triton side), matching
    the Triton signatures so kernels can move between backends.
  2. An SDMA collective — one collective, one backend, as a proof point. All-gather
    is the natural first: the transfer is a contiguous per-destination copy, which
    is exactly the contiguous_copy=True path put already supports.

Work

  • Mirror copy_engine_ctx / use_copy_engine in iris/mem/gluon/context.py
  • Add a copy-engine all-gather variant behind all_gather_variant="sdma"
  • Decide whether Config grows an engine axis or SDMA stays a variant name
  • Correctness vs torch.distributed on 2/4/8 ranks before timing
  • Benchmark vs the CU-driven variants through benchmark/ccl/bench_all_gather.py,
    which already has a comm_sms axis — the interesting number is CU count at
    equal bandwidth, not bandwidth at equal CU count

Related

#568 (engines= / copy-engine API), #573 (triggered SDMA), #585 (TDM all-gather).

主要言語
Python
スター
203
フォーク
57
平均マージ
3日 7時間
マージ済み PR（30日）
31

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

ROCm/iris のほかの issue

ROCm/iris の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。