+2
-2
doc/languages-frameworks/cuda.section.md
+2
-2
doc/languages-frameworks/cuda.section.md
···-1. Update `nvcc-compatibilities.nix` in `pkgs/development/cuda-modules/` to include the newest release of NVCC, as well as any newly supported host compilers.-2. Update `gpus.nix` in `pkgs/development/cuda-modules/` to include any new GPUs supported by the new release of CUDA.+1. Update `nvccCompatibilities` in `pkgs/development/cuda-modules/lib/data/nvcc.nix` to include the newest release of NVCC, as well as any newly supported host compilers.+2. Update `cudaCapabilityToInfo` in `pkgs/development/cuda-modules/lib/data/cuda.nix` to include any new GPUs supported by the new release of CUDA.
-3
pkgs/development/cuda-modules/README.md
-3
pkgs/development/cuda-modules/README.md
···
+3
-2
pkgs/development/cuda-modules/aliases.nix
+3
-2
pkgs/development/cuda-modules/aliases.nix
···
+1
-1
pkgs/development/cuda-modules/cuda/extension.nix
+1
-1
pkgs/development/cuda-modules/cuda/extension.nix
···# Generally we prefer to do things involving getting attribute names with feature_manifest instead# names as the keys, whereas the redistrib manifest will also have things like version, name, license,
+3
-3
pkgs/development/cuda-modules/cudnn/shims.nix
+3
-3
pkgs/development/cuda-modules/cudnn/shims.nix
···
+5
-13
pkgs/development/cuda-modules/cusparselt/extension.nix
+5
-13
pkgs/development/cuda-modules/cusparselt/extension.nix
·········# TODO(@connorbaker): With an auxiliary file keeping track of the CUDA versions each release supports,···
+5
-9
pkgs/development/cuda-modules/cutensor/extension.nix
+5
-9
pkgs/development/cuda-modules/cutensor/extension.nix
···# - Instead of providing different releases for each version of CUDA, CuTensor has multiple subdirectories in `lib`······# TODO(@connorbaker): With an auxiliary file keeping track of the CUDA versions each release supports,···
+4
-2
pkgs/development/cuda-modules/fixups/tensorrt.nix
+4
-2
pkgs/development/cuda-modules/fixups/tensorrt.nix
······if finalAttrs.passthru.featureRelease.cudnnVersion == null || (cudaPackages ? desiredName) then
-399
pkgs/development/cuda-modules/flags.nix
-399
pkgs/development/cuda-modules/flags.nix
···-cudaArchNameToVersions = lists.groupBy' (versions: gpu: versions ++ [ gpu.computeCapability ]) [ ] (-# non-Jetson devices and require an aarch64 host platform. As such, if they're present anywhere,-# Maps a feature across a list of architecture versions to produce a list of gencode arguments.-# For example, "sm" and [ "8.0" "8.6" "8.7" ] produces [ "-gencode=arch=compute_80,code=sm_80"-"-gencode=arch=compute_${dropDot computeCapability},code=${feat}_${dropDot computeCapability}"-# NOTE: This function *will* be called by unsupported systems because `cudaPackages` is part of-# `all-packages.nix`, which is evaluated on all systems. As such, we need to handle unsupported-# NOTE: This function *will* be called by unsupported systems because `cudaPackages` is part of-# `all-packages.nix`, which is evaluated on all systems. As such, we need to handle unsupported-# The virtual architectures are typically used for forward compatibility, when trying to support-# E.g. [ "-gencode=arch=compute_75,code=sm_75" ... "-gencode=arch=compute_86,code=compute_86" ]-# A semicolon-separated string of CUDA capabilities without dots, suitable for passing to CMake.-# Jetson devices cannot be targeted by the same binaries which target non-Jetson devices. While-# NVIDIA provides both `linux-aarch64` and `linux-sbsa` packages, which both target `aarch64`,-Jetson devices cannot be targeted with non-Jetson devices. Additionally, they require hostPlatform to be aarch64.-gencodeString = "-gencode=arch=compute_75,code=sm_75 -gencode=arch=compute_86,code=sm_86 -gencode=arch=compute_86,code=compute_86";-gencodeString = "-gencode=arch=compute_62,code=sm_62 -gencode=arch=compute_72,code=sm_72 -gencode=arch=compute_72,code=compute_72";-# formatCapabilities :: { cudaCapabilities: List Capability, enableForwardCompat: Boolean } -> { ... }
+23
-17
pkgs/development/cuda-modules/generic-builders/manifest.nix
+23
-17
pkgs/development/cuda-modules/generic-builders/manifest.nix
······+redistSystem = cudaLib.utils.getRedistSystem backendStdenv.hasJetsonCudaCapability hostPlatform.system;······# we will have `outputs = [ "out" ] ++ possibleOutputs`. This is of note because platforms which# aren't supported would otherwise have evaluation errors when trying to access outputs other than `out`.-# The alternative would be to have `outputs = [ "out" ]` when`redistArch = "unsupported"`, but that would+# The alternative would be to have `outputs = [ "out" ]` when`redistSystem = "unsupported"`, but that would# require adding guards throughout the entirety of the CUDA package set to ensure `cudaSupport` is true --# recall that OfBorg will evaluate packages marked as broken and that `cudaPackages` will be evaluated with-if redistArch == "unsupported" then possibleOutputs else builtins.filter hasOutput possibleOutputs;···url = "https://developer.download.nvidia.com/compute/${redistName}/redist/${relative_path}";···description = "${redistribRelease.name}. By downloading and using the packages you accept the terms and conditions of the ${finalAttrs.meta.license.shortName}";
+8
-13
pkgs/development/cuda-modules/generic-builders/multiplex.nix
+8
-13
pkgs/development/cuda-modules/generic-builders/multiplex.nix
······# The featureRelease is used to populate meta.platforms (by way of looking at the attribute names), determine the# outputs of the package, and provide additional package-specific constraints (e.g., min/max supported CUDA versions,············
-244
pkgs/development/cuda-modules/gpus.nix
-244
pkgs/development/cuda-modules/gpus.nix
···-# A5000, A6000, NVIDIA A40, GA106 – RTX 3060, GA104 – RTX 3070, GA107 – RTX 3050, RTX A10, RTX
-125
pkgs/development/cuda-modules/nvcc-compatibilities.nix
-125
pkgs/development/cuda-modules/nvcc-compatibilities.nix
···-# https://docs.nvidia.com/cuda/cuda-installation-guide-linux/index.html#host-compiler-support-policy-# NVCC performs a version check on the host compiler’s major version and so newer minor versions-# E.g.: CUDA 12.2.1 maxxed out with support for Clang 15.0; 12.2.2 added support for Clang 16.0.-# NOTE: Because all platforms NVIDIA supports use GCC and Clang, we omit the architectures here.-# https://docs.nvidia.com/cuda/archive/11.0/cuda-toolkit-release-notes/index.html#cuda-compiler-new-features-# https://docs.nvidia.com/cuda/archive/11.1.1/cuda-toolkit-release-notes/index.html#cuda-compiler-new-features-# https://docs.nvidia.com/cuda/archive/11.2.2/cuda-installation-guide-linux/index.html#system-requirements-# https://docs.nvidia.com/cuda/archive/11.4.4/cuda-toolkit-release-notes/index.html#cuda-general-new-features-# NOTE: There is a bug in the version of GLIBC that GCC 11 uses which causes it to fail to compile some CUDA-# https://forums.developer.nvidia.com/t/cuda-11-5-samples-throw-multiple-error-attribute-malloc-does-not-take-arguments/192750/15-# https://docs.nvidia.com/cuda/archive/11.7.1/cuda-toolkit-release-notes/index.html#cuda-compiler-new-features-# https://docs.nvidia.com/cuda/archive/11.8.0/cuda-installation-guide-linux/index.html#system-requirements-# https://docs.nvidia.com/cuda/archive/12.0.1/cuda-installation-guide-linux/index.html#system-requirements-# https://docs.nvidia.com/cuda/archive/12.1.1/cuda-toolkit-release-notes/index.html#cuda-compilers-new-features-# https://docs.nvidia.com/cuda/archive/12.2.2/cuda-installation-guide-linux/index.html#host-compiler-support-policy-# https://docs.nvidia.com/cuda/archive/12.4.0/cuda-installation-guide-linux/index.html#host-compiler-support-policy-# https://docs.nvidia.com/cuda/archive/12.6.0/cuda-installation-guide-linux/index.html#host-compiler-support-policy-# https://docs.nvidia.com/cuda/archive/12.8.0/cuda-installation-guide-linux/index.html#host-compiler-support-policy
+3
-3
pkgs/development/cuda-modules/tensorrt/shims.nix
+3
-3
pkgs/development/cuda-modules/tensorrt/shims.nix
···
+78
pkgs/development/cuda-modules/tests/flags.nix
+78
pkgs/development/cuda-modules/tests/flags.nix
···+gencodeString = "-gencode=arch=compute_75,code=sm_75 -gencode=arch=compute_86,code=sm_86 -gencode=arch=compute_86,code=compute_86";
+49
-33
pkgs/top-level/cuda-packages.nix
+49
-33
pkgs/top-level/cuda-packages.nix
···# I've (@connorbaker) attempted to do that, though I'm unsure of how this will interact with overrides.···-name: version: name + "_" + strings.replaceStrings [ "." ] [ "_" ] (versions.majorMinor version);+# Since Jetson capabilities are never built by default, we can check if any of them were requested+# through final.config.cudaCapabilities and use that to determine if we should change some manifest versions.+redistSystem = cudaLib.utils.getRedistSystem hasJetsonCudaCapability stdenv.hostPlatform.system;+# It is important that cudaLib (and fixups, which will be addressed later) are not part of the package set+# > The layering should be: configuration -> (identifies/is part of) cudaPackages -> (is built using) cudaLib.+# That is to say that cudaLib should only know about package sets and configurations, because it implements+# functionality for interpreting configurations, resolving them against data, and constructing package sets.···-# NOTE: mkVersionedPackageName is an internal, implementation detail and should not be relied on by outside consumers.···+# TODO(@connorbaker): Enable the corresponding warnings in `../development/cuda-modules/aliases.nix` after some# Barring packages which share a home (e.g., cudatoolkit and cudatoolkit-legacy-runfile), new packages# should be added to ../development/cuda-modules/packages in "by-name" style, where they will be automatically······(import ../development/cuda-modules/cuda/extension.nix { inherit cudaMajorMinorVersion lib; })······(import ../development/cuda-modules/cuda-library-samples/extension.nix { inherit lib stdenv; })
+2
-15
pkgs/top-level/release-cuda.nix
+2
-15
pkgs/top-level/release-cuda.nix
······