NixOS CUDA | 288 Members | |
| CUDA packages maintenance and support in nixpkgs | https://github.com/orgs/NixOS/projects/27/ | https://nixos.org/manual/nixpkgs/unstable/#cuda | 56 Servers |
| Sender | Message | Time |
|---|---|---|
| 13 Dec 2024 | ||
| generally just a review of the nix code and anything I did stupid | 07:42:31 | |
| 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 | |
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 | ||
| 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 | |
| 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 | |
| instead of doing it in the installPhase for example | 16:52:32 | |
| if you enable cudaSupport and rocmSupport, what happens? Do you actually get an output that is usable for both? | 20:24:53 | |
| matthewcroughan: IMO it might be faster and better for you to write the missing pyproject.toml it needs | 20:34:25 | |
| Would I not have to rewrite that each and every single time the owner updates the package? | 20:34:49 | |