| 17 Oct 2025 |
 connor (burnt/out) (UTC-8) | The CUDA 13 PR now has libnvshmem, built from source (that was not fun)
It does not have nvshmem4py since that’s gonna be irritating to build and requires stuff we don’t have packaged yet | 01:16:43 |
| connor (burnt/out) (UTC-8) | Lost about an hour of my life to figuring out that while they “support CMake” they don’t really support CMake
They do a full configure and build of a CMake project during a different project’s build and don’t thread arguments through properly, so there’s a fun note like this: https://github.com/NixOS/nixpkgs/blob/a32200680f4a5511fbc9456ff0fa689a0af12dac/pkgs/development/cuda-modules/packages/libnvshmem.nix#L104 | 01:19:55 |
| connor (burnt/out) (UTC-8) | As part of this I also packaged gdrcopy (but not the driver bit, since I’m not sure what the best way to handle that is) | 01:21:18 |
| connor (burnt/out) (UTC-8) | Gaétan Lepagedo you know if the PyTorch bump wants the nvshmem library or the Python bindings? | 01:40:29 |
 Gaétan Lepage | Thanks a lot for your work connor (he/him) (UTC-7)!!!
The PyTorch bump needs the library, not the python bindings. | 08:02:56 |
| 18 Oct 2025 |
|  @ihar.hrachyshka:matrix.org left the room. | 00:13:10 |
| connor (burnt/out) (UTC-8) | Various things which need to be fixed outside of the CUDA 13 PR:
- patchelf breaking Jeston binaries because of invalid binary modifications (there’s an open issue for this on Nixpkgs IIRC)
- packages with stubs should provide a setup hook which replaces the stub in the run path with wherever the library will be found at runtime (without duplicating run path entries — this is part of what started me making arrayUtilities setup hooks)
- cuda compat library precedence in run path entries is or can be lower than /run/opengl-driver/lib so it won’t be used; need to update hook to fix that (the other driving force behind arrayUtilities)
- Support for Clang as a host compiler for backendStdenv
- investigate cc-wrapper scripts to see if there’s anything relevant for NVCC (like random seed, or anything which enables deterministic compilation and linking)
There are others but I can’t remember them :/
| 06:38:17 |
|  devusb joined the room. | 17:55:08 |
| 19 Oct 2025 |
|  kaya 𖤐 changed their display name from kaya to kaya 𖤐. | 17:17:43 |
| connor (burnt/out) (UTC-8) | https://github.com/peylnog/ContinuousSR is incredible | 18:48:03 |
| connor (burnt/out) (UTC-8) | And if anyone wanted to run the demo, I've packaged it with a flake: https://github.com/ConnorBaker/ContinuousSR
Still need to download the model from their google drive (https://github.com/ConnorBaker/ContinuousSR?tab=readme-ov-file#pretrained-model)
$ nix develop --command -- python demo.py --input butterflyx4.png --model ContinuousSR.pth --scale 4,4 --output output.png
/nix/store/i8vsz78lc405s5rifmz3p1lpvzhh1x74-python3-3.13.7-env/lib/python3.13/site-packages/timm/models/layers/__init__.py:48: FutureWarning: Importing from timm.models.layers is deprecated, please import via timm.layers
warnings.warn(f"Importing from {__name__} is deprecated, please import via timm.layers", FutureWarning)
/nix/store/i8vsz78lc405s5rifmz3p1lpvzhh1x74-python3-3.13.7-env/lib/python3.13/site-packages/torch/functional.py:554: UserWarning: torch.meshgrid: in an upcoming release, it will be required to pass the indexing argument. (Triggered internally at /build/pytorch/aten/src/ATen/native/TensorShape.cpp:4322.)
return _VF.meshgrid(tensors, **kwargs) # type: ignore[attr-defined]
/home/connorbaker/ContinuousSR/models/gaussian.py:245: UserWarning: To copy construct from a tensor, it is recommended to use sourceTensor.detach().clone() or sourceTensor.detach().clone().requires_grad_(True), rather than torch.tensor(sourceTensor).
get_xyz = torch.tensor(get_coord(lr_h * 2, lr_w * 2)).reshape(lr_h * 2, lr_w * 2, 2).cuda()
finished!
| 19:07:16 |
| 20 Oct 2025 |
 BerriJ | This look super cool! Remings me of the new 100x digital zoom feature of the Pixel Phones. So nice to see something open for that :) | 06:51:27 |
