03:33 alyssa: zmike: ngl ending an iris bug report with "Works fine on zink" is a flex :P
03:54 HdkR: 4
04:39 Sachiel: 8
08:00 gawin: have there been changes to zstd handling recently? 32bit build seems busted on arch
08:02 gawin: fails at /usr/sbin/ld: cannot find /usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../../lib32/libzstd.so: No such file or directory
08:04 gawin: (it was working for me a week ago with outdated tree)
08:08 linkmauve: gawin, dumb question, but do you have lib32-zstd installed?
08:08 gawin: I do
08:09 linkmauve: gawin, do you perhaps mean /usr/lib/gcc/x86_64-pc-linux-gnu/12.2.1/../../../../lib32/libzstd.so ?
08:14 zzag: do you need special permissions to allocate buffers when using a render node provided by vgem?
08:15 zzag: I get "KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied" when trying to allocate buffers using gbm
08:17 gawin: yeah, seems missing, maybe it's on gcc's side. I don't see updating any libzstd package in logs recently and was using this recently.
08:17 MrCooper: gawin: if this is about Mesa (or another project using meson), maybe try something like 'meson configure --clearcache <build directory> || meson setup <build directory> --reconfigure || meson setup <build directory> --wipe'
08:17 linkmauve: gawin, sounds like the build system didn’t get updated after an update of your system, try wiping— yeah what MrCooper is saying.
08:17 MrCooper: zzag: dumb BOs being a KMS thing, I wouldn't expect render nodes to support them
08:19 emersion: zzag: you need primary nodes
08:20 zzag: yeah, it seems to work
08:20 zzag: but that's not exactly what I want
08:21 zzag: I'd like to have some way to allocate buffers where I can render to
08:22 emersion: dumb buffers are for software rendering only
08:22 gawin: seems going, thanks, meson lesson learned: slapping --reconfigure can be not enough.
08:30 zzag: emersion: How does mesa handle such things? Does it open the primary node? I'd like to run some tests that need OpenGL on a machine without physical GPUs, so software rendering seems the only viable option..
08:38 zzag: oh, given surfaceless_probe_device(), it appears like mesa searches for DRM_NODE_PRIMARY when using software rendering
14:11 mairacanal: danvet, i was thinking on applying https://lore.kernel.org/dri-devel/20230412142923.136707-1-mcanal@igalia.com/, that concerns checking for valid formats on fb_create. would you mind take a look at it before i apply it?
14:17 danvet: mairacanal, tbh I'd include the entire explainer with all the links in the commit message
14:19 danvet: also maybe explain a bit more what the i915 issue is: in the legacy case (where we don't get the modifier from userspace) the i915 fb_create hook computes the right modifier, which isn't necessarily linear, and so if we check before that point we might get wrong answers
14:19 danvet: with that a-b: me
14:21 mairacanal: thanks! i'll improve the commit message
14:54 gfxstrand: jenatali: At this point, I'm fine with abandoning it.
14:54 gfxstrand: jenatali: At one point, there was some notion that it might become a proper layer. At this point, I no longer think that will ever happen. Embrace the runtime.
14:58 jenatali: gfxstrand: Ok cool. I've kept the headers clean for now but have been more cavalier accepting implementation details
14:58 jenatali: This series is getting... large, for a very minor payoff at the end
15:07 DemiMarie: How does OpenCL 2.0 compare to Vulkan compute?
15:10 danvet: tzimmermann, on the defio overflow, I just replied that we could just put a WARN_ON(total_size > helper->fb-height * helper->fb->pitches[0]); in the damage calc path
15:10 danvet: just to make sure we don't miss this crucial connection again
15:10 danvet: thoughts?
15:10 tzimmermann: makes sense
15:10 danvet: but I also don't want to really bikeshed this any further, imo also fine to merge what'ver you're happy with as-is
15:11 danvet: feel a bit sorry for dragging sui around so much :-/
15:11 tzimmermann: let's add the WARN_ON and get it merged
15:11 danvet: tzimmermann, either way, can you pls reply to sui and ack the change to so it's clear?
15:11 danvet: ack
15:15 gfxstrand: jenatali: :'(
15:16 tzimmermann: ok
15:17 jenatali: gfxstrand: Hopefully I'll have it done enough for a (draft) MR today, so you can see what I'm thinking and let me know if I went overboard
15:22 gfxstrand: Ok
15:22 gfxstrand: sounds good
15:59 zmike: eric_engestrom: is there syntax yet for the picker script to do version-specific backports
15:59 zmike: I have a lot of patches that should only be backported to 23.1
16:42 eric_engestrom: zmike: `Cc: 23.1 <mesa-stable>` (see https://docs.mesa3d.org/submittingpatches#the-stable-tag)
16:43 zmike: oh it finally got added
16:43 zmike: nice
16:43 eric_engestrom: that one has always been there
16:43 zmike: always feels a bit strong
16:44 eric_engestrom: but with dcbaker we had two ideas of how to make a "backport to release branch X.Y" tag; we should get back to that and land something that's more intuitive than the `cc:` syntax
16:45 eric_engestrom: zmike: by "always" I mean that it predates our use of gitlab, which feels like it's been forever by now :)
16:45 dcbaker: eric_engestrom: At this point I don't remember what the two suggestions were and I don't really care, because the CC: syntax is bad
16:45 dcbaker: if you want I can implement the Stable: X.Y tag
16:45 zmike: maybe that's what I was 🤔 of
16:45 dcbaker: or I'll review something from you
16:45 eric_engestrom: this tag was how we nominated things back in the "emailing patchings to a mailing-list" days
16:46 dcbaker: I do have some changes I need to send out for the pick script anyway
16:47 eric_engestrom: dcbaker: agreed; iirc the two of us each had an MR with a suggestion, but I don't remember more, and I think we should just land whatever looks like it won't be too much of a hassle to update later, but it's not like this process changes often so it probably doesn't matter really
16:48 eric_engestrom: (don't have time to look at this today though)
16:49 dcbaker: I think I closed mine and yours is opened still and I was supposed to review it :/
16:49 dcbaker: let me go do that right now
16:51 dcbaker: eric_engestrom: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13664 looks good to me, but there's a fixup! commit in there that needs to be squashed. With that squash done I'd be happy to send that to marge
17:04 jenatali: gfxstrand: 43 files changed, 970 insertions(+), 549 deletions(-)
17:04 jenatali: Not convinced yet that it's worth it :)
17:14 eric_engestrom: dcbaker: ah right, it was the question of whether we want to allow multiple lines `Backport-to: 23.0` + `Backport-to: 23.1` vs combining them into a single line `Backport-to: 23.0 23.1`; I still prefer the former, but I'll see if we can support both or if that doubles the code
17:14 eric_engestrom: anyway, definitely not for today :)
17:14 dcbaker: Sounds fair ;)
17:15 dcbaker: err s/;)/:)s
17:15 dcbaker: I prefer the two on one line, since that makes fewer lines of metadata in the commit message, but at this point getting rid of CC is my main request :)
17:53 anholt: anyone for acking my nerf of yamllint? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22562
18:01 jenatali: anholt: ack
18:01 jenatali: I might've gone for like 300 or 500 but eh that seems fine
18:01 anholt: I didn't see a "disable" value
18:01 anholt: which is what I really wanted
18:02 anholt:assigns to marge, hopes we can at least close the lid on the ci dumpster fire we've had this week.
18:04 jenatali: 👍
18:04 jenatali: Thanks for all the hard work!
18:11 daniels: ++
18:24 gfxstrand: jenatali: Ugh.
18:25 jenatali: Yeah
18:25 jenatali: A few more build errors in things that don't build on Windows that I need to fix and I'll post a MR
18:28 gfxstrand: kk
18:51 jenatali: gfxstrand: Posted
18:51 jenatali: !22584
19:07 karolherbst: is there a way to get the power consumption of AMD GPUs?
19:11 karolherbst: ahh sensors reports it