Open
Conversation
It doesn't make sense currently to have CLC in a multicta context without multicast. As such, we hide this flag and we infer it automatically. The reason why it doesn't make sense it's because in multicta just one CTA is allowed to request to cancel. In CUDA you can imagine patterns like doing CLC without multicast and then share the result from one CTA to all the others manually. We don't allow that in Gluon.
Smelly bits: We execute CLC in the TMA partition to avoid having to create a new partition for CLC. I think we should create a different partition for CLC but I wanted to have @pawelszczerbuk's approval before doing it. We model CLC as we model TMA writes, via a Barrier::EffectWrites. The idea of this mode is that we link all the writes on the op to the barrier. We also annotate in the table `barrierWriteRecipients` which CTAs will become visible once we wait on the associated barrier. We note something interesting and document it. `BarrierTrackingMode::Frontier` should be used when we have a commit/arrive/expect op that affects anything in flight before it. Instead, we use `BarrierTrackingMode::EffectWrites` when the PTX op accepts a barrier so the barrier just signals the completion of the op's particular write. The other point we add is a flag `bool diagonalEffectRecipientCTAs`. This differentiates the behaviour between TMA, where after waiting on the barrier you see all the writes from all the CTAs in the multicas group, vs. the diagonal version, as in CLC, where waiting on CTAi just makes the thread see the CTAi memory.
pawelszczerbuk
approved these changes
Apr 16, 2026
Contributor
pawelszczerbuk
left a comment
pawelszczerbuk
left a comment
There was a problem hiding this comment.
Looks great! Small nit in the comments
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
2 participants
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.
CLC gets its own partition, running over threads 48-63.
We model CLC as we model TMA writes, via a Barrier::EffectWrites.
The idea of this mode is that we link all the writes on the op to the
barrier. We also annotate in the table
barrierWriteRecipientswhichCTAs will become visible once we wait on the associated barrier.
We note something interesting and document it.
BarrierTrackingMode::Frontiershould be used when we have acommit/arrive/expect op that affects anything in flight before it.
Instead, we use
BarrierTrackingMode::EffectWriteswhen the PTX opaccepts a barrier so the barrier just signals the completion of the op's
particular write.
The other point we add is a flag
bool diagonalEffectRecipientCTAs.This differentiates the behaviour between TMA, where after waiting on
the barrier you see all the writes from all the CTAs in the multicas
group, vs. the diagonal version, as in CLC, where waiting on CTAi just
makes the thread see the CTAi memory.