[saleelk]

hipExtMemcpyBatchAsync has no graph support. Add a hipGraphNodeTypeExtMemcpyBatch
node whose parameters mirror hipExtMemcpyBatchAsync: sizesDst for asymmetric
swap, the reserved waits/signals arrays, and hipExtMemcpyAttributes.

The node is reachable three ways: explicitly via hipGraphAddExtMemcpyBatchNode,
or by capturing hipExtMemcpyBatchAsync or hipMemcpyBatchAsync, both of which go
through STREAM_CAPTURE. hipExtMemcpyBatchAsync previously rejected capture with
hipErrorStreamCaptureUnsupported.

Argument validation is shared with the stream path (ihipValidateMemcpyBatch), so
node add/set and the stream APIs reject the same inputs. Classification is
shared too, so asymmetric swaps decompose identically on both paths.

Parameter updates work through hipGraphExtMemcpyBatchNodeSetParams,
hipGraphExecExtMemcpyBatchNodeSetParams and hipGraphExecUpdate.

Tests: catch/unit/graph/hipGraphAddExtMemcpyBatchNode.cc covers explicit
construction and capture of both batch APIs, parameter get/set, exec update, a
batch sandwiched between two kernel nodes, a peer-to-peer broadcast and an
asymmetric swap. Unit_hipExtMemcpyBatchAsync_StreamCapture_Negative becomes
_Positive.

Stacked on #9098 (hipExtMemcpyBatchAsync); targets its branch so only this commit shows. Retarget to develop once #9098 merges.

[mangupta]

🤖 AI-assisted pre-review (for @mangupta)

[IMPORTANT] No contract test or uncovered_apis.txt rationale for the four new public graph APIs

The PR adds four public HIP APIs to hip_runtime_api.h: hipGraphAddExtMemcpyBatchNode, hipGraphExtMemcpyBatchNodeGetParams, hipGraphExtMemcpyBatchNodeSetParams and hipGraphExecExtMemcpyBatchNodeSetParams. It also adds the public enum value hipGraphNodeTypeExtMemcpyBatch. It does not add a projects/hip-tests/catch/contract/ test with an @asserts: API - invariant annotation, does not add an entry to catch/contract/uncovered_apis.txt, and does not update catch/TEST_PLAN.md.

Suggested fix: For each new API, add contract tests under catch/contract/ following AUTHORING.md, for example: null pGraphNode → hipErrorInvalidValue; wrong node type for GetParams → hipErrorInvalidValue; a count change through ExecSetParams → hipErrorInvalidValue. Alternatively, add a concrete rationale to uncovered_apis.txt. Then regenerate catch/TEST_PLAN.md.

[IMPORTANT] rocprofiler-sdk gets ABI asserts for the new dispatch entries but no API IDs, argument plumbing, or hip.def.cpp registration

The PR adds four HipDispatchTable entries (step version 39) and HIP_API_IDs 492–495 in hip_prof_str.h. On the rocprofiler-sdk side it only adds ROCP_SDK_ENFORCE_ABI lines in abi.cpp and a format.hpp case for the new node type. It does not add the API to runtime_api_id.h, api_args.h, or hip.def.cpp. Without those, rocprofiler-sdk cannot assign callback/buffer-tracing operations to the new APIs, so calls to them would not show up in HIP API traces.

Suggested fix: Following the pattern used for earlier step versions, add ROCPROFILER_HIP_RUNTIME_API_ID_hipGraphAddExtMemcpyBatchNode and the other three IDs, guarded by HIP_RUNTIME_API_TABLE_STEP_VERSION >= 39, to runtime_api_id.h. Add matching argument structs to api_args.h and HIP_API_INFO_DEFINITION entries to hip.def.cpp. If they are intentionally deferred, say so in the PR and add a follow-up.

[SUGGESTION] No CHANGELOG entry for the new graph APIs and capture behavior; hipMemcpyBatchAsync doc doesn't mention capture

