Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

SDMA is Triton-only, and no collective uses it

Open
  • Is something wrong?
#593 1 comment 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 2 days

@ariscript is already working on this.

Since Oct 16, 2026.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
18/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
distributed-systems, hpc

Research direction

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.

Written by the indexing model from the issue text.

Description

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

Dominant language
Python
Stars
202
Forks
52
Avg merge
5d 2h
Merged PRs (30d)
23

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ROCm/iris

All issues in ROCm/iris

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.