Conversation
…lation not concurrency
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Phase 0 for the prefill/decode co-scheduling idea, measured on GPU0 (idle box) 2026-08-09.
docs/58+ the probe source inbenchmarks/cu_mask_probe.hip. Runs in under a minute, needs no model.Four of five hardware assumptions hold. The fifth is the interesting one.
hipExtStreamGetCUMaskread-backHW_IDper workgroup, not fromhipSuccessThe graph row was the one I expected to fail (undocumented; the mask binds to a dedicated HSA queue at stream creation, and
hipGraphLaunchcould plausibly route around it). It does not fail, which matters because vLLM decode is graph-replayed.The last row is why this is not a green light. HIP already overlaps independent streams here, so CU masking buys isolation, not concurrency — a real but strictly smaller property than the framing invites. And the probe kernel is pure-ALU spin, so it says nothing about HBM contention, which is where the interference actually lives given round 62 has decode at 10% of achievable bandwidth.
Two traps documented for whoever builds on this:
SE = bit % 8on 8 SE x 13 CU, so 13 contiguous bits span all eight shader engines, not one. Any "give decode N adjacent CUs" sweep is measuring a different partition than it thinks.Framed against the incumbent rather than against nothing: this has to beat
docs/52's already-adopted DP=2 (1.118x aggregate, 0.888x TPOT), and it contends for the board power budgetdocs/53shows is already binding on prefill — a kill criterion the original framing omitted.Ledger entry added. No production change.