gpo.zugaina.org

Search Portage & Overlays:

dev-python/nvidia-cudnn-frontend

cuDNN Frontend Python bindings (header API + pybind11 layer)

Screenshots

  • nvidia-cudnn-frontend-1.18.0
    ~amd64
    python_targets_python3_11 python_targets_python3_12 python_targets_python3_13 python_targets_python3_14 debug

    View      Download      Browse     License: MIT   
    Overlay: stuff

ChangeLog

commit b0a95a6e2552e3f94f66f7e09bd0d2f6d41a311f
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Thu May 7 16:23:42 2026 +0200

dev-python/nvidia-cudnn-frontend: new package, 1.18.0

Tier 0 leaf for the vllm CUDA target packaging cycle. cuDNN Frontend
Python bindings — the highest version satisfying vllm's cuda.txt cap
of >=1.13.0,<1.19.0; 1.19+ has a breaking change.

Upstream's PyPI release at this version is wheel-only with no sdist;
we build the binding from the matching tag at NVIDIA/cudnn-frontend.
The Python wheel ships its own copy of the cudnn_frontend C++ headers
(under site-packages/include/), so the in-tree ::gentoo
sci-ml/cudnn-frontend-1.16.1 C++ header package is NOT consumed at
build time — the "ABI gap" the audit memo flagged is moot for this
shape, and the 1.16.1 vs 1.18.0 mismatch concern doesn't apply.

CMake configure FetchContent's DLPack header-only and there's no
in-tree alternative without carrying a sizeable patch series, so
RESTRICT="network-sandbox" is accepted (same shape vllm uses for its
cpu target). pkgcheck's UnknownRestrict warning is a known false
positive (the keyword list lags portage); --scan=n at commit time.

Builds against system dev-libs/cudnn (>=9 in ::gentoo) and
dev-util/nvidia-cuda-toolkit. License is MIT-style ("Permission is
hereby granted...") per LICENSE.txt — pyproject.toml's "NVIDIA
Proprietary Software" string is incorrect.