@@ -34,10 +34,10 @@ in Python. While we encourage new Python projects to start using streams (and ot
34
34
CUDA types) from ``cuda.core ``, we understand that there are already several projects
35
35
exposing their own stream types.
36
36
37
- To address this issue, we propose the :attr: `~_stream.IsStreamT.__cuda_stream__ ` protocol (currently version
38
- 0) as follows: For any Python objects that are meant to be interpreted as a stream, they
39
- should add a ``__cuda_stream__ `` method that returns a 2-tuple: The version number
40
- (``0 ``) and the address of ``cudaStream_t `` (both as Python `int `):
37
+ To address this issue, we propose the :attr: `~_stream.IsStreamT.__cuda_stream__ ` protocol
38
+ (currently version 0) as follows: For any Python objects that are meant to be interpreted
39
+ as a stream, they should add a ``__cuda_stream__ `` * method * that returns a 2-tuple: The
40
+ version number (``0 ``) and the address of ``cudaStream_t `` (both as Python `int `):
41
41
42
42
.. code-block :: python
43
43
@@ -48,12 +48,11 @@ should add a ``__cuda_stream__`` method that returns a 2-tuple: The version numb
48
48
49
49
...
50
50
51
- Then such objects can be understood by ``cuda.core `` anywhere a stream-like object
52
- is needed.
51
+ Then such objects can be understood and wrapped by :meth: `Device.create_stream `.
53
52
54
- We suggest all existing Python projects that expose a stream class to also support this
55
- protocol wherever a function takes a stream . For new Python projects that need to access
56
- CUDA streams, we encourage you to use :class: `~_stream.Stream ` directly.
53
+ We suggest all existing Python projects that already expose a stream class to also support
54
+ this protocol . For new Python projects that need to access CUDA streams, we encourage you
55
+ to use :class: `~_stream.Stream ` from `` cuda.core ` ` directly.
57
56
58
57
59
58
Memory view utilities for CPU/GPU buffers
0 commit comments