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 | 57 Servers |
| Sender | Message | Time |
|---|---|---|
| 27 Jun 2024 | ||
In reply to @coruscate:matrix.orgNixpkgs' unstable is at 12.2 🤔 | 10:39:19 | |
| * I think the section in the official manual is not in an unreasonable state, although messy: https://nixos.org/manual/nixpkgs/unstable/#cuda | 10:39:49 | |
| should have said later then, i guess? <11.5 weirdly enough | 10:46:27 | |
| Ah so opensycl requires an older release? | 10:54:07 | |
Just use cudaPackages_11_5. Start ad hoc, building only opensycl against it. If you wish to rebuild the whole package set, use an overlay. | 10:55:35 | |
| They don't seem to specify any constraints: https://github.com/archibate/OpenSYCL/blob/b919667ea53f99dbc55a9832f297cf0cb689034e/cmake/FindCUDA.cmake#L31 | 11:02:25 | |
| * They don't seem to specify any constraints: https://github.com/archibate/OpenSYCL/blob/b919667ea53f99dbc55a9832f297cf0cb689034e/cmake/FindCUDA.cmake#L31 (oh, this is some fork) | 11:02:44 | |
| my issue seems to be the packaged clang version in the nixpkg opensycl package, i'll probably simply repackage it. | 11:16:02 | |
Does anybody get cicc died due to signal 9 (Kill signal) | 12:19:18 | |
| When trying to build onnxruntime with cuda support? | 12:19:24 | |
In reply to @connorbaker:matrix.orgSame.. That sounds very familiar | 12:21:21 | |
| https://github.com/rapidsai/cudf/issues/8018 | 12:21:36 | |
| seems like the solution to cicc getting killed is to limit parallelism also | 12:21:48 | |
In reply to @ss:someonex.net I seem to be too dumb to figure this out. I use this flake:
and expect both the shell and the sycl package to use the correct version, this clearly is not the case though. I expect that I can set it the way the documentation leads me to believe for the sycl package, as I use the callPackage function, but how would I do the same for the shell?
sorry if this is too incoherent or stupid to begin with | 13:17:07 | |
In reply to @ss:someonex.net* I seem to be too dumb to figure this out. I use this flake:
and expect both the shell and the sycl package to use the correct version, this clearly is not the case though. I expect that I can set it the way the documentation leads me to believe for the sycl package, as I use the callPackage function, but how would I do the same for the shell?
sorry if this is too incoherent or stupid to begin with | 13:17:20 | |
There's no config.cudaPackages option; cudaPackages is an attribute in an evaluated pkgs instance; it can be overridden using overlays | 13:41:48 | |
coruscate is there a public repo with the flake and the opensycl.nix? | 13:42:37 | |
Looking at how setup-cuda-hook.sh propagates itself and once again I cannot remember where the extra offset of (0, 1) is coming from... | 21:28:55 | |
Say someone puts a cuda_cudart in buildInputs (that's (0,1)), it has the hook in propagatedNativeBuildInputs (that's (-1, 0), right?). The expectation (confirmed by a successful build is that we arrive at (-1, 0)=nativeBuildInputs again, but the arithmetics says (0, 0) | 21:31:06 | |
* Looking at how setup-cuda-hook.sh propagates itself and once again I cannot remember where the extra offset of (1, 0) is coming from... | 21:31:28 | |
Is it added manually? Hmm now come to think of it if a is in buildInputs, and has b in propagatedBuildInputs, which has c in propagatedBuildINputs - c should end up at the same offsets, i.e. in buildInputs | 21:32:31 | |
* Is it added manually? Hmm now come to think of it if a is in buildInputs, and has b in propagatedBuildInputs, which has c in propagatedBuildINputs - we want c to end up at the same offsets, i.e. in buildInputs | 21:32:46 | |
| 28 Jun 2024 | ||
| Should work this time: https://github.com/NixOS/nixpkgs/pull/323056 Can I bump a nixpgks-review? xD | 01:43:56 | |
| * Should work this time: https://github.com/NixOS/nixpkgs/pull/323056 Can I bum a nixpgks-review? xD | 01:44:00 | |
In reply to @ss:someonex.netOmg, nevermind... I checked that magma still builds after the first commit, then did something in the second and now it doesn't | 01:49:25 | |
| 02:44:51 | ||
In reply to @matthewcroughan:defenestrate.itI know, that it's broken ... actually it would be good if someone upgrade it to the current version TensorRT-10.1.0.27 | 11:00:16 | |
Shoot, I think propagatedBuildOutputs are broken with __structuredAttrs | 11:08:29 | |
The hook loops over $propagatedBuildOutputs but __structuredAttrs make it onti an array, so the first expression resolves into the value of the first element 🤡 | 11:09:03 | |
In reply to @search-sense:matrix.orgWould you like to just take over tensorrt in Nixpkgs? | 11:28:58 | |