NixOS CUDA | 292 Members | |
| CUDA packages maintenance and support in nixpkgs | https://github.com/orgs/NixOS/projects/27/ | https://nixos.org/manual/nixpkgs/unstable/#cuda | 57 Servers |
| Sender | Message | Time |
|---|---|---|
| 2 Nov 2024 | ||
| * I just raised an issue earlier today about some of the driver hashes missing for some of the releases, it feels to me like we really need a solid cuda json scraper to prefetch script | 23:47:33 | |
In reply to @ss:someonex.netI'm wondering what can we do to remove this hack | 23:53:53 | |
| I have no idea how it works in the first place, let alone how to remove it | 23:56:04 | |
| i guess it just consistently is the case that there's a better path than that one | 23:57:02 | |
| * i guess it's just consistently the case that ld.so believes there's a better match than that one. | 23:57:48 | |
In reply to @sielicki:matrix.orgYes, there's https://github.com/ConnorBaker/cuda-redist-find-features/ but afaik Connor's developing this alone, and there stuff to be improved with the way we parse the results on nixpkgs side too | 23:58:38 | |
| 3 Nov 2024 | ||
In reply to @sielicki:matrix.orgIt's not about ld.so in this case, it's that iirc CUDA::cuda_driver in CMake somehow wanted to see the .1 during the build, which I suspect is wrong | 00:01:09 | |
| do you remember what issue/bug it was? | 00:04:40 | |
In reply to @ss:someonex.netreally nice, I was just gonna propose we run wget --recursive on https://developer.download.nvidia.com/compute/cuda/repos/runfile/x86_64/ | 00:16:04 | |
| much prefer the feature extraction stuff, that's wicked | 00:16:23 | |
| one problem with the runfile json is it excludes certain components, eg: nccl | 00:17:14 | |
| 4 Nov 2024 | ||
| Is there a reason why https://github.com/NixOS/nixpkgs/pull/291471 is not merged? | 13:46:49 | |
In reply to @snektron:matrix.orgStuck on unvendoring qt libraries it seems | 15:58:17 | |
What are your thoughts on nixGL and nix-gl-host? Specifically as it relates to ensuring people use the same driver version on both NixOS and non-NixOS host machines | 22:43:59 | |
| It's a disagreeable opinion but the whole "inspect the system at eval time" business in nixGL makes me want to scream "why". Even the idea of requiring a running nix-daemon in order to load the drivers at the program's startup... I think it's very backwards. I think nix-gl-host decomposes tasks better, but
| 23:07:53 | |
| * It's a disagreeable opinion but the whole "inspect the system at eval time" business in nixGL makes me want to scream "why". Even the idea of requiring a running nix-daemon in order to load the drivers at the program's startup... I think it's very backwards. I think nix-gl-host decomposes tasks better, but
| 23:08:04 | |
| FWIW I see no reason not to implement both approaches (host's libs vs. nixpkgs' libs that match the running kernel) in one tool | 23:09:19 | |
That could be just two flags: --drivers-from={HOST|<nix expr or a flake ref>} and --export=/run/opengl-driver/lib as the alternative to --run <CMD> | 23:12:23 | |
| (and then of course there's this whole libcapsule business that's waiting to be tried) | 23:13:40 | |
| Note there was recently somebody in nix-gl-host issues advertising their Rust rewrite | 23:29:51 | |
| 5 Nov 2024 | ||
| Has anyone successfully built blender on unstable with CUDA support enabled recently? | 02:31:45 | |
| 🤔 Currently, openusd fails in patch phase. | 08:39:43 | |
In reply to @aidalgol:matrix.orglooks like it's broken since end of October: https://hydra.nix-community.org/build/1720981 | 15:13:24 | |
In reply to @ss:someonex.netDid you take a look at https://github.com/NVIDIA/nvidia-container-toolkit already? I think they are battling with similar issues, plus sandboxing on top. It seems like they are using ld.so.cache as a loading mechanism instead of the LD_* env var and that might be more robust? | 15:16:02 | |
In reply to @zimbatm:numtide.comYes that's what we use for docker/podman on nixos | 15:16:44 | |
| I'm not sure if it's worth reusing because nixGL and nix-gl-host are solving a more general problem; the ctk just assumes an FHS environment, we have to patch it and we have to patch its outputs to make them usable on nixos | 15:19:32 | |
| But yes we should keep in mind the general idea of exporting ld.so.cache. We actually used it at least for some time for the singularity containers | 15:21:25 | |
In reply to @zimbatm:numtide.com
Well here's the first offender | 15:22:59 | |
| Ah isn't it nice to have a per-attribute build history | 15:23:36 | |
| So odd that wasn't a thing with hercules | 15:24:15 | |