refactor(cust_raw): consolidate CUDA, cuDNN, OptiX bindgen and remove find_cuda_helper

[adamcavendish]

1. Consolidation of bindgen related "*-sys" packages
   • Remove the common dependency of find_cuda_helper. Use the cargo
     metadata mechanism instead.
   • Merged all CUDA bindgen-generated code into the cust_raw crate for
     simplicity and maintainability.
   • Add CUDA Runtime API bindgen support.
2. cuDNN and OptiX Integration
   • Split cudnn into cudnn (high-level API) and cudnn-sys (low-level
     bindgens) for better abstraction.
   • Split optix into optix (high-level API) and optix-sys (low-level
     bindgens) for better abstraction.
3. CUDA 12+ Support
   • Updated cust to support CUDA versions >= 12.
   • Added compatibility for CUDA 12.3+ graph API changes:
     • Renamed cuGraphKernelNodeGetParams →
       cuGraphKernelNodeGetParams_v2.
     • Enabled conditional node support for CUDA >= 12.3.
4. Temporarily disable cuDNN in CI
   • Windows CI pipelines have no cuDNN support yet.

Co-authored-by: Adam Basfop Cavendish GetbetterABC@yeah.net
Co-authored-by: Jorge Ortega jorge-ortega@outlook.com

---

This PR addresses #166, please refer to the issue for more discussion backgrounds.

[adamcavendish]

@jorge-ortega @LegNeato The PR builds in Ubuntu Linux 24.04 nvidia container with CUDA 12.8.0, cuDNN 9, OptiX 7.3.0 including all examples. The change is for review as I might add more CUDA versions support in the following days if we still want to embed the generated code into our codebase.

If we are sure we do not want to add generated code, I'll switch over to drop version features and ensure they are built from host.

Note:

1. I don't have graphics support on a server so the OptiX might be better to get run by someone if possible.
2. The CI mostly fails on rustfmt for the generated code. I also wonder whether we should do formatting on the generated code.

[jorge-ortega]

Seeing how infectious specifying the version through feature flags are, I'd rather we go with host generated bindings all the way. It'd be easier for the ecosystem to evolve with the assumption that you bring you own SDK to build against and check for a supported version through cargo metadata, instead of relying on users to ensure they have the same version feature flags set across all crates that might use cust or the bindings directly.

[LegNeato]

Now that I see it I agree.

[jorge-ortega]

We might have to exclude cudnn from CI for the time being until we get the SDK installed on workers.

[jorge-ortega]

Now comes the fun part of cfg gating in order to support an old CUDA version like v11.2 😆

[adamcavendish]

Now comes the fun part of cfg gating in order to support an old CUDA version like v11.2 😆

Yeah, I'm looking into this. Do we have a plan on what versions we would like to support and how long?

[jorge-ortega]

CUDA v12 builds pass 🎉Just clippy and rustdoc issues to address.

Yeah, I'm looking into this. Do we have a plan on what versions we would like to support and how long?

Nothing official. @LegNeato should we drop 11.2 so we can focus rebooting on 12.0 and up until we figure out what cust will officially support moving forward?

[jorge-ortega]

Issues like this I can address with the changes on my workspace which handles macro function renaming. Since v12 builds, I'm good to merge these.

[LegNeato]

@jorge-ortega I think you should be able to merge yourself, let me know if you can not!

[LegNeato]

I filed #185, which will get us cudnn and remove some future maintenance burden.