chore(examples): restructure CUDA examples and add a GEMM example

[adamcavendish]

• Refactored the CUDA examples directory for improved clarity and modularity so each example is more self-contained.
• Added a new GEMM (General Matrix Multiply) example, including naive and tiled kernel implementations, build scripts, and benchmarks.
• The tiled-gemm kernel demonstrates the shared memory usage.

[adamcavendish]

Emm ... it seems that the Windows workflow is now generating the rustc_codegen_nvvm at D:\a\Rust-CUDA\Rust-CUDA\target\debug\deps\rustc_codegen_nvvm.dll.lib but it requires a dynamic linked library rustc_codegen_nvvm.dll.

[adamcavendish]

Emm ... it seems that the Windows workflow is now generating the rustc_codegen_nvvm at D:\a\Rust-CUDA\Rust-CUDA\target\debug\deps\rustc_codegen_nvvm.dll.lib but it requires a dynamic linked library rustc_codegen_nvvm.dll.

I found the original CI Windows pipeline has "add" disabled so maybe the issue has been around for a while.
I have the new examples disabled currently as well so it won't block the merge.

I wonder whether someone can reproduce it locally on a windows? @jorge-ortega

[jorge-ortega]

On Windows, an import lib is generated in addition to the dll. All that does is load the actual dll when the process starts.

I tried cargo clean and then cargo build --workspace --exclude "optix*" --exclude "path-tracer" --exclude "denoiser" --exclude "cudnn*". I get several LoadLibraryEx errors, and a linker error

 = note: LINK : fatal error LNK1104: cannot open file 'C:\Users\jorge\Workspace\rust-cuda\target\debug\deps\rustc_codegen_nvvm.dll'

I think the issue might have to be with these warnings:

warning: output filename collision.
The lib target `rustc_codegen_nvvm` in package `rustc_codegen_nvvm v0.3.0 (D:\a\Rust-CUDA\Rust-CUDA\crates\rustc_codegen_nvvm)` has the same output filename as the lib target `rustc_codegen_nvvm` in package `rustc_codegen_nvvm v0.3.0 (D:\a\Rust-CUDA\Rust-CUDA\crates\rustc_codegen_nvvm)`.
Colliding filename is: D:\a\Rust-CUDA\Rust-CUDA\target\debug\rustc_codegen_nvvm.dll
The targets should have unique names.
Consider changing their names to be unique or compiling them separately.
This may become a hard error in the future; see <https://github.com/rust-lang/cargo/issues/6313>.
warning: output filename collision.
The lib target `rustc_codegen_nvvm` in package `rustc_codegen_nvvm v0.3.0 (D:\a\Rust-CUDA\Rust-CUDA\crates\rustc_codegen_nvvm)` has the same output filename as the lib target `rustc_codegen_nvvm` in package `rustc_codegen_nvvm v0.3.0 (D:\a\Rust-CUDA\Rust-CUDA\crates\rustc_codegen_nvvm)`.
Colliding filename is: D:\a\Rust-CUDA\Rust-CUDA\target\debug\deps\rustc_codegen_nvvm.dll.lib
The targets should have unique names.
Consider changing their names to be unique or compiling them separately.
This may become a hard error in the future; see <https://github.com/rust-lang/cargo/issues/6313>.

We get them on both Windows and Linux (minus the .lib). Seems cargo is building it multiple times for each binary. As soon as it finishes building it for one build script, another build of the codegen comes and wipes it before the compiler can load it. This would explain the LoadLibrary and linker error

We might need to switch to workspace dependencies so the codegen and other crates only build once for everything in the workspace.

[jorge-ortega]

It tried switching to workspace deps, but it doesn't seem to work for build-dependencies. We might have to instead build each example in separate build commands, so they don't interfere with each other.

[adamcavendish]

It tried switching to workspace deps, but it doesn't seem to work for build-dependencies. We might have to instead build each example in separate build commands, so they don't interfere with each other.

Get it. What about merging this change first since previously we have such issue too?

[jorge-ortega]

@LegNeato FYI, since you've been working on the modal CI. Hope this won't interfere much.

[LegNeato]

Thanks! Don't worry about me, I'll keep rebasing.