Skip to content

RFC: Remove StridedMemoryView (to somewhere else)? #1371

Closed
Closed
RFC: Remove StridedMemoryView (to somewhere else)?#1371
Assignees
leofang
Labels
P0High priority - Must do!RFCPlans and announcementsbreakingBreaking changes are introducedcuda.coreEverything related to the cuda.core module
Milestone
cuda.core v0.6.0

Description

@leofang
leofang
opened on Dec 15, 2025

As part of #674 (comment) it was raised that our library design should strictly follow what the underlying CUDA driver/runtime/library APIs offer (Update: added "library" to cover other CTK libraries such as NVRTC and cuFILE, I missed that when summarizing the meeting notes I took).

StridedMemoryView is not a fundamental object of CUDA and was offered only for Python users' convenience.

I have a somewhat strong opinion that a data structure should co-live with the data algorithm implementations. Otherwise, we do not know if a data structure is properly designed, and to test it would require us to duplicate the algorithms implemented elsewhere. Since we decided to purge StridedLayout, it would make sense to stick to the same design guidelines and purge SMV as well. It should be moved to the library that would provide algorithms that consume SMV.

This RFC aims for downstream SMV users to provide feedbacks.

Activity

  1. leofang
    added this to the cuda.core beta 11 milestone on Dec 15, 2025
  2. leofang
    added
    P0High priority - Must do!
    cuda.coreEverything related to the cuda.core module
    cuda.pathfinderEverything related to the cuda.pathfinder module
    RFCPlans and announcements
    breakingBreaking changes are introduced
    and removed
    cuda.pathfinderEverything related to the cuda.pathfinder module
    on Dec 15, 2025

  3. leofang commented on Dec 15, 2025

    @leofang
    leofang
    on Dec 15, 2025
    MemberAuthor

    In an offline discussion @cpcloud pointed out that with Python memoryview assignment is allowed:

    >>> m = memoryview(bytearray(10))
>>> m[1]
0
>>> m[1]= 3
>>> m[1]
3

    This adds to another reason to move SMV elsewhere. We cannot possibly support assignment or in general anything that requires launching a CUDA kernel in cuda.core, unless we relax the design requirement that cuda.core offers abstractions on top of CUDA.

  4. leofang commented on Dec 15, 2025

    @leofang
    leofang
    on Dec 15, 2025
    MemberAuthor

    (Update: I updated the issue description to cover CTK libraries such as NVRTC and cuFILE, I missed that when summarizing the meeting notes I took)

  5. leofang
    added a parent issue on Dec 17, 2025

  6. rparolin commented on Feb 5, 2026

    @rparolin
    rparolin
    on Feb 5, 2026
    Collaborator

    @kkraus14 Can we close this issue now that SMV is staying in cuda.core?

  7. kkraus14 commented on Feb 5, 2026

    @kkraus14
    kkraus14
    on Feb 5, 2026
    Collaborator

    I would be in support, but I'd defer to @leofang for if he would prefer to keep this discussion open

  8. rparolin commented on Feb 6, 2026

    @rparolin
    rparolin
    on Feb 6, 2026
    Collaborator

    @leofang is in favor -- we were discussing during backlog review. I'll close the ticket. Thank you!

  9. rparolin
    closed this as completedon Feb 6, 2026
  10. rparolin
    assigned
    leofang
    on Feb 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

P0High priority - Must do!RFCPlans and announcementsbreakingBreaking changes are introducedcuda.coreEverything related to the cuda.core module

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions