This project is discontinued in favour of the CUDA-enabled Nixpkgs release in-tree, built on the "community Hydra" and cached at nix-community.cachix.org within the nix-community infrastructure team's effort. Nix-Community's infrastructure is funded via an OpenCollective project: consider committing for a monthly donation to ensure its continuing availability.
First, a word of warning: this is just a development repo that ought to be replaced with something sustainable later. For an up-to-date information about CUDA in nixpkgs seek in:
- #cuda:nixos.org
- https://nixos.wiki/wiki/CUDA
- https://nixos.org/manual/nixpkgs/unstable/#cuda
- discourse.nixos.org
With the above in mind, let's proceed.
2024-08-15: As of #33, this repo no longer maintains any jobsets and consumes instead the new
release-cuda.nix
maintained in Nixpkgs2024-06-09: I had been having issues with the Hercules CI's "effects" queue getting jammed, effectively shutting down the "flake-update" effect. The effects were disabled and replaced with a flake-update github action, which triggers HCI to rebuild the "default" job against the new master. Other jobs may be at times be building stale nixpgs revisions... This is all rather flaky and I haven't had time to debug this.
2023-03-05: Repo no longer tries to be a drop-in substitute for nixpkgs. We just build. The flake is now used to track all nixpkgs branches (-> flake.lock is much larger), and hercules CI's
onSchedule
, rather than a GitHub workflow, is used to trigger builds. For a drop-in nixpkgs replacement cf. numtide/nixpkgs-unfreeWe build for different cuda architectures at a different frequencies, which means that to make use of the cache you might need to import nixpkgs as e.g.
import <nixpkgs> { ...; config.cudaCapabilities = [ "8.6" ]; }
. Cf. the flake for details
The repo is used to build and cache the nixpkgs world with
cudaSupport = true
. See the dashboard at: https://hercules-ci.com/github/SomeoneSerge/nixpkgs-cuda-ci
This means you can use pre-built pytorch, tensorflow, jax and blender with Nix
This also means that we notice and can act when things break in development branches. We build:
master
,nixos-unstable
,nixpkgs-unstable
,- and the last release, at the time of writing -
nixos-23.05
We might build different branches at different frequency. We also might prioritize certain
cudaCapabilities
.The cachix is limited in space and has garbage collection on. This means that you'd need to stay up-to-date to benefit from the cache (as we build newer packages, the old cache is eventually discarded)
The builds currently run on volunteers' machines. We plan to soon make and maintain the exact list on wiki. Each machine uses its own key to push the build results to cachix and these keys can be revoked without breaking the whole chain. You consume just one public key listed at https://cuda-maintainers.cachix.org/. The cachix
cuda-maintainers
cache and cachix keys are currently managed by @samuela. Our cachix space is courtesy of @domenkozar.We hope one day to arrive at a more sustainable and trust-worthy solution, but right now we're working on this as on a proof-of-concept.
To use the cache, get cachix, and execute:
cachix use cuda-maintainersTo use the cache on NixOS, check the following snippet for your
configuration.nix
module:nix.binaryCachePublicKeys = [ "cuda-maintainers.cachix.org-1:0dq3bujKpuEPMCX6U4WylrUDZ9JyUG0VpVZa7CNfq5E=" ]; nix.binaryCaches = [ "https://cuda-maintainers.cachix.org" ];Verify that the public key comes from https://cuda-maintainers.cachix.org
You can also suggest the cache to users of your flake, with
# ... nixConfig = { extra-substituters = [ "https://cuda-maintainers.cachix.org" ]; extra-trusted-public-keys = [ "cuda-maintainers.cachix.org-1:0dq3bujKpuEPMCX6U4WylrUDZ9JyUG0VpVZa7CNfq5E=" ]; }; outputs = { ... }: { # ... };When interacting with your flake, the users would be asked whether they want to use that cache and trust that key.
The most consistent albeit most expensive way to use cuda-enabled packages from nixpkgs is to import them with the global
config.cudaSupport
:pkgs = import nixpkgs { config.allowUnfree = true; config.cudaSupport = true; }With that,
pkgs.python3Packages.jax
,pkgs.python3Packages.pytorch
, etc evaluate into packages with cuda support.This flake attempts to play a drop-in replacement (rather, a proxy) for
nixpkgs
. The following usages are expected to work:
Executing
nix run github:SomeoneSerge/nixpkgs-unfree/nixpkgs-unstable#blender
to run blender built with cuda-supportUsing in flake inputs:
inputs.nixpkgs.url = github:NixOS/nixpkgs/nixpkgs-unstable; inputs.nixpkgs-unfree.url = github:SomeoneSerge/nixpkgs-unfree; inputs.nixpkgs-unfree.inputs.nixpkgs.follows = "nixpkgs";DEPRECATED: Using in flake inputs as a drop-in replacement for nixpkgs (unless someone does something special)
inputs.nixpkgs.url = github:SomeoneSerge/nixpkgs-unfree/nixpkgs-unstable; inputs.home-manager.inputs.nixpkgs.follows = "nixpkgs";DEPRECATED: Importing as nixpkgs:
inputs.nixpkgs = github:SomeoneSerge/nixpkgs-unfree/nixpkgs-unstable; outputs = { nixpkgs }: let system = "x86_64-linux"; overlay = final: prev: { }; pkgs = import nixpkgs { overlays = [ overlay ]; }; in { # ... }Note that if you pass
config
in the arguments, you must again includecudaSupport
andallowUnfree
NOTE: Setting
<nixpkgs>
to point at this repo has proven a somewhat painful experience. Most problems concentrate around tools usingimport <nixpkgs/lib>
. There's a proxy in ./lib right now which makes these import work, but almost certainly at the cost of downloading a yet another copy of nixpkgs...If you're only enabling the cache on a per-project or per-user basis, you might need to set
trusted-users = ${yourName}
in/etc/nix/nix.conf
.