Dealing with optional CUDA in package development



I’m developing a package with both GPU routines and a CPU fall-back. I have two related queries:

  1. How should I best determine if a CUDA device is available?
  2. What would be the best way to avoid forcing CUDA dependencies on a user without a GPU?

My current solution would be to define the CUDA-requiring functions conditionally on readstring(deviceQuery) not failing. This feels a bit dirty though - is there a better way?

Thoughts much appreciated.


Take a look at this:


@tim.holy I was checking the package the other day, and from what I understood we still don’t have a way to let’s say pass in an option GPU=true to a function and get the code branching automatically for the user, correct? Please correct if I am wrong, but with ComputationalResources.jl we expect the users of our packages to type in the resources they want to use explicitly.

Given that the users of my package don’t have a clue of what CPUThreads, ArrayFire, etc. means, I decided to live with no precompilation in ImageQuilting.jl.


I don’t think this needs to affect precompilation; that’s more an issue for Requires.jl.

ComputationalResources.jl is more about controlling dispatch in a way that lets you (in combination with Requires.jl) write implementations for, e.g., GPUs without introducing hard dependencies. If you don’t need compile-time dispatch, of course you can use a keyword + Requires.jl rather than ComputationalResources.jl + Requires.jl.


@tim.holy does Requires.jl solves the issue with optional dependencies and precompilation? In my case, I have this function:

If OpenCL and CLFFT are installed, I can pass in the option gpu=true and everything works. Could I just wrap the entire GPU-related source code in a @require block and be able to activate precompilation?


Requires.jl looks interesting for my purposes. Might give it a go based on requiring CUDArt. Thanks,