| 31 Aug 2022 |
 tpw_rules | i was more curious if it broke something or it was just a cleanup | 00:34:47 |
| tpw_rules | have you tried to compile with cuda support yet? | 00:34:54 |
 hexa | it was a cleanup | 00:34:56 |
| hexa | no | 00:35:00 |
| tpw_rules | ok. like i said i'll try to smoke test it this week if you don't mind waiting and let you know on the cuda capability list. i think we need a better story for managing them | 00:35:40 |
| tpw_rules | thanks for all your effort though | 00:35:43 |
| hexa |
i think we need a better story for managing them
| 00:35:54 |
| hexa | totally. | 00:35:55 |
| hexa | it was on my todo list for a while | 00:36:17 |
| tpw_rules | how does one propose that kind of thing? i think we would want buy-in from nixpkgs as a whole because i imagined it as an attribute like blas/lapack and mpi implementation selection are | 00:38:14 |
| hexa | I think it is reasonable to create a draft PR and discuss it | 00:39:05 |
| tpw_rules | i guess that would be to just create a global atttribute and some docs? i need to familiarize myself around the cudaPackages scope, maybe it's more appropriate to add it there | 00:40:46 |
| hexa | not an expert on where documentation would actually go | 00:40:48 |
| tpw_rules | but i know that's a recent thing | 00:40:53 |
| hexa | tying it to some package set would be easiest | 00:41:08 |
| tpw_rules | i think the user would want to control it though. not sure what you mean by that comment | 00:41:47 |
| tpw_rules | but more my question is i assume actually switching packages to care about it could wait until a later PR | 00:42:30 |
| tpw_rules | isn't the cudaPackages a new thing? | 00:42:38 |
| hexa | I don't know | 00:43:03 |
| hexa | so you basically want a module that controls the cuda version used everywhere? | 00:43:20 |
 Samuel Ainsworth | Seems fine to me as long as it builds! | 00:43:38 |
| tpw_rules | not the cuda version, but the cuda architecture support list: https://github.com/NixOS/nixpkgs/blob/849bf642cf8319b0aca69708462ff8c4874189ca/pkgs/development/python-modules/torch/default.nix#L82 | 00:45:01 |
| Samuel Ainsworth | IIRC Someone S also brought the cuda architecture support issue up in the past. we don't have a solution yet, but it sounds like a nice addition! | 00:46:35 |
| tpw_rules | the tl;dr is that almost every generation of card requires binaries that target it specifically. binaries can't be used on cards that don't match. there are pre-binary forms which can be JITed into binaries in most circumstances, but performance can suffer. distributors would compile all binaries possible, but for the user who wants it to work on just their card, not doing that can save literal hours of compilation time | 00:46:47 |
| tpw_rules | * the tl;dr is that almost every generation of card requires binaries that target it specifically. binaries can't be used on cards that don't match. there are pre-binary forms which can be JITed into binaries in most circumstances, but performance can suffer. distributors usually compile all binaries possible, but for the user who wants it to work on just their card and has to compile from source, which is everybody for nixpkgs cuda stuff, not doing that can save literal hours of compilation time | 00:47:09 |
| tpw_rules | "all binaries possible" also depends on the cuda library version and specific package capabilities | 00:47:46 |
| Samuel Ainsworth | IIUC the tradeoff here is between user compile times and the size of cached builds, ie. not every user needs every arch but we support more than one so that users don't have to rebuild locally | 00:47:57 |
| tpw_rules | i wonder what percentage of nixpkgs cuda users use cached builds. i think it's very low | 00:48:29 |
| Samuel Ainsworth | there's no established guidelines for this atm, packages set their own cuda arch's independently | 00:48:39 |
| tpw_rules | maybe i am wrong | 00:48:41 |
