From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pekka Paalanen Subject: Re: RFC: page-flip with damage? Date: Fri, 13 Oct 2017 09:41:19 +0300 Message-ID: <20171013094119.47237d4a@eldfell> References: <52d7547e-8d32-6b0b-e35f-392858415bbe@vmware.com> <20170926081811.3zj2myhhvqv2u7au@phenom.ffwll.local> <20171012135540.7c20eb2f@eldfell> <20171012145122.6ytwnx4zchr2svuv@art_vandelay> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0590864399==" Return-path: Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) by gabe.freedesktop.org (Postfix) with ESMTPS id F3D286EA11 for ; Fri, 13 Oct 2017 06:41:28 +0000 (UTC) Received: by mail-lf0-x235.google.com with SMTP id l23so8402693lfk.10 for ; Thu, 12 Oct 2017 23:41:28 -0700 (PDT) In-Reply-To: <20171012145122.6ytwnx4zchr2svuv@art_vandelay> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Sean Paul Cc: Thomas Hellstrom , "dri-devel@lists.freedesktop.org" List-Id: dri-devel@lists.freedesktop.org --===============0590864399== Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/CfdMY+QcVeypAnZw4skCM2l"; protocol="application/pgp-signature" --Sig_/CfdMY+QcVeypAnZw4skCM2l Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 12 Oct 2017 10:51:22 -0400 Sean Paul 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 wrote: > > =20 > > > On 09/26/2017 01:18 AM, Daniel Vetter wrote: =20 > > > > On Sun, Sep 24, 2017 at 07:41:45PM +0200, Thomas Hellstrom wrote: = =20 > > > >> Hi, list! > > > >> > > > >> Page flips, while efficient on real hardware, aren't that efficien= t in other > > > >> situations, like for virtual devices with local, or even worse, re= mote > > > >> 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 forwar= ds all the > > > >> way down to the function where page-flip is called. =20 > > =20 > > > > 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 enou= gh, and > > > > a nice simplification of the interface (both uapi and driver). =20 > > >=20 > > > I think multiple cliprects had its benefits for old X type rendering:= =20 > > > Frontbuffer-type diagonal > > > lines benchmarked with x11perf and similar. Now that everybody's=20 > > > compositing that use-case is mostly gone, and as you say > > > most driver coalesce anyway. Even we to some extent, at least on newe= r=20 > > > "hardware" versions. =20 > >=20 > > Hi, > >=20 > > 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. > >=20 > > I'm thinking Wayland compositors here. > >=20 > > 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, =20 >=20 > Sounds like you're making a case for overlay planes here :-) >=20 > Perhaps migrating the damage rect to plane state would make everyone happ= y. 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 com= positor > 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. > >=20 > > 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. > >=20 --Sig_/CfdMY+QcVeypAnZw4skCM2l Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEJQjwWQChkWOYOIONI1/ltBGqqqcFAlngYA8ACgkQI1/ltBGq qqcmgA/9Gwu4+hwJoakOBlrg+DtfsDuznpiBwtVuYVa0v0Rv7xaQ6qe6QxX2mKg8 Lxest7BX+njPu8P9VfWuPMhQlRgS6QpManvv50pp6Kj47UsSrbPPBebY8u1SmHDc EeZxqdn9sDuhJIk8H2KKensPf4r9IQd0nlRbpKaARVNqm2zSjSnEari4Ln6yA4Yh DYejFM+FWcp0FeK44VdPX+2vnD28I7rk4EozGR1KOVHwPEmlZM3dvSBuymkEr2P/ iqobbD+nbRVUzCA/ajjqE+AOyXLxGE/jM4Wng8DSGf+Dl0JSgRxVm8SNkxR01etf gyWOC72n6H8pIqukbVBq4/Zn5OnCQmxiMgXp4hvpJKsabz/Wahxe8t8QPsOFWKgQ swxUbENrRsQTTrxLxcP8ewrQdxz3cgMPYvXvBDwnhCjIziEPlLjC0hPE1rl9cjL4 1PUJ7WH9j/skaY0MKmyN2mJBOA5goJsVrWlEBrK9dUJEWI8R/5rJJ3L8wQ8mFYbP Ypsue8uukYRIHyjO36xaBAl+ZE3xH7tjBSbZ2RYT0UNTkeLJsxhVRGUYGR0NrBaU hgZQxIcfWzyw8E+KaIJwcHKJrWDmXiBTmJb2UG/qVikrVQG62+g5ZD9IcgcUJsju hHBinepRm/XTUMWKqE+DIW2qDXU1BZpHbTFIeT143q2seWniAg8= =3Vwa -----END PGP SIGNATURE----- --Sig_/CfdMY+QcVeypAnZw4skCM2l-- --===============0590864399== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============0590864399==--