Hi@pwuertz, thanks for joining the discussion on Numba. I don't have comment for your effort here (yet), but I'd like to kindly ask that when this PR (and any subsequent ones) is merged, it'd be nice if you could follownumba/numba#5104 and add opencv to the list 🙂 Thank you.

CudaArrayInterface

I believe it should own upstreamgpu_mat object in its fields (extend lifetime ofdata_gpu_cv in example).

@alalek Please note thatclass CudaArrayInterface is not part of this PR. The PR was meant to provide the minimum requirement for any kind of interoperability in python, which is the access to the CUDA pointers.

For out-of-the-box interoperability with other libraries like Numba and Cupy I was planning on implementing the CUDA array interface (CAI) in a follow-up PR. As described earlier, I'm having trouble figuring out some OpenCV python binding generator details though.

Also note that within the current CAI specification (version 2), the responsibility for lifetime and synchronization resides with the user (similar to using cv::Mat constructors with data pointers). If this changes in some future version I'd be willing to update the CAI version on the OpenCV side of course.

@asmorkalov

• I tried addinguchar* data asCV_PROP, but it doesn't compile.CV_PROP apparently doesn't support pointer types.
• Like@alalek, I figured that it shouldn't be allowed to change thedata pointer via public interface (neither from C++ nor from python), so having/promoting a getter method for it seems like a good thing.
• TheGpuMat::data pointer looks identical toMat::data (name, uint8_t*, doc), yet it represents something completely different. I thinkvoid* cudaPtr() is a good name for what this pointer represents - an opaque handle to the CUDA array, not a data pointer for reading / writing uint8_t.

@alalek It's true that__cuda_array_interface__ currently does not specify stream handling, but stream interoperability really is a low hanging fruit. With access to the CUDA pointers, I did the following:

# allocated dataX_cpu, dataX_gpu_cv, stream_cv# (proof of principle numba views dataX_gpu_nb, stream_nb)t1=time.time()data1_gpu_cv.upload(arr=data1_cpu,stream=stream_cv)# OpenCV uploadkernel_nb(data1_gpu_nb,out=data2_gpu_nb,stream=stream_nb)# Numba operationdata2_gpu_cv.download(dst=data2_cpu,stream=stream_cv)# OpenCV downloadt2=time.time()# CPU time: 0.001 sstream_nb.synchronize()t3=time.time()# GPU time: 0.042 s# verified data2_cpu

So you can freely mix OpenCV and Numba operations on a single, fully async stream.

@asmorkalov Oh sorry, haven't noticed theStreamAccessor class before. I'll try adding wrapper definitions to it. This means thatcudaStream_t needs some kind of globally defined conversion rule too?

@asmorkalovStreamAccessor uses thecudaStream_t typedef, thus having a hard dependency on the CUDA SDK. I assume this is the reason for keeping it separate fromStream, which provides a public interface without CUDA dependency.

Even withHAVE_CUDA defined, neithermisc/python headers norcv2.cpp are able to include<cuda_runtime.h>.

How to proceed? Usingvoid* for transporting CUDA stream pointers appears to be the least intrusive solution..