01:39mareko: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23221 is assigned to Marge, I *think* the last commit isn't needed in stable
01:42mareko: the last commit should be fine in stable if it doesn't break the build
01:50DavidHeidelberg[m]: zmike: zink started brutally failing recently on Debian 12 https://gitlab.freedesktop.org/mesa/mesa/-/jobs/42407683 not a flake
01:51DavidHeidelberg[m]: something must got broken in today MRs
01:51DavidHeidelberg[m]: (I guess, I hope I didn't introduce accidentally some fckup, but I don't expect to)
01:51zmike: uhhhhhhhh
01:52zmike: not sure what to do about that
01:54zmike: I guess it could be from merging https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22378
02:09DavidHeidelberg[m]: zmike: I'll try to revert tomorrow and see . thanks
07:21MrCooper: mlankhorst: the diffstat in the drm-intel-fixes PR is 1 MB of mostly noise; if there's no way to get a more useful diffstat, might be better to just leave it out?
08:54jani: MrCooper: mlankhorst: there was already the question of how it was generated; doesn't seem done with dim. so maybe it's a question of the upstream used for generating the pull request?
09:19dolphin: MrCooper, jani: are we talking about drm-intel-fixes, my last PR seems fine?
09:19dolphin: or did you mean drm-misc-fixes?
09:20MrCooper: maybe, apparently the subject was wrong as well
09:21MrCooper: the PR in question is still in the dri-devel moderation queue due to the above issue
09:28jani: oh wow
09:29jani: dolphin: you don't seem to be in Cc. it's drm-misc-fixes with drm-intel-fixes subject. rodrigovivi replied to it, but looks like that's also in the moderation queue due to size
09:34MrCooper: yeah I rejected that, since it's 1 MB of quoted text, which was mostly noise in the first place :)
09:35MrCooper: moral of the story: trim quoted text
09:45jani: moral of the story: use the provided tooling for making pull requests ;D
10:37DavidHeidelberg[m]: zmike: first data suggest that you guessed the offending MR
10:43DavidHeidelberg[m]: zmike: verified, I propose to revert the MR and uprev CI and then wait until it pass, see https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22378#note_1926396
11:40zmike: DavidHeidelberg[m]: can you try adding asan to that job first so we can get an idea what's crashing?
11:42DavidHeidelberg[m]: Sure
11:43zmike: it's baffling that all this stuff gets hit on ci but nobody can repro locally
11:47pq: Isn't that what CI is for, finding problems no-one else does? :-)
12:27cwabbott: gfxstrand: seems like VK_EXT_attachment_feedback_loop_dynamic_state is breaking some pretty fundamental assumptions in vk_graphics_state
12:28cwabbott: the state is part of vk_render_pass_state in the pipeline state but it's only part of the fragment output interface
12:30DavidHeidelberg[m]: zmike: https://gitlab.freedesktop.org/okias/mesa/-/jobs/42440333 is it useful to you?
12:30zmike: ughhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
12:30cwabbott: just adding MESA_VK_DYNAMIC_ATTACHMENT_FEEDBACK_LOOP_ENABLE to MESA_VK_GRAPHICS_STATE_RENDER_PASS_BIT doesn't work because RENDER_PASS_BIT is "needed" by other stages
12:31cwabbott: so it won't get filtered out of e.g. pre-rasterization dynamic states
12:33zmike: DavidHeidelberg[m]: can you try pumping VVL to the commit hash of main on your branch
12:33zmike: there will be a new tag in a day or two but this should be an easy test to see if it's fixed
12:34DavidHeidelberg[m]: zmike: VVL?
12:34zmike: DavidHeidelberg[m]: https://gitlab.freedesktop.org/zmike/mesa/-/snippets/7633 I think should do it
12:35zmike: basically you're hitting a VVL bug that somehow is only triggering on your branch
12:35zmike: so the options are either disable VVL or try to uprev
12:37DavidHeidelberg[m]: zmike: testing uprev :)
12:47cwabbott: gfxstrand: but adding a whole new state group would seem to require adding a new struct that gets allocated etc. which seems bad for just one small field
12:56dolphin: airlied, sima: "Would the real drm-intel-fixes please stand up", the PR has been sent with just 1 line shortlog so should be easy tell from the other :)
12:59sima: dolphin, I think I'm missing some context, was this about a ping from airlied?
13:05alyssa: nir_lower_shader_calls is ??????
13:05dolphin: sima: I think mlankhorst accidentally sent drm-misc-fixes as "drm-intel-fixes" titled PR
13:05dolphin: if you scroll up to what jani said
13:06dolphin: generating a 1 MiB log
13:06sima: dolphin, oh lol
13:53kusma: CI appreciation day again! I sent an MR that touched a file in Zink, and I got a grand total of zero needless jobs triggered! Great work everyone!
13:56ccr: :O
13:59ccr:suddenly starts singing "every CI node is sacred, every CI node is great / if a CI job is wasted, admins get quite irate"
14:05DavidHeidelberg[m]: zmike: new version helped, pushing, thanks!
14:09alyssa: kusma: :-D
14:12DavidHeidelberg[m]: kusma: don't worry, just merging Debian 12 CI uprev, it'll change.....
14:19DavidHeidelberg[m]:obviously kidding... or not.
14:43kode54: cleaning up my mail accounts
14:43kode54: I've been listening to a bunch of mailing lists and just skipping inbox and sending them to folders
14:43kode54: marking 400k unread messages as read...
14:43kode54: then I need to amend my filters to mark as read as well
14:43karolherbst: the only way of dealing with mailing lists
14:44DavidHeidelberg[m]: please do not assign to Marge in next ~ 30 minutes, I'll need to re-assign Marge for the CI upgrade (rootfs rebuild takes too long and it wasn't pre-prepared)
14:44kode54: ouch, good luck
14:44karolherbst: kode54: there is a little trick I'm doing to handle that nonsense: just push them all into mailing lists folders _unless_ you are on Cc or To, then they can into your inbox
14:45kode54: I wish I could do that to gmail filters
14:45karolherbst: you can
14:45kode54: oh wait, I can
14:45karolherbst: I have a "To Me" label in gmail where all mails go which are directly addressing me
14:47gfxstrand: cwabbott: Hrm...
15:05doras: karolherbst: I'm trying to package Rusticl without much experience with OpenCL runtimes. I found that compiler/clc requires a few Clang headers at runtime. For example, `opencl-c-base.h` and a few others: https://gitlab.freedesktop.org/mesa/mesa/-/blob/394d592525c2ca80f428355bf8595ae33ed0b93d/src/compiler/clc/clc_helpers.cpp#L869
15:06karolherbst: correct. Those will be provided by clang
15:06doras: Since I'd rather avoid packaging unnecessary files as runtime-dependencies, do you know if there's a rule of thumb of exactly which files are needed at runtime?
15:07karolherbst: all headers clang ships
15:08doras: karolherbst: no Clang executables or something surprising like this, right?
15:09karolherbst: right, we only use libclang
15:09karolherbst: but it has to come with all the header files
15:10doras: Right. Thanks for the help, I hope this is the last obstacle.
15:13karolherbst: I think in general it is potentially fine to just ship the opencl-c-base.h header, but I'd rather not trying to be smart and just ship them all and have it be part of libclang packaging or something.. dunno
15:22kode54: whee
15:22kode54: fastmail is useless at filtering that way
15:23kode54: it doesn't provide a way to separately match to, cc, or bcc
15:23cwabbott: gfxstrand: any suggestions?
15:23jenatali: karolherbst: I still think it'd be useful to provide an option for someone to statically link opencl-c-base.h for running on systems without full Clang installed
15:24kode54: um, how does one statically link a header file?
15:24jenatali: Turn it into a byte array
15:25jenatali: We do it for the code we ship on Windows
15:25kode54: huh
15:25jenatali: Much easier than shipping it as a separate file and trying to find that file on disk
15:29jenatali: alyssa: Would you be able to take a closer look at the nir patches in !23173?
15:32kode54: is there a halfway decent mail client to use offline?
15:33kode54: thunderbird is just chugging away spinning a core almost completely just tracking my immense archives folders
15:33DavidHeidelberg[m]: Merged. It was stable before, hopefully it'll stay that way.
15:33gfxstrand: cwabbott: My first thought is that having a dynamic state part of the framebuffer shouldn't be a problem.
15:34gfxstrand: s/framebuffer/render pass/
15:34gfxstrand: cwabbott: But render pass state is weird because it's all broken into bits.
15:34cwabbott: yeah, it's the "broken into bits" part that makes this painful
15:35gfxstrand: cwabbott: So is the concern where to put it in the vk_dynamic_graphics_state struct? Or how to handle it at the pipeline level?
15:35cwabbott: gfxstrand: the pipeline level
15:38gfxstrand: cwabbott: We already have the filtering for those two bits to only populate them as part of the fragment output interface. Or did I flub that somehow?
15:38cwabbott: gfxstrand: yeah, we handle the bits
15:39cwabbott: it's handling the dynamic state flag that's the problem
15:40gfxstrand: Why? That should really get handled in vk_dynamic_graphics_state_fill and that should be able to pull any state from anywhere.
15:40cwabbott: we need to make sure to ignore VK_DYNAMIC_STATE_ATTACHMENT_FEEDBACK_LOOP_ENABLE_EXT for stages except fragment output interface, because on the Vulkan level that's where it is
15:40cwabbott: that won't work if we make it part of MESA_VK_GRAPHICS_STATE_RENDER_PASS_BIT
15:41cwabbott: because that's considered needed by the last 3 stages
15:42gfxstrand: Oh, I see
15:42gfxstrand: It's get_dynamic_state_groups that doesn't really make sense.
15:42gfxstrand: Yeah, that's problematic. :-/
15:42cwabbott: exactly :-/
15:42cwabbott: that's where I kind-of got stuck
15:44cwabbott: one thing I was thinking about was passing VkGraphicsPipelineLibraryFlagsEXT to get_dynamic_state_groups
15:44cwabbott: but it seems like the design so far intentionally avoided passing that around
15:44cwabbott: so, I wanted to know how much you hated that
15:45gfxstrand: Yeah...
15:45gfxstrand: Okay, I see the problem.
15:45gfxstrand: It's all such a mess.
15:45cwabbott: yup
15:45gfxstrand: GPL sucks
15:46gfxstrand: I think we can just special-case the filtering.
15:46gfxstrand: Do get_dynamic_state_groups to get dynamic_filter and then do
15:46cwabbott: it's also not great that there are now like 3.5 ways to signal you have a feedback loop
15:46gfxstrand: if (!(lib & FRAGMENT_OUT)) dynamic_filter &= ~FEEDBACK_LOOP
15:47gfxstrand: With a comment about how annoying this all is
15:47gfxstrand: cwabbott: Yeah, that's really not great. Stuffing it in a flag was maybe not optimal.
15:47cwabbott: gfxstrand: I'm not 100% sure but wouldn't that barf in validation?
15:49gfxstrand: I don't think so.
15:49kode54: gee
15:49kode54: someone already doubting the importance of filtering the uAPI changes downstream
15:49kode54: I guess they didn't know there is 32-bit multilib downstream
15:49kode54: let's just fix that in the kernel instead
15:50gfxstrand: All it's doing is effectively discarding VK_DYNAMIC_STATE_ATTACHMENT_FEEDBACK_LOOP_ENABLE whenever you aren't including fragment output, which seems like exactly what we want.
15:50gfxstrand: That should default it to included which should be safe.
15:50gfxstrand: To be clear, that special case around filtering assumes that feedback loop is included in render pass state for all other purposes.
15:54cwabbott: gfxstrand: the other issue is that this doesn't interact that well with my feedback_loop_input_only thing
15:56cwabbott: first off, feedback loops from the render pass (real or emulated) are independent of the dynamically-enabled feedback loops, so we have to combine them at draw time
15:58cwabbott: so, the question is, do we merge feedback loops via the pipeline flags with renderpass ones (as we do now) or do we keep them separate and set the dynamic state with them
15:59MrCooper: DavidHeidelberg[m]: congrats on and thanks for bumping the CI to Debian bookworm!
16:00cwabbott: I'm doing the first thing, and just setting the dynamic feedback state to 0 when it's statically set
16:01cwabbott: that keeps existing drivers (anv) the same but leads to some weird code where we always set the dynamic state to 0 in the pipeline
16:07gfxstrand: cwabbott: Yeah... That's a bit weird.
16:08gfxstrand: cwabbott: I'm inclined to say that we should just have 4 logically independent bits: two for textures and two for input attachments.
16:08gfxstrand: We can patch ANV and RADV to deal with both.
16:09cwabbott: actually now that I think about it we don't *have* to have separate bits for texture vs. input attachment feedback loop
16:10cwabbott: that might help
16:12cwabbott: and, of course, input vs. texture is slightly different from renderpass vs. pipeline flags because the renderpass could be an emulated mesa one that uses textures, but unlike the pipeline flags it can be set independently from the dynamic bits
16:12cwabbott: *sigh*
16:14cwabbott: I think if we tried to separate input vs. texture in the pipeline state, then we'd have 3 different feedback loop flags: texture on the pipeline, input attachment on the pipeline, dynamic texture
16:14cwabbott: and all 3 would need to be or'd together
16:16cwabbott: yeah, not sure that would be any better
16:32gfxstrand: If you think you can do it with 1, I guess that's okay.
16:33gfxstrand: My thought about render pass emulation is that, if we ever do actual input attachments from emulated render passes, we'd set the input attachment flags for those.
16:33gfxstrand: Whatever that looks like.
16:38DemiMarie: kode54: not much?
16:39kode54: ?
16:44DemiMarie: https://wiki.archlinux.org/title/Notmuch
16:44DemiMarie: https://notmuchmail.org/
16:45mattst88: kode54: wrt gmail filtering, karolherbst is right -- you basically have to skip the inbox on things that aren't To: or Cc: you
16:46mattst88: https://github.com/mattst88/gmail-gitlab-filtering in "The Problem" section has a bit about doing this. it's pretty easy
16:46mattst88: the way this screws things up is, you basically never see emails that are bcc'd to you
16:47mattst88: I occasionally have to search my gmail for 'is:unread has:nouserlabels' to find those
16:57kode54: I'm attempting to set up notmuch with offlineimap
17:28dcbaker: kode54: I had better luck with isync than with offlineimap, YMMV though
17:28kode54: ah
17:29dcbaker: but I gave up (and quit developing alot) after mesa switched to gitlab
18:43DemiMarie: dcbaker: why?
18:44dcbaker: Because mesa was the last project I worked on that still used a mailing list, outside of that the amount of email I get is so small it wasn't worth the effort
20:08doras: jenatali: it's possibly more convenient for my use case to have the Clang headers embedded. I'll check if it works.
20:10jenatali: Dor Askayo: Right now the header is embedded if the microsoft-clc project is included in the build. It really should be split into a separate build option
20:11doras: jenatali: I can open a MR if it ends up working fine for me.
20:11jenatali: Cool, sounds good
23:06q66: any hints what to attempt if i get graphical corruption like this? https://matrix.org/_matrix/media/v3/download/matrix.org/UHnidhnXhJsiAHfXWiAxyHeK/IMG_1850.jpeg
23:07q66: it's gnome-shell, wayland, on ampere altra aarch64, mesa 23.1.0, clang, musl, amdgpu (radeonsi); tested radeon rx 5500xt (navi) and radeon pro wx2100 (polaris) with identical results
23:07q66: the corruption appears to be application-side as forcing LIBGL_ALWAYS_SOFTWARE=1 makes it go away
23:07q66: and the corruption scrolls with the content in firefox which also indicates it's application-side
23:07q66: but not quite sure where to start looking
23:08q66: tried setting various radeonsi-related env vars without much success
23:09q66: i originally thought it was kernel, because getting the rx5500xt working on the altra was quite an ordeal (by default it panics the kernel, you gotta disable a bunch of stuff) and then there were still some scary messages in dmesg, but now the output is clean and needs no workarounds, yet i still get graphics corruption on a completely different gpu, so i suspect mesa now :)
23:10q66: also using zink for firefox also fixes the corruption in firefox, but if i run gnome-shell with it or certain other apps that are affected, the whole screen gets corrupted :)