RFC: page-flip with damage?

[Thomas Hellstrom]

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

Sounds fine with me. I think the DIRTY_IOCTL was designed with 
user-space in mind. Typically
userspace has easier access to what part of the framebuffer was dirtied 
than to which parts
of all crtcs scanning out of the framebuffer were dirtied. But even 
vmwgfx eventually
translates this to crtc rects so I'm OK with that.

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

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

Great.

> -Daniel


If anybody's already doing this or has code to share, please let me 
know. Or for that matter if somebody needs this stuff faster than 
vmwgfx's moderate development pace :).

/Thomas