-
Notifications
You must be signed in to change notification settings - Fork 1k
[FEA] External libcudf APIs should expose CUDA streams #925
Copy link
Copy link
Closed as not planned
Labels
SparkFunctionality that helps Spark RAPIDSFunctionality that helps Spark RAPIDSfeature requestNew feature or requestNew feature or requestlibcudfAffects libcudf (C++/CUDA) code.Affects libcudf (C++/CUDA) code.proposalChange current process or codeChange current process or code
Milestone
Description
Is your feature request related to a problem? Please describe.
In order to maximize efficiency and utilization of the GPU, you need to be able to execute kernels and memory copies on independent streams. However, no libcudf API currently exposes streams to the end user.
Describe the solution you'd like
Any API that executes a GPU kernel or allocates/copies memory should provide the end user with the option to specify a stream.
Open questions:
- How should the stream be exposed? E.g., accept a
cudaStream_t*? Or bundled inside of anoptionsstruct? - Who is responsible for creating/destroying the stream?
- In a C++ API its easy to provide a default argument for the stream, but in the C API the user will always be required to specify a stream. Is this what we want?
- Should streams be exposed in all of the Python APIs?
I suspect we'll all agree this does need to be done, the question is rather one of how and when.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
SparkFunctionality that helps Spark RAPIDSFunctionality that helps Spark RAPIDSfeature requestNew feature or requestNew feature or requestlibcudfAffects libcudf (C++/CUDA) code.Affects libcudf (C++/CUDA) code.proposalChange current process or codeChange current process or code