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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
