Full-motion zero-copy screen capture in Weston

[Hoosier, Matt]

> -----Original Message-----
> From: Pekka Paalanen <pekka.paalanen at collabora.com>
> Sent: Monday, June 17, 2024 3:28 AM
> To: Hoosier, Matt <Matt.Hoosier at garmin.com>
> Cc: 'sir at cmpwn.com' <sir at cmpwn.com>; 'contact at emersion.fr'
> <contact at emersion.fr>; 'Marius Vlad' <marius.vlad at collabora.com>;
> 'wayland-devel at lists.freedesktop.org' <wayland-
> devel at lists.freedesktop.org>; 'Daniel Stone' <daniel at fooishbar.org>
> Subject: Re: Full-motion zero-copy screen capture in Weston
> 
> On Fri, 14 Jun 2024 18:36:57 +0000
> "Hoosier, Matt" <Matt.Hoosier at garmin.com> wrote:
> 
> >
> > Hmm. As I read through the history of the original support for
> > writeback screenshots
> > (https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/458)
> > and get some initial results just trying to drive a steady stream of
> > writeback composition, I'm not sure this can work effectively.
> >
> > MR 458 has a fairly long discussion about the restriction that no
> > further commits must be made to the source CRTC or any of the other
> > KMS objects reachable on its graph, while a writeback composition
> > referencing that CRTC is still in flight.
> >
> > Daniel Vetter confirmed that interpretation.
> >
> > I think this means that unless you are extremely lucky that:
> >
> > (a) your hardware's writeback mechanism is synchronous with scanout,
> > and (b) the fence fd manages to fire and get dispatched immediately
> > upon scanout/writeback passing through the final scanline, and (c)
> > there's a really large vertical back porch
> >
> > , there will be no time left to enqueue a page flip for the
> > immediately succeeding vblank.
> >
> > Seems like this will almost always cut the frame achievable update
> > rate on the main connector in half.
> >
> > Did I misinterpret something in there? Early results look like the
> > kernel state machine gets confused (with VKMS anyway) if I queue up
> > two writeback operations in flight at the same time.
> 
> Hi Matt,
> 
> I really don't know. If hardware and drivers require that, and cannot stream at
> full refresh rate, then there is not much we can do.
> 
> Not much, because I got one idea: Weston could repaint pre-emptively
> according to its own schedule, but KMS-flip only when the writeback situation
> allows. That should reduce the time needed between the writeback
> completion fence firing and the KMS deadline for the flip.
> 
> VKMS might rely on the above rules, or maybe it's not fully developed, I'm not
> sure. You'd have to ask its developers. OTOH, if all hardware drivers need the
> above rules, then VKMS should too. Maybe it just needs to check and fail
> better.
> 
> 
> Thanks,
> pq

Okay. I think maybe it makes sense to figure out who originally added this kernel documentation and see whether the situation is really so grim.

I'll see about writing something to whoever that was, perhaps with dri-devel CC'ed.