From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pekka Paalanen Subject: Re: RFC: page-flip with damage? Date: Thu, 12 Oct 2017 13:55:40 +0300 Message-ID: <20171012135540.7c20eb2f@eldfell> References: <52d7547e-8d32-6b0b-e35f-392858415bbe@vmware.com> <20170926081811.3zj2myhhvqv2u7au@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0193364874==" Return-path: Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) by gabe.freedesktop.org (Postfix) with ESMTPS id 2BEA16E786 for ; Thu, 12 Oct 2017 10:55:50 +0000 (UTC) Received: by mail-lf0-x229.google.com with SMTP id a16so5481040lfk.0 for ; Thu, 12 Oct 2017 03:55:50 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Thomas Hellstrom Cc: "dri-devel@lists.freedesktop.org" List-Id: dri-devel@lists.freedesktop.org --===============0193364874== Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/wD2ZoULo6xbf.qwIPODFo9E"; protocol="application/pgp-signature" --Sig_/wD2ZoULo6xbf.qwIPODFo9E Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 26 Sep 2017 09:07:45 -0700 Thomas Hellstrom wrote: > On 09/26/2017 01:18 AM, Daniel Vetter wrote: > > 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 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 wort= h 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 a= ll 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). =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 newer=20 > "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, 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. Thanks, pq --Sig_/wD2ZoULo6xbf.qwIPODFo9E Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEJQjwWQChkWOYOIONI1/ltBGqqqcFAlnfSiwACgkQI1/ltBGq qqe4bBAArc/OcBScM1pYDMMruZDdaygqbdU87fFdtIoZPex3odhbX5GdQnZe92mC hRGz0PmBvefLZuHElR2+fsaod+twUHGwuSmYgmS4NyioRWYGcLQ5h2RAFgepwgdz W76LVmpR/gOszieaPrxFeZHqBlZ7YTqyD4Sm1LVbuHrNmLSN/RccJCA/geD6E+Rd TejbZHKxWB07rSIY3z1DBGOZNhgChRbtmK9sgU43KGrLvnKV3JWb9ZCaqnKU45Pe F07vZW8xFb1/6joU/LNQ64i2EAHRgGpAtZeFY0gZifKyQhJtH7/tw+rIpfCWrEPn jxqd8h6q88lLj7B9Qsdv+7ymqMLoCFSc7KBY0U7tRNRvhMWuKOCZzQO+xetHBBJV XNiJXW8HHJZ1tXM05su2S4hJ1iPaOXO29Sq95AboyNo6v7qruZ/xE7qApqUSdc1Y OiDPO6q1HSUqdQtU1AiIM8sDpGD7En4w1TEsUHpCo7ZMjIidWPfuIGi1EBhgMd0+ 7gyp/5wR0r0WZIb4mjq3D6ouX2CChFbPIVxI80hx+ycdCfqFEEMbb58z9hYhY5sS gaxDRNCDjJXT2RTid+BahHZNXsO6qpRQQbjY9X9Cy6tojMVTKlyHI3PMwiu9n0ZL RJnOFOLs4WTG5QAiga1s4uNhlNsVcj4kr/xP7FwaeKvhzVjiUY8= =bs2l -----END PGP SIGNATURE----- --Sig_/wD2ZoULo6xbf.qwIPODFo9E-- --===============0193364874== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============0193364874==--