GPU resource interop + OpenCL and CUDA backends

[AdrianEddy]

Hi :)

Would you be open to contribution of OpenCL and CUDA backends to gpgpu-rs and also a way to use GPU resources directly instead of CPU buffers as inputs? I like the API of gpgpu-rs but I basically need to process all possible GPU resources. I have most of the interops implemented already here in wgpu-interop*.rs, so it would be mostly a matter of refactoring that into gpgpu-rs crate, or maybe a new separate crate which then can be used here.

Basically what I envision is to be able to provide the input/output as enum like this:

pub enum BufferSource<'a> {
    None,
    Cpu { buffer: &'a mut [u8] },
    OpenCL {
        buffer: ocl::ffi::cl_mem,
        queue: ocl::ffi::cl_command_queue
    },
    DirectX11 {
        texture: *mut std::ffi::c_void, // ID3D11Texture2D*
        device: *mut std::ffi::c_void, // ID3D11Device*
        device_context: *mut std::ffi::c_void, // ID3D11DeviceContext*
    },
    OpenGL {
        texture: u32, // GLuint
        context: *mut std::ffi::c_void, // OpenGL context pointer
    },
    Vulkan {
        texture: u64,
        device: u64,
        physical_device: u64,
        instance: u64,
    },
    MetalTexture {
        texture: *mut metal::MTLTexture,
        command_queue: *mut metal::MTLCommandQueue,
    },
    MetalBuffer {
        buffer: *mut metal::MTLBuffer,
        command_queue: *mut metal::MTLCommandQueue,
    },
    CUDABuffer {
        buffer: *mut std::ffi::c_void // Cudeviceptr
    },
}

and add Shader::from_cuda_file and Shader::from_opencl_file

I can take care of all implementation and create a pull request, but I wanted to get your input first to see if you're open to such contribution. If not, I'll have to create a new crate

[UpsettingBoy]

Hey! Thanks for the suggestion, let me think about it 😄

[UpsettingBoy]

Hi! Sorry for the slow reply, it's been a busy month.

Right now I have 2 ideas about this:

1. Leave gpgpu-rs as wgpu compatible and build integrations. This means that if you want to use something from CUDA, you would have to copy it into a wgpu buffer/texture (using wgpu-core probably)
2. Rewrite gpgpu-rs to be just a set of traits, so anyone can implement their own backend.

Personally, I like the 2nd option, and more now that I read that async trait are about to be stabilized 😄. Anyway, I would like some input here haha

Answering to question more specifically, I'll be fine adding this if GpuBuffer remains as part of the API and BufferSource becomes an implementation detail of it (I don't know if that was your original plan 😉).

[AdrianEddy]

I would go with option 2 as well. Would you be interested to refactor the crate with async traits (I believe Rust 1.75 comes out Dec 28th), and just have the wgpu backend implemented like it's now? I would be able to then implement CUDA and OpenCL backends and provide a PR.

In my app I currently do something similar to 1., which is to create a wgpu texture on Vulkan which is backed by CUDA memory, and this works to process CUDA buffers, but it's not ideal since it involves data copy (on device, but still), so I would like to have pure CUDA backend which can process buffers directly. Of course I would leave the possibility to process CUDA buffers on wgpu, if you don't want to write separate CUDA kernel and you're ok with that extra copy.

I'll be aiming to have the CUDA backend done entirely dynamically using libloading, to not add any build-time external dependencies and to keep it simple. I think I can make OpenCL the same way too

[UpsettingBoy]

Sounds good! Thanks for the input btw