cudnn: 8.3.0 -> 8.3.2

[samuela]

Description of changes

Update cuDNN 8.3 version. Refactor the cuDNN derivations to be clearer and enforce CUDA version constraints.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 22.05 Release Notes (or backporting 21.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[samuela]

cc @NixOS/cuda-maintainers

[samuela]

I'll go ahead and merge tomorrow unless anyone objects.

[SomeoneSerge]

If it's too old, why do we keep it as a default?

[samuela]

Just because no one's gotten around to updating it yet. But that would be great for a follow-up PR!

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/announcing-the-nixos-cuda-maintainers-team-and-a-call-for-maintainers/18074/10

[SomeoneSerge]

Nixpkgs also packages cudatoolkit-11.6. Archlinux allows installing cudnn-8.3.2 with it and it seems to work there:

https://archlinux.org/packages/community/x86_64/cudnn/
Dependencies (1)
cuda>=11.5

Which attribute should the users of cudatoolkit-11.6 use for cudnn?

[SomeoneSerge]

Some package set maintainers may complain about the effort it takes to update and validate urls and hashes, but I think mkSrc is a step in good direction. This is because we can follow up with discarding this confusing cudnn_${cudnn-ver}_cudatoolkit_${cuda-ver} pattern and instead have a single overridable cudnn that chooses the sources and does all the checks

[samuela]

Which attribute should the users of cudatoolkit-11.6 use for cudnn?

Sadly, none. I'm basing this off of NVIDIA's official version constraints. There's sort of a policy question here: How strictly should we track upstream's version constraints? As you note, it is possible to smudge those constraints in certain scenarios and it "seems to work." My personal inclination atm is to wait for a new cuDNN release that officially supports CUDA 11.6 because

• Diverging from the official version constraints mean that the responsibility of testing cuDNN/CUDA combos falls on us, as opposed to upstream. That increases our maintenance burden and makes it that much more difficult when debugging issues, eg "Is X failing bc of this cuDNN/CUDA combo, or just bc the code is broken?". Reporting issues to NVIDIA upstream is also a lot easier if it occurs within their stated constraints.
• Users can still override the official version constraints if they so desire. The package will still evaluate, just with meta.broken set. And that can be overridden as well with only a little fuss.

Some package set maintainers may complain about the effort it takes to update and validate urls and hashes, but I think mkSrc is a step in good direction. This is because we can follow up with discarding this confusing cudnn_${cudnn-ver}cudatoolkit${cuda-ver} pattern and instead have a single overridable cudnn that chooses the sources and does all the checks

Thanks! Yeah, I'm hoping that this is a step in the right direction. Dealing with these version constraints is a huge mental burden normally so it's nice to have the system help you out here and there.

[SomeoneSerge]

Sadly, none

Then we can clarify the cudnn-cudatoolkit situation in the wiki (st people don't just feel they're on their own), and later work out the UX of overriding cuda version

[samuela]

Yeah, good idea. This would be a great bit of info for the wiki page.

[SomeoneSerge]

I haven't edited the main page yet, but I added comments in the talk page: https://nixos.wiki/wiki/Talk:Nvidia#cudnn

[rehno-lindeque]

Doesn't this have to be cudnn_8_3_cudatoolkit_10 in order to be compatible with the currently packaged cudatoolkit?

[samuela]

Ideally, yes. The issue is that cuDNN 7.6.5 doesn't actually support CUDA 10.2, the current cudatoolkit version. And I didn't want to upgrade cuDNN past 7.6.5 here in the interest of keeping this PR as small as possible. The solution is to upgrade cudnn to 8.3 which supports CUDA 10.2-11.5. (Looks like you're already on that, great!)

In the future, it think it would be nice to explore a solution like cudatoolkit_11.withPackages similar to python3.withPackages, but we have to move one step at a time to get the ball rolling.