| 29 Mar 2025 |
 ruro | I think I saw very similar error messages while trying to fix cuda-samples and I was able to fix them by explicitly adding a -L${CUDA_PATH}/lib to the nvcc invocation, where CUDA_PATH is a symlinkJoin with a bunch of cuda libs (not 100% sure, which specific ones were needed for the __cudaCDP2* symbols, maybe cuda_cudart or cuda_cudart.static?). | 07:26:15 |
| 1 Apr 2025 |
|  Artem Andreenko joined the room. | 09:58:12 |
|  Adam Neverwas set a profile picture. | 23:15:44 |
| 2 Apr 2025 |
|  @athyfr:matrix.org joined the room. | 01:29:37 |
| 3 Apr 2025 |
|  theabm joined the room. | 12:00:11 |
| 5 Apr 2025 |
|  underpantsgnome left the room. | 15:47:02 |
| 8 Apr 2025 |
 SomeoneSerge (back on matrix) | Kevin Mittman: are you aware of https://github.com/systemd/systemd/pull/32234/? It woudl be great to have this for CUDAToolkit and other components | 14:25:50 |
 connor (burnt/out) (UTC-8) | Hey all, some notes from a call I had with Serge about some priorities we're tracking: https://pad.lassul.us/s/GBcXdgeFz | 16:15:57 |
 indoor_squirrel | In reply to @connorbaker:matrix.org
Hey all, some notes from a call I had with Serge about some priorities we're tracking: https://pad.lassul.us/s/GBcXdgeFz It looks like there are hosted on Lassulus' personal site. Is that right? Any chance of (or any need to) getting these as files in some repo or something a bit more distributed? | 16:18:39 |
| connor (burnt/out) (UTC-8) | It's markdown, so we could definitely take them elsewhere, or even publish them on GitHub pages, but no immediate plans to do that due to lack of time | 16:20:03 |
| indoor_squirrel | Does nixpkgs use gh-pages? | 16:20:29 |
| indoor_squirrel | Seems like a great place for "project" notes. | 16:20:37 |
| SomeoneSerge (back on matrix) | I was wondering if it might be ok to abuse the nixos wiki for this? | 18:20:41 |
| SomeoneSerge (back on matrix) | From wiki matrix channel:
we could probably standardise this using Meetings/teamname/date as the template
| 18:45:12 |
| 9 Apr 2025 |
|  apache8080 joined the room. | 01:21:59 |
 Kevin Mittman (UTC-8) | In reply to @ss:someonex.net
Kevin Mittman: are you aware of https://github.com/systemd/systemd/pull/32234/? It woudl be great to have this for CUDAToolkit and other components I am not aware of that proposal getting adopted in any of the package ecosystems. It could be a good starting point | 04:12:05 |
| SomeoneSerge (back on matrix) | Does NixOS count? 🙃 https://github.com/NixOS/nixpkgs/pull/307068/commits/2328731ad041735a2260698574ce6599591f33ad | 10:02:32 |
| @athyfr:matrix.org changed their profile picture. | 20:51:58 |
| 10 Apr 2025 |
| connor (burnt/out) (UTC-8) | As an update, I’ve been added to the nix-community org but haven’t had a chance to push a copy of the to-be-removed CUDA components and GCC expressions | 16:26:37 |
| connor (burnt/out) (UTC-8) | Complication there is mostly figuring out important paths in the tree so I know what to keep when doing a filter (to retain commit history) | 16:27:19 |
| connor (burnt/out) (UTC-8) | SomeoneSerge (UTC+U[-12,12]): as a quick fix for nix-gl-host for Jetson devices for the problem I was seeing where cuda_compat wouldn’t be set in the LD_LIBRARY_PATH and the drivers would take priority, would it be enough to scan the run path of the binary passed to nixglhost to look for cuda_compat and conditionally prepend it to LD_LIBRARY_PATH if it is present?
Kind of gross, but given usage of cuda_compat is per-application and not a single vendor supplied directory on the host, not sure how else to handle it.
Ugh I imagine one should also check the version of the host driver to see if using cuda_compat when it is present in the run path would actually break things (i.e., the driver is newer than what cuda_compat provides for, so we need to use the driver’s backward compatibility instead of cuda_compat’s forward compatibility). | 16:32:12 |
| SomeoneSerge (back on matrix) | Hmmm why'd you need the scanning? | 16:32:51 |
| SomeoneSerge (back on matrix) |
the driver is newer than what cuda_compat provides for
H'm, interesting
| 16:33:24 |
| connor (burnt/out) (UTC-8) | The cuda_compat used in the runpath of the binary provided to nix-gl-host depends on the version of CUDA used
OH
Maybe I’m thinking about this wrong | 16:35:10 |
| connor (burnt/out) (UTC-8) | X86 has a cuda_compat library too from what I remember, it’s just not available as a redist
So maybe we shouldn’t package the one for Jetsons
And instead, nixglhost should use the one on the host system if it is available | 16:36:17 |
| connor (burnt/out) (UTC-8) | Although that won’t us on NixOS systems — cuda_compat is usually provided as a Debian with newer releases of CUDA, so it would just fail to run on NixOS systems if the driver isn’t new enough | 16:37:40 |
| connor (burnt/out) (UTC-8) | * Although that won’t help us on NixOS systems — cuda_compat is usually provided as a Debian with newer releases of CUDA, so it would just fail to run on NixOS systems if the driver isn’t new enough | 16:37:48 |
| SomeoneSerge (back on matrix) |
So maybe we shouldn’t package the one for Jetsons
No, I think whenever it's available we'd rather do the pure linking, because that's what we do to other libraries. This is in general a tradeoff, and it would have been great if we had tools for quickly relinking stuff/tools for building stuff against reproducible content-addressed stubs with a separate linking phase, but that's not where we are
| 16:39:50 |
| connor (burnt/out) (UTC-8) | Ugh
So on all platforms, we should only use cuda_compat if the host driver is old and we need forward compat
I guess the question is where cuda_compat should come from, if the decision to use it or not requires knowing what version the host driver is | 16:40:10 |
| SomeoneSerge (back on matrix) | This is not different from the GL/vulkan situation | 16:41:29 |
