PSA: CUDA.jl replacing CuArrays.jl/CUDAnative.jl/CUDAdrv.jl/CUDAapi.jl -- call for testing!

Package Announcements
,
1

Hi all,

I just registered and tagged v0.1 of CUDA.jl, a package that now contains the documentation and functionality from the several packages that make up the Julia/CUDA stack. I merged them because there was too much coupling between the individual packages, and it wasn’t particularly user-friendly to split functionality that’s often used together across several packages.

Apart from some major test suite changes, the functionality should be a 1:1 copy of what used to be in CuArrays/CUDAnative/etc, so I’d quickly like to tag a v1.0 release. Before that, I’d like to make sure there aren’t any obvious issues with application code, so please try your CUDA applications with CUDA.jl and let me know!

The upgrade procedure should be straightforward: remove CuArrays/CUDAnative/CUDAdrv/CUDAapi, add CUDA.jl, and replace module imports/references.

43 Likes
2

Nice! A couple questions:

  1. Does this mean that all of those other packages are going to be deprecated?
  2. Are issues from those packages going to be migrated to CUDA.jl?
3
  1. I would like to do that, yes.
  2. Yes, I will do that this week. Only PRs will remain on the original repo.
3 Likes
4

FYI the package README has quick install instructions for CUDAnative instead of CUDA.jl.

1 Like
5

Thanks, fixed.

3 Likes
6

This is awesome, thanks for working on CUDA.jl @maleadt!

Tried adding CUDA.jl but ran into a dependency issue that I was able to replicate in an empty repository with Julia 1.3:

   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.3.0 (2019-11-26)
 _/ |\__'_|_|_|\__'_|  |  Official https://julialang.org/ release
|__/                   |

(TmpRepo) pkg> st
Project TmpRepo v0.1.0
    Status `~/TmpRepo/Project.toml`
  (empty environment)

(TmpRepo) pkg> add CUDA
  Updating registry at `~/.julia/registries/General`
  Updating git-repo `https://github.com/JuliaRegistries/General.git`
 Resolving package versions...
ERROR: Unsatisfiable requirements detected for package GPUCompiler [61eb1bfa]:
 GPUCompiler [61eb1bfa] log:
 ├─possible versions are: [0.1.0, 0.2.0, 0.3.0] or uninstalled
 ├─restricted by compatibility requirements with CUDA [052768ef] to versions: 0.3.0
 │ └─CUDA [052768ef] log:
 │   ├─possible versions are: 0.1.0 or uninstalled
 │   └─restricted to versions * by an explicit requirement, leaving only versions 0.1.0
 └─restricted by julia compatibility requirements to versions: [0.1.0, 0.2.0] or uninstalled — no versions left

Couldn’t figure out the issue as the CUDA.jl Project.toml looks fine to me but wondering if anyone else is getting this.

7

So GPUCompiler v0.3.0 has a lower bound on Julia v1.4.0. Which means presumably CUDA.jl cannot be installed in Julia v1.3.

2 Likes
8

That makes sense so maybe the CUDA.jl README needs updating as it says “The package is tested against, and being developed for, Julia 1.3 and above.”

9

Yes that’s correct. I’ll add it to the README.

1 Like
10

The new CUDA.jl looks great. Last time I tried CuArrays, it did not support an older version of the Nvidia driver on a server I was using (which I could not update because I was not admin). But now it seems to run fine!

Just to confirm, have there been any changes enabling support for older driver versions?

11

Not specifically, but with the artifact changes you might now have a matching CUDA toolkit.

1 Like
12

Damn case sensitivity… add cuda.jl …no… add Cuda.jl … no … CUDA.jl …yes…

One small plea… this has irritated me when installing other packages.
I guess there is not much to be done about it - having cuda and Cuda point toward CUDA as some sort of alias probably would lead to confusion.

Reporting back - installs OK on Windows 10/Julia 1.4.1 but I have no Nvidia card.
If I find time later I will test on Jetson Nano

1 Like
13

On Jetson Nano / Julia 1.4.1 CUDA.jl installs but during test codegen fails

codegen (2) | failed at 2020-05-28T12:10:16.847

Looks like my userid does not have the privileges to profile CUDA code. I will get that fixed and report back

14

I have the same issue with codegen. I added the privileges but still get the same error :confused:

15

Not good news

Nvidia Visual Profiler and nvprof don’t support profiling on Tegra devices (like Jetson TX2) for non-root users. The only workaround is to start the profiling session as a root user.

16

There is an issue talking about displaying similarly named packages when trying to add a package not in the registries. I started a PR for a search feature that hopefully can also be used for add.

3 Likes
17

Fantastic work, @maleadt! I think this is a good idea. For what it’s worth, I ran the test suite on the current tagged release, Julia 1.4.1 using a RTX 2060 on CUDA driver 10.2.0 and toolkit 10.2.0.

After disabling my startup.jl file (Testsuite calls startup.jl · Issue #182 · JuliaGPU/CUDA.jl · GitHub) I was able to run the testsuite and everything passed.

1 Like
18

Thanks @maleadt; this looks like a great improvement in terms of user-friendlyness! I believe it is nice to have just one package :slight_smile:

I have a little question on how the packages were merged. Are there symbol names which appear in more than one of the packages CuArrrays/CUDAnative/CUDAdrv, but are not identical? If so, how did you merge them? E.g. is the method CUDAnative.synchronize identical to the method of CUDAdrv.synchronize without arguments? If not, what did go into CUDA.sychronize()?

CUDAnative/CUDAdrv 

help?> CUDAnative.synchronize
  synchronize()

  Wait for the device to finish. This is the device side version, and should not be called from the host.

  synchronize acts as a synchronization point for child grids in the context of dynamic parallelism.

help?> CUDAdrv.synchronize
  synchronize()

  Block for the current context's tasks to complete.

  ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

  synchronize(s::CuStream)

  Wait until a stream's tasks are completed.

  ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

  synchronize(e::CuEvent)

  Waits for an event to complete.

CUDA 

help?> CUDA.synchronize
  synchronize()

  Block for the current context's tasks to complete.

  ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

  synchronize(s::CuStream)

  Wait until a stream's tasks are completed.

  ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

  synchronize(e::CuEvent)

  Waits for an event to complete.

Thanks!

19

I renamed device-side synchronization to device_synchronize. It’s a tough call, though. I considered adding a submodule to contain all device functionality so that we could retain the name, e.g. Device.synchronize, but that would be too breaking. In all other cases, I kept the previous name, even though that now mixes host and device functionality in a single package (making it easy to, e.g., crash Julia by inadvertently calling GPU code from the CPU). I hope that we’ll soon be able to use contextual dispatch to have those methods error when called from the wrong context.

20

Thanks @maleadt for this information.

I believe that would be fantastic and a big step forward in the right direction!