00:01zmike: it can wait till next year if it needs a big refactor
08:37jsa1: jsa: tzimmermann, jani: what is eta to merge fix ? Most of the i915 and xe CI systems fail oin module load due to this regression?
08:38jsa1: I meant tzimmermann, jani: what is eta to merge fix ? Most of the i915 and xe CI systems fail oin module load due to this regression?
08:40tzimmermann: jsa1, i got a conflict from merging drm-tip. got to fix this first. someone was kind enougth to not clean up their merge conflicts
08:41tzimmermann: jsa1, and then, which fix specifically do you need to get merged?
08:42vsyrjala: the fbcon fix. but it hasn't even been tested by ci. i bounced it to intel-gfx so ci should now at least see it, but i'm unsure if such a bounced mail will pass the new ci email checks...
08:44tzimmermann: jsa1, vsyrjala, ASAP
08:46vsyrjala: for some reason i'm not getting it delivered back to me via intel-gfx, and can't see it in lore either. but i do see it in lists.fdo archives
08:52vsyrjala: the conflict seems to be due to a drm-xe-next pull into drm-next. i guess airlied/sima didn't rebuild-tip afterwards
09:12tzimmermann: vsyrjala, jsa, i went with the drm-next version. but i'm going to compile-test before merging. as you said, git took the gotos instead of the returns
09:12tzimmermann: after that, the fbcon fix can land
09:22jsa1: tzimmermann,vsyrjala: bat results https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_154881v1/index.html? Looks mostly ok.
09:23jsa1: Or better view: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_154881v1/combined-alt.html?
09:38tzimmermann: jsa1, the fbcon fix is now in drm-misc-fixes
10:42jsa1: tzimmermann: thanks.
10:50jsa1: Ci now again "clean"
10:50sima: \o/
12:53austriancoder: It would be nice if someone with st/mesa st_extension knowledge could look at the first commit of !37524
13:16idr: austriancoder: I can take a look.
13:43simon-perretta-img: mareko: A while back in !36087 you mentioned radv eventually phasing out nir_lower_io_array_vars_to_elements, and that gallium drivers used st_nir_unlower_io_to_vars; would it be reasonable to relocate that pass under nir/?
13:43simon-perretta-img: I've trialled it locally with some added options and it seems to takes care of the struct-splitting headache without too much churn, I can open a draft MR once it's been through a dEQP run
15:03austriancoder: idr: thx - now I need to find a good way to check each driver :)
15:05idr: austriancoder: I think I would just check to see if there are any that only have the packed formats or only have the s8_uint format.
17:09alyssa: dschuermann: why null device instead of relying on drm-shim?
17:10alyssa: LD_PRELOAD=/home/alyssa/mesa/build/src/amd/drm-shim/libamdgpu_noop_drm_shim.so AMDGPU_GPU_ID=NAVI10 is what i use to test aco and it works fine iirc
17:10alyssa: oh. windows. blech.
17:11alyssa:should've read the patch in full
17:44gfxstrand: Don't we have a tool somewhere for running just a SPIR-V file through the compiler?
17:47glehmann: gfxstrand: if you only care about compute https://github.com/ValveSoftware/Fossilize/blob/master/cli/fossilize_synth.cpp
18:24dcbaker: eric_engestrom: Do you want to create a new PR with the fixes from https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37490 in it and assign to Marge? I noticed Intel is about to add a dep on shader_stats.h and thought there might be a race condition, which is true, but also, you have a fix for it
18:24dcbaker: those fixes all have my r-b
18:25dcbaker: Derp, I meant to add: "or would you prefer if I made that PR"?
18:33Sachiel: I miss when marge knew how to delete merged branches
18:34zmike: amen
18:36alanc: marge still knows how, just most people haven't given marge permission to modify their fork, and gitlab took away the permission to do it without that
18:37zmike: huh
18:37zmike: how does one do that
18:37zmike: I don't think anyone ever said anything about it
18:38karolherbst: there is a flag on the MR
18:38zmike: I've been ticking that box for years and it doesn't do anything
18:39alanc: I think I saw it mentioned as an aside on #freedesktop - a recent gitlab upgrade made that flag no longer apply to delete branch, but if you go to Manage -> Members in your fork and add Marge there, she can then start doing it again
18:39pendingchaos: I think that flag broke at some point
18:39jenatali: Yeah you have to add Marge as a member of your fork
18:40zmike: as what? developer?
18:40Sachiel: ohh
18:40Sachiel: would have been good to announce that somewhere
18:41zmike: yeah for real
18:48alanc: you still need to tick the flag on your MR so marge can rebase and update the commit messages
18:57glehmann: developer works, that's what I did
19:33alyssa: people don't like my 2000 branches??
19:35alyssa: (I am.. assuming my branch count alyssa/mesa is the largest fork on fd.o. uh, oops.)
20:13Sachiel: I even went and deleted all the pre-existing mesa branches from my fork
20:31HdkR: Doing work and stress testing the system. Double win!
21:19alyssa: \o/