Home • Explore • Blog • Models • CI
☰



nixpkgs
1st chunk of `pkgs/development/cuda-modules/README.md`
211228e126c142492efaab46ba60c97cc5330d5aa1628cb60000000100000981
# CUDA Modules

> [!NOTE]
> 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.
> For a user-facing document, see [the CUDA section of the manual](../../../doc/languages-frameworks/cuda.section.md).

The files in this directory are added (in some way) to the `cudaPackages`
package set by [cuda-packages.nix](../../top-level/cuda-packages.nix).

## Top-level directories

- `cuda`: CUDA redistributables! Provides extension to `cudaPackages` scope.
- `cudatoolkit`: monolithic CUDA Toolkit run-file installer. Provides extension
    to `cudaPackages` scope.
- `cudnn`: NVIDIA cuDNN library.
- `cutensor`: NVIDIA cuTENSOR library.
- `fixups`: Each file or directory (excluding `default.nix`) should contain a
    `callPackage`-able expression to be provided to the `overrideAttrs` attribute
    of a package produced by the generic manifest builder.
    These fixups are applied by `pname`, so packages with multiple versions
    (e.g., `cudnn`, `cudnn_8_9`, etc.) all share a single fixup function
    (i.e., `fixups/cudnn.nix`).
- `generic-builders`:
  - Contains a builder `manifest.nix` which operates on the `Manifest` type
      defined in `modules/generic/manifests`. Most packages are built using this
      builder.
  - 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`.
- `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.
- `packages`: Contains packages which exist in every instance of the CUDA
    package set. These packages are built in a `by-name` fashion.
- `setup-hooks`: Nixpkgs setup hooks for CUDA.
- `tensorrt`: NVIDIA TensorRT library.

## Distinguished packages

### CUDA Compatibility

[CUDA Compatibility](https://docs.nvidia.com/deploy/cuda-compatibility/),
Title: Nixpkgs CUDA Modules Structure for Maintainers
Summary
This document, intended for CUDA maintainers, outlines the structure of CUDA packages within Nixpkgs, which are integrated into the `cudaPackages` set. It describes several top-level directories, including `cuda`, `cudatoolkit`, `cudnn`, `cutensor`, and `tensorrt` for redistributables and libraries; `fixups` for applying package overrides; `generic-builders` (comprising `manifest.nix` for most packages and `multiplex.nix` for handling multiple versions); `modules` for manifest validation and shims; `packages` for common CUDA packages; and `setup-hooks` for Nixpkgs setup. It also briefly introduces 'CUDA Compatibility' as a distinguished package concept.