| 31 Aug 2022 |
 tpw_rules | yeah it does do cuda things | 21:56:01 |
| tpw_rules | and the wheel has all the cuda .so files | 21:56:24 |
 hexa | ok, great | 22:03:05 |
| hexa | so the cuda arch support list remains todo? | 22:03:33 |
| tpw_rules | oh, no, i did check that and it doesn't need to be expanded | 22:03:56 |
| tpw_rules | there is a new 8.7 architecture but that's only for the nvidia agx embedded aarch64 things which nixpkgs doesn't touch yet | 22:04:22 |
| tpw_rules | from my perspective it's ready for merging. samuela says we shouldn't have that cuda packages pin, and it's immaterial now | 22:05:53 |
| tpw_rules | but i think you rebased when you force pushed so the diff is meaningless to me | 22:06:07 |
| hexa | yes, rebased onto a recent master | 22:06:37 |
| tpw_rules | what did you change when you force pushed? | 22:06:50 |
| hexa | https://github.com/NixOS/nixpkgs/pull/189013#pullrequestreview-1092543709 | 22:07:01 |
| hexa | just this | 22:07:04 |
| tpw_rules | just added that line? meh if you added it then whatever. samuela says the "usual practice" is to not have it. but it doesn't actually change anything at this point because we haven't packaged cuda 11.7 yet | 22:08:01 |
| hexa | I can drop it, I don't mind | 22:10:08 |
| tpw_rules | ok. i'd say drop that line then merge | 22:10:49 |
| hexa | sgtm | 22:10:54 |
| tpw_rules | do you always rebase onto master as part of force pushing? your diff ended up with a bunch of random junk in it again | 22:23:00 |
| hexa | huh | 22:48:51 |
| hexa | yeah, mostly. | 22:49:00 |
| hexa | the diff should be the same against master | 22:49:09 |
| tpw_rules | well i mean github's nice "here's what's changed in the force push" button | 22:50:36 |
| hexa | huh, ok. Never used that | 22:51:21 |
| 1 Sep 2022 |
 SomeoneSerge (back on matrix) | Ah, OK. I think some derivations have already been using that for a while | 11:19:55 |
| SomeoneSerge (back on matrix) | But not e.g. pytorch, I think. They had some custom stuff and one would have to experiment with getting their way around it | 11:21:18 |
| SomeoneSerge (back on matrix) | I'll update the scripts for nixpkgs-unfree cachix | 11:26:15 |
| SomeoneSerge (back on matrix) | 🤔 did it even have to be cu113? | 11:26:48 |
| SomeoneSerge (back on matrix) | RE: CUDA Arch List
- Early on, there has been a talk of maybe making a global
config.cudaArchList attribute, analogous to config.cudaSupport that all packages would inherit from. This is so we could switch all nixpkgs' cuda architectures at once
- This was before we had
cudaPackages_XX package sets and more or less arbitrary
- Now it might make sense to have global default lists per package sets (they support different ranges of architectures),
cudaPackages_XX.cudaArchList. They probably could be implemented as just min/max limits instead
- When drafting a PR on this, it would be nice to provide functions to convert back and forth between a "default" list format (e.g. cmake's
CUDA_ARCHITECTURES) and whatever other formats we frequently deal with
RE: Building for single target/building for widest compatibility
A thought that's been brought up here before, although now I'm skeptical of it, is that rather than building for all architectures at once we could cache many single-target builds. The idea is that when the end-user has to build something extra that hasn't been cached, they'd spend less compute
A counter-point would be that the user can override arch list just for their extra package instead
| 11:48:58 |
| tpw_rules | if we build for all architectures why would the user have to build something extra? | 15:58:30 |
| SomeoneSerge (back on matrix) | Because there will always be some packages we haven't built | 15:58:51 |
| SomeoneSerge (back on matrix) | ...an opencv.override { enableSomething = true; } | 15:59:24 |
