| 15 Dec 2025 |
 yorik.sar | I’m surprised to see parser there - how much code were you evaluating? | 10:54:09 |
| yorik.sar | I think I already saw some lock implementation in Nix code, probably better to reuse that one. Also, Nix code seems to prefer RAII (smth like { auto _thelock = lock.get(); … }) rather than passing continuation to a function (withLock(…)). | 10:56:46 |
| yorik.sar |
I'd like to do further work to deduplicate queries for .narinfo and the like, since Nix already generates quite the network storm by firing them off in serial.
I wonder if Nix uses HTTP/2 there. I think with stream multiplexing, all requests could essentially fit in one pack of packets.
| 10:59:07 |
| yorik.sar | *
I'd like to do further work to deduplicate queries for .narinfo and the like, since Nix already generates quite the network storm by firing them off in serial.
I wonder if Nix uses HTTP/2 there. I think with stream multiplexing, all requests could essentially fit in one pack of packets.
| 10:59:14 |
 Ari Lotter | okay - i think i just figured out why cudnn/torch/nvrtc is broken..
cudnn does seem to require NVRTC at runtime - see https://docs.nvidia.com/deeplearning/cudnn/backend/latest/api/cudnn-graph-library.html for CUDNN_STATUS_NOT_SUPPORTED_RUNTIME_PREREQUISITE_MISSING -
A runtime library required by cuDNN cannot be found in the predefined search paths. These libraries are libcuda.so (nvcuda.dll) and libnvrtc.so
but it looks like nvrtc is not provided to the cudnn package in nixpkgs!!!
https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/cuda-modules/packages/cudnn.nix
so, unless i'm missing something, don't we just need to include nvrtc in buildInputs for cudnn, and this will fix the weird auto-runpath thing..?
| 17:32:01 |
| Ari Lotter | (didn't wanna dump this in the gh issue in case im totally mistaken heh) | 17:36:42 |
| Ari Lotter | er or maybe propagatedBuildInputs | 17:37:54 |
| Ari Lotter | oh no it's way worse lol | 20:06:25 |
| Ari Lotter | because dlopen doesn't check the runpath of libtorch_cuda.so does it | 20:06:36 |
| Ari Lotter | since dlopen ignores the caller's runpath | 20:06:48 |
| Ari Lotter | it only checks the runpath of the main executable.. | 20:06:55 |
| Ari Lotter | ok i have no idea what im doing <3 giving up | 20:11:43 |
| Ari Lotter | have managed to make it work by setting LD_LIBRARY_PATH but uhh seems pretty.. unusable | 20:13:36 |
| Ari Lotter | i think we'd have to patch the dlopen call | 20:13:40 |
| Ari Lotter | inside cudnn..? | 20:13:45 |
| Ari Lotter | https://github.com/NixOS/nixpkgs/issues/461334#issuecomment-3657416223 | 20:19:51 |
| Ari Lotter | i think it's pretty hopeless. lol | 20:19:58 |
 connor (burnt/out) (UTC-8) | I’ve not; I suspect zero speedup since evaluating a single config doesn’t have opportunities for parallelism and all the locking is done through kernel structures so it should be super low overhead
(Also Nixpkgs basically forbids eval time fetchers so I don’t think a config using just Nixpkgs would show a speedup) | 20:39:18 |
| connor (burnt/out) (UTC-8) | That was evaluating all of the closures attribute in nixos/release.nix with nix eval --json | 20:40:10 |
| connor (burnt/out) (UTC-8) | There is some, but it blocks forever, doesn’t do cleanup, and lacks a few other features needed for different types of builtin fetchers and substitutions | 20:41:22 |
| connor (burnt/out) (UTC-8) | Robbie Buxton have you run into this (or seen anyone run into it)? You’re one of the like three people I know who use PyTorch from Nixpkgs other than myself | 20:42:49 |
 Robbie Buxton | In reply to @connorbaker:matrix.org
Robbie Buxton have you run into this (or seen anyone run into it)? You’re one of the like three people I know who use PyTorch from Nixpkgs other than myself I haven’t run into that but I have run into libcuda failing on trying to dlopen things it claims to not depend on | 21:07:52 |
| Robbie Buxton | Regarding that issue iirc RPATHS are recursive but RUNPATHS aren’t and if a RUNPATH exists the RPATH won’t be used (its replacing RPATHs) | 21:12:39 |
| Robbie Buxton | I think @[Ari Lotter] is right and we should add it as an (undocumented) dep or cudnn | 21:15:47 |
| Robbie Buxton | * I think @[Ari Lotter] is right and we should add it as an (undocumented) dep of cudnn | 21:15:56 |
 apyh | adding it as a cudnn dep doesn't work still though from my testing | 21:16:10 |
| Robbie Buxton | How are you adding it? | 21:16:20 |
| apyh | i tried it as a propagatedBuildInput | 21:16:30 |
| apyh | the only thing i managed was to pass it in ld library path manually :/ | 21:16:43 |
| Robbie Buxton | Oh you’ll need to patchelf it | 21:16:44 |
