Repository navigation
[FEA]: Autodetect __cuda_array_interface__ for launching kernels #1435
Description
Is this a duplicate?
- I confirmed there appear to be no duplicate issues for this request and that I agree to the Code of Conduct
Area
cuda.pathfinder
Is your feature request related to a problem? Please describe.
When researching how to launch kernels in python i came to the problem that unlike cupy, CUDA python needs .data.ptr or .data_ptr depending if its a cupy array or a pytorch tensor.
This came up in de discussion of a cupy kernel launch problem.
cupy#9576
Describe the solution you'd like
The __cuda_array_interface__ already has the specification that data key returns the pointer.
So the question is if we can leverage this and make the passing of array/tensors more pythonic (like for ints and so on).
By getting the pointer automatically if the interface is part of the object?
Describe alternatives you've considered
Alternatively we could just standardize either .data.ptr or .data_ptr. But as its already part or a standard interface this seams to be redundant.
But if here are other ideas or ways to achieve the same goal my very happy to hear them.
Additional context
No response
Activity
cpcloud commentedon Jan 7, 2026
You might be able to use
StridedMemoryViewto get the abstraction you're after:leofang commentedon Jan 7, 2026
Yes. Using SMV is our recommendation and in the future we'll make it work nicer (ex: #1280 would be the ideal end goal, and #1387 is the first step).
As I noted in cupy/cupy#9576 (comment), though, we care a lot about kernel launch overhead, so it is unclear when/if #1280 will ever be supported. This problem is a lot worse for Array Interface and CUDA Array Interface, because checks like
hasattrhave side effects that prompted us to design the DLPack and CUDA Stream Protocols differently. Using CAI during kernel launch is known to kill perf for small kernels (the addition overhead is O(100) us instead of O(1) us).StridedMemoryViewincuda.core.launch()#1280