RFC: page-flip with damage?

[Daniel Vetter]

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.
> 
> 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.

So my rough plan for all this was:

- Add damage to drm_crtc_state, in screen coordinates. I think this is the
  most natural place for this, since it's what PSR/manual upload DSI want.
  It should also fit well for udl and tinydrm.  Virtual drivers like
  vmwgfx might need helpers to wrap this back to framebuffer rectangles,
  but that seems the odd case out - the framebuffer-based approach in the
  DIRTY_IOCTL forces most drivers to do a fancy lookup from fb to the
  crtc.

  Per-plane dirty rectangle seems to be an awkward in-betwen state, with
  all the confusion about whether it's pre/post scaled and how to best
  combine them. And then someone changes the background color of the crtc
  (or something like that), what happens then? I think pushing all that
  onto userspace is best, it can always ask for a complete flip if it's
  unclear whether it damaged the entire screen or not.

- Add a helper to the atomic core to implement fb_funcs->dirty on top of
  this new atomic state, so that drivers don't have to implement both the
  frontbuffer and the pageflip version of the _with_damage update. Just
  doing a flip (or an async one, if the driver supports that) should work
  well I think.

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).

Wrt enabling this on the legacy pageflip ioctl: I wouldn't bother, since
all drivers we reasonable care about are atomic already. One exception is
amdgpu, but that's going to be fixed soonish by merging the DC branch I
hope.

There's definitely lots of people who want to see this happen, that part
is for sure.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch