| 28 Sep 2025 |
 Lun | pkgsRocm is an entire nixpkgs | 15:03:54 |
 Vladimír Čunát | OK, I assumed this pkgsRocm would be just the diff mentioned in
that list is too expensive to generate on every eval, but that is also not really required, it can gradually be adapted to what is needed
Because we don't want huge amount of duplicate jobs on Hydra (even if the hashes are the same in them).
| 15:05:29 |
| Vladimír Čunát | * OK, I assumed this pkgsRocm would be just that diff mentioned in
that list is too expensive to generate on every eval, but that is also not really required, it can gradually be adapted to what is needed
Because we don't want huge amount of duplicate jobs on Hydra (even if the hashes are the same in them).
| 15:05:41 |
| Vladimír Čunát | 🤔 anyway, that was just a quick thought. Maybe someone will have a better suggestion. | 15:06:51 |
 hexa | recursing into pkgsRocm would duplicate eval time | 15:07:42 |
| hexa | * recursing into pkgsRocm would double eval time | 15:08:04 |
| Vladimír Čunát | I suspect we did have a tool for evaluating just a particular subset of attributes, but I'm not sure about efficiency. | 15:08:22 |
| Vladimír Čunát | Essentially, I meant to take whatever you propose for a separate jobset and plug it in. The cost shouldn't differ significantly. | 15:09:16 |
 7c6f434c | Ask ROCm-interested people to maintain release-rocm.nix with things they care about (which can be sometimes linted locally, but no need to check completeness on every eval), then import it in the main release? | 15:12:56 |
| Lun | If I import release-rocm's jobs into release do I need to make sure all the names end up unique or it'll break? So if release-rocm.nix is making an "openmpi" job that needs to be something else to be valid to add in release.nix and not conflict with the default openmpi | 15:29:48 |
| Lun | https://github.com/LunNova/nixpkgs/blob/push-kuknstozqsvo/pkgs/top-level/release-rocm.nix is what I have as an attempt at a release-rocm.nix but I'm not clear on what importing it in the main release properly would look like | 15:42:20 |
| Vladimír Čunát | I thought we'd nest it all under some name like rocmPackages to avoid name collisions. | 15:48:48 |
| Vladimír Čunát | * I thought we'd nest it all under some name like pkgsRocm to avoid name collisions. | 15:49:45 |
| Vladimír Čunát | pkgsRocm exists but doesn't generate jobs on Hydra. So ideally we'd reuse the attribute paths to reduce confusion? (but only put the chosen packages into it and not everything) | 15:52:43 |
 SomeoneSerge (back on matrix) | Was the separate-jobset option already dismissed? | 16:59:25 |
| Vladimír Čunát | I'm not against a separate jobset. But I haven't heard any advantage to gain from the separation. | 17:09:41 |
| Vladimír Čunát | * I'm not against a separate jobset. But so far I haven't heard any advantage to gain from the separation. | 17:09:47 |
| hexa | it was just what I was used to from the cuda jobsets on nix-community | 17:14:32 |
| hexa | and recursing into pkgsRocm was a non-starter | 17:14:39 |
| hexa | but importing it into the existing jobset is absolutely fine with me | 17:15:21 |
| Lun | Is there a point in still having a separate release-rocm.nix then? I could put the generated list of different-for-rocm packages somewhere in rocm-modules and have release.nix's pull those in under packageJobs without needing a new top level release- file | 18:00:15 |
| Lun | * Is there a point in still having a separate release-rocm.nix then? I could put the generated list of different-for-rocm packages somewhere in rocm-modules and have release.nix pull those in under packageJobs without needing a new top level release- file | 18:00:49 |
| Vladimír Čunát | Whatever the way, I assume that we want to filter the jobs for x86_64-linux only, so the approach should support that somehow. (Because other platforms are rarely combined with HW where rocm makes sense?) | 18:17:27 |
 K900 | Technically you can have an AMD GPU in an ARM server | 18:20:53 |
| hexa | rocm clang is x86-64-linux only right now | 18:21:08 |
| Lun | yeah I'd like to get the package set working for aarch64 at some point but I don't have the builders for anything but x86_64 and nobody who does has been trying to use it. one laptop with 16gb of RAM does not build a rocmPackages.
jobs will be x86_64-linux only for now | 18:22:44 |
| hexa | https://nix-community.org/community-builders/ | 18:23:28 |
| Lun | How powerful are the aarch64 boxes there? | 18:23:45 |
| hexa | q80-30, 128G memory, 128G swap | 18:24:21 |
| Lun | maybe that's viable after 7.x when we manage to drop a bunch of CK… | 18:24:44 |
