cudaPackages: introduce and use cudaLib

[ConnorBaker]

Broadly, this PR does these things:

• Introduces a new top-level attribute, _cuda, which consolidates CUDA package set backbone (static data, configurations, utility functions, etc. required to create a CUDA package set)
• Removes things from the CUDA package set fixed point which should be supplied by callPackage and the newScope used to construct the package set (i.e., _cuda.bootstrapData, _cuda.fixups)
• Aligns language regarding redistributables: redist arch has been changed to redist system to better mirror nix system, as both are two-tuple system configs
• Rewrites cudaPackages.backendStdenv

This PR is a step toward landing more improvements from https://github.com/ConnorBaker/cuda-packages and merging the changes in #406740.

This PR presents largely organizational changes, but does cause rebuilds due to changes in the default selection of CUDA capabilities (see the section under _cuda.lib).

The _cuda attribute and all that it contains is introduced to enable re-use out of tree. For the time being, it is provided without any guarantee of stability.

_cuda.fixups

• fixups is moved to _cuda.fixups
• _cuda.fixups is removed from CUDA package sets and exists only at top-level to make clear it exists outside of any CUDA package set's fixed point

_cuda.bootstrapData

• GPU capabilities are rewritten to include more information, updated with new architectures and feature sets, and brought under _cuda.bootstrapData.cudaCapabilityToInfo (pkgs/development/cuda-modules/_cuda/db/bootstrap/cuda.nix)
• NVCC compatibilities are rewritten to group versions for host compilers under an attribute set rather than using a string prefix and brought under _cuda.bootstrapData.nvccCompatibilities (pkgs/development/cuda-modules/_cuda/db/bootstrap/nvcc.nix)
• Additional commonly used data are available (e.g., redistNames, redistUrlPrefix)

_cuda.lib

Constructing out-of-tree package sets for CUDA packages is difficult and typically requires vendoring large numbers of files to be able to benefit from the machinery we (the CUDA team) have built. _cuda.lib provides an interface through which out-of-tree consumers of Nixpkgs can access the same machinery we use. (Data and configuration re-use are enabled by _cuda.bootstrapData and _cuda.fixups.)

_cuda.lib also serves to centralize and document a number of ad-hoc functionalities created in the CUDA package set. For example, many of the functions which had been lumped into flags.nix are now available in _cuda.lib.

Due to its recency, very little of _cuda.lib is provided as a stable API. Many functions are only used internally at the moment (they are prefixed with an _) and are provided without guarantees of stability or correctness. They are however, available for use given their utility.

Changes to the default set of CUDA capabilities

Previously, the set of default capabilities for CUDA 12.8 were

6.0 6.1 7.0 7.5 8.0 8.6 8.9 9.0 9.0a 10.0 12.0

They are now

            7.5 8.0 8.6 8.9 9.0      10.0 12.0

Given the number of capabilities introduced by the last few releases, dropping older capabilities becomes a necessity to keep the amount of device code generated small enough to link against. (There is a 2GB limit.) Since recent TensorRT releases have deprecated and no dropped support for 6.0 through 7.0, it makes sense to drop them from the default set of capabilities.

Additionally, the inclusion of architecture-specific capabilities, like 9.0a, have been removed from the default collection of targets, as they are not meant to be used with other capabilities without careful guarding in source (a feature only discussed in 12.9¹).

cudaPackages.backendStdenv

The changes made to backendStdenv enable evaluation-time checking of certain common mistakes. Additionally, it provides a single point of access to common attributes describing the CUDA package set, such as:

• nvccHostCCMatchesStdenvCC: whether the current stdenv matches the version which will be provided to NVCC
• hostNixSystem: an alias to stdenv.hostPlatform.system
• hostRedistSystem: the NVIDIA equivalent of hostNixSystem
• cudaCapabilities: the resolved collection of CUDA capabilities cudaPackages.flags's attributes target
• hasJetsonCudaCapability: whether cudaCapabilities contains a capability belonging to a Jetson device

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• 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/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 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
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

Footnotes

1. https://developer.nvidia.com/blog/nvidia-blackwell-and-nvidia-cuda-12-9-introduce-family-specific-architecture-features/#architecture-specific_features ↩

