| 2 Mar 2023 |
 SomeoneSerge (back on matrix) | In reply to @ss:someonex.net
CMakeCache.txt:CMAKE_CUDA_ARCHITECTURES:STRING=52
CMakeCache.txt:CUDA_ARCHITECTURES:UNINITIALIZED=86
❯ cuobjdump /nix/store/mkrv74b38zx1afkkpj55xmnm68rgmywq-magma-2.7.1/lib/libmagma.so | rg 'arch =' | sort | uniq
arch = sm_86
| 23:31:22 |
| SomeoneSerge (back on matrix) | connor (he/him): how bad would it be if magma accepted both gpuTargets and cudaPackages.cudaFlags, but only used the latter for cuda capabilities? | 23:49:13 |
| 3 Mar 2023 |
 connor (he/him) | Hmm...
So from what I could tell when I originally started on the Magma derivation, gpuTargets was used solely for AMD GPUs. In the hip attribute set (their equivalent of cudaPackages?), they have gpuTargets which is the equivalent of our cudaCapabilities (I think). In the original derivation, the gpuTargets attribute Magma takes had precedence over whatever hip.gpuTargets was. | 00:56:31 |
| connor (he/him) | I like the idea of specifying per-package GPU target overrides, so when I refactored the derivation I made gpuTargets also take precedence over cudaPackages's capabilities | 00:57:17 |
| SomeoneSerge (back on matrix) | I ended up just pushing it into that fat pr... https://github.com/NixOS/nixpkgs/pull/218265/commits/0d6eb2a8e03e7a9d2e625ac6d568c73040429c27 | 01:00:19 |
| SomeoneSerge (back on matrix) | nix build nixpkgs#magma fails | 01:08:39 |
| SomeoneSerge (back on matrix) | It defaults to cudaSupport = true and dies evaluating unfree cuda_nvcc | 01:09:28 |
| connor (he/him) | In reply to @ss:someonex.net
❯ cuobjdump /nix/store/mkrv74b38zx1afkkpj55xmnm68rgmywq-magma-2.7.1/lib/libmagma.so | rg 'arch =' | sort | uniq
arch = sm_86
oh I had just added the equivalent of "-DCUDA_ARCHITECTURES=89" instead of "-DCMAKE_CUDA_ARCHITECTURES", derp. I'll try rebuilding and see if I also see it complied with the specified arch that way instead of just the default | 01:16:03 |
| connor (he/him) | Oh hell yeah
$ cuobjdump ./result/lib/libmagma.so | rg "arch =" | sort -u
arch = sm_89
| 01:17:02 |
| connor (he/him) | I'm going to see if I can repro your nix build failure | 01:19:47 |
| connor (he/him) | fwiw I'm able to build it, but I used nix build --impure -L .#magma and my ~/.config/nixpkgs/config.nix looks like
{
allowUnfree = true;
cudaSupport = true;
cudaCapabilities = [ "8.6" ];
cudaForwardCompat = false;
}
| 01:24:56 |
| SomeoneSerge (back on matrix) | That's the difference, yeah | 01:25:18 |
| connor (he/him) | What's it supposed to fail with (if at all)? I think it does that on master as well? | 01:26:44 |
| SomeoneSerge (back on matrix) | Yes, I meant master | 01:27:42 |
| SomeoneSerge (back on matrix) | ❯ nix build github:NixOS/nixpkgs/master#magma
error: Package ‘cuda_nvcc-11.7.64’ in /nix/store/hjlp6rhp33n9npc69g2ikhq138fkrh9w-source/pkgs/development/compilers/cudatoolkit/redist/build-cuda-redist-package.nix:47 has an unfree license (‘unfree’), refusing to evaluate.
a) To temporarily allow unfree packages, you can use an environment variable
because it takes cudaSupport ? true
| 01:28:51 |
| SomeoneSerge (back on matrix) | And then we just import it in all-packages.nix as is | 01:29:04 |
| SomeoneSerge (back on matrix) | I'm not sure what we're exposing magma, magma_2_7_1 and magma_2_6_2 for, I think we only use magma-cuda and magma-hip? | 01:30:06 |
| SomeoneSerge (back on matrix) | Oh, I get it now! I was wondering why doesn't ofborg complain about it, but it defaults tocudaSupport = true, so it sets license = unfree, so ofborg doesn't try to evaluate it | 01:31:53 |
| connor (he/him) | torch takes magma as an argument supplied by callPackage -- torchWithCuda and torchWithRocm specifically pass magma = magma-cuda etc., but the default torch just expects magma | 01:33:12 |
| connor (he/him) | lmao is torch the only package that actually takes magma as an argument | 01:34:22 |
| SomeoneSerge (back on matrix) | And is it true that magma can't be built cpu-only, and can't mix cuda and hip? | 01:34:56 |
| connor (he/him) | Actually not sure about mixing cuda and HIP, but it is a GPU-accelerated library so not sure what the point of building CPU-only (if at all possible) would be | 01:35:47 |
| connor (he/him) | Ah from the CMakeLists.txt it does look like it's CUDA XOR HIP: https://bitbucket.org/icl/magma/src/f4ec79e2c13a2347eff8a77a3be6f83bc2daec20/CMakeLists.txt#lines-469 | 01:37:11 |
| SomeoneSerge (back on matrix) | That's convincing | 01:37:35 |
 hexa | Samuel Ainsworth: jax tests broke on python-updates due to scipy update | 03:18:19 |
| hexa | https://hydra.nixos.org/log/rgrylknin2b3yflgiy7jbjrb5r7j18m3-python3.10-jax-0.4.1.drv | 03:18:22 |
| hexa | * Samuel Ainsworth: jax tests broke on python-updates due to numpy/scipy update | 03:19:16 |
| SomeoneSerge (back on matrix) | * Mostly outPaths react to cudaSupport through gst-plugins-bad, which depend on opencv
#FalsePositive | 15:51:59 |
| SomeoneSerge (back on matrix) | Another potential #FalsePositive: we rebuild scikitimage because it depends on numba, which changes with cudaSupport | 15:54:07 |
| 4 Mar 2023 |
| SomeoneSerge (back on matrix) | Turned off the hercules builds. I finally skimmed through the part of the manual, where it says it supports onSchedule jobs, I'm hoping I can ditch github actions and bash scripts, and make a smarter schedule where I'd build e.g. 8.6 more frequently than the big default set of capabilities 🤔 | 00:50:21 |
