Adding CUDA and OpenCL backends

[AdrianEddy]

Hello, I would like to discuss a potential addition of CUDA and OpenCL backends to naga. Since both of them are more-or-less C++, it should be pretty similar to Metal backend, so I think it wouldn't be too much work to add them. It would support compute-only (no rendering).
Ideally it would be nice to also have CUDA and OpenCL backends in wgpu too, but I realize there's not enough interest to add that much maintenance burden. Adding it just for naga would maybe be in scope?

The motivation for me is to be able to interop with raw CUDA and OpenCL memory obtained from somewhere else. I can do that using Vulkan/CUDA interoperability, but that's not ideal because it requires to copy the data on device, sometimes even 2 copies are required.
It I could use CUDA directly, I would be able to operate on the provided buffer without any additional overhead.

The main use case for me is writing VFX plugins for Adobe Premiere, After Effects, DaVinci Resolve and other hosts. All these hosts are working with CUDA (on NVIDIA) or OpenCL (on AMD) buffers. On mac there's no problem because I can already use Metal interop in wgpu.

Currently I have to maintain 4 implementations of the same shader/kernel - Rust (for CPU fallback), WGSL (for wgpu), OpenCL and CUDA.

With CUDA and OpenCL backends in naga I would be able to reduce them all to a single Rust implementation and use rust-gpu from Embark and then use naga to compile for all my targets of interest.
I'm ok with having separate execution code for wgpu, OpenCL and CUDA, because that doesn't change too often. Implementing all shader/kernel changes for each backend is quite a maintenance burden

I'm not a graphics expert but I know enough to be able to contribute these backends to naga if there's a chance it would get merged, so I wanted to discuss if that's even remotely possible

[cwfitzgerald]

I'm really sorry this took so long to respond to! Sounds like an interesting project, and we definitely want to support this effort, however we don't have the maintainership bandwidth to merge more backends in-tree right now. That being said, out-of-tree backends are definitely an intended use case!

As such, if there are any internals that aren't accessible but are needed to write a backend, please raise an issue about it so it can be discussed. The one main caveat is that we cannot guarantee IR stability. We need the flexibility to change the IR every release. Outside of that, definitely get in contact if you have any issues with writing out of tree backends.