Essentials
Initialization
CUDACore.functional — Method
functional(show_reason=false)Check if the package has been configured successfully and is ready to use.
This call is intended for packages that support conditionally using an available GPU. If you fail to check whether CUDA is functional, actual use of functionality might warn and error.
CUDACore.has_cuda — Function
has_cuda()::BoolCheck whether the local system provides an installation of the CUDA driver and runtime. Use this function if your code loads packages that require CUDA.jl.
CUDACore.has_cuda_gpu — Function
has_cuda_gpu()::BoolCheck whether the local system provides an installation of the CUDA driver and runtime, and if it contains a CUDA-capable GPU. See has_cuda for more details.
Note that this function initializes the CUDA API in order to check for the number of GPUs.
Global state
CUDACore.context — Function
context(ptr)Identify the context memory was allocated in.
context()::CuContextGet or create a CUDA context for the current thread (as opposed to current_context which may return nothing if there is no context bound to the current thread).
CUDACore.context! — Function
context!(ctx::CuContext)
context!(ctx::CuContext) do ... endBind the current host thread to the context ctx. Returns the previously-bound context. If used with do-block syntax, the change is only temporary.
Note that the contexts used with this call should be previously acquired by calling context, and not arbitrary contexts created by calling the CuContext constructor.
CUDACore.device — Function
device(::CuContext)Returns the device for a context.
device(ptr)Identify the device memory was allocated on.
device()::CuDeviceGet the CUDA device for the current thread, similar to how context() works compared to current_context().
CUDACore.device! — Function
device!(dev::Integer)
device!(dev::CuDevice)
device!(dev) do ... endSets dev as the current active device for the calling host thread. Devices can be specified by integer id, or as a CuDevice (slightly faster). Both functions can be used with do-block syntax, in which case the device is only changed temporarily, without changing the default device used to initialize new threads or tasks. KernelInterface.device! on a CUDABackend switches only the calling task, and leaves that default alone.
Calling this function at the start of a session will make sure CUDA is initialized (i.e., a primary context will be created and activated).
CUDACore.stream — Function
stream()Get the CUDA stream that should be used as the default one for the currently executing task.
Each task gets its own stream, which may be handed to another task once the task has finished and all work on the stream has completed. If you need a stream that outlives the task, or that is never shared, create one with CuStream() and activate it using stream!.
CUDACore.stream! — Function
stream!(::CuStream)
stream!(::CuStream) do ... endChange the default CUDA stream for the currently executing task, temporarily if using the do-block version of this function.
CUDACore.priority — Method
priority()Return the effective priority of the current task's stream on the active device. See priority! to change it.
CUDACore.priority! — Function
priority!([f::Function,] p::Union{Integer,Symbol})Set the priority of the current task's CUDA work on the current device. The do-block form restores the previous stream after f returns, ordered after the work that f submitted (unless f throws). Priorities are assigned when streams are created, so switching priorities selects another stream and orders it after the previous one. Repeated switches reuse the task's streams.
Use an integer from priority_range, or :normal, :low, or :high. The symbolic values map to 0, the least priority, and the greatest priority, respectively. Stream priority is a scheduling hint for pending GPU work, not a guarantee of execution order. The :low and :normal values may coincide. A different priority replaces an explicit stream selected with stream!; use the do-block form to restore that stream. New tasks start at normal priority. Changing priority during graph capture is unsupported. Using an array from the previous stream may wait on the CPU for that stream's pending work.