The PR adds four public APIs, a new public hipGraphNodeType value, and stream-capture support for hipExtMemcpyBatchAsync, which previously returned hipErrorStreamCaptureUnsupported. It also adds capture support for hipMemcpyBatchAsync. projects/clr/CHANGELOG.md is not updated. Only the hipExtMemcpyBatchAsync doxygen was updated for capture; the hipMemcpyBatchAsync doxygen was not changed to say that capture now records a hipGraphNodeTypeExtMemcpyBatch node.

Suggested fix: Add a CLR CHANGELOG entry listing the new APIs, the node type, and the capture support. Update the hipMemcpyBatchAsync doxygen to describe its capture behavior and the restrictions (no host-to-host, single device).

[mangupta]

🤖 AI-assisted pre-review (for @mangupta)

[IMPORTANT] Graph batch node accepts host-to-host and cross-device batches at add/capture/SetParams time and only fails later at instantiate/launch

The graph path cannot run host-to-host entries or entries that classify to a device other than the stream's device. ihipMemcpyBatchCreateCommands returns hipErrorNotSupported for both. That check only runs from GraphExtMemcpyBatchNode::CreateCommand, which executes when the graph is instantiated or launched. hipGraphAddExtMemcpyBatchNode, hipGraphExtMemcpyBatchNodeSetParams, hipGraphExecExtMemcpyBatchNodeSetParams and the two capture paths (capturehipMemcpyBatchAsync / capturehipExtMemcpyBatchAsync) call only ValidateExtMemcpyBatchNodeParams, which calls ihipValidateMemcpyBatch. That function checks argument shape and never classifies the copies. So these calls return hipSuccess for a batch the node can never execute.

Suggested fix: Run ClassifyMemcpyBatch at node add, capture, and SetParams time, using the target device: the capturing stream's device for capture, and the current device for explicit add, recorded on the node. Return hipErrorNotSupported, with failIdx where one is available, for host-to-host or cross-device entries. When capture rejects a batch, invalidate the capture the same way other unsupported captured operations do. Then align the doxygen with the error-reporting point, and add negative tests that add and capture a host-to-host batch and expect hipErrorNotSupported from the add/capture call.

[mangupta]

🤖 AI-assisted pre-review (for @mangupta)

[SUGGESTION] Capture path of hipMemcpyBatchAsync returns before failIdx is set to SIZE_MAX

STREAM_CAPTURE is placed before if (failIdx != nullptr) *failIdx = SIZE_MAX;. On a capturing stream the API returns from inside STREAM_CAPTURE, so failIdx is never reset. For success, and for errors not tied to one entry (for example count == 0 or invalid attrs), the caller gets whatever stale value was in failIdx instead of SIZE_MAX. The non-capture path does reset it.

Suggested fix: Move the *failIdx = SIZE_MAX assignment above STREAM_CAPTURE, or set it at the start of capturehipMemcpyBatchAsync, so both paths report failIdx the same way.

[andraghetti]

HRR side only: the hipExtMemcpyBatchAsync capture and replay, with pointer translation for the arrays and the 16-entry limit documented, look right.

[andraghetti]

Running gen_hrr_api_args.py at a039890 gives HRR_API_COUNT = 562, not 558: the four hipGraph*ExtMemcpyBatchNode* slots this PR adds to HipDispatchTable are missing from the checked-in HRR files. So a graph built with hipGraphAddExtMemcpyBatchNode is captured without that node and replays without its copies. Regenerating the three files fixes it.

[andraghetti]

Regenerating adds the slots but does not replay the node. hipExtMemcpyBatchNodeParams holds the same pointer arrays as hipExtMemcpyBatchAsync, so hipGraphAddExtMemcpyBatchNode and both SetParams calls need matching Deref entries in gen_hrr_api_args.py.

[andraghetti]

