Skip to content

Support incontiguous logits and bitmask. - #359

Merged
Ubospica merged 1 commit into
mlc-ai:mainfrom
hnyls2002:lsyin/kernel-stride
Jul 18, 2025
Merged

Ubospica merged 1 commit into
mlc-ai:mainfrom
hnyls2002:lsyin/kernel-stride

Conversation

@hnyls2002

@hnyls2002 hnyls2002 commented Jul 11, 2025

Copy link
Copy Markdown
Collaborator

This PR supports incontiguous logits and bitmasks when applying token bitmasks (The vocab stride still requires to be 1)

@hnyls2002
hnyls2002 requested a review from Ubospica July 11, 2025 04:40

@Ubospica Ubospica left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! We can add a test and merge it

@Ubospica Ubospica added the high-priority High priorty PRs and issues label Jul 13, 2025
@Ubospica
Ubospica merged commit d411a7e into mlc-ai:main Jul 18, 2025
@Ubospica

Copy link
Copy Markdown
Collaborator

We can merge it for now and add tests later

Seven-Streams pushed a commit to CaiJohn/xgrammar that referenced this pull request Aug 25, 2026
fill_next_token_bitmask addressed bitmask rows as `data + index * buffer_size`,
assuming a compact layout, while apply_token_bitmask_inplace addresses them as
`data + idx * strides[0]`. For a non-contiguous bitmask the two disagree: the
mask is written to one row and read from another, leaving the requested logits
row entirely -inf. Nothing raises, and the shape checks cannot catch it because
a strided view has exactly the same shape as a contiguous one.

apply became stride-aware in mlc-ai#359 (CUDA) and mlc-ai#390 (CPU/Triton); fill never
followed. Before mlc-ai#390 both sides assumed the compact layout and therefore
agreed, so non-contiguous bitmasks worked end to end -- this is a regression
first released in v0.1.23.

Address rows by strides[0] when strides are present, matching apply. All three
callers of CheckAndGetBitmaskPtr are covered by the one change. Since a row is
read as a single packed DynamicBitset, the vocabulary dimension must remain
unit-stride; reject anything else rather than silently misreading it, matching
the constraint mlc-ai#359 already documents for CUDA.

Also fall back to the compact layout when strides is NULL in ApplyMask32Bits
and ApplyMask16Bits, which dereferenced it unconditionally. The vendored DLPack
is v1.0, where NULL strides is legal and means compact, and that header ships
in the package's include dir.
Seven-Streams pushed a commit to CaiJohn/xgrammar that referenced this pull request Sep 1, 2026
fill_next_token_bitmask addressed bitmask rows as `data + index * buffer_size`,
assuming a compact layout, while apply_token_bitmask_inplace addresses them as
`data + idx * strides[0]`. For a non-contiguous bitmask the two disagree: the
mask is written to one row and read from another, leaving the requested logits
row entirely -inf. Nothing raises, and the shape checks cannot catch it because
a strided view has exactly the same shape as a contiguous one.

apply became stride-aware in mlc-ai#359 (CUDA) and mlc-ai#390 (CPU/Triton); fill never
followed. Before mlc-ai#390 both sides assumed the compact layout and therefore
agreed, so non-contiguous bitmasks worked end to end -- this is a regression
first released in v0.1.23.

Address rows by strides[0] when strides are present, matching apply. All three
callers of CheckAndGetBitmaskPtr are covered by the one change. Since a row is
read as a single packed DynamicBitset, the vocabulary dimension must remain
unit-stride; reject anything else rather than silently misreading it, matching
the constraint mlc-ai#359 already documents for CUDA.

Also fall back to the compact layout when strides is NULL in ApplyMask32Bits
and ApplyMask16Bits, which dereferenced it unconditionally. The vendored DLPack
is v1.0, where NULL strides is legal and means compact, and that header ships
in the package's include dir.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

high-priority High priorty PRs and issues

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants