| 23 May 2024 |
 hexa | So what is the overlap between our configs? | 22:07:47 |
 Gaétan Lepage | I basically have the same config as you have hexa (UTC+1) | 22:18:24 |
| Gaétan Lepage | I guess that the origins of those warnings are internal to nixpkgs. | 22:18:40 |
| hexa | ok, it is nothing in this file 😄 | 22:41:19 |
| hexa | killing nixpkgs.config.cudaSupport gets rid of the trace | 22:41:59 |
| hexa | ok, this one is sus | 23:03:45 |
| hexa |
trace: warning: cudaPackages.autoAddOpenGLRunpathHook is deprecated, use pkgs.autoAddDriverRunpath instead
| 23:03:51 |
| hexa | Already up to date.
❯ rg autoAddOpenGLRunpathHook
nixos/doc/manual/release-notes/rl-2405.section.md
248:- `cudaPackages.autoAddOpenGLRunpathHook` and `cudaPackages.autoAddDriverRunpath` have been deprecated for `pkgs.autoAddDriverRunpath`. Functionality has not changed, but the setuphook has been renamed and moved to the top-level package scope.
pkgs/development/cuda-modules/aliases.nix
15: autoAddOpenGLRunpathHook =
16: mkRenamed "autoAddOpenGLRunpathHook" "pkgs.autoAddDriverRunpath"
| 23:04:40 |
| hexa | * ❯ rg autoAddOpenGLRunpathHook
nixos/doc/manual/release-notes/rl-2405.section.md
248:- `cudaPackages.autoAddOpenGLRunpathHook` and `cudaPackages.autoAddDriverRunpath` have been deprecated for `pkgs.autoAddDriverRunpath`. Functionality has not changed, but the setuphook has been renamed and moved to the top-level package scope.
pkgs/development/cuda-modules/aliases.nix
15: autoAddOpenGLRunpathHook =
16: mkRenamed "autoAddOpenGLRunpathHook" "pkgs.autoAddDriverRunpath"
| 23:04:44 |
| hexa | the only two mentions | 23:04:49 |
| hexa | let's rule out the release notes for a second 😄 | 23:04:55 |
| hexa | that makes the definition the only place???? | 23:05:05 |
| hexa | nix is supposed be lazy, so how does it get evaluated when nobody consumes it? | 23:05:54 |
 SomeoneSerge (matrix works sometimes) | In reply to @hexa:lossy.network
trace: warning: cudaPackages.autoAddDriverRunpath is deprecated, use pkgs.autoAddDriverRunpath instead
trace: warning: cudaPackages.autoAddDriverRunpath is deprecated, use pkgs.autoAddDriverRunpath instead
trace: warning: cudaPackages.autoFixElfFiles is deprecated, use pkgs.autoFixElfFiles instead
trace: warning: cudaPackages.autoAddOpenGLRunpathHook is deprecated, use pkgs.autoAddDriverRunpath instead
trace: warning: cudaPackages.autoAddDriverRunpath is deprecated, use pkgs.autoAddDriverRunpath instead
There was an autoAddDriverRunpath in cudaPackages, and then there was a @jonringer's PR introducing aliases.nix for cudaPackages, we moved autoAddDriverRunpath to the top-level and added an alias in cudaPackages | 23:06:46 |
| SomeoneSerge (matrix works sometimes) | I don't it should be evaluated | 23:07:04 |
| hexa | this is on release-24.05 fwiw | 23:07:06 |
| 24 May 2024 |
 aidalgol | SomeoneSerge (UTC+3): I didn't quite understand your "deploy this impurely" comment on the libXNVCtrl patch. | 18:53:47 |
| aidalgol | * SomeoneSerge (UTC+3): I didn't quite understand your "deploy this impurely" comment on the libXNVCtrl PR. | 18:53:49 |
| SomeoneSerge (matrix works sometimes) | In reply to @aidalgol:matrix.org
SomeoneSerge (UTC+3): I didn't quite understand your "deploy this impurely" comment on the libXNVCtrl PR. /run/opengl-driver instead of rpath | 18:56:55 |
| aidalgol | Ah, right. I'm not certain whether it needs to match the driver version or not. | 18:57:58 |
| SomeoneSerge (matrix works sometimes) | In reply to @aidalgol:matrix.org
Ah, right. I'm not certain whether it needs to match the driver version or not. Same. I suggest that we test | 19:00:03 |
 connor (he/him) | Okay, my absolute favorite new functionality in the PR I've been working on is being able to do this:
nix build --impure -L .#cudaPackages_11_8.pkgs.xgboost
and build xgboost with cudaPackages_11_8.
| 20:56:50 |
| connor (he/him) | It makes it so much easier to see if something is broken because of the CUDA version | 20:57:06 |
| connor (he/him) | Relevant change https://github.com/NixOS/nixpkgs/pull/306172/commits/98906659f42a774afc6d43bfae795cf9bbf4768b | 21:06:17 |
| SomeoneSerge (matrix works sometimes) | In reply to @connorbaker:matrix.org
Okay, my absolute favorite new functionality in the PR I've been working on is being able to do this:
nix build --impure -L .#cudaPackages_11_8.pkgs.xgboost
and build xgboost with cudaPackages_11_8.
This looks nice but also looks like a way to shoot yourself in the foot and/or cause infinite recursion | 21:06:22 |
| connor (he/him) | Has anyone had the opportunity to do anything with Intel Optane's enterprise drives? | 21:08:07 |
| connor (he/him) | Unrelated: has anyone encountered a similar error? Looks like xgboost doesn't build with CUDA 12.4.
xgboost> /build/source/src/common/quantile.cu(184): error: no instance of function template "cuda::std::__4::make_tuple" matches the argument list
xgboost> argument types are: (bool, size_t)
xgboost> return thrust::make_tuple<uint64_t, uint64_t>(!ind, ind);
xgboost> ^
xgboost> /nix/store/n5qpzxhxivwp6nxhlrf5synfxjzqqbnh-cuda12.4-cudatoolkit/include/cuda/std/detail/libcxx/include/tuple(1106): note #3326-D: function template "cuda::std::__4::make_tuple" does not match because argument #2 does not match parameter
xgboost> make_tuple(_Tp &&...__t) {
xgboost> ^
| 21:09:32 |
| connor (he/him) | :f https://gitlab.com/petsc/petsc/-/merge_requests/7354 | 21:11:03 |
| SomeoneSerge (matrix works sometimes) | !ind hmmhmm was that meant to be ~ind | 21:15:18 |
 Philip Taron (UTC-8) | In reply to @connorbaker:matrix.org
Has anyone had the opportunity to do anything with Intel Optane's enterprise drives? I have two of them I bought off ebay that I stuck in my machine. They're fast and high iop, but I haven't felt like they changed the game in any meaningful way. | 21:15:47 |
