I'm currently working on improving the packaging of the NVIDIA driver. My plan, is to first split the namespace and driver extraction into two separate files without changing semantics with the assistance of LLM, and then switch from the current passthru pattern to using scope.

The first step is now complete. Semantics should be unchanged. I'm not sure how to verify semantic equivalence (suggestions welcome!), but this PR works fine with my current NixOS configuration.

As a side note, I also moved nvidia-modprobe into the nvidiaPackages namespace.

Since these changes are mostly structural and don't alter semantics, could they be merged separately, with the scope migration and further work happening in a new PR?

For the CUDA variant stuff, look for changes here:

• https://github.com/NixOS/nixpkgs/blob/e72912dc31edae89f04a12982c684f9652c95348/pkgs/development/cuda-modules/_cuda/lib/cuda.nix#L75-L103
• https://github.com/NixOS/nixpkgs/blob/e72912dc31edae89f04a12982c684f9652c95348/pkgs/development/cuda-modules/buildRedist/default.nix#L70-L97
  Ugh so getSupportedReleases needs to support something like desiredCudaVariants being an ordered list

Thanks Prayag Bhakar for your suggestions.
At the time, our CI capacity only allows us to build ~10% of our "target jobsets" for x86_64 alone.
This means that cross-building for aarch64 is definitely not feasible with the current hardware.

We are actively working in the background to secure "sponsorships" and get a legitimate compute capacity, but this is not done yet.
Supporting Jetson architectures is definitely on the list of things we would like to do, but we are way too much hardware-bound for it.

Hey, sorry for disappearing on the github ticket, v limited bandwidth currently.

The first and most important point, elaborating on Gaétan's reply: our infra currently lacks aarch64 builders, and frankly we as of now haven't even a fraction of the x8664 capacity that we need. We are currently working on securing proper funding for the hardware and for the general effort, and first and foremost for reducing the harm and the extra load that CUDA imposes on the rest of Nixpkgs maintainers. It's been in the works for almost two years now. Recently our entire team, including our new "manager" member @dhofer:matrix.org, has been fully dedicating to making this happen, but, while there's been some very modest progress, it's going to take a while before we start testing and caching Jetsons or in fact anything besides the vanilla x86-64-linux nixpkgs simply due to cashflow considerations. We are actively looking for companies willing to properly pay for the service of testing and keeping the Jetson ecosystem "green" & functional here upstream in Nixpkgs, but so far there's no ETAs for this specific effort. In our personal projects we normally use very different kind of hardware, so it's not a priority for any of the maintainers.

Regarding your other messages, just some clarifications:

1. Binfmt/qemu is not "cross-compilation". Nixpkgs does have cross capabilities, albeit less stable than native builds, and we are also very interest in making cross compilation possible for CUDA projects (it currently isn't, mostly because nvidia is making it artificially hard), but it's not a priority for any of us, and we haven't found any interested customers or sponsors yet either.
2. Binfmt builds in CI are indeed not impossible, and Connor and I had burned quite a bit of energy by trying them out in the old Hercules-based CI... It's been an incredible pain, besides also harming reproducibility and all. Jetsons without paying consumers and without our own research projects needing them is not something we'd want to spend our currently extremely limited and scarce compute on, I'm afraid.
3. Re: the PR, as I mentioned we moved from nix-community infra to our own, and we had to temporarily pause consuming the release-cuda.nix file (which, though, remains the authoritative source, and which is also what's being built by Flox). I'd honestly rather first do the hard work of removing backendStdenv and config.cuda*, because then we wouldn't need to modify release-lib in this first place. That said, if this were a priority, we could hack jetsons in in the release-cuda file, e.g. to get them built by Flox (I forget if they do aarch64 though)

Now to what is a priority to us, fot example: I'm happy to brainstorm with anyone about how do we get rid of the backendStdenv thing and how to cleanly model coprocessors/accelerators in the elaborated-system structure, whether to make coprocessors part of a system "quadruple" (contrast to triple), and whether the specific cudaCapabilities and/or rocm gpuTargets should become a part of... well, I suppose, the system "polycule".
I know @lt1379:matrix.org and @tomberek:matrix.org , besides the CUDA Team have been pondering about the same questions.

no worries SomeoneSerge (matrix works sometimes) I'm grateful for any time folks are taking out of their day to help me out. I figured the conversation may be more fruitful in the matrix channel

Binfmt/qemu is not "cross-compilation"

ah, sorry I was under the impression it was close enough. Since option A is off the table, do options B and C have any legs? I understand that there is a process to secure more compute, but can that compute come from volunteers like me? From my understanding even with just a Jetson nano, it can start compiling other aarch64 packages until more capable compute is secured

Now to what is a priority to us,

oh I see, so have the GPU definitions be part of the core hostPlatform instead of treated like added on accelerators. Does this mean there are plans to also add core hostPlatform support for other accelerators like TPUs and FPGAs? Is there someplace I can read up on this body of work and try to figure out how I can help? I'm happy to scrap my PR if there is a more established north start being pursued by the team

While a Jetson can indeed build packages for aarch64-linux, having a single one would not enable anything.
The amount of (decently fast) ARM cores needed to start enabling aarch64-linux jobsets on hydra.nixos-cuda.org is ~64 at the very extreme minimum.

We appreciate the proposition, but until we get access to something resembling a serious build capacity for this platform, we won't spend time supporting it.