06:11 zzoon: Lynne: ok. cool
07:51 MoeIcenowy: strange, I cannot git fetch from https://gitlab.freedesktop.org/simon-perretta-img/mesa.git
07:51 MoeIcenowy: gitlab.fd.o facility issue?
07:52 MoeIcenowy: (I was asked username when trying to fetch here, which I think that should not happen for a public repo
07:53 karolherbst: MoeIcenowy: it's not public
07:53 MoeIcenowy: ah? it's not public?
07:54 karolherbst: it's set to "internal"
07:54 MoeIcenowy: okay
07:54 MoeIcenowy: this sounds weird
07:54 MoeIcenowy: ( BTW I think this is the source repo of https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33998
07:55 karolherbst: sure
07:55 karolherbst: but you can fetch the MR
08:01 karolherbst: `git fetch mesa refs/merge-requests/33998/head`
08:02 karolherbst: or origin or whatever you name the mesa remote
17:43 Lynne: int b_linebuf[128] = { }; int main() { b_linebuf[0] = 0; int p = b_linebuf[0]; } segfaults while parsing in spirv-opt
17:44 Lynne: there are a lot of jokes being made about javascript being written in 10 days, somehow they pale in humor when applied to a language written over 25 years
17:44 Sachiel: you can report that here https://github.com/KhronosGroup/SPIRV-Tools/issues
20:37 K900: If I may once again bump https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33890
20:38 K900: I would very much like this to make 25.1
20:44 mattst88: what other gbms are there? just minigbm or is there something else?
20:50 K900: Right now our libgbm loader is just a Mesa built with everything possible disabled
20:51 K900: But long term I want to get the gbm-loader bits out of Mesa and into their own repo
20:53 mattst88: interesting. why?
20:54 K900: Because we can have applications that are linked against an old libgbm loader running on a system with a newer driver
20:54 K900: And we want that to not explode
20:54 K900: Also it's nice to not pull all of Mesa for applications that really just want a libgbm
20:55 mattst88: I see
20:58 airlied: maybe putting libgbm into glvnd might be an option?
20:58 airlied: though I suspect api stability might not be good enough
20:59 K900: I don't think it'll fit well given the design approach
20:59 K900: libgbm already has a stable backend ABI
20:59 K900: That is not (quite) libgbm-shaped
20:59 K900: The existing code in Mesa is already basically doing what glvnd does
21:00 K900: But the implementation is pretty different from gvlnd
21:00 K900: I think it's better off just being its own thing
21:00 K900: We already have glvnd, vulkan-loader, ocl-icd, libva, what's one more :P
21:07 mattst88: I guess I'm just wondering what the end goal is
21:08 mattst88: e.g. you want to be able to make significant changes to gbm internals without affecting the ABI
21:08 K900: Being able to replace the Mesa version an application is running against without relinking the application and/or any LD_PRELOAD tricks
21:09 K900: (or replacing libraries it is linked against)
22:25 cwabbott: daniels: any idea what's causing random spurious crashes with a618 trace jobs like this? https://mesa.pages.freedesktop.org/-/mesa/-/jobs/73873303/artifacts/results/summary/results/trace@freedreno-a618@godot@godot-tps-gles3-high.trace.html
22:25 cwabbott: it seems to be downloading a corrupted/wrong file, so proxy issues?
22:32 daniels: cwabbott: yeah I know the root cause and I’ll fix it tomorrow - itmt put [flaky,skip] on any you see doing that and I’ll revert those in the MR to fix
22:32 daniels: sorry about that