Skip to content

cherry-pick: #10161 and #10640 into therock-10.1-20260825 - #10873

Merged
sdarisala merged 2 commits into
release/bkc/therock-10.1-20260825from
rccl-cherry-pick-0907/10640-10161-bkc-10.1-20260825
Aug 28, 2026
Merged

sdarisala merged 2 commits into
release/bkc/therock-10.1-20260825from
rccl-cherry-pick-0907/10640-10161-bkc-10.1-20260825

Conversation

@sdarisala

Copy link
Copy Markdown
Contributor

Cherry-picks (via merge commits):

nileshnegi and others added 2 commits August 27, 2026 23:06
## Motivation

The Rome model-matching logic in `rome_models.cc` contains hardcoded
topology patterns for specific AMD GPUs (MI2XX and MI3XX series). These
patterns define optimized ring/tree topologies based on known GPU-to-GPU
connectivity matrices.

gfx1250 has a different interconnect topology that doesn't match any
existing Rome model. When the matcher attempts to find a matching model
and fails, it falls back to generic search anyway, but only after
wasting cycles on futile pattern comparisons. More critically, a partial
or incorrect match could select a suboptimal topology.

This change proactively skips Rome model matching for gfx1250, ensuring
the generic topology search algorithm is used from the start.

## Technical Details

- Modified the `skipPresetTopoMatching` assignment in
`initTransportsRank()` to include an architecture check
- When `comm->topo->nodes[GPU].nodes[0].gpu.gcn` matches "gfx1250",
preset matching is skipped. Rome model parsers (parseChordalRing,
parseA2a8P, parseRome4P2H, parse1H16P, parse4H4P, parseGIOTopos) are
bypassed.
- Control falls through to the generic `ncclTopoSearchRec()` algorithm

## Issue Tracking

JIRA ID: AICOMRCCL-1932

---------

