01:03 karolherbst: Could somebody look into why the zink-tu-a618-traces-performance and a618-traces-performance jobs are taking so long to execute? We had multiple pipelines running for 1.5 hours today and those jobs seem to run for 50 minutes alone, e.g. https://gitlab.freedesktop.org/mesa/mesa/-/jobs/106787998 or
01:03 karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/106788000
01:04 karolherbst: seems to have been a pattern for at least today
05:40 anholt: karolherbst: that job log clearly shows 49 minutes of waiting for hardware to become available. So the runners were just overloaded.
08:51 glehmann: man the nir_instr_set abstraction reallly gets in the way of adding subgroup support to nir_opt_cse
10:19 Ristovski: hakzsam (and perhaps et al): what exactly is missing in addrlib for gfx9 for host_image_copy?
10:20 hakzsam: it's missing everything but AMD provided an implementation here https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42475
10:20 Ristovski: oh, how the hell did I miss that >_> thanks!
10:27 Ristovski: huh so your question whether it came from the internal addrlib repo never got answered
11:26 karolherbst: anholt: mhh I guess might want to consider having more runner for jobs if that pattern remains for a longer period. Not sure we are bottlenecked on the pipelines yet, but it kinda feels like we are getting close to that
13:33 MrCooper: Venemo: FYI, https://bugzilla.redhat.com/show_bug.cgi?id=2510053#c12 looks like fallout from enabling amdgpu by default for SI
13:37 Venemo: MrCooper: thanks for the link, I'll look into it
13:37 Venemo: unfortunately there have been a lot of regressions lately
13:38 Venemo: (eg. on current amd-staging-drm-next, all Vega and older GPUs just crash on boot. that is not related to the issue you linked though)
15:23 valentine: karolherbst, anholt: the traces-performance jobs are post-merge, they run on a specific device for performance tracing, which is why they had to wait longer to get that one available
15:24 valentine: but they only run after Marge finishes, and that's not why that MR timed out
15:24 valentine: the containers had to be rebuilt, which takes a while and delays starting the pre-merge test jobs
15:25 karolherbst: valentine: ahh.. okay, so unrelated to things taking real long to get marged
15:25 valentine: I triggered the container rebuild manually on your MR now, so Marge won't have to do it when she gets to it next time
15:25 valentine: yup
15:26 karolherbst: though but ~48 MRs a day should be enough, but I'm wondering if we have monitoring on how close we are at being bottlenecked by CI
15:28 valentine: https://ci-stats-grafana.freedesktop.org/d/n7guL8ySz/from-marge-to-merge
15:29 valentine: yeah, we've had some pretty long queues recently
15:35 karolherbst: that's a great dashboard
15:36 karolherbst: so it's not just a feeling we really hit 9 hours from assign to marge..
17:33 glehmann: oh wtf, I get -Woverflow for a uint16_t assignment in nir_opt_algebraic.c after adding some more patterns
17:44 karolherbst: probably because the original int was promoted to 32 int32_t
17:45 karolherbst: like C is weird, but the expression will be done in 32 bits and then reduced to 16 bit again, so you might have an overflow there?
17:45 karolherbst: or uhm...
17:45 karolherbst: do we have that many patterns?
17:50 Sachiel: that's a lot of patterns
18:48 austriancoder: 7:00 CEST is the best time to assign MRs to marge :)
18:48 HdkR: Make sure to assign as many as possible on release day as well.
20:58 dviola: zmike: hi, I was wondering if this will also help zink: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/43463
21:06 zmike: I would assume if it helps one driver it would help all of them
21:56 dviola: zmike: cool