On Mon, 3 Jun 2024 17:57:18 +0000 "Hoosier, Matt" <matt.hoos...@garmin.com> wrote:
> > What do you mean you can capture all virtual machines with KMS > > writeback? > > > > What's the architecture there? How do virtual machines access KMS > > hardware? Why would Weston be able to capture their outputs at all? > > > > I hope to have more to say about this shortly. I'm interested because I worry whether it will work. I don't see how it could work with the traditional display controllers and DRM drivers. Maybe some kind of hardware assisted plane "leasing" that works around the DRM KMS software model limitations? > > The disadvantage is that buffer allocations are accounted to the > > compositor (which can manage its own memory consumption, sure), and > > either the compositor allocates a new buffer for every frame > > (possibly serious overhead) or it needs to wait for all consumers > > to tell that they are done with the buffer before it can be used > > again. Clients might hold on to the buffer indefinitely or just a > > little too long, which is the risk. > > It seems to me this would be a risk of the existing Pipewire backend, > no? At least, if I understood the buffering model of the dmabuf MR > that Marius linked earlier. > I haven't looked at any of that, so I can't say. I don't know if pipewire is only allocate-send-forget, or does it include consumers signalling they are done to allow re-use as well. Or maybe the sources trust that rotating N buffers is always enough, and if a sink needs the data for longer, it will make a copy in time. It's a trade-off. Sometimes the overhead of allocate-send-forget with the risk of OOM (KMS writeback might require a specific type of memory that could be scarce), maybe even with an added copy to avoid exhausting writeback-capable memory, may be justified. Thanks, pq
pgpUuGG4KCRnG.pgp
Description: OpenPGP digital signature
