!eWOErHSaiddIbsUNsJ:nixos.org

NixOS CUDA

293 Members
CUDA packages maintenance and support in nixpkgs | https://github.com/orgs/NixOS/projects/27/ | https://nixos.org/manual/nixpkgs/unstable/#cuda57 Servers

Load older messages

SenderMessageTime
10 Feb 2025
@ruroruro:matrix.orgruro* Taking a cursory look at that repository, it seems that the original author just commited the whole SVN repo in the initial commit instead of importing the history from SVN, which is kind of annoying/problematic.03:09:06
@stick:matrix.orgstick another option would be to just remove freeImageInteropNPP from the cuda-samples build 08:19:23
@stick:matrix.orgstick * another option would be to just remove freeImageInteropNPP sample from the cuda-samples build 08:19:34
@stick:matrix.orgstick

by changing SAMPLE_ENABLED := 1 to SAMPLE_ENABLED := 0 here:

https://github.com/NVIDIA/cuda-samples/blob/9c688d7ff78455ed42e345124d1495aad6bf66de/Samples/4_CUDA_Libraries/freeImageInteropNPP/Makefile#L284

08:22:11
@stick:matrix.orgstickor maybe even that is not necessary and the build correctly detects that FreeImage is not available and skips that sample08:23:19
@ruroruro:matrix.orgruroI was under the impression that there were a lot more samples that depended on FreeImage. If this is indeed the only sample that requires FreeImage, then I will simply remove it since I am already going to remove a few broken samples that don't have easy fixes.09:40:54
@ruroruro:matrix.orgruro* I was under the impression that there were a lot more samples that depended on FreeImage. If this is indeed the only sample that requires FreeImage, then I will simply remove it since I am already planning to remove a few broken samples that don't have easy fixes.09:41:03
@ruroruro:matrix.orgruro* Nice catch! I was under the impression that there were a lot more samples that depended on FreeImage. If this is indeed the only sample that requires FreeImage, then I will simply remove it since I am already planning to remove a few broken samples that don't have easy fixes.09:41:12
@ss:someonex.netSomeoneSerge (back on matrix) They're both aarch64, it can build both, just it doesn't have the runtime 13:29:37
@ss:someonex.netSomeoneSerge (back on matrix)

Afaik, the official hydra builders don't build insecure packages, so I am kind of against setting

Yeah but honestly I see no reason for that

13:30:47
@ss:someonex.netSomeoneSerge (back on matrix)

I still think that we should just change freeimage to

That would be lies though?

13:31:27
@ss:someonex.netSomeoneSerge (back on matrix)

Message deleted by NixOS Moderation Bot

o_0

13:32:39
@ruroruro:matrix.orgruro I think that only 5 samples actually depend on freeimage - FilterBorderControlNPP, boxFilterNPP, cannyEdgeDetectorNPP, freeImageInteropNPP and histEqualizationNPP. That's not that many (given that there are like 200 total or something), so I am probably going to throw my over-engineered freeimage.overrideAttrs chicanery out of the window and just disable these samples by default. 13:56:04
@ruroruro:matrix.orgruro

On a related note, can somebody tell me:

  1. Should I prefer linking to libglvnd instead of libGL?
  2. Is it bad if I end up having both libGL and libglvnd in the same closure?
  3. It seems that libglvnd doesn't provide libGLU or libglut. Is there an equivalent vender-neutral dispatch mechanism for those libraries?
14:02:59
@ruroruro:matrix.orgruro *

~~On a related note, can somebody tell me:

  1. Should I prefer linking to libglvnd instead of libGL?
  2. Is it bad if I end up having both libGL and libglvnd in the same closure?
  3. It seems that libglvnd doesn't provide libGLU or libglut. Is there an equivalent vender-neutral dispatch mechanism for those libraries?~~
14:03:16
@ruroruro:matrix.orgruro *

On a related note, can somebody tell me:

  1. Should I prefer linking to libglvnd instead of libGL?
  2. Is it bad if I end up having both libGL and libglvnd in the same closure?
  3. It seems that libglvnd doesn't provide libGLU or libglut. Is there an equivalent vender-neutral dispatch mechanism for those libraries?

Edit: nvm, I am blind. libGL is an alias for libglvnd

14:03:56
@ruroruro:matrix.orgruro *

~~On a related note, can somebody tell me:~~

  1. Should I prefer linking to libglvnd instead of libGL?
  2. Is it bad if I end up having both libGL and libglvnd in the same closure?
  3. It seems that libglvnd doesn't provide libGLU or libglut. Is there an equivalent vender-neutral dispatch mechanism for those libraries?

Edit: nvm, I am blind. libGL is an alias for libglvnd

14:04:04
@ruroruro:matrix.orgruro *

~On a related note, can somebody tell me:~

  1. Should I prefer linking to libglvnd instead of libGL?
  2. Is it bad if I end up having both libGL and libglvnd in the same closure?
  3. It seems that libglvnd doesn't provide libGLU or libglut. Is there an equivalent vender-neutral dispatch mechanism for those libraries?