[ConnorBaker]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 406531 --extra-nixpkgs-config '{ allowAliases = false; allowBroken = false; allowUnfree = true; checkMeta = true; contentAddressedByDefault = false; cudaCapabilities = [ "8.9" ]; cudaSupport = true; }'

---

x86_64-linux

✅ 1 package built:

• nixpkgs-manual

[ConnorBaker]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 406531

---

x86_64-darwin

✅ 1 package built:

• nixpkgs-manual

---

aarch64-darwin

✅ 1 package built:

• nixpkgs-manual

[ConnorBaker]

Changes:

• rebased on master after tree-wide: cudaPackages.cudaFlags -> cudaPackages.flags #406545 was merged
• added cudaLib.utils.allowUnfreeCudaPredicate
• added commit for tree-wide changes to update usage of cudaPackages.flags

[SomeoneSerge]

Here - instead of exposing cudaLib I see something like makeCudaScope = let cudaLib = ...; in cudaLib.${...}; cudaPackages_XX_YY = makeCudaScope { ... }

[ConnorBaker]

I would like to have cudaLib exposed outside of the CUDA package set since it does not depend on the CUDA version or architecture. Having it at the top level is also important because if out-of-tree consumers modify it (e.g., by adding new GPUs), those changes are propagated to all consumers of cudaLib. One such example where that's important is the pkgsCuda attribute set I'd like to introduce in #406568: eb044ff.

[SomeoneSerge]

Following up on the discussions we've had asynchronously:

• Out-of-tree support as such requires two public pieces of information:

  • (extendible) static data, and
  • the package set constructor (Data -> Configuration -> PackageSet,

  where Configuration is version/tag constraints but may include extra extensions, extra fixups, etc.). Implicit here are the "fixups" and "shims", hidden inside the "constructor" (keep this way?). This PR gathers the data we've used so far into data.nix. tests.cuda.db: init #406740 is to unify data.nix with the machine-readable part of the "knowledge". We're yet to sketch the "constructor".

• DX-wise we do want to establish a few fixpoints to facilitate propagation of overrides to the multiple ps instances used by Nixpkgs: a fixpoint for extensions, for fixups, for "static data". We do want to keep them to the minimum though, so as not to commit to supporting a wider interface. Connor you mentioned you had a PR for cudaPackagesExtensions open?

• In the current form it's a bit backward that cudaLib is defined outside cudaPackages but is only used inside. In the formalism established above, the motivation is obscured by the fact we haven't isolated the "constructor" yet.

• I'd also potentially abstain from exposing anything that doesn't need to be a fixpoint

[SomeoneSerge]

@ConnorBaker I didn't want to overwrite your commits, leaving the autosquash to you. IMO this is ready to be merged to master, but let's have another look-over and maybe a nixpkgs-review before backporting

[ConnorBaker]

Rebased, squashed, force-pushed, and updated the PR description. Also built PyTorch to confirm it works on x86_64-linux.

@SomeoneSerge ready for merge!

[nixpkgs-ci]

Backport failed for release-24.11, because it was unable to cherry-pick the commit(s).

Please cherry-pick the changes locally and resolve any conflicts.

git fetch origin release-24.11
git worktree add -d .worktree/backport-406531-to-release-24.11 origin/release-24.11
cd .worktree/backport-406531-to-release-24.11
git switch --create backport-406531-to-release-24.11
git cherry-pick -x 646bebe3be8004e578842745136b8196f4f1fced a018d736978adf55e1b8f7bf79e736cd6d042573 0ac3a73b6a997ea5e05067577a17c613ecddcd7d 629ae4e42c4764f1e56cd64746a3f19e28ff62a0 c5dad2886a5623fc5e41054ab9ed9ff8e5f7ac91 765529dfff5cb04cd8ebf9275c9bccc9473fcbb5 ead65813623f92f8630811b1b3616877a727b1d9 8fcff2390e3224e970291975cedcbd23f743c6da 688e14d21a38135270544bfdfcc793d25dea2802

[nixpkgs-ci]

Successfully created backport PR for release-25.05:

• [Backport release-25.05] cudaPackages: introduce and use cudaLib #411445

[SomeoneSerge]

Ah, didn't realize that this made flags depend on the package set