devcount() return zero when none available?

[lucasb-eyer]

Currently, devcount() fails with an error if there's no device available, because in that case, it returns the cudaErrorNoDevice error code. It makes sense for most functions to fail when there's no device, but I'd hope devcount() to return zero so I can use it to detect the presence of a CUDA-capable GPU.

Or is there another way to determine the availability of a device? (My goal is to not run the GPU-related tests of my package when there's no GPU.)

If you agree with this suggestion, I can write a PR for it, I hope it's as easy as adding that function to this list.

[timholy]

Yes, that's very reasonable.

[lucasb-eyer]

Ah, turns out I only have CUDA 7.0, so I think I can't do that. I don't see any obvious way you accounted for multiple versions, is there?

[timholy]

I think we can support multiple "gen" directories (it might take a bit of tweaking of the core code, but that part should be pretty easy). Start by making a gen-7.0 folder, copying the wrap_cuda.jl script from the 6.5 directory, and run it. (You'll need to install Clang.) It's a bit of a pain to get this set up (you need to build Julia with Clang support, if you don't have it already), but once all the parts are there it was (for 6.5) entirely automagic.

[lucasb-eyer]

OK I'll try that but It'll take me some time before I get there then, quite busy currently.

[lucasb-eyer]

I believe I've generated the bindings (for 7.5, not 7.0, I was mistaken) but I am clueless as to how we should decide which one to include here and here. Any ideas or pointers?

Also, even if I generate bindings for 7.5 and can load and use them, we should also apply this fix to the 6.5 folder so that both bindings behave the same. But I don't know how to generate them given I don't have cuda 6.5. I don't think I can easily install multiple cuda versions in Arch linux because it gets installed to /opt/cuda/... without version number in the path.

[timholy]

I believe I've generated the bindings (for 7.5

Nice!

Probably the best choice is to do the check in deps/build.jl, and encode the proper path in a deps/deps.jl file. ImageMagick.jl has an example of the kind of logic that would likely be useful.

Also, even if I generate bindings for 7.5 and can load and use them, we should also apply this fix to the 6.5 folder

I volunteer to make that change to the 6.5 folder and test it.

[lucasb-eyer]

How about running wrap_cuda.jl during build, is that a bad idea?

Otherwise, how would you go about finding out the installed CUDA version? Parsing the output of nvcc -V sounds wrong and brittle. I don't think BinDeps is the right thing here, because a lot of people install CUDA manually.

Maybe it's best to move this or similar to build-time and then call one of these two manually.

But do we expect people to re-run Pkg.build("CUDArt") manually when they update CUDA? I'm sure many won't, I'd probably forget myself. Though we could detect that by saving the "built version" and checking the current version on module load.

Sorry for so many questions, it's the first time I do this 😰

[timholy]

How about running wrap_cuda.jl during build, is that a bad idea?

Yes, because most people won't have Clang.jl installed and working.

CUDA library versioning doesn't seem to have been a big problem so far, I'd say.

Maybe it's best to move this or similar to build-time and then call one of these two manually.

Seems reasonable.

But do we expect people to re-run Pkg.build("CUDArt") manually when they update CUDA? I'm sure many won't, I'd probably forget myself. Though we could detect that by saving the "built version" and checking the current version on module load.

I think it's OK to expect people to do a little manual work when they update CUDA. Furthermore, if they don't, but nothing breaks, I wouldn't classify that as a problem. Most of the CUDA API has been pretty stable over many releases, so I don't think it's a catastrophe to get the version wrong.