You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A buffer created with Batch.empty(...) accepts exactly one put(). After the first successful put(), every subsequent put() silently copies nothing: num_graphs stops growing and no error or warning is raised. zero() is not required to trigger this: a plain put → put sequence drops the second copy too. The repro below uses put → zero → put only because it makes the symptom most visible (num_graphs stays 0).
Expected: a buffer with remaining capacity should accept further put()s, and zero() should restore the freshly-allocated state. At minimum, a dropped copy should raise or warn rather than silently no-op.
This also affects in-tree consumers that reuse a Batch.empty buffer:
GPUBuffer uses the same pattern but is not affected in practice: it already carries an explicit workaround (_restore_batch_ptr_capacity) that re-extends the trimmed batch_ptr after every write. This workaround was introduced in Buffer sync semantics #4, so the trimming behavior itself seems to be known; fixing it in put would make the workaround removable.
The distributed pipeline: _CommunicationMixin reuses pre-allocated send/recv buffers across steps with this exact pattern (_recv_to_batch does put then zero; _batch_to_buffer does repeated put), so every transfer after the first one would be silently dropped.
put #1 -> num_graphs = 1zero() -> num_graphs = 0
put #2 -> num_graphs = 0 (expected 1)
put #3 -> num_graphs = 0 (expected 2)
Environment details
Device-independent: reproduces on both CPU and GPU.
Not tied to any specific CUDA / GPU / PyTorch / Warp version.
Additional context
I have already tracked down the root cause (the first successful put() truncates the pre-allocated batch_ptr in SegmentedLevelStorage.put, so all later capacity checks fail) and have a fix in hand. I understand direct code contributions are not accepted during the public beta. Happy to open a PR once they are, or earlier if a maintainer assigns this issue to me.
Version
0.1.0 (also present on the latest
maincheckout)On which installation method(s) does this occur?
Pip, Source
Describe the issue
A buffer created with
Batch.empty(...)accepts exactly oneput(). After the first successfulput(), every subsequentput()silently copies nothing:num_graphsstops growing and no error or warning is raised.zero()is not required to trigger this: a plainput → putsequence drops the second copy too. The repro below usesput → zero → putonly because it makes the symptom most visible (num_graphsstays0).Expected: a buffer with remaining capacity should accept further
put()s, andzero()should restore the freshly-allocated state. At minimum, a dropped copy should raise or warn rather than silently no-op.This also affects in-tree consumers that reuse a
Batch.emptybuffer:GPUBufferuses the same pattern but is not affected in practice: it already carries an explicit workaround (_restore_batch_ptr_capacity) that re-extends the trimmedbatch_ptrafter every write. This workaround was introduced in Buffer sync semantics #4, so the trimming behavior itself seems to be known; fixing it inputwould make the workaround removable._CommunicationMixinreuses pre-allocated send/recv buffers across steps with this exact pattern (_recv_to_batchdoesputthenzero;_batch_to_bufferdoes repeatedput), so every transfer after the first one would be silently dropped.Minimum reproducible example
Relevant log output
Environment details
Additional context
I have already tracked down the root cause (the first successful
put()truncates the pre-allocatedbatch_ptrinSegmentedLevelStorage.put, so all later capacity checks fail) and have a fix in hand. I understand direct code contributions are not accepted during the public beta. Happy to open a PR once they are, or earlier if a maintainer assigns this issue to me.