Add some docs to exported functions, fix export function `devcount`

[ranjanan]

@tkelman Could you review this so we can merge? Thanks.

[ranjanan]

@tkelman I have incorporated those changes. Thanks.

[ranjanan]

@ViralBShah , if @tkelman doesn't have any more suggestions, can we merge this?

[ViralBShah]

Is this good to merge? Does it need squashing commits?

[ViralBShah]

I assume we need to tag a new version.

[tkelman]

@vchuravy okay with you? Make any edits if anything looks off, otherwise someone with commit access should do the tag so we can push it to https://github.com/JuliaGPU/CUDA.jl/releases as well

[vchuravy]

@timholy As far as I know CUDA.jl and CUDArt.jl have a similar goal and CUDA.jl was mostly abandoned until recently. Since you originally created CUDArt could you shortly describe how it differs and if it makes sense to have both around.

Otherwise I would suppose that we keep CUDA.jl, with a disclaimer that development moved on to CUDArt.

[ViralBShah]

Maybe we should retire this package then?

[vchuravy]

All the other CUDA packages in JuliaGPU e.g. CUBLAS... depend on CUDArt and this graph says everything: https://github.com/JuliaGPU/CUDA.jl/graphs/contributors vs https://github.com/JuliaGPU/CUDArt.jl/graphs/contributors

[tkelman]

Yes it certainly looks like @ranjanan has been working on the wrong one then. If CUDArt is strictly better, this one should be deprecated so it doesn't lead to confusion and misdirected effort again.

[ViralBShah]

I agree. I have seen occasional use of CUDA.jl in the wild too, and hence clear signalling from the JuliaGPU organization about deprecation and using CUDArt would be good.

[timholy]

Thanks for kicking this off, @vchuravy. It's been a while, but these are the main differences I remember:

• The rt means "runtime," as in it's a wrapper of the runtime API. For many months we were in the situation that CUDA.jl could not be used with runtime-based toolkits like CUFFT (we got segfaults), and at the time the advice on the web was that you couldn't use the driver and runtime APIs together. (Well, you can call driver routines if you're using the runtime API, but the impression we all had was that you couldn't call runtime routines if you hadn't initialized resources through the runtime.) Eventually @moon6pence figured out how to get the two working together, but by that point CUDArt had advanced well beyond CUDA.
• CUDArt has an automated wrapper-generator (based on Clang.jl) for keeping up-to-date with new versions of CUDA. See https://github.com/JuliaGPU/CUDArt.jl/pull/39 for one holdup.
• IIRC, CUDArt has better support for machines with multiple GPU boards (my lab has one machine with 4 cards).
• Probably the least-obvious but most useful functional difference is the management and cleanup of resources, e.g., memory and kernel modules. A particular focus has been on finding a reasonable way to blend CUDA's static memory management with Julia's GC. The hardest problems occur from device resets within the same Julia session and the fact that CUDA can reassign the same pointer---we do our best to detect such issues and trigger garbage collection on the "stale" items. It doesn't work perfectly, but in my experience it's quite good, and generally you can launch, shut down, restart, etc. new CUDA-based computations at will without trouble within a single session, exploiting the results for extensive pure-CPU computations in between. In my lab, we have some computations we distribute to multiple julia processes, and individual processes can query whether a particular device is busy, and if not open a session on it, collect the result, and shut it down, freeing the device for use by other processes.
• CUDArt contains implementations of commonly-used julia functions like fill!, copy!, and sleep, support for arrays represented with PitchedPtrs and HostArrays (although the latter have problems spelled out in the README).
• IIRC, the support for streams is considerably more sophisticated in CUDArt.
• More tests

On the flip side, I think most of @maleadt's work (and your extension of it) was based on CUDA.jl.

[maleadt]

CUDArt also uses the driver API for module loading and kernel execution. Maybe we should strip CUDA.jl from its high-level features, pointing users towards CUDArt.jl instead (which supersedes CUDA.jl for most almost all use cases), yet still keeping the low-level functionality available in CUDA.jl for those who really need it (CUDArt.jl, and my Julia/NVPTX runtime).

[timholy]

@maleadt, that sounds like a fine plan.