[satyanveshd]

Motivation

hipMemcpyBatchAsync call waits on the host side after 16 dispatches causing delays in enqueue.

Technical Details

hipMemcpyBatchAsync API should reserve only the total descriptor size on the kernel arg pool for that dispatch and not the maximum amount of chunk memory that can be allocated each time.

Issue Tracking

JIRA ID: ROCM-30841

Test Plan

Verify with the provided reproducer that hipMemcpyBatchAsync doesn't wait on the host side after 16 dispatches causing dispatch latency.

Test Result

PASS

Submission Checklist

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

[therock-pr-bot]

✅ All Policy Checks Passed

Check	Status	Details
📝 PR Description	✅ Pass	—
⛔ Forbidden Files	✅ Pass	—
🧪 Unit Test	⚠️ Warning	Error: Source/code files changed without an accompanying unit test. Expected: add at least one test file named like test_<name>.py / test_<name>.cpp (or <name>_test.*). Current: code file(s) changed: projects/clr/rocclr/device/rocm/rocblit.cpp; no test file found
🚫 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?

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[marandje]

I would remove the comment as code is descriptive enough already.

[jaydeeppatel1111]

I would remove the comment as code is descriptive enough already.

Right, How about test to be added?, JIRA has already provided reproducer.

[satyanveshd]

I would remove the comment as code is descriptive enough already.

Right, How about test to be added?, JIRA has already provided reproducer.

This is not a functional issue. It is increasing the enqueue time of hipMemcpyBatchAsync API if more than 16 dispatches are enqueued after a long kernel in the same stream. This can affect performance but doesn't break anything as such. Hence there is no new unit test required to be added for this specific scenario.

[jaydeeppatel1111]

I would remove the comment as code is descriptive enough already.

Right, How about test to be added?, JIRA has already provided reproducer.

This is not a functional issue. It is increasing the enqueue time of hipMemcpyBatchAsync API if more than 16 dispatches are enqueued after a long kernel in the same stream. This can affect performance but doesn't break anything as such. Hence there is no new unit test required to be added for this specific scenario.

Thanks — fix looks right, not blocking.

Small nuance: hipMemcpyBatchAsync is an async enqueue, so blocking the host until the in-flight kernel finishes (~80 ms in the repro) is a behavior deviation, with perf as the visible symptom. hipMemcpyAsync doesn't do this, and 7.14 didn't either.

Also, nothing in hipMemcpyBatchAsync.cc catches it today — those cases verify bytes after sync and never wrap the 16 kernarg chunks. A small case there (long kernel, 17 count==1 calls, assert enqueue isn't ~kernel duration) would cover it but I let you decide.

Thanks!

[mangupta]

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

[systems-assistant]

TheRock Submodule Bump Activity

Newest first

• 2026-09-29 — Included in TheRock via ROCm/TheRock#8567.