pyrox.dev / nixpkgs
lol
fork atom

Apply markdown lints to CUDA READMEs

Yann Hamdaoui a39043f1 a59c7364

+64 -18
unified split
+26 -9
pkgs/development/cuda-modules/README.md
··· 1 - # cuda-modules 2 3 > [!NOTE] 4 - > This document is meant to help CUDA maintainers understand the structure of the CUDA packages in Nixpkgs. It is not meant to be a user-facing document. 5 > For a user-facing document, see [the CUDA section of the manual](../../../doc/languages-frameworks/cuda.section.md). 6 7 - The files in this directory are added (in some way) to the `cudaPackages` package set by [cuda-packages.nix](../../top-level/cuda-packages.nix). 8 9 ## Top-level files 10 11 - Top-level nix files are included in the initial creation of the `cudaPackages` scope. These are typically required for the creation of the finalized `cudaPackages` scope: 12 13 - `backend-stdenv.nix`: Standard environment for CUDA packages. 14 - `flags.nix`: Flags set, or consumed by, NVCC in order to build packages. 15 - `gpus.nix`: A list of supported NVIDIA GPUs. 16 - - `nvcc-compatibilities.nix`: NVCC releases and the version range of GCC/Clang they support. 17 18 ## Top-level directories 19 20 - `cuda`: CUDA redistributables! Provides extension to `cudaPackages` scope. 21 - - `cudatoolkit`: monolothic CUDA Toolkit run-file installer. Provides extension to `cudaPackages` scope. 22 - `cudnn`: NVIDIA cuDNN library. 23 - `cutensor`: NVIDIA cuTENSOR library. 24 - `generic-builders`: 25 - - Contains a builder `manifest.nix` which operates on the `Manifest` type defined in `modules/generic/manifests`. Most packages are built using this builder. 26 - - Contains a builder `multiplex.nix` which leverages the Manifest builder. In short, the Multiplex builder adds multiple versions of a single package to single instance of the CUDA Packages package set. It is used primarily for packages like `cudnn` and `cutensor`. 27 - - `modules`: Nixpkgs modules to check the shape and content of CUDA redistributable and feature manifests. These modules additionally use shims provided by some CUDA packages to allow them to re-use the `genericManifestBuilder`, even if they don't have manifest files of their own. `cudnn` and `tensorrt` are examples of packages which provide such shims. These modules are further described in the [Modules](./modules/README.md) documentation. 28 - `nccl`: NVIDIA NCCL library. 29 - `nccl-tests`: NVIDIA NCCL tests. 30 - `saxpy`: Example CMake project that uses CUDA.
··· 1 + # Cuda modules 2 3 > [!NOTE] 4 + > This document is meant to help CUDA maintainers understand the structure of 5 + > the CUDA packages in Nixpkgs. It is not meant to be a user-facing document. 6 > For a user-facing document, see [the CUDA section of the manual](../../../doc/languages-frameworks/cuda.section.md). 7 8 + The files in this directory are added (in some way) to the `cudaPackages` 9 + package set by [cuda-packages.nix](../../top-level/cuda-packages.nix). 10 11 ## Top-level files 12 13 + Top-level nix files are included in the initial creation of the `cudaPackages` 14 + scope. These are typically required for the creation of the finalized 15 + `cudaPackages` scope: 16 17 - `backend-stdenv.nix`: Standard environment for CUDA packages. 18 - `flags.nix`: Flags set, or consumed by, NVCC in order to build packages. 19 - `gpus.nix`: A list of supported NVIDIA GPUs. 20 + - `nvcc-compatibilities.nix`: NVCC releases and the version range of GCC/Clang 21 + they support. 22 23 ## Top-level directories 24 25 - `cuda`: CUDA redistributables! Provides extension to `cudaPackages` scope. 26 + - `cudatoolkit`: monolothic CUDA Toolkit run-file installer. Provides extension 27 + to `cudaPackages` scope. 28 - `cudnn`: NVIDIA cuDNN library. 29 - `cutensor`: NVIDIA cuTENSOR library. 30 - `generic-builders`: 31 + - Contains a builder `manifest.nix` which operates on the `Manifest` type 32 + defined in `modules/generic/manifests`. Most packages are built using this 33 + builder. 34 + - Contains a builder `multiplex.nix` which leverages the Manifest builder. In 35 + short, the Multiplex builder adds multiple versions of a single package to 36 + single instance of the CUDA Packages package set. It is used primarily for 37 + packages like `cudnn` and `cutensor`. 38 + - `modules`: Nixpkgs modules to check the shape and content of CUDA 39 + redistributable and feature manifests. These modules additionally use shims 40 + provided by some CUDA packages to allow them to re-use the 41 + `genericManifestBuilder`, even if they don't have manifest files of their 42 + own. `cudnn` and `tensorrt` are examples of packages which provide such 43 + shims. These modules are further described in the 44 + [Modules](./modules/README.md) documentation. 45 - `nccl`: NVIDIA NCCL library. 46 - `nccl-tests`: NVIDIA NCCL tests. 47 - `saxpy`: Example CMake project that uses CUDA.
+38 -9
pkgs/development/cuda-modules/modules/README.md
··· 1 # Modules 2 3 - Modules as they are used in `modules` exist primarily to check the shape and content of CUDA redistributable and feature manifests. They are ultimately meant to reduce the repetitive nature of repackaging CUDA redistributables. 4 5 - Building most redistributables follows a pattern of a manifest indicating which packages are available at a location, their versions, and their hashes. To avoid creating builders for each and every derivation, modules serve as a way for us to use a single `genericManifestBuilder` to build all redistributables. 6 7 ## `generic` 8 9 - The modules in `generic` are reusable components meant to check the shape and content of NVIDIA's CUDA redistributable manifests, our feature manifests (which are derived from NVIDIA's manifests), or hand-crafted Nix expressions describing available packages. They are used by the `genericManifestBuilder` to build CUDA redistributables. 10 11 - Generally, each package which relies on manifests or Nix release expressions will create an alias to the relevant generic module. For example, the [module for CUDNN](./cudnn/default.nix) aliases the generic module for release expressions, while the [module for CUDA redistributables](./cuda/default.nix) aliases the generic module for manifests. 12 13 - Alternatively, additional fields or values may need to be configured to account for the particulars of a package. For example, while the release expressions for [CUDNN](./cudnn/releases.nix) and [TensorRT](./tensorrt/releases.nix) are very close, they differ slightly in the fields they have. The [module for CUDNN](./modules/cudnn/default.nix) is able to use the generic module for release expressions, while the [module for TensorRT](./modules/tensorrt/default.nix) must add additional fields to the generic module. 14 15 ### `manifests` 16 17 - The modules in `generic/manifests` define the structure of NVIDIA's CUDA redistributable manifests and our feature manifests. 18 19 - NVIDIA's redistributable manifests are retrieved from their web server, while the feature manifests are produced by [`cuda-redist-find-features`](https://github.com/connorbaker/cuda-redist-find-features). 20 21 ### `releases` 22 23 - The modules in `generic/releases` define the structure of our hand-crafted Nix expressions containing information necessary to download and repackage CUDA redistributables. These expressions are created when NVIDIA-provided manifests are unavailable or otherwise unusable. For example, though CUDNN has manifests, a bug in NVIDIA's CI/CD causes manifests for different versions of CUDA to use the same name, which leads to the manifests overwriting each other. 24 25 ### `types` 26 27 - The modules in `generic/types` define reusable types used in both `generic/manifests` and `generic/releases`.
··· 1 # Modules 2 3 + Modules as they are used in `modules` exist primarily to check the shape and 4 + content of CUDA redistributable and feature manifests. They are ultimately meant 5 + to reduce the repetitive nature of repackaging CUDA redistributables. 6 7 + Building most redistributables follows a pattern of a manifest indicating which 8 + packages are available at a location, their versions, and their hashes. To avoid 9 + creating builders for each and every derivation, modules serve as a way for us 10 + to use a single `genericManifestBuilder` to build all redistributables. 11 12 ## `generic` 13 14 + The modules in `generic` are reusable components meant to check the shape and 15 + content of NVIDIA's CUDA redistributable manifests, our feature manifests (which 16 + are derived from NVIDIA's manifests), or hand-crafted Nix expressions describing 17 + available packages. They are used by the `genericManifestBuilder` to build CUDA 18 + redistributables. 19 20 + Generally, each package which relies on manifests or Nix release expressions 21 + will create an alias to the relevant generic module. For example, the [module 22 + for CUDNN](./cudnn/default.nix) aliases the generic module for release 23 + expressions, while the [module for CUDA redistributables](./cuda/default.nix) 24 + aliases the generic module for manifests. 25 26 + Alternatively, additional fields or values may need to be configured to account 27 + for the particulars of a package. For example, while the release expressions for 28 + [CUDNN](./cudnn/releases.nix) and [TensorRT](./tensorrt/releases.nix) are very 29 + close, they differ slightly in the fields they have. The [module for 30 + CUDNN](./modules/cudnn/default.nix) is able to use the generic module for 31 + release expressions, while the [module for 32 + TensorRT](./modules/tensorrt/default.nix) must add additional fields to the 33 + generic module. 34 35 ### `manifests` 36 37 + The modules in `generic/manifests` define the structure of NVIDIA's CUDA 38 + redistributable manifests and our feature manifests. 39 40 + NVIDIA's redistributable manifests are retrieved from their web server, while 41 + the feature manifests are produced by 42 + [`cuda-redist-find-features`](https://github.com/connorbaker/cuda-redist-find-features). 43 44 ### `releases` 45 46 + The modules in `generic/releases` define the structure of our hand-crafted Nix 47 + expressions containing information necessary to download and repackage CUDA 48 + redistributables. These expressions are created when NVIDIA-provided manifests 49 + are unavailable or otherwise unusable. For example, though CUDNN has manifests, 50 + a bug in NVIDIA's CI/CD causes manifests for different versions of CUDA to use 51 + the same name, which leads to the manifests overwriting each other. 52 53 ### `types` 54 55 + The modules in `generic/types` define reusable types used in both 56 + `generic/manifests` and `generic/releases`.