develop is already at v9, with hipKernelSetAttributeForDevice at 547 (#13472). The APIs added here move the compiler IDs again, so once this targets develop it needs v10; otherwise a v9 archive from develop decodes __hipPopCallConfiguration (548) as hipExtMemcpyBatchAsync.

[andraghetti]

#9098 landed on develop as v12 with HRR_API_COUNT 559, so after the rebase this needs v13.

[cfreeamd]

🤖 AI-assisted pre-review (for @cfreeamd)

The ROCr changes thread an optional dst_size_list (per-entry dst-side swap sizes) through DmaCopyFanOutOp → SubmitBodies → BuildWaitSignalSwapCommand, plumbing asymmetric-swap sizing while keeping the feature gated behind the new NativeAsymmetricSwapSupported() (false for all current BlitSdma instantiations). Symmetric copy/swap throughput is unchanged — b_size(d) collapses to size_list[d] whenever the op is non-swap or dst_size_list == nullptr. Completion-signal ordering is untouched; only per-chunk byte counts and the addr↔size pairing changed.

[cfreeamd]

🤖 AI-assisted pre-review (for @cfreeamd)

[Question] The swap here flips sizes_a[i], sizes_b[i] → sizes_b[i], sizes_a[i] so addr_a (dst) is paired with the dst size — correct pairing, inert for symmetric entries where sizes_a==sizes_b. But is the fused coordinator actually reachable for asymmetric swaps in this PR, or only in the follow-up asym-swap branch? If asymmetric swaps can't reach it yet, consider adding an assert here too (sizes_a[i]==sizes_b[i]) to mirror the classic and wait/signal-swap builders and make all three paths fail consistently until native support lands.

[cfreeamd]

🤖 AI-assisted pre-review (for @cfreeamd)

[Optional] Good defensive assertion. Note that it is debug-only: in a release build, if a future NativeAsymmetricSwapSupported()==true blit somehow routes an asymmetric entry through this classic path, BuildSwapCopyCommand(... size_list[d]) would silently use the src size and emit a wrong copy with no error. The real guarantee is that native-asymmetric blits must never use this builder. Consider a hard return HSA_STATUS_ERROR_INVALID_ARGUMENT instead of (or in addition to) the assert, or a comment pointing at the follow-up branch so reviewers know this assert is load-bearing until that work merges.

[cfreeamd]

🤖 AI-assisted pre-review (for @cfreeamd)

[Optional] engines[d].blit->NativeAsymmetricSwapSupported() is dereferenced for each entry before the main dispatch. Worth confirming that engines[d].blit is guaranteed non-null for all d < num_entries at this point (the downstream fan-out code clearly assumes valid engines, so this is likely fine — just worth a quick check in the context of the broader function).

[therock-pr-bot]

✅ All Policy Checks Passed

Check	Status	Details
📝 PR Description	✅ Pass	—
⛔ Forbidden Files	✅ Pass	—
🧪 Unit Test	✅ Pass	—
🚫 Draft PR	🔜 To Be Enabled	—
🚩 Feature Flag	🔜 To Be Enabled	—
📊 Code Coverage	🔜 To Be Enabled	—

🎉 All policy checks passed!

📖 Need help? See the Policy FAQ for details on every check and how to fix failures.

🙋 Wish to Override Policy?

[andraghetti]

Checked on MI350 (gfx950) at a039890 with a standalone program, develop b09c3ab as control.

[andraghetti]

hipMemcpyBatchAsync lost the numAttrs > count check that ran before this conversion. count=1, numAttrs=SIZE_MAX now throws in resize and returns hipErrorUnknown, both immediately and under capture; develop returns hipErrorInvalidValue. Restore the check ahead of ihipToExtMemcpyAttributes in hipMemcpyBatchAsync and capturehipMemcpyBatchAsync.

[andraghetti]

This call leaves capture at its default true, so a batch node added to the graph from hipStreamGetCaptureInfo_v2 is not registered as a manual node. hipStreamEndCapture then returns hipErrorStreamCaptureUnjoined; the same flow with hipGraphAddEmptyNode returns hipSuccess. Pass false, as hipGraphAddEmptyNode does.

[andraghetti]

BatchBuffers keeps dsts_, srcs_ and sizes_ alive and unchanged, so a node that aliased the caller's arrays would also pass this relaunch. Overwrite the arrays after BuildBatchGraph so the test checks the copy.