RFC: page-flip with damage?

[Rob Clark]

On Sun, Sep 24, 2017 at 1:41 PM, Thomas Hellstrom <thellstrom at vmware.com> 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.
>
> So I'd like to start looking at page-flips with damage, meaning that the
> damage is an optional hint to the device about what part of the contents is
> actually updated. What would be the best way to implement this? I figure
> this can be done within the atomic context with a region attached to the
> plane state? Would we want to follow the EGL extension and forward an array
> of rects or for simplicity use a single bounding box? Both these options
> would be a great win.
>

If we do list of rects, I'd suggest that perhaps userspace should be
encouraged to break things down into non-overlapping rects.. else
kernel side gets to do some complicated thinking to avoid
re-transmitting the parts that are covered by multiple rects.

This is also a pretty useful thing for DSI command-mode panels (and I
guess eDP-psr), so I think worth solving.

Not sure if anyone has hardware that lets you queue up multiple rects?
 IIRC last time I looked at this for DSI, you could feed the hw a
single rect at a time and then when you get an irq back from the hw
feed it the next rect.  So multiple rects seems more useful if there
are updates on very disjoint parts of the screen.

OTOH the existing dirty ioctl takes a list of clip-rects.. maybe that
is an argument for a list instead of single rect?

BR,
-R