Den 24.09.2017 23.32, skrev Rob Clark:
On Sun, Sep 24, 2017 at 1:41 PM, Thomas Hellstrom <thellstrom@xxxxxxxxxx> 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.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
