In reply to @sielicki:matrix.org
I just raised an issue earlier today about some of the driver hashes missing for some of the releases, it feels to me like we really need a solid cuda json scraper to prefetch script

In reply to @sielicki:matrix.org
i guess it's just consistently the case that ld.so believes there's a better match than that one.

In reply to @ss:someonex.net
Yes, there's https://github.com/ConnorBaker/cuda-redist-find-features/ but afaik Connor's developing this alone, and there stuff to be improved with the way we parse the results on nixpkgs side too

In reply to @snektron:matrix.org
Is there a reason why https://github.com/NixOS/nixpkgs/pull/291471 is not merged?

It's a disagreeable opinion but the whole "inspect the system at eval time" business in nixGL makes me want to scream "why". Even the idea of requiring a running nix-daemon in order to load the drivers at the program's startup... I think it's very backwards.

I think nix-gl-host decomposes tasks better, but

1. It doesn't handle the "nixos but a different release (libc)" situation (nixGL... well it does, just under some set of assumptions)
2. I'd much rather have a mode where nix-gl-host is used to export the /run/opengl-driver/lib prefix, rather than construct LD_LIBRARY_PATH. ot only because the latter screws up search path priorities, but because the workflow I'd rather see is you run a non-nixos, you drop a systemd unit, and voilla your drivers work exactly the way they do on nixos

It's a disagreeable opinion but the whole "inspect the system at eval time" business in nixGL makes me want to scream "why". Even the idea of requiring a running nix-daemon in order to load the drivers at the program's startup... I think it's very backwards.

I think nix-gl-host decomposes tasks better, but

1. It doesn't handle the "nixos but a different release (libc)" situation (nixGL... well it does, just under some set of assumptions)
2. I'd much rather have a mode where nix-gl-host is used to export the /run/opengl-driver/lib prefix, rather than construct LD_LIBRARY_PATH. ot only because the latter screws up search path priorities, but because the workflow I'd rather see is you run a non-nixos, you drop a systemd unit, and voilla your drivers work can be consumed exactly the way they do on nixos

In reply to @aidalgol:matrix.org
Has anyone successfully built blender on unstable with CUDA support enabled recently?

In reply to @ss:someonex.net
Note there was recently somebody in nix-gl-host issues advertising their Rust rewrite

In reply to @zimbatm:numtide.com
Did you take a look at https://github.com/NVIDIA/nvidia-container-toolkit already? I think they are battling with similar issues, plus sandboxing on top. It seems like they are using ld.so.cache as a loading mechanism instead of the LD_* env var and that might be more robust?

In reply to @zimbatm:numtide.com
looks like it's broken since end of October: https://hydra.nix-community.org/build/1720981

In file included from /build/source/intern/cycles/scene/image_vdb.cpp:5:
/build/source/intern/cycles/scene/../scene/image_vdb.h:12:12: fatal error: nanovdb/util/GridHandle.h: No such file or directory
   12 | #  include <nanovdb/util/GridHandle.h>
      |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [intern/cycles/scene/CMakeFiles/cycles_scene.dir/build.make:328: intern/cycles/scene/CMakeFiles/cycles_scene.dir/image_vdb.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
[ 56%] Building CXX object source/blender/makesrna/intern/CMakeFiles/bf_rna.dir/rna_access_compare_override.cc.o
In file included from /build/source/intern/cycles/scene/image.cpp:9:
/build/source/intern/cycles/scene/../scene/image_vdb.h:12:12: fatal error: nanovdb/util/GridHandle.h: No such file or directory
   12 | #  include <nanovdb/util/GridHandle.h>
      |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~

Well here's the first offender