Wrong library filename used for CUDA driver on Windows

[hipparcos]

I was trying to run the examples, and let dev = CudaDevice::new(0)?; was causing a LoadLibraryExW error for me.

To fix this for myself, I replaced
LIB.get_or_init(|| Lib::new(libloading::library_filename("cuda")).unwrap())
in src/driver/sys/mod.rs with
LIB.get_or_init(|| Lib::new(libloading::library_filename("nvcuda")).unwrap()).

I think this is because I am on Windows and the CUDA driver library is called nvcuda.dll.

Edit: I also needed to have
LIB.get_or_init(|| Lib::new(libloading::library_filename("nvrtc64_120_0")).unwrap())
in src/nvrtc/sys/mod.rs.

[Corey Lowman]

@jhuang97 can you also try this on cudarc version 0.10.0? I'm wondering if this error was introduced with the swap to dynamic loading. 0.10.0 does dynamic linking only, so if this was introduced recently you should be able to compile on that version. If you aren't able to compile on 0.10.0, then that might be an edge case system setup and we can work to get a workaround.

[hipparcos]

I tried running the examples on cudarc version 0.10.0. Everything is fine on that version.

[Corey Lowman]

@jhuang97 thanks! If you enable the dynamic-linking feature flag with 0.11.0 (or current main branch), do things work for you? So cargo run -F dynamic-linking <whatever command you were runnign to test things>.

I think we can definitely add a fallback for loading nvcuda if loading cuda doesn't work:

LIB.get_or_init(|| {
        Lib::new(libloading::library_filename("cuda"))
            // checking for nvcuda in case of error on windows. See issue #219.
            .or_else(|e| Lib::new(libloading::library_filename("nvcuda")))
            .unwrap()
    })

I'm a little hesitant about nvrtc one because it seems like they are encoding some versioning information into the dll name which could get really complicated.