02:28 Lynne: "Function parameter Decoration not handled: SpvDecorationCoherent"
02:29 Lynne: does mesa not implement certain parts of the SPIRV spec?
02:31 Lynne: either glslang or mesa miscompiles a bda buffer, and I'm gathering evidence so I can exonorate myself in the future, just in case
02:37 Sachiel: from the spirv docs for that: Coherent is not allowed if the declared memory model is Vulkan.
02:42 Lynne: I'm using volatile
02:43 Lynne: oh no, does glslang miscompile, AND confuse volatile with coherent in some situations?
02:45 Sachiel: don't know, I'd expect it to respect the rules of the target-env you ask for it
03:33 DavidHeidelberg: Company: force GTK apps dev to use PinePhone 1 :D Problem solved :trollface:
03:35 Company: I think you guys first need to get the driver to actually rerender the screen fast enough
03:35 Company: because last someone checked, cairo was very competitive on that phone
03:36 Company: something like 50% faster for GTK4, with 6fps vs 4fps
07:15 mahkoh: What is the purpose of https://gitlab.freedesktop.org/mesa/mesa/-/blob/28655b26f5cd62c7e7c581e3eabe3244ce7d9769/src/egl/drivers/dri2/platform_wayland.c?page=2#L1717-1725
07:16 mahkoh: In certain places mesa will just loop on dispatching wayland messages if this field is set. Nowadays I'd expect this sync to be mostly unrelated to buffer release message.
07:17 mahkoh: I saw mesa emitting a bunch of these syncs in a row (without any other wayland messages) in an application I was testing.
07:22 mahkoh: (I'm suspecting that it was mesa. I didn't see any other involved code using wl_display_sync.)
07:23 mahkoh: https://gist.github.com/mahkoh/299fdc305d0a2b1d5d4e96ede92bf9e4
07:36 daniels: mahkoh: well it's right after a wl_surface_commit and other protocol requests in the snippet you posted, so you'd at least see those rather than just back-to-back syncs
07:36 daniels: it's there for two reasons: partly because older versions of some compositors used to not flush after sending wl_buffer.release events, so you'd need something else like frame or sync to get the release event out of its queue
07:36 mahkoh: True, I guess it's not mesa after all.
07:37 daniels: and secondly, because you want _some_ kind of limiting on how fast you issue commits, rather than just sending so many messages you fill up the sendq
07:37 daniels: (you'll only hit that path if you have eglSwapInterval(0) i.e. completely free-running client not using fifo/ct or frame)
07:37 mahkoh: But isn't this already throttled by the swapchain length? If you're committing faster than the compositor can handle, you'll eventually run out of buffers.
07:49 daniels: yeah, true
08:37 hakzsam: not sure what's happening in CI here https://gitlab.freedesktop.org/mesa/mesa/-/pipelines/1294903
08:41 daniels: hakzsam: hmm, I wonder if one of the shared runners is sick - python-test just died halfway through without reporting failure, then looked like it sort of spontaneously restarted
12:09 daniels: DavidHeidelberg: so what's the plan with the fedora-release job? is there something blocking us from disabling LTO in pre-merge?
15:13 ernstp: agd5f: is that a good list of patches for 6.11.5 stable...? only: always apply the powersave optimization & Only force workload setup on init