CUDAStreamView (or similar name) object

[jakirkham]

Just like in the array case, where there are many different ways to define an array (Python Buffer Protocol, __array_interface__, __cuda_array_interface__, DLPack, etc.), there is a similar issue with streams up to this point. To provide a few examples...

• Python __dlpack__ can contain a stream
  • Specify synchronization semantics dmlc/dlpack#57
• Numba's __cuda_array_interface__ can contain a stream
  • Discussion: should __cuda_array_interface__ include a stream pointer? numba/numba#4933
• Plus a number of libraries provide their own stream objects
  • torch.cuda.stream
  • cupy.cuda.Stream
• Not to mention cases where a cudaStream_t is passed around as an integer address

With all these objects floating around that provide different APIs, there remains a need to wrangle them them into some kind of common object and that has proper RAII semantics and can be used in a standard way

A CUDAStreamView, much like the StridedMemoryView, would help provide this standard way to consume these different objects and provide a standard object and API to use (including __cuda_stream__)

It could...

1. Identify the object
2. Keep a copy of the cudaStream_t in an attribute
3. Keep a reference to the exporting object
4. Query/store any other relevant info

[leofang]

The goal of cuda.core is to not bifurcate the CUDA-owned objects in each Python project, and instead new projects should just use cuda.core and get streams.

For established projects, we already have (by design) __cuda_stream__ + Device.create_stream for wrapping a foreign stream object, so I do not think there's anything extra that cuda.core needs to do, other than helping/educating/urging existing Python projects to implement __cuda_stream__.
https://nvidia.github.io/cuda-python/cuda-core/latest/generated/cuda.core.experimental.Device.html#cuda.core.experimental.Device.create_stream

[vyasr]

The main possible value-add that I see is having a standard vocabulary type for processing objects that expose the protocol. Essentially if my lib exposes a function foo that takes a stream, the protocol approach would have you do this:

# lib.py
def foo(..., stream_like):
    if not hasattr(stream_like, "__cuda_stream__"):
        raise ValueError("Invalid stream object")
    stream = process_stream_like(stream_like.__cuda__stream__) # This function needs to be defined.

A standard view type in cuda.core would replace the need for process_stream_like.

from cuda.core import StreamView
def foo(..., stream_like):
    stream = StreamView(stream_like)

It's definitely not a requirement though, just a convenience.