Edit: nvm, I am blind. libGL is an alias for libglvnd

14:04:12
@ruroruro:matrix.orgruro *

On a related note, can somebody tell me:

  1. Should I prefer linking to libglvnd instead of libGL?
  2. Is it bad if I end up having both libGL and libglvnd in the same closure?
  3. It seems that libglvnd doesn't provide libGLU or libglut. Is there an equivalent vender-neutral dispatch mechanism for those libraries?

Edit: nvm, I am blind. libGL is an alias for libglvnd

14:05:15
@ruroruro:matrix.orgruro *

On a related note, can somebody tell me:

  1. Should I prefer linking to libglvnd instead of libGL?
  2. Is it bad if I end up having both libGL and libglvnd in the same closure?
  3. It seems that libglvnd doesn't provide libGLU or libglut. Is there an equivalent vender-neutral dispatch mechanism for those libraries?

Edit: nvm, I am blind. libGL is an alias for libglvnd

14:05:30
@ruroruro:matrix.orgruro *

On a related note, can somebody tell me:

  1. Should I prefer linking to libglvnd instead of libGL?
  2. Is it bad if I end up having both libGL and libglvnd in the same closure?
  3. It seems that libglvnd doesn't provide libGLU or libglut. Is there an equivalent vender-neutral dispatch mechanism for those libraries?

Edit: nvm, I am blind. libGL is an alias for libglvnd

14:06:04
@ruroruro:matrix.orgruro *

On a related note, can somebody tell me:

  1. Should I prefer linking to libglvnd instead of libGL?
  2. Is it bad if I end up having both libGL and libglvnd in the same closure?
  3. It seems that libglvnd doesn't provide libGLU or libglut. Is there an equivalent vender-neutral dispatch mechanism for those libraries?

Edit: nvm, I must be blind and/or sleep deprived. libGL is an alias for libglvnd

14:06:35
@ruroruro:matrix.orgruro *

On a related note, can somebody tell me:

  1. Should I prefer linking to libglvnd instead of libGL?
  2. Is it bad if I end up having both libGL and libglvnd in the same closure?
  3. It seems that libglvnd doesn't provide libGLU or libglut. Is there an equivalent vender-neutral dispatch mechanism for those libraries?

Edit: nvm, I must be blind and/or sleep deprived. libGL is an alias for libglvnd

14:08:14
@stick:matrix.orgsticksounds good 15:05:28
@ruroruro:matrix.orgruro

Btw, it seems that there is a mismatch in CUDA vs GCC version compatibility after all. In particular, for me

cudaPackages_11_2.backendStdenv.cc.version == "12.4.0"

and with that compiler, a couple of the samples in cuda-samples are failing to compile due to errors inside cuda_cccl headers. Here is a forum post discussing this exact error.

I wasn't able to find precise compatibility matrices for CUDA 12.1, but according to this stackoverflow answer, CUDA 12.1 supports GCC versions up to 12.2 which is lower than the current 12.4.0.

Minor versions don't work in pkgs/development/cuda-modules/nvcc-compatibilities.nix, but setting gccMaxMajorVersion = "11" for "12.1" I was able to successfully build the problematic samples that fail with GCC 12.4.0. So it looks like CUDA 12.1 doesn't fully support GCC 12.4 after all.

Thoughts?

15:53:25
@ss:someonex.netSomeoneSerge (back on matrix)Hm. The logic for choosing gcc initially used gccMaxMajorVersion from some other file, nvcc-compatibilities was added later15:54:53
@ss:someonex.netSomeoneSerge (back on matrix)I hope to rewrite the eval bit in the coming month15:55:19
@ruroruro:matrix.orgruro *

Btw, it seems that there is a mismatch in CUDA vs GCC version compatibility after all. In particular, for me

cudaPackages_11_2.backendStdenv.cc.version == "12.4.0"

and with that compiler, a couple of the samples in cuda-samples are failing to compile due to errors inside cuda_cccl headers. Here is a forum post discussing this exact error.

I wasn't able to find precise compatibility matrices for CUDA 12.1, but according to this stackoverflow answer, CUDA 12.1 supports GCC versions up to 12.2 which is lower than the current 12.4.0.

Minor versions don't work in pkgs/development/cuda-modules/nvcc-compatibilities.nix, but setting gccMaxMajorVersion = "11" for CUDA "12.1" I was able to successfully build the problematic samples that fail with GCC 12.4.0. So it looks like CUDA 12.1 doesn't fully support GCC 12.4 after all.

Thoughts?

15:57:11
@stick:matrix.orgsticki was able to build most of the release-cuda packages on aarch64-linux without any build issues - so this is awesome!17:29:24
@stick:matrix.orgsticki pushed the results into https://app.cachix.org/cache/cuda-arm in case anyone would like to play with that17:30:29

Show newer messages

Back to Room ListRoom Version: 9