Changelog: https://github.com/NVIDIA/cudnn-frontend/releases/tag/v1.32.0
1.32.0 contains the fix for a crash at process exit
(473a2c8f76,
from NVIDIA/cudnn-frontend#1565). 1.31.0 releases plans recorded into
CUDA graphs through get_cuda_symbol(), whose library handle map is a
function-local static. A static cache destroyed after that map at exit,
such as TransformerEngine's fused-attention graph cache, then reads freed
memory, and its processes can crash with SIGSEGV
(NVIDIA/cudnn-frontend#1486).
python3Packages.nvidia-cudnn-frontend builds from the same source. Its
Python bindings now use nanobind instead of pybind11 and require
nanobind>=3.0.1,<4, so it builds with nanobind_3, and the ninja pin it
relaxes now carries a platform marker. The bindings include standard
headers before Python.h, so pyconfig.h redefines the _POSIX_C_SOURCE and
_XOPEN_SOURCE that glibc 2.44 defines with other values, which upstream's
-Werror makes an error; the Python build drops -Werror.
It also takes cudnn-frontend's update script, run on
cudaPackages.cudnn-frontend: the nix-update script it inherited from
buildPythonPackage can't update a version and source it inherits.
Assisted-by: Claude Code (Claude Opus 5.5)
NVIDIA publishes standalone cuBLAS releases between CUDA releases. Each
is a patch release for one CUDA toolkit update, with the same major and
minor version as the cuBLAS that update shipped, and exports the same
symbols. Later CUDA updates don't include them: CUDA 13.4 Update 3,
released after cuBLAS 13.8.1, still ships 13.8.0.4.
A package set pins a standalone release only when it is a newer patch
release of its CUDA release's cuBLAS, and evaluation fails otherwise, so
a CUDA update that ships a newer cuBLAS must drop or update the pin.
That pins 12.8.5.7, 13.4.2.4, 13.6.2.16, and 13.8.2.12 for CUDA 12.8,
13.2, 13.3, and 13.4. CUDA 12.6 has no standalone release, and CUDA's
cuBLAS is as new or newer for CUDA 12.9, 13.0, and 13.1. libcublas uses
the pin where it has a build for the host; standalone releases have no
linux-aarch64 builds, so pre-Thor Jetson with CUDA 12.8 uses CUDA's. The
source is visible as libcublas.passthru.redistName.
Standalone archives lack the stubs and pkg-config file, so generate
them: like NVIDIA's, the stubs define the libraries' versioned
functions, each printing a warning, and the build checks they export
the same symbols as the libraries. The pkg-config file matches CUDA's.
Standalone archives are under the CUDA EULA, which lists cuBLAS as
distributable, but buildRedist defaults to nvidiaCudaRedist only for
CUDA's redistributables, so set the license.
Assisted-by: Claude Code (Claude Opus 5.5)
The unit tests use the utility headers in tools/util (the
cutlass_tools_util_includes target), which CMake only adds with
CUTLASS_ENABLE_TOOLS. With the tools disabled, building the tests failed
with "cutlass/util/device_memory.h: No such file or directory". Enable the
tools when doCheck is set, keeping the CUTLASS library (and so the
profiler) disabled unless enableTools is set.
Add passthru.gpuCheck, which enables doCheck, in place of the TODO.
Assisted-by: Claude Code (Claude Opus 5.5)
CUTLASS tags pre-releases such as v4.8.0dev, which gitUpdater picked as
the newest version (https://github.com/NixOS/nixpkgs/pull/560392).
Assisted-by: Claude Code (Claude Opus 5.5)
Before CUDA 13.4, cuda-XX.Y.pc set libdir to lib and linked with
-L${libdir} -lcuda, though libcuda.so is only in lib/stubs; postPatch
fixed that by pointing libdir at lib/stubs. CUDA 13.4 changed Libs to
-L${libdir}/stubs, so with both changes the search path became
lib/stubs/stubs and anything linking libcuda through pkg-config failed
with "cannot find -lcuda".
Drop the extra /stubs. The install check now links a program through the
installed cuda and cudart package config files, so wrong library paths
fail the build.
Assisted-by: Claude Code (Claude Opus 5.5)
Signed-off-by: Connor Baker <ConnorBaker01@gmail.com>
rmm vendored the NVTX 3.2.0 source through CPM because the redistributable doesn't ship NVTX's CMake package
configuration. cudaPackages.nvtx now does from CUDA 12.9 on (rmm requires 13.4), and rapids-cmake's
CPM_USE_LOCAL_PACKAGES makes CPM find it. Propagate it, since rmm's installed configuration finds nvtx3.
Assisted-by: Claude Code (Claude Opus 5.5)
From CUDA 12.9, the redistributable contains only the NVTX v3 headers and libnvtx3interop. Build them from
https://github.com/NVIDIA/NVTX at 3.6.0 instead, along with the CMake package configuration and the NVTXW loader.
libnvtx3interop is built from the upstream test exporting the C API and exports the same symbols as the
redistributable's.
Earlier releases also contain the NVTX v2 headers and library (libnvToolsExt), which are not open source, so they
continue to use the redistributable.
Nothing in the build depends on the CUDA release, so it uses stdenv and no CUDA name prefix, and every CUDA package
set from 12.9 on shares one derivation.
passthru.pythonVersion records the version of the Python package in python/ (versioned independently of the C/C++
API), which the update script keeps in sync, for python3Packages.nvtx.
Assisted-by: Claude Code (Claude Opus 5.5)
NVTX is to be built from source where possible, so it is no longer named after the redistributable. The
redistributable build moves to nvtx/redist.nix, and cuda_nvtx becomes a deprecated alias.
No rebuilds: the redistributable keeps its pname.
Assisted-by: Claude Code (Claude Opus 5.5)
nvlink loads ../nvvm/lib64/libnvvm.so for device link-time
optimization, but before CUDA 13 we renamed nvvm/lib64 to lib, so
linking with -dlto failed with "nvlink fatal : elfLink linker library
load error". From CUDA 13, NVVM comes from libnvvm, which provides the
link already.
Assisted-by: Claude Code (Claude Opus 5.5)
MathDx bundles NVIDIA's device-side math libraries: cuBLASDx, cuFFTDx,
cuRANDDx, cuSolverDx, and nvCOMPDx.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
TensorRT 11.4.0.106 ships the same Linux archives as 11.3.0: linux-x86_64 for CUDA 12.9 and 13.4, and linux-sbsa for
CUDA 13.4. Unlike 11.3.0's, the linux-sbsa archive's libnvdla_compiler.so no longer links against the L4T-only
libnvos.so; no remaining TensorRT 11 release needs it (11.1.0 doesn't ship libnvdla_compiler.so), so drop libnvos.so
from autoPatchelfIgnoreMissingDeps. Jetson devices and linux-sbsa with CUDA 12 stay on TensorRT 10.x and 11.1.0.
The 11.4 release has no sample data, so tensorrt-samples keeps using the 11.0 data.
Remove the now-unused 11.3.0 manifest.
Changelog: https://docs.nvidia.com/deeplearning/tensorrt/latest/getting-started/release-notes-11/11.4.0.html
Assisted-by: Claude Code (Claude Opus 5.5)
tileiras dlopens libNVVM and execs ptxas, looking for them under
CUDA_ROOT, CUDA_HOME, or CUDA_PATH, or else relative to its own binary
as in a CUDA Toolkit installation. None of these resolve in Nixpkgs, so
compiling any non-trivial Tile IR program failed with
"failed to compile Tile IR program" (exit code 5).
Default CUDA_ROOT to cuda_nvcc, which has both bin/ptxas and
nvvm/lib64/libnvvm.so.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