| connor (burnt/out) (UTC-8) | That uses something closer to multi-frame super-resolution (which is specifically what I’m interested in — I’d like to rewrite ContinuousSR to support that use case). Here’s a reproducer for an earlier version of the software Google used around the Pixel 3 era: https://github.com/Jamy-L/Handheld-Multi-Frame-Super-Resolution | 14:24:13 |
| connor (burnt/out) (UTC-8) | This was also a great way to find out that on master the wrong version of cuDNN is selected when building for Jetson (we get the x86 binary) — that’s mostly why the flake is using my PR with CUDA 13 and the packaging refactor | 14:29:02 |
| 21 Oct 2025 |
| connor (burnt/out) (UTC-8) | Started work on CUDA-legacy for everyone who needs support for older versions of CUDA https://github.com/nixos-cuda/cuda-legacy/pull/1 | 00:33:26 |
| connor (burnt/out) (UTC-8) | There might be interesting stuff in the second commit if you’re unfamiliar with flake-part’s partitions functionality | 06:22:13 |
| connor (burnt/out) (UTC-8) | SomeoneSerge (back on matrix)
what if 👉👈
you merged my CUDA 13 PR 🥺 | 06:23:32 |
 SomeoneSerge (back on matrix) | In reply to @connorbaker:matrix.org
SomeoneSerge (back on matrix)
what if 👉👈
you merged my CUDA 13 PR 🥺 'most there | 22:00:59 |
| 22 Oct 2025 |
 Niclas Overby Ⓝ | Are there any good resources for getting CUDA projects, built with CUDA packages from Nixpkgs, running with libcuda.so provided by a non-NixOS host?
Can it be done with LD_LIBRARY_PATH or LD_PRELOAD? | 08:08:09 |
 hacker1024 | nixGL has worked for me in the past | 08:56:54 |
| hacker1024 | Technically that finds a kernel-compatible libcuda.so in Nixpkgs | 08:57:24 |
 Robbie Buxton | In reply to @niclas:overby.me
Are there any good resources for getting CUDA projects, built with CUDA packages from Nixpkgs, running with libcuda.so provided by a non-NixOS host?
Can it be done with LD_LIBRARY_PATH or LD_PRELOAD? If you create a /run/opengl-driver/lib (it might be called something slightly different) folder and symlink all the cuda kernel mode drivers in there. It should work out of the box | 14:40:53 |
| Robbie Buxton | * If you create a /run/opengl-driver/lib (it might be called something slightly different) folder and symlink all the cuda kernel mode drivers into there. It should work out of the box | 14:41:06 |
| Robbie Buxton | You need to add this folder to the rpaths of those drivers too others they can’t find each other | 14:41:38 |
| Robbie Buxton | I.e libcuda.so tries to load something else with nix linker | 14:42:05 |
| Robbie Buxton | * I.e libcuda.so tries to load something else with the nix linker | 14:45:15 |
| connor (burnt/out) (UTC-8) | Both nixGL and nixglhost should work I’ve also had success doing what Robbie outlined
I’ve also been able to export LD_LIBRARY_PATH and that’s worked as well | 15:02:28 |
| Robbie Buxton | * You need to add this folder to the rpaths of those drivers too otherwise they can’t find each other | 15:13:26 |
| 23 Oct 2025 |
| connor (burnt/out) (UTC-8) | Got the majority of redists in https://github.com/nixos-cuda/cuda-legacy/pull/1; still need to verify stuff builds and add more redists to the older package sets
Everything being as-is is nice, I don’t have to care nsight_systems uses an old version of Qt with known vulnerabilities | 01:28:19 |
| hacker1024 | If anyone happens to be using datacenter drivers, be aware the the GSP firmware is not loading. This might lead to unexpected performance problems.
https://github.com/NixOS/nixpkgs/issues/454772 | 04:58:50 |
