On Thu, 12 Oct 2017 10:51:22 -0400 Sean Paul <seanpaul@xxxxxxxxxxxx> wrote: > On Thu, Oct 12, 2017 at 01:55:40PM +0300, Pekka Paalanen wrote: > > On Tue, 26 Sep 2017 09:07:45 -0700 > > Thomas Hellstrom <thellstrom@xxxxxxxxxx> wrote: > > > > > 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. > > > > > > 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. > > > > Hi, > > > > it still is awfully easy to create a pathological use case where > > collapsing into a single rect adds a thousand-fold more pixels to the > > damage than having more than one rectangle would allow: two tiny > > animations at the opposite corners of a screen. > > > > I'm thinking Wayland compositors here. > > > > Simplifying damage regions while not crashing down to just one > > rectangle is quite possible I believe. Let userspace do simplification > > from hundreds down to a few rectangles, > > Sounds like you're making a case for overlay planes here :-) > > Perhaps migrating the damage rect to plane state would make everyone happy. In > the case where the hardware or compositor only supports one plane, there is one > big rect. In the case where multiple planes are used, you rely on the compositor > to make plane assignments and pass down the individual damage regions per plane. Hi Sean, no, I wasn't really. I was thinking of a single big Wayland app window, that has small changes roughly in opposite corners. Or two windows far apart on the same output, updating at the same, and being composited into a single framebuffer, e.g. because they are software-rendered. The real world use case I have hit was with Xwayland with a fullscreen X11 window getting these little updates scattered around. Xwayland collapsing the damage into a single rect to be submitted to Weston caused Weston to spend a lot of time in the pixman-renderer (software compositing). Fixing it to submit detailed damage regions reduced Weston's CPU usage significantly, down to a quarter or something in that magnitude, if I recall correctly. This is an extreme example, comparing a single rect to the original hundreds of rects. In practice, one should have a damage region simplifier that optimizes the trade-off between more pixels and more rects. That example is not directly applicable to the question at hand, but I do believe it extrapolates somewhat on the downsides of using only a single rectangle per plane or crtc on cases where damage is a useful hint. After all, 2D-compositors should be able to provide detailed damage regions if they are allowed to. Would this not also be in the interest of power saving? Thanks, pq > > and then collapse into one > > rectangle in the driver if absolutely necessary. That's what I'd hope. > > > > It is totally fine to require non-overlapping rectangles. You could > > even demand a specific layout of rectangles, e.g. the form Pixman > > regions use. You can also put an arbitrary cap on how many rectangles > > are allowed. > >
Attachment:
pgpOQjHfhRm5i.pgp
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