Co-authored-by: Claude <noreply@anthropic.com>
…XGMI peers (#10640)

## Motivation
RCCL topology on AMD compute-partitioned GPUs (gfx1250 DPX/XCP and
MI300X CPX) was aborting or building a wrong graph. HIP reports logical
partitions as extra PCI functions (.1–.7), but only the physical
function .0 exists in sysfs as a GPU. NCCL 2.30’s MLOPart overlay
originally used those same function bits, so the two encodings collided.

## Technical Details
MLOPart is NVIDIA’s name for a logical GPU partition of one physical GPU
(Blackwell/GB200 “uGPU”). CUDA exposes two devices that share a PCI BDF
and tags the name as MLOPart0 / MLOPart1. NCCL 2.30 parses that string,
then overlays a partition index onto the packed bus ID so the DEV nodes
stay unique while still grouping as siblings when those bits are masked
off.

RCCL reuses that overlay for HIP logical GPUs. HIP names have no
"MLOPart" tag; the index is taken from the HIP PCI function instead. On
this hardware the HIP aliases are not real endpoints: DRM/sysfs GPU is
only ….00.0, and a non-zero function may be a NIC or missing entirely.

The overlay now sits above the 36-bit PCI bus ID
(NCCL_TOPO_MLOPART_SHIFT=36, enable bit + 3-bit index, DEV_MAX=8) so
partitions 0–7 hang off the physical PCI node without clobbering the
function nibble. Genuine NVIDIA MLOPart siblings still group after
masking.

### Failures this PR fixes

1. MLOPart overlay used PCI function bits [1:0]. HIP can expose sibling
partitions as ….00.0 / .1 (and CPX .0–.7), so ncclTopoCheckMloPartBusId
aborted even when HIP names have no "MLOPart" tag. A 2-partition mask
also could not represent CPX.
2. XGMI tclass came from sysfs at the HIP BDF. A HIP alias such as
0001:01:00.1 can be a NIC (0x028000) or missing, so a GPU–GPU hop was
typed as a switch/NIC instead of NVL.
3. HIP “fake” PCI functions were treated as extra endpoints. Logical
GPUs were hung off a NIC node or a non-existent PCI function instead of
the physical GPU.
4. AllGather3 looked up the GPU by raw comm->busId. After the DEV
overlay, node ids are NCCL_TOPO_GPU_LOCAL_ID of the overlaid DEV, so
partition ranks missed. Match NCCL and use ncclTopoRankToIndex.
5. XGMI DEV lookup used the raw HIP BDF. On packages where the physical
GPU is already at a non-zero function (XCP .1), lookup must match
overlay DEV on the same domain:bus:device regardless of physical
function.
6. Unconfigured ualink (link_type=invalid) is a node setup issue, not a
missing interconnect. UALoE is used only when fabric is ready/active;
otherwise fall back to 1-hop XGMI.

## What changed

## Issue Tracking

- Move MLOPart overlay from PCI function [1:0] to [39:36] (SHIFT=36,
mask 0xf << 36: enable + 3-bit index 0–7), below GPU local rank (bit
40). Real PCI IDs never occupy those bits.
- Stamp mlopart from the HIP PCI function (0–7) when that function is
not a GPU in sysfs. Remap HIP alias BDFs to the physical .0 PCI node and
attach all partition <gpu>s under it.
- Stamp direct 1-hop XGMI (and UALoE) peers with tclass=0x120000
(PCI_ACCELERATOR_CLASS) at XML creation. AMD fill-missing-tclass trusts
sysfs only for GPU / accelerator / NVSwitch; NIC or missing class stays
accelerator.
- ncclTopoGetDevForPciBusId: if the exact busId misses, match an overlay
DEV on the same domain:bus:device whose MLOPart index equals the HIP
function nibble (covers physical GPUs at .1).
- alt_rsmi findCardForBdf: exact BDF first; if function ≠ 0 and miss,
retry function 0.
- AllGather3 / topo_expl: look up the GPU node by rank, not raw busId.
- Tests: overlay vs function nibble; eight CPX partitions under one
physical PCI; XGMI when the physical GPU is at .1; alt_rsmi
fake-function fallback to fn 0. Init microtests stub
ncclOsGetPciDeviceClassByBusId.

JIRA ID : ROCM-29722

## Test Plan

- rccl-UnitTestsFixturesDebug --gtest_filter='TopoTest.*'
- rccl-UnitTestsAltRsmi
--gtest_filter='AltRsmiTest.FabricInfo_FakePciFunctionFallsBackToFn0'
- Topology dump with NCCL_CUMEM_ENABLE=0 NCCL_TOPO_DUMP_FILE=… on
gfx1250 DPX (-np 2) and MI300X CPX (8 and 64 HIP devices)
- Dump matches with default alt_rsmi (unset RCCL_USE_AMD_SMI_LIB)

    
## Test Result
DebugFast + tests built. All 12 TopoTest cases passed (existing +
overlay/CPX/XCP). Alt-RSMI fake-function fallback passed.

On MI300X CPX (8 physical GPUs × 8 HIP partitions): 8-GPU dump has
mlopart=0..7 under one physical PCI (0000:0c:00.0); 64-GPU dump has 64
<gpu>s with mlopart, 8 physical PCI parents, and XGMI links stamped
tclass=0x120000.

On gfx1250 DPX, both ranks sit under 0001:01:00.0 with mlopart=0/1 and
bidirectional XGMI. sendrecv_perf can still report an internal error
after graph search on that package (nChannels / path typing); that is
separate from PCI placement.

## Submission Checklist

- [ ] Look over the contributing guidelines at
https://github.com/ROCm/rocm-systems/blob/develop/CONTRIBUTING.md.

---------

Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Nilesh M Negi <Nilesh.Negi@amd.com>
Co-authored-by: Claude <noreply@anthropic.com>
@sdarisala
sdarisala requested review from a team August 28, 2026 06:27
@sdarisala
sdarisala requested a review from a team as a code owner August 28, 2026 06:27
@HereThereBeDragons

HereThereBeDragons commented Aug 28, 2026 •

Copy link
Copy Markdown
Contributor

can you add bkc/ to the title? to make it clear which release stream it belongs to (also applicable to your other pr)

@ScottTodd

Copy link
Copy Markdown
Member

Is there any particular CI signal you want to check on this, or should we just merge without waiting for longer, then pull this into the release branch in TheRock?

@sdarisala

Copy link
Copy Markdown
Contributor Author

Is there any particular CI signal you want to check on this, or should we just merge without waiting for longer, then pull this into the release branch in TheRock?

Let me check the build failure on ubuntu + gfx950 combination.

@sdarisala

Copy link
Copy Markdown
Contributor Author

Is there any particular CI signal you want to check on this, or should we just merge without waiting for longer, then pull this into the release branch in TheRock?

Let me check the build failure on ubuntu + gfx950 combination.

I checked the failure. The failure comes from a link time failure of a test binary. The release branch is missing a commit from develop #10624, which fixes the test binary linkage failure. The RCCL library itself builds successfully and RockCI build itself has passed.

@sdarisala
sdarisala merged commit ad6708a into release/bkc/therock-10.1-20260825 Aug 28, 2026
64 of 70 checks passed
@sdarisala
sdarisala deleted the rccl-cherry-pick-0907/10640-10161-bkc-10.1-20260825 branch August 28, 2026 22:07
@ScottTodd

Copy link
Copy Markdown
Member

The release branch is missing a commit from develop #10624, which fixes the test binary linkage failure.

Do you want that commit cherry-picked also?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants