 | NixOS CUDA | 282 Members |
| CUDA packages maintenance and support in nixpkgs | https://github.com/orgs/NixOS/projects/27/ | https://nixos.org/manual/nixpkgs/unstable/#cuda | 58 Servers |
| NixOS CUDA | 282 Members |
| CUDA packages maintenance and support in nixpkgs | https://github.com/orgs/NixOS/projects/27/ | https://nixos.org/manual/nixpkgs/unstable/#cuda | 58 Servers |
| Sender | Message | Time |
|---|---|---|
| 9 Dec 2024 | ||
 SomeoneSerge (back on matrix) | atry | 16:04:31 |
| SomeoneSerge (back on matrix) | * Atry | 16:04:33 |
 hexa | we should probably deduplicate all issues to this one | 16:05:04 |
| 11 Dec 2024 | ||
 @magic_rb:matrix.redalder.org joined the room. | 00:50:41 | |
| @magic_rb:matrix.redalder.org | cross post from #dev:nixos.org
| 00:51:08 |
| hexa |
| 20:11:21 |
| hexa | 🥳 | 20:11:23 |
| hexa | now if only the cuda build was working | 20:11:35 |
| hexa | https://github.com/microsoft/onnxruntime/issues/22855#issue-2662882047 | 20:58:10 |
| hexa | ah, very coool 🫠 | 20:58:14 |
| 12 Dec 2024 | ||
 connor (he/him) | Ah right that thing I was told CMake is supposed to understand it’s a header-only library and not try to actually link against a shared object file, so not sure why it’s doing exactly that and causing the build to fail | 01:48:43 |
| connor (he/him) | Ah I need to actually respond to the issue after I try their suggestion | 01:50:04 |
| connor (he/him) | How is there so little time in a day 😭 | 01:50:57 |
| connor (he/him) | ugh, my main desktop is gone from my tailscale network and unreachable from the other hosts. Damn Intel chip probably did a voltage whoopsy and needs to be hard reset. | 04:05:37 |
| connor (he/him) | Cool that shit is gonna be broken until I can fly home at the end of the month lmao | 04:42:54 |
 Moritz Sanft | If I'm not mistaken, this brings in a dependency of nvidia-x11 upon all of the packages listed here, right? https://github.com/NixOS/nixpkgs/blob/eac1633a086e8e109e00ce58c0b47721da1dbdfd/pkgs/os-specific/linux/nvidia-x11/generic.nix#L112 I wondered why perl is included in my closure, and thus discovered the mesa dependency of the driver, then got confused. If this is really the case, this is something you wouldn't want on a space-constrained system, right? | 15:20:27 |
| 13 Dec 2024 | ||
 sielicki | hey connor -- I can't request a github review on https://github.com/aws/aws-ofi-nccl/pull/745 for some reason, but I would like a review from you (or anyone else idling here) if you can find time. It's using the external cuda flake. | 04:07:57 |
| sielicki | I have a very thorough libfabric derivation on my personal laptop that I intend to finish over the holidays and propose to nixpkgs proper | 04:08:36 |
| sielicki | * hey connor -- I can't request a github review on https://github.com/aws/aws-ofi-nccl/pull/745 for some reason, but I would like a review from you (or anyone else idling here) if you can find time. Specifically asking you because it's using your external cuda flake. | 04:09:30 |
| sielicki | want to call it out here (mostly as a reminder to myself): the openmpi drv in nixpkgs should be capable of completely detaching from ucx/ucc, but it's not simple to make that happen today. On aws you shouldn't need ucx/ucc at all. | 04:13:37 |
| connor (he/him) | I’ll try to take a look sometime this weekend; one of my remote machines is down so my ability to build stuff is hosed | 04:58:25 |
| sielicki | In reply to @connorbaker:matrix.orgsure -- no need to build anything, just looking for an overall look at how it's using cudaPackagesExtensions etc | 07:42:06 |
| sielicki | In reply to @connorbaker:matrix.org* sure -- no need to build anything, just looking for an overall look at how it's using cudaPackagesExtensions etc. | 07:42:20 |
| sielicki | generally just a review of the nix code and anything I did stupid | 07:42:31 |
| Moritz Sanft | I just noticed another weird thing while trying to hunt down that Perl dependency: As I'm building the driver for a server scenario, I removed the graphics and X11 stuff from the libPath. I still had the Perl dependency in my image though. When analyzing its chain, I saw the following:Now, when I remove the persistenced, the dependency is gone. This means that the persistenced depends on another NVIDIA driver than what the system actually uses, somehow. The driver that's used in the system is at /nix/store/zsdr4vrybbik9hb8nss6fbmi71wsqhv3-nvidia-x11-550.90.07-6.11. When I now run nix derivation show /path/to/persistenced-package, I see the following:This means that another driver is used for building the persistenced somehow? Looking at the packaging infrastructure, it seems that nvidia_x11 is passed as an argument, which would mean that it should use the same one. However, I fear that there's some kind of evaluation differential here, as the persistenced package might be built before hardware.nvidia.package is even evaluated? Has anyone of you ever run into something similar before? | 08:41:49 |
| Moritz Sanft | fwiw; Solved it by doing a very dirty hack that overrides the nvidia_x11 used in nvidia-persistenced explicitly:https://github.com/edgelesssys/contrast/commit/5bf5cb81ce05f6f25b2cdf960ca3ab57a7f3459f | 15:05:40 |
| 14 Dec 2024 | ||
 matthewcroughan | Is there a way to wrap programs in Nix so that they believe they have a specific directory structure, like an FHS Env, whilst not screwing around too much with things that impact Cuda/GPU access? | 16:47:31 |
| matthewcroughan | I'm trying to package an application that wants access to source code dir paths, and I think this would be a good use of a layer/wrapper that performs symlinking at runtime to change the view of the world from the perspective of the application:
| 16:52:25 |
| matthewcroughan | instead of doing it in the installPhase for example | 16:52:32 |
| matthewcroughan | if you enable cudaSupport and rocmSupport, what happens? Do you actually get an output that is usable for both? | 20:24:53 |