Repository navigation
Split off the cooperative queue from the xfer queue - #13665
Conversation
❌ PR Check — Action Required
📖 Need help? See the Policy FAQ for details on every check and how to fix failures. |
|
🚫 Please fix the failed policies before requesting reviews. The following policy checks failed:
The |
|
This will reduce the exposure of the problem rocgdb has with cooperative queues. |
There was a problem hiding this comment.
🟡 Changes recommended
Dynamic queue reclamation can leave the transfer queue without a hardware queue, causing subsequent kernel-backed transfers to crash.
1 open finding
What changed in this PR
Separates ROCm’s internal transfer queue from cooperative launches so cooperative hardware queues are allocated only when needed.
Changes:
- Creates a non-cooperative internal transfer queue.
- Adds lazy cooperative-queue creation and cleanup.
- Routes cooperative kernel launches through the new queue.
| File | Description |
|---|---|
| projects/clr/rocclr/device/rocm/rocvirtual.cpp | Uses the cooperative queue for cooperative launches. |
| projects/clr/rocclr/device/rocm/rocdevice.hpp | Declares separate queue state and accessors. |
| projects/clr/rocclr/device/rocm/rocdevice.cpp | Implements separate queue creation and cleanup. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
f7d21af to
33f6eaa
Compare
|
🤖 AI-assisted pre-review (for @mangupta) Re-reviewed the updated head ( |
|
🤖 AI-assisted pre-review (for @mangupta) Re-reviewed the updated head ( |
|
🤖 AI-assisted pre-review (for @mangupta) Re-reviewed the updated head ( |
|
🤖 AI-assisted pre-review (for @mangupta) Re-reviewed the updated head ( |
|
🤖 AI-assisted pre-review (for @mangupta) Re-reviewed the updated head ( |
|
🤖 AI-assisted pre-review (for @mangupta) Re-reviewed the updated head ( |
|
🤖 AI-assisted pre-review (for @mangupta) Re-reviewed the updated head ( |
Make the internal xfer queue non-cooperative and add a separate coopQueue, created lazily on the first cooperative launch. Route both through createVirtualDevice() via a new cooperative argument, and pin the non-cooperative xfer queue before create() so its HW queue is not reclaimed.
cc30958 to
0ff9414
Compare
|
🤖 AI-assisted pre-review (for @mangupta) Re-reviewed the updated head ( |
|
hi @b-sumner ! thanks for this PR, i notice you enabled i noticed those jobs (particularly gfx117X) were massively queued. i cancelled the job! |
|
I have created PR 14396 to eliminate some of the false failures that are showing up here. |
|
🤖 AI-assisted pre-review (for @mangupta) Re-reviewed the updated head ( |
|
🤖 AI-assisted pre-review (for @mangupta) Re-reviewed the updated head ( |
|
🤖 AI-assisted pre-review (for @mangupta) Re-reviewed the updated head ( |
|
✅ Author chose to skip pr bot run hence removing label ( |
|
🤖 AI-assisted pre-review (for @mangupta) Re-reviewed the updated head ( |
|
Errors are unrelated to PR's content, overriding. |
TheRock Submodule Bump ActivityNewest first
|

Motivation
Split the ROCm internal device queue into a general transfer queue and a cooperative queue
The single internal VirtualGPU (xferQueue_) served both as the blit/transfer queue (xferMgr() and friends) and as the device's cooperative-launch queue, so it was created as an HSA_QUEUE_TYPE_COOPERATIVE queue whenever HIP coop groups were enabled — even though only the coop-launch path needs cooperative semantics.
This separates the two roles:
A cooperative HW queue is now allocated only when a cooperative launch actually occurs, rather than for every HIP process. The two queues each own their blit lock; transfers and coop launches are still ordered by the existing CPU-synchronous blit path and barrier-signal handshakes, not by queue sharing.
No functional change for transfers; cooperative-launch semantics (GWS init, barriers, exclusive access) are unchanged beyond the accessor name.
Test Plan
All existing tests should run unchanged
Test Result
Tests I tried ran unchanged
Submission Checklist
@skip-pr-bot