| 15 Oct 2025 |
 Ari Lotter | (still me sorry, diff devices w bad key management) | 19:44:26 |
| Ari Lotter | https://github.com/PsycheFoundation/psyche/blob/main/nix/nvshmem.nix | 19:44:30 |
| Ari Lotter | we don't have nvshmem in nixpkgs | 19:44:35 |
| Ari Lotter | i'm using this with torch 2.9.0 :) | 19:45:38 |
 Gaétan Lepage | Thanks for sharing! I guess we'll need to cleanly upstream this then? | 20:03:40 |
| Gaétan Lepage | * Thanks for sharing! I guess we'll need to cleanly upstream this then. | 20:03:41 |
 connor (burnt/out) (UTC-8) | I could probably add it to the CUDA 13 PR; nvshmem is one of the dependencies of libcublasmp I didn’t try to package | 20:53:02 |
| 16 Oct 2025 |
| Ari Lotter | lmk if i can help - 2.9.0 (nightly) is in active usage in the above project | 00:46:36 |
| connor (burnt/out) (UTC-8) | Looks like it should be very doable to package — it’s a redist so shouldn’t be too bad and can re-use all the helpers we’ve got for that. Will take a closer look tomorrow | 04:53:50 |
 Niclas Overby Ⓝ | Is there something like rust-overlay for CUDA, so you can specify exactly which CUDA version to use? | 11:39:49 |
| connor (burnt/out) (UTC-8) | You can specify which CUDA version to use currently so long as it is a CUDA version supported in-tree by using an overlay or the cudaPackages.pkgs pattern (see Nixpkgs manual) | 14:08:11 |
| connor (burnt/out) (UTC-8) | Arbitrary versions aren’t something doable with the current state of things because of the amount of patching required for each package (which varies by version of course) | 14:10:31 |
| connor (burnt/out) (UTC-8) | Plus, some of these binaries aren’t stand-alone — NVCC for example requires a host compiler.
So if we wanted to support arbitrary CUDA versions, we’d need to somehow know ahead of time which host compilers and versions are supported by all NVCC releases (we have a list we maintain in tree but it’s updated manually by reading release notes).
And then we’d need to use the appropriate version of the host compiler… but what if it’s not packaged in Nixpkgs? CUDA 11 releases used GCC 9, 10, and 11 and those aren’t maintained in-tree any more. | 14:14:59 |
| connor (burnt/out) (UTC-8) | I’ve been working on the ability to extend the CUDA package set and make new ones for out of tree users, but it’s generally non-trivial and requires a great deal of familiarity | 14:17:53 |
| 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 |
