RFC: page-flip with damage?

[Noralf Trønnes]

Den 24.09.2017 23.32, skrev 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?

There's a TODO that Daniel Vetter came up with during the tinydrm
review that touches this:
https://dri.freedesktop.org/docs/drm/gpu/todo.html#better-manual-upload-support-for-atomic

If I remember correctly struct drm_rect was preferred in-kernel over
struct drm_clip_rect.

tinydrm is geared mainly towards MIPI DBI type panels, where the pixels
are pushed through the command (MIPI DCS) interface (mostly SPI).
This means that there are major savings in reducing the area to be flushed.
AFAIK X windows only sends one rectangle at a time in the DIRTYFB call.

Noralf.