05:44 tzimmermann: airlied, sima, hi! please merge last week's PR of drm-misc-next-fixes https://lore.kernel.org/dri-devel/20250327141835.GA96037@linux.fritz.box/
05:46 airlied: tzimmermann: done
06:37 MrCooper: K900: what specifically is the issue with apps linked against old libgbm running on a system with a newer driver?
06:38 K900: Mesa generally expects the GBM backend to match the drivers
06:38 K900: And when that's not the case, things explode
06:38 MrCooper: there's a versioned ABI
06:38 K900: Between GBM and the backend, yes
06:39 K900: Between the Mesa drivers and the DRI backend specifically, no
06:39 MrCooper: why wouldn't the Mesa GBM backend match the rest of Mesa?
06:39 K900: Because until recently the GBM backend was hard-compiled into libgbm
06:40 K900: Which is exactly the thing I'm trying to untangle here
06:40 MrCooper: I'm afraid I'm having trouble seeing the real-world scenario
06:41 K900: The easiest non-NixOS-shaped scenario is you want to run an app with a local build of Mesa
06:41 K900: And you can just configure your glvnd/vulkan-loader to pick up your local Mesa, but not GBM
06:41 MrCooper: that picks up libgbm from the local build?
06:42 K900: It won't normally
06:42 K900: Unless you LD_PRELOAD it or something
06:42 K900: Or mess with LD_LIBRARY_PATH
06:42 K900: * "LD_LIBRARY_PATH"
06:42 MrCooper: sounds like a bug somewhere
06:42 K900: How would it pick up the local libgbm?
06:42 MrCooper: doesn't it work with "meson devenv"?
06:42 K900: Now it does because it's been partially untangled
06:42 MrCooper: same way as the other Mesa binaries
06:42 K900: Before that it didn't
06:44 MrCooper: not sure why it wouldn't, if it picked up libgbm from the local build
06:44 K900: It didn't
06:44 K900: It just happened to mostly work without that
06:44 K900: Usually
06:45 MrCooper: not picking up libgbm from the local build is a bug as far as I'm concerned
06:46 K900: The real use case I care more about is NixOS, which builds applications with (gross simplification) hardcoded, read-only, content-addressed paths, so an application is not linked against /usr/lib/libgbm.so, but /nix/store/<long hash>/libgbm.so, and those paths never change
06:46 K900: So running such an application on a system with newer drivers generally leads to explosions
06:47 K900: (the drivers are intentionally not hardcoded, because that causes issues for people with newer hardware, etc)
06:58 etehtsea: Hi! Is some noticeable lag might happen between sending a patch to the mailing list and it's appearance in the archive? I can swear I checked multiple times before sending a RESEND copy and there were none but now I see all three of my emails (incl resend)
07:02 tzimmermann: thanks airlied
08:45 MrCooper: K900: it doesn't allow running against newer versions of shared libraries?
08:46 K900: Not without rebuilding the application against them
08:50 MrCooper: that defeats one of the main purposes of shared libraries
08:50 K900: Yet it also provides a lot of interesting benefits
10:07 MoeIcenowy: K900: then why not consider libgbm.so as part of the driver?
10:08 K900: Because applications link to it directly?
10:12 MoeIcenowy: well in this case I think gbm should be built as a loader and backends
10:13 MoeIcenowy: the libgbm source code in Mesa is organized in such way
10:13 MoeIcenowy: but I am not sure whether it's possible to build them to 2 .so's instead of 1
10:14 K900: Yes that's exactly what's happening
10:14 K900: Or rather that's exactly what my first change was about
10:14 K900: This change is about making the loader standalone, so it can exist outside of Mesa
10:15 MrCooper: libgbm should be in its own package, which can be pinned to the version the app was built against, and the backend can be shipped in a separate package which doesn't need to be the same version
10:15 K900: Or at least paving the way for that
10:15 K900: MrCooper: This is exactly what I'm working towards
10:15 MrCooper: it's not really necessary for that though
10:15 MrCooper: it's just a downstream packaging exercise
10:15 MoeIcenowy: well I think the backend needs to be locked to other parts of the driver
10:16 MoeIcenowy: and in fact at least we should allow backends to be built w/o loader
10:16 K900: MrCooper: Yes but no
10:16 MoeIcenowy: to allow some temporary replacement of mesa
10:16 MrCooper: definitely yes
10:17 MrCooper: otherwise it's a NixOS issue
10:17 K900: The problem is that Mesa itself also links libgbm
10:17 K900: And right now it links _its own_ libgbm
10:17 K900: Always
10:18 K900: So if you have a driver installed system-wide that's built against a different libgbm, you open yourself up to all kinds of funny symbol conflict nonsense
10:19 K900: By moving the loader out of Mesa, we can just build Mesa against whatever loader the user has on their system
10:20 MrCooper: then you still can't mix apps & Mesa built against different versions of the loader though, can you?
10:20 K900: Yes, but that's generally the case for any system library
10:21 MrCooper: can't Mesa be fixed not to link libEGL_mesa.so.0.0.0 to libgbm, e.g. use dlopen instead?
10:21 K900: (see: the webkitgtk/soup debacle, etc)
10:21 K900: MrCooper: Possibly?
10:22 K900: But I don't think that's practical to do for everything
10:22 K900: Like, I'd rather just treat libgbm like libglvnd
10:22 K900: As something that comes from the base system
10:59 MoeIcenowy: MrCooper: the problem isn't that it uses interface in libgbm
10:59 MoeIcenowy: the problem is that the gbm dri backend calling into gallium directly
11:00 MoeIcenowy: and gallium has no stable interface
12:08 MrCooper: MoeIcenowy: that's not relevant, those things are shipped together
20:58 Lynne: would there be any reason why a 6464*128 image would be slower to access than a buffer on AMD?
20:58 Lynne: optimally-tiled images, of course
22:01 Lynne: on nvidia, there's no difference between storage images and buffers, but on AMD, its massive
22:02 Lynne: I thought that image extent checks were free in a shader and due to tiling, access is faster
23:27 Lynne: nevermind, my code was wrong