ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
nerdopolis has joined #wayland
guru_ has joined #wayland
crazybyte has quit [Quit: Bye]
crazybyte has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
Guest229 has quit [Remote host closed the connection]
JEEB has quit [Ping timeout: 480 seconds]
yang2 has quit [Ping timeout: 600 seconds]
yang2 has joined #wayland
garnacho has joined #wayland
garnacho has left #wayland [#wayland]
naemi44 has quit [Remote host closed the connection]
naemi449 has joined #wayland
garnacho has joined #wayland
garnacho has left #wayland [#wayland]
Company has joined #wayland
privacy has joined #wayland
lsd|2|2 has joined #wayland
lsd|2 has quit [Read error: No route to host]
TheCaptain82970403198578471379 has joined #wayland
lsd|2|2 has quit []
<colinmarc>
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.
<emersion>
the impl is not the compositor fwiw
<emersion>
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)
<emersion>
are a few reasons
<colinmarc>
thanks for the quick answer, I hadn't thought about memory accounting. (I have no idea how that works with gpu memory)
<kennylevinsen>
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
<kennylevinsen>
same for when you use the a swapchain with the WSI
<colinmarc>
doesn't VkCreateSwapchain do the allocation, though? You don't usually call VkAllocateMemory for that, right?
<colinmarc>
I understand what you're saying, though
<colinmarc>
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
<emersion>
vulkan has no say in the client-compositor architecture, no?
<kennylevinsen>
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?
<emersion>
for all vulkan cares, the windowing system could be offscreen, the kernel, in-process, whatever?
<colinmarc>
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.
tzimmermann_ has quit []
<emersion>
hm i'm not really sure i understand why you feel like this
<emersion>
right now, inside the WSI there is a vkAllocateMemory() call
<emersion>
if the compositor allocated buffers, that would be wl_allocate_memory(), with some more boilerplate
<emersion>
i don't really see how that would simplify the WSI impl
<emersion>
the fact that buffer alloc is in-process and synchronous simplifies things for the WSI impl
<kennylevinsen>
"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...
<kennylevinsen>
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…
Brainium has quit [Quit: Konversation terminated!]
<colinmarc>
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?
<colinmarc>
that makes sense
kts has joined #wayland
selckin has quit [Quit: selckin]
selckin has joined #wayland
JEEB has joined #wayland
cptaffe` has joined #wayland
bim9262_ has joined #wayland
cptaffe has quit [Ping timeout: 480 seconds]
bim9262 has quit [Ping timeout: 480 seconds]
bim9262_ is now known as bim9262
kts has quit [Quit: Konversation terminated!]
Hypfer has quit [Ping timeout: 480 seconds]
cyrinux has quit []
cyrinux has joined #wayland
mclasen has quit [Remote host closed the connection]
narodnik has joined #wayland
Company has quit [Read error: Connection reset by peer]
Brainium has joined #wayland
qyliss_ has joined #wayland
mvlad has quit [Remote host closed the connection]
Company has joined #wayland
qyliss has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
King_DuckZ has quit []
King_DuckZ has joined #wayland
lsd|2 has joined #wayland
riteo has joined #wayland
riteo_ has quit [Ping timeout: 480 seconds]
rv1sr has quit []
privacy has quit [Ping timeout: 480 seconds]
glennk has quit [Ping timeout: 480 seconds]
privacy has joined #wayland
leon-anavi has quit [Remote host closed the connection]