00:00 anholt: daniels: huh?
00:04 daniels: anholt: why would it be better for deqp-runner to emit flakes.txt and failures.txt etc rather than differences-from-expectations.(csv|json)?
05:30 MoeIcenowy: daniels: Thomas Zimmermann says he will merge PATCH 1~5 of https://lore.kernel.org/dri-devel/20260129023922.1527729-1-zhengxingda@iscas.ac.cn/ , but he haven't appeared since I sent v7 to address the small things he raised in v6; well... could you help here?
05:31 MoeIcenowy: well I seems to asked for a wrong person... I don't know why I have the impression that daniels is responsible for drm-misc... sorry
05:31 MoeIcenowy: mripard: ^ could you look at this?
08:34 MrCooper: karolherbst: AFAICT it's always been GALLIUM_DRIVER=softpipe (on top of what's needed to force swrast)
10:02 lucaceresoli: Gentle ping about https://lore.kernel.org/lkml/20260128-drm-bridge-fix-imx8qxp-pixel-combiner-null-deref-v1-0-2138d0933cf1@bootlin.com/
10:02 lucaceresoli: The bug is still there, both on master and on drm-misc-next, but still not clear what's the process to apply the conflicting fix patches
10:07 lucaceresoli: Based on the docs it looks like I should apply the fix on drm-misc-next-fixes, so I plan to do that later today, but the fix for drm-misc-fixes is still not R-by/A-by so master will still be broken, this doesn't look good
10:47 zmike: glehmann: I'm fine with fc2 being a separate MR so don't consider that a blocker
10:49 glehmann: 👍
15:48 alyssa: hakzsam: fyi https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39669
15:52 hakzsam: thanks
16:21 dj-death: heh
16:21 dj-death: fun times
16:49 Lynne: is there some bottleneck when a lot of specialization constants are used?
16:49 Lynne: I tried shoving 255 8-bit ints in, and it does work, but shader init time is a lot longer
16:50 Lynne: I would think that shader caching would take care of it, but it doesn't, same constants, init time consistently as long
16:55 alyssa: Lynne: might be a bug
16:55 alyssa: have you profiled?
16:56 Lynne: profile the shader or the mesa c code?
17:00 alyssa: mesa
17:29 dcbaker: pixelcluster: I have "aco: Fix parameter stack size calculation" nominated for 25.3, but it doesn't apply, and I don't think it's actually relevant as the code it's fixing isn't in 25.3, could you confirm?
17:39 Lynne: alyssa: lavapipe spends and entire eternity and a half int JIT'd code
17:40 Lynne: and on real GPUs, hash_table_get_entry, nir_instr_insert, nir_intrinsic_instr_create, _mesa_hash_pointer, etc. all show up on perf
17:42 dcbaker: glehmann: I have "nir/opt_varyings: actually clone alu math control to different shader" nominated for 25.3, but the code that is supposed to be fixed doesn't exist in the stable branch, I don't think we need this patch, can you confirm that for me?
17:44 glehmann: dcbaker: yes, should be fine
17:44 dcbaker: glehmann: thanks!
17:57 dcbaker: hakzsam: I had to fix some conflicts with "https://gitlab.freedesktop.org/mesa/mesa/-/commit/57e9f7fb6a4bcb06f448f6a0fe1ea2452ad2e14c", could you make sure that still looks okay?
17:57 dcbaker: sghuge: Same as above for "https://gitlab.freedesktop.org/mesa/mesa/-/commit/65bdd90e973bcfe142b41b9a875a53f3855d477c"
17:58 hakzsam: dcbaker: LGTM
17:58 dcbaker: Thanks!
18:02 alyssa: Lynne: flame graph on real GPU might be interesting
18:02 alyssa: zmike: fwiw nir_opt_varyings was one of the few things that actually improved real game fps on honeykrisp
18:03 zmike: alyssa: that's my assumption as well
18:03 alyssa: not sure why exactly
18:03 zmike: I imagine it will be huge for multiview
18:03 alyssa: Instrs: 23793021 -> 22776261 (-4.27%); split: -4.41%, +0.14%
18:03 alyssa: that might've helped :p
18:09 glehmann: I suspect varying space is somewhat important for mobile too?
18:11 glehmann: reminds me that radv doesn't benefit much from the code motion at the moment, because nir_opt_varying expects variables and no lowered io there for some reason
18:13 mareko: only UBO variables are expected
18:13 dcbaker: robclark: Does https://gitlab.freedesktop.org/mesa/mesa/-/commit/99c9082035844b9f8a61b2a7014c7ce3aa4fa043 look like a reasonable backport?
18:13 mareko: though that could be changed if VK has access to the same UBOs in all shaders
18:15 dcbaker: robclark: specifically I had to change info->props to info->a6xx
18:15 mareko: inter-shader code motion always works for any expression that doesn't have UBO loads
18:15 robclark: dcbaker: this is for 25.3?
18:15 dcbaker: robclark: yes
18:16 mareko: are the same UBOs accessible from all shaders in VK?
18:16 alyssa: mareko: yes
18:16 mareko: it's easy then
18:16 alyssa: GL has descriptors per stage, VK has descriptors per set and the same N sets accessible to all shader stages
18:17 alyssa: an app /can/ burn 1 set per stage for GL style binding, but doesn't have to
18:17 robclark: dcbaker: ok.. that backport lgtm... should only matter for a702 and some of the other low tier devices
18:18 dcbaker: robclark: sweet, thanks
18:18 robclark: np, thx
18:23 dcbaker: zdobersek: https://gitlab.freedesktop.org/mesa/mesa/-/commit/1ed7de4984fb5886018dba3b3d92e6963aab6c02 is a backport of one of your patches to 25.3, I had to make some changes to get it to apply, can you double check it for me and make sure it's okay?
18:25 glehmann: alyssa: mareko: technically there are some interesting details there, like apps can emit barriers in a way that writes to the ubo only become visible for the FS and not the VS. But I think most drivers move those before the draw
18:26 glehmann: but I think getting access to the descriptor in the other stage should be easy
18:28 alyssa: glehmann: oh, that's... problematic for interstage code motion indeed
18:28 alyssa: and also tilers.
18:34 glehmann: I think for amd it would only matter if we wanted to mesh<->task code motion
18:39 mareko: how is mesh<->task different from VS<->FS? barriers shouldn't be affected by the AMD implementation
18:40 mareko: aren't UBOs always read-only in a pipeline of shaders, i.e. barries don't affect them?
18:45 mareko: if not and for SSBOs, code motion backwards should be fine as long as there is no barrier between the load in the consumer and the beginning of the consumer
18:47 mareko: also moving VS input loads to later shaders (e.g. TES) could be interesting
18:47 jenatali: Barriers indicate which stages of the pipeline should wait for writes to be made available. Only those stages technically need to wait, so a VS could execute before a barrier makes writes available to the FS. Moving the UBO read to the VS would be invalid
18:48 mareko: I see
18:49 mareko: luckily we don't have mid-pipeline sync
18:49 glehmann: mareko: I thought mesh/task might be special because there are two queue involved on amd, but maybe I'm wrong
18:50 dcbaker: pixelcluster: I have 4 patches nominated fro 25.3, none of them apply: 62254ab0be, ad23e02a28, 0d7705c206, 3275be503c. Can you either send me a backport MR for staging/25.3, or let me know if you'd rather me de-nominate them? Thanks
19:23 zdobersek: dcbaker: looks good
19:23 dcbaker: zdobersek: thx
20:19 pixelcluster: dcbaker: those should only be backported to 26.0, sorry for not specifying - i'll remember to do that next time. feel free to drop them for 25.3.x
21:22 dcbaker: pixelcluster: no worries, thanks!