Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

SDMA is Triton-only, and no collective uses it

Aperta
#593 1 commento 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

@ariscript ci sta già lavorando.

Dal 16/10/2026.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
18/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
python

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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).

Lingua principale
Python
Stelle
202
Fork
52
Merge medio
5g 2h
PR unite (30g)
23

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ROCm/iris

Tutte le issue di ROCm/iris

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.