Home • Explore • Blog • CI
☰



nixpkgs
1st chunk of `pkgs/development/cuda-modules/README.md`
d43231b4d8cfc383c72e0487d52e616d500e9301247bda6d0000000100000981
# 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: Structure of CUDA Packages in Nixpkgs
Summary
This document outlines the structure of CUDA packages within Nixpkgs, intended for maintainers. It details the top-level directories and their roles, including `cuda`, `cudatoolkit`, `cudnn`, `cutensor`, `fixups`, `generic-builders`, `modules`, `packages`, `setup-hooks`, and `tensorrt`. It also highlights the use of generic manifest builders and multiplex builders for managing package versions, along with Nixpkgs modules for checking manifest shapes and content. Finally, it mentions notable packages like Cuda Compatibility.