CUDA Bindings

[HurricanKai]

It may be useful to bind to the CUDA C interface. We will need to investigate what the licensing around CUDA is, and how useful just the C interface is.
From my vague memory, CUDA somehow hooks into the C(++) compiler and that way allows in line calling of shaders, which we can't somehow port.

[Perksey]

The CUDA headers are included in the CUDA Toolkit, which we won't be able to bind as it's barred by a proprietary license agreement.

[HurricanKai]

Thing is they explicitly mention Java and Python wrappers on their website. I have not yet figured out whether they have made those or whether they have a deal with library authors, or whether they somehow "left a hole" in the license

[Perksey]

For the parallel heterogeneous compute scene, I believe that OpenCL covers the majority of use cases if OpenGL or Vulkan Compute Shaders aren't good enough for you. OpenCL is capable of using the "good SPIRV" i.e. the SPIRV that allows for creation of advanced compute kernels, not just plain old pipelined shader modules.

Some wrappers are open source under OSI-approved licenses, however it's sneaky because the moment you actually use CUDA yourself you become bound by the CUDA EULA. I don't think we can reasonably force users to sign this agreement (sure there's the NuGet "force acceptance" thing, but that isn't respected by all IDEs and doesn't really compare to NVIDIA actually locking the code behind a "please accept this EULA" barrier), and without doing so we'd set the .NET Foundation up for potentially a nasty bit of legal trouble.

The wrappers they refer to are likely also part of the CUDA Toolkit, which is EULA-barred. I don't think this is something the Silk.NET project can safely get involved in.

Moreover, from a moral standpoint we'd be a free and open-source project promoting access to a proprietary API that creates tie-ins to the NVIDIA GPU platform. We have no upside, and we are creating upsides (and potentially a revenue stream) for NVIDIA.

If, despite all this, we did want to take this further we should consult with the Foundation to get us in touch with a IP lawyer.

TL;DR Silk.NET can't safely implement this from a legal standpoint, and has nothing much to gain anyway.

[HurricanKai]

Moreover, from a moral standpoint we'd be a free and open-source project promoting access to a proprietary API that creates tie-ins to the NVIDIA GPU platform.
I very much agree with this. Especially due to me personally not even being able to test whether it works 🙂

If a future reader wants this and has some reasoning why it makes sense to include this in Silk.NET they are free to comment on this issue.