05:44eric_engestrom: dcbaker: no need to split things out, I'll merge !37490 today, unless I misunderstood something (see the reply to your comment I just posted)
07:05mareko: simon-perretta-img: yes
07:49simon-perretta-img: marko: Ty, opened !37540
07:49simon-perretta-img: *mareko
07:57glehmann: why does pco use io variables?
07:57glehmann: usually backends want lowered io
08:35simon-perretta-img: glehmann: It does use lowered io, the vars just happened to be a convenient interface to {re,ab,}use to feedback the io info to the driver
08:36simon-perretta-img: I do have plans to change it, but it's a very early design decision from before I was super familiar with how other vendors handled it, that ended up sticking around longer than expected
10:20mareko: no driver is fully using lowered IO, the minimum possible amount of unlowered IO is used by radeonsi+glsl, one NIR lowering pass is missing to stop using nir_lower_io_vars_to_temporaries
10:54glehmann: what do you mean? I guess most drivers do some optimizations on io variables, but after they are lowered I don't think radv interacts with them at all?
10:55glehmann: things like flat/pre primitive masks are gathered from io intrinsics, not variables
11:12mareko: radv uses these, but glsl doesn't: nir_compact_varyings, nir_remove_unused_varyings, nir_link_xfb_varyings, nir_link_opt_varyings, nir_lower_io_vars_to_temporaries (glsl only uses this for outputs, and that will be removed next)
11:19mareko: optimizations on IO vars are redundant; NIR can only lower these in the IO variable representation: indirect outputs, outputs reads, and moving output stores to the end (e.g. out of control flow)
11:20mareko: once NIR can lower those in the lowered IO representation, we can stop using nir_lower_io_vars_to_temporaries and the subsequent cleanup passes
11:21mareko: shaders will compile faster as a result
12:32Venemo: mareko, glehmann: I have a MR for that, but the main issue is that we get stats regressions by removing the old linking passes. last I checked the blocker was that one of the new passes requires all lowered outputs to be scalarized, but then the revectorization pass couldn't handle "holes" so it was overall a stats regression. I plan to revisit that soonish, but I have my hands full with other stuff at the moment
12:42crowen: Hello! I am running into a mesa git build problem that appears on x86_64 on fedora 42 and 43 since very recently.
12:42crowen: https://download.copr.fedorainfracloud.org/results/che/mesa/fedora-43-x86_64/09597134-mesa/builder-live.log.gz
12:45MrCooper: crowen: "404 Not Found"
12:45crowen: wait i will actually put it on a pastebin :)
12:46crowen: MrCooper, https://paste.centos.org/view/10cce007
12:47crowen: I guess pco/pco_common.h is generated by the python script
13:06simon-perretta-img: crowen: I can take a look, probably missed a dependency somewhere oops
13:06crowen: simon-perretta-img, thank you so much! really appreciate it!
13:06crowen: simon-perretta-img, on i686 the build worked if that helps eventually
13:18mareko: Venemo: if that was just more TCS stores, then that's changed since TCS stores now always execute vec4 stores
13:19Venemo: mareko: I don't recall the details anymore, but I'll get back to you when I managed to revisit it
13:21mareko: all other shaders use either single-dword memory stores or LDS where holes in outputs don't matter
13:32simon-perretta-img: crowen: no worries! Would you be able to apply and test a patch? https://paste.centos.org/view/dc1ba29b
13:33crowen: sure
13:33crowen: let me do a test build
13:35crowen: simon-perretta-img, please bear with me... build will take ~30 mins
13:35simon-perretta-img: Sure thing
14:06crowen: simon-perretta-img, aarch64 succeeded now... failed before aswell
14:30crowen: simon-perretta-img, fedora 41/42/43 on i686/aarch64/x86_64 build successfully with the patch and git master branch
14:30crowen: simon-perretta-img, thank you so much!
14:32simon-perretta-img: crowen: Awesome, thank _you_ for reporting and testing!
14:32crowen: simon-perretta-img, thank you for fixing things so fast!
14:33crowen: simon-perretta-img, really appreciated!
14:59dcbaker: eric_engestrom: thanks!
15:35alyssa: eric_engestrom: it would be great if the meson missingdep check ran automatically as part of builds
15:35alyssa: so we catch issues locally on dev machines before CI ever sees them (and fails a pipeline over)
15:36alyssa: but maybe that's not possible due to meson architecture?
15:36alyssa: dcbaker: ^
15:37dcbaker: I've been thinking about adding a depcheck to the meson test automatically as part of Meson itself...
15:39alyssa: would be cool :]
15:50eric_engestrom: :)
15:50eric_engestrom: (agreed with everything)
18:12Venemo: mareko: as far as I remember the issue was with VS inputs, but I'd have to look again to be sure