Hi all! Very much appreciate the work that's been put into CUDA support in nixpkgs/NixOS.
Recently updated my system configuration to a more recent version of nixpkgs and had to pin cudaCapabilities to 6.1 now that CUDA 13.0 has dropped support for Pascal, started getting some confusing build failures as a result.
Spent several hours looking into how the CUDA packaging ecosystem works only to realize using --trace-verbose gave the answer straight up >.<.

It seems nixpkgs updating to use cuDNN 9.13 means that other packages pulling in cudaPackages_12_{6,8,9} no longer support compute capabilities < 7.5 even though CUDA supports compute capabilities >= 5.0 up until the jump to 13.0.

I noticed 9.13 is not the only version in nixpkgs though, what is the strategy around how many legacy versions of CUDA packages to maintain in nixpkgs?
Does it make sense to add cuDNN 9.11 as a pinned version to bridge the gap since 9.12 has dropped support for compute capabilities < 7.5?
If that's not appropriate 8.9.7 is the most recent version available in nixpkgs which still supports my hardware, how would I/how reasonable is it to force my config to use that?

Sorry for all the questions, appreciate any advice 😅

In reply to @aliarokapis:matrix.org
any idea what is the difference between torch-bin and torchWithCuda ?

I’ll try to answer this later today. Depending on how comfortable you are with Nix, pull in the overlay for CUDA-legacy (https://github.com/nixos-cuda/cuda-legacy) to add a bunch of manifests and then customize the package set to your liking by using override on the CUDA package set and providing the manifest version you want. The docs are lacking an example for this.

As you discovered, NVCC may support capabilities but that doesn’t mean the big libraries most people use (cuDNN, libcublas, TensorRT, etc.) do. We have the unenviable job of either adopting the latest release for each version or fixing them in time and never updating. The decision is made more difficult by the fact NVIDIA seems to fix bugs by doing major/minor releases much more often than patch releases.

The trace-verbose thing is handy but undocumented and only exists because implementations of the Problems RFC keep getting bikeshedded to death.

We should probably have a section in the CUDA docs which list supported capabilities for each package set. Could be automatically generated given I added the available capabilities for each release to backendStdenv.

problems rfc

Tha release was cut off, IMO we should push a half-assed partial impl as per my closed PR in, bc 99% of the features we don't care about

stdenv attributes

...also nuke the other 90% attributes that don't actually belong and aren't even used

In reply to @tpw_rules:matrix.org
i'm mildly peeved about a recent merging of something i maintain where i'm pretty sure the merger does not own the expensive hardware required to properly test the package. i don't think it broke anything but i was given precisely 45 minutes to see the notification before somebody merged it