RFC: page-flip with damage?

[Sean Paul]

On Thu, Oct 12, 2017 at 01:55:40PM +0300, Pekka Paalanen wrote:
> On Tue, 26 Sep 2017 09:07:45 -0700
> Thomas Hellstrom <thellstrom at vmware.com> wrote:
> 
> > On 09/26/2017 01:18 AM, Daniel Vetter wrote:
> > > On Sun, Sep 24, 2017 at 07:41:45PM +0200, Thomas Hellstrom wrote:  
> > >> Hi, list!
> > >>
> > >> Page flips, while efficient on real hardware, aren't that efficient in other
> > >> situations, like for virtual devices with local, or even worse, remote
> > >> desktops.
> > >> We might ending up forwarding or encoding a couple of full frames worth of
> > >> data instead of a small region at a cursor blink.
> > >>
> > >> Now there is this extension EGL_KHR_swap_buffers_with_damage, and
> > >> gnome-shell/wayland on KMS also has a damage region that it forwards all the
> > >> way down to the function where page-flip is called.
> 
> > > Wrt single dirty rect vs. rectlist: I'd opt for a single rect since that
> > > makes the interface easier. Currently most drivers collapes the list
> > > passed to fb_funcs->dirty to a single rect, so that seems good enough, and
> > > a nice simplification of the interface (both uapi and driver).  
> > 
> > I think multiple cliprects had its benefits for old X type rendering: 
> > Frontbuffer-type diagonal
> > lines benchmarked with x11perf and similar. Now that everybody's 
> > compositing that use-case is mostly gone, and as you say
> > most driver coalesce anyway. Even we to some extent, at least on newer 
> > "hardware" versions.
> 
> Hi,
> 
> it still is awfully easy to create a pathological use case where
> collapsing into a single rect adds a thousand-fold more pixels to the
> damage than having more than one rectangle would allow: two tiny
> animations at the opposite corners of a screen.
> 
> I'm thinking Wayland compositors here.
> 
> Simplifying damage regions while not crashing down to just one
> rectangle is quite possible I believe. Let userspace do simplification
> from hundreds down to a few rectangles, 

Sounds like you're making a case for overlay planes here :-)

Perhaps migrating the damage rect to plane state would make everyone happy. In
the case where the hardware or compositor only supports one plane, there is one
big rect. In the case where multiple planes are used, you rely on the compositor
to make plane assignments and pass down the individual damage regions per plane.

Sean


> and then collapse into one
> rectangle in the driver if absolutely necessary. That's what I'd hope.
> 
> It is totally fine to require non-overlapping rectangles. You could
> even demand a specific layout of rectangles, e.g. the form Pixman
> regions use. You can also put an arbitrary cap on how many rectangles
> are allowed.
> 
> 
> Thanks,
> pq



> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


-- 
Sean Paul, Software Engineer, Google / Chromium OS