07:39jadahl: anyone needing a w-p release or should I wait for the icon undefined buffer semantics to be fixed first?
08:17wlb: weston Issue #924 opened by TyphoonWu (TyphoonWu) Dependency wayland-server found: NO found 1.18.0 but need: '>= 1.22.0' https://gitlab.freedesktop.org/wayland/weston/-/issues/924
10:34wlb: weston Issue #924 closed \o/ (Dependency wayland-server found: NO found 1.18.0 but need: '>= 1.22.0' https://gitlab.freedesktop.org/wayland/weston/-/issues/924)
12:30wlb: weston Merge request !1563 opened by Marius Vlad (mvlad) kiosk-shell: Don't assume a valid output https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1563 [kiosk-shell]
12:56wlb: weston Issue #925 opened by ye-huang (ye-huang) The app image will freeze on screen after killi it https://gitlab.freedesktop.org/wayland/weston/-/issues/925
13:01wlb: weston Merge request !1564 opened by Marius Vlad (mvlad) backend-drm: Avoid providing a divisor of zero https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1564 [DRM/KMS backend]
15:27colinmarc: what is the reasoning behind wayland having client-allocated buffers? I ask because vulkan sort of inverts that (it's the implementation's job to allocate the buffers for a swapchain) which leads to more complexity in userspace WSI code. obviously wayland predates that, though.
15:29emersion: the impl is not the compositor fwiw
15:30emersion: no roundtrip necessary, memory is accounted for the correct process, client has full freedom which facility to use to allocate (GBM, V4L2, VA-API, etc)
15:30emersion: are a few reasons
15:33colinmarc: thanks for the quick answer, I hadn't thought about memory accounting. (I have no idea how that works with gpu memory)
15:33kennylevinsen: colinmarc: note that you're loading the Vulkan implementation into the client. When you vkAllocateMemory, it's your process (i.e., the client) that is allocating memory
15:33kennylevinsen: same for when you use the a swapchain with the WSI
15:35colinmarc: doesn't VkCreateSwapchain do the allocation, though? You don't usually call VkAllocateMemory for that, right?
15:36colinmarc: I understand what you're saying, though
15:36colinmarc: I understand how from a system perspective the WSI code is actually part of the client, but it's also not really from an interface design perspective
15:47emersion: vulkan has no say in the client-compositor architecture, no?
15:49kennylevinsen: That the swapchain is responsible for allocation doesn't really mean anything in this aspect. Why should vkCreateSwapchain have very different allocation behavior and memory ownership than vkAllocateMemory?
15:49emersion: for all vulkan cares, the windowing system could be offscreen, the kernel, in-process, whatever?
15:51colinmarc: I guess my question is coming from the observation that the WSI code is sort of a dumping ground for a lot of the complexity. So in a different world with almost no impedance mismatch between VkCreateSwapchain and the wayland protocol it would be much thinner.
15:52emersion: hm i'm not really sure i understand why you feel like this
15:52emersion: right now, inside the WSI there is a vkAllocateMemory() call
15:53emersion: if the compositor allocated buffers, that would be wl_allocate_memory(), with some more boilerplate
15:53emersion: i don't really see how that would simplify the WSI impl
15:54emersion: the fact that buffer alloc is in-process and synchronous simplifies things for the WSI impl
15:55kennylevinsen: "a different world with almost no impedance mismatch" would be a world where WSIs were thinner by not trying to manage window state for you...
15:58kennylevinsen: But that aside, it makes perfect sense to me that swapchain is just a thin wrapper around local allocations, not much different than if you had an array of vkimage’s on your own…
16:04colinmarc: you're saying that the impl already knows how to do allocations, so that's simpler than importing a buffer, which it would have to learn how to do?
16:04colinmarc: that makes sense