08:20 bbhtt: is drmModeCloseFB function here only useful for compositors https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/332 or can it get used by other userspace applications that link against libdrm?
08:22 emersion: in general, FB IDs are only useful for KMS clients
08:29 bbhtt: emersion: Ok, thanks
08:30 emersion: fwiw, xf86drmMode.h contains the KMS API, ie. should only be useful to compositors and the like
08:32 bbhtt: gstreamer uses some functions from it
08:35 emersion: that's… surprising
08:35 emersion: which functions?
08:36 bbhtt: drmModeAddFB2 in gst-plugins-bad I saw not sure if there are others
08:37 emersion: does gstreamer have a plugin which displays stuff straight to KMS
08:37 emersion: ?
08:39 bbhtt: Seems like this one https://gstreamer.freedesktop.org/documentation/kms/index.html?gi-language=c probably
08:39 bbhtt: I'm asking in the context of ABI changes though, not too sure about this stuff
08:41 bbhtt: I need to be relatively sure that mesa, gstreamer, libva - things that depend on libdrm won't use it
08:42 emersion: anything that uses KMS may use it, anything else should not
08:44 pq: gstreamer kmssink is a KMS client, yes
08:44 bbhtt: yea then I can't be sure here thanks
08:44 pq: bbhtt, what are you doing?
08:46 pq: bbhtt, I'd expect projects to declare the their minimum required library versions and check for them at build time.
08:47 bbhtt: pq: tldr is, it's shipped as part of the flatpak runtime. I froze due to ABI additions in .120 but it was later reverted with that function patched to update to mesa 24.0
08:48 bbhtt: now mutter is using it, but linking fails
08:48 bbhtt: trying to figure out a safe way to revert the patch
08:48 pq: mutter running inside flatpak?
08:49 pq: sorry, I didn't understand any of that
08:49 bbhtt: pq: gnome-build-meta uses it for their GNOME os
08:49 bbhtt: gnome-build-meta uses freedesktop sdk
08:50 bbhtt: freedesktop-sdk provides the runtimes for flatpaks and the base image for stuff like gnome os
08:50 bbhtt: libdrm comes from freedesktop sdk and goes into child sdks like gnome, kde etc.
08:51 bbhtt: pq: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/merge_requests/17210
08:51 bbhtt: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/merge_requests/17665
08:53 pq: I know nothing of these sdk things, sorry.
08:53 bbhtt: yep no worries, I figured I can't easily revert the patch and make the function public again
08:56 pq: Requiring forward ABI compatibility of libraries seems like a very tall order. libwayland does not provide that, either.
08:58 bbhtt: unfortunately we have maintain both directions because of flatpak extensions
08:58 bbhtt: only crypto libraries are allowed to break forward abi
09:05 MrCooper: bbhtt: seems like an SDK issue, not an upstream libdrm one
09:06 bbhtt: yea
10:39 Ermine: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26358 -- I guess this one will go to Mesa 25.x ?
14:11 Venemo: hi
14:11 Venemo: is there anything preventing us from removing old git tags? the context for this is: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3970#note_2329003 CC eric_engestrom
14:22 DavidHeidelberg: austriancoder: Heya, one "nightly" flake https://gitlab.freedesktop.org/blu/mesa/-/jobs/56471662 (2nd run went successfully)
14:42 eric_engestrom: Venemo: if nobody says they need them, no reason to keep them
14:43 eric_engestrom: one issue is that they might be accidentally pushed again by someone who hasn't deleted them locally
14:50 eric_engestrom: (I replied on the issue)
14:56 Venemo: eric_engestrom: not that many people push to the main repo these days, so I don't think it's a problem, but you are technically correct
15:31 swick[m]: hwentlan_ vsyrjala can you take a look at https://lore.kernel.org/all/20240305135155.231687-1-sebastian.wick@redhat.com/ at some point?
15:32 swick[m]: airlied sima https://lore.kernel.org/all/20240314-portable-pragmatic-weasel-7dd91e@houat/
15:33 sima:readies the ack stamp
15:34 emersion: got enough ink?
15:34 sima: it's only one paragraph, one stamp is enough
15:35 emersion: has anyone already given a physical Acked-by stamp as a kernel maintainer?
15:35 emersion: to a*
15:36 sima: I have my 40th birthday this summer ...
15:36 emersion: noted!
16:28 DemiMarie: sima: congratulations!
16:28 DemiMarie: Generally, is userspace be able to put a GPU in a state that the kernel driver cannot get it out of (by resetting the GPU)?
16:31 DemiMarie: Equivalently, can I assume that any case where the GPU fails to recover from userspace doing something nasty with it is automatically a bug in the kernel driver, firmware, or hardware?
16:40 sima: DemiMarie, yeah userspace shouldn't be able to permanently hang the gpu
16:40 sima: reality is sometimes a disappointment though and some hw is very busted
16:40 DemiMarie: sima: thanks! So that is at least one area where GPUs _are_ expected to be robust.
16:41 DemiMarie: Is there any hardware that you can think of that is busted, and any hardware that is generally good?
16:42 sima: newer tends to be better, with older ones we try to fill the gaps with command checkers and stuff like that, but not sure it's perfect
16:43 sima: also reset tends to be more wobbly on older chips ime
16:49 DemiMarie: That’s good. Is this just for Intel GPUs, or is it a trend across all of the vendors?
16:50 DemiMarie: sima: thank you for all of the help you have given me, and for all of the time you have spent giving me that help.
16:51 sima: DemiMarie, in general I think
16:58 DemiMarie: sima: that is good.
17:23 alyssa: mareko: post-hoc r-b on the zlib revert fwiw
17:30 mareko: thanks
18:53 Ermine: I guess using mesa main is a relatively safe bet?
19:04 mattst88: usually,yeah
19:11 Ermine: That's nice, thank you
19:26 DemiMarie: Is blending memory latency bound on CPUs? Do llvmpipe/lavapipe use non-temporal stores? If not, is it worth trying?