Add cuda.core.NDBuffer #674

Activity

1. leofang

   added this to the cuda.core parking lot milestone on Jun 2, 2025
2. leofang

   added

   triageNeeds the team's attentionNeeds the team's attention

   P1Medium priority - Should doMedium priority - Should do

   featureNew feature or requestNew feature or request

   cuda.coreEverything related to the cuda.core moduleEverything related to the cuda.core module

   on Jun 2, 2025
3. leofang commented on Jun 4, 2025

   

   leofang

   on Jun 4, 2025

   MemberAuthor

   More actions

   Capturing what Satya noted in an offline meeting:

   I think NDBuffer is useful for two reasons:

   • While it's possible for users to compute the offset themselves, it's better to do that as part of the type so that each user is not burdened with it.
   • We can offer efficient copy functions across layouts that users can take advantage of. While it's straightforward to write a copy function, it's hard to write a performant copy function.
4. kkraus14 commented on Jun 4, 2025

   

   kkraus14

   on Jun 4, 2025

   Collaborator

   More actions

   • I think it should be owning (I was wrong in one of the meetings today) because Buffer is owning too. That'd make this NDBuffer look more like mdarray ([FEA]: Provide mdarray cccl#2474; see also Raft's counterpart and p1684).

   The name NDBuffer is very confusing to me as I think of a Buffer as an untyped region of memory. I think using ndarray (more Python than mdarray?) is a more natural name, though we don't want to give the impression we will have all of the functionality that Python users expect of an array and we are purely a data container.

   As far as ownership semantics go, we could take the NumPy like approach, where instead of StridedMemoryView that is purely a non-owning class, we could have a single class that can act as both an owning type (where it allocates a Buffer underneath itself on construction as needed) or a view type (where it holds a reference to a Python object that supports __dlpack__ protocol or similar).
5. cpcloud commented on Nov 17, 2025

   

   cpcloud

   on Nov 17, 2025

   Contributor

   More actions

   It seems like we've already gone down the path of the dual-ownership numpy-like model, since StridedMemoryView has an exporting_obj member that is the owning object of the data backing the view.

   👍React with 👍2Reacted by Keith Kraus and Leo Fang
6. leofang commented on Dec 11, 2025

   

   leofang

   on Dec 11, 2025

   MemberAuthor

   More actions

   Yes. This issue could need a bit of update. The tl;dr is: Instead of NDBuffer, we just add StridedLayout. Together with the existing 1D contiguous, untyped Buffer, it can represent what we need with NDBuffer. @stiepan has done this part in #1283 and is working on migrating the ND-copy routine from nvmath-python.
7. leofang

   modified the milestones: cuda.core backlog, cuda.core beta 10 on Dec 11, 2025
8. leofang commented on Dec 15, 2025

   

   leofang

   on Dec 15, 2025

   MemberAuthor

   More actions

   Copy-pasting @kkraus14's offline summary:

   • We don't want this to ultimately live in cuda.core, but want it to live in CCCL. We want the implementation in CCCL C++ but with the typical exposure up through CCCL Python that is JITed.
   • We will close the PR at the top of the thread and revert the StridedLayout changes made to SMV prior to the 0.5.0 release of cuda.core.
   • nvmath-python will continue to rely on their internal implementation until we have a new implementation usable in CCCL-Python.
9. leofang

   closed this as not plannedon Dec 15, 2025
10. leofang commented on Jan 7, 2026

    

    leofang

    on Jan 7, 2026

    MemberAuthor

    More actions

    xref apache/tvm-ffi#328