From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Re: [PATCH] UXA: Wait until a pageflip actually completes to report it. Date: Thu, 08 May 2014 08:54:52 -0700 Message-ID: <87bnv8fepf.fsf@eliezer.anholt.net> References: <1399356307-7392-1-git-send-email-jamey@minilop.net> <20140507155518.GI7322@nuc-i3427.alporthouse.com> <20140508054423.GA9791@minilop.net> <20140508060845.GA20315@nuc-i3427.alporthouse.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1167979402==" Return-path: In-Reply-To: <20140508060845.GA20315@nuc-i3427.alporthouse.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Chris Wilson , intel-gfx@lists.freedesktop.org, Theo Hill List-Id: intel-gfx@lists.freedesktop.org --===============1167979402== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Chris Wilson writes: > On Wed, May 07, 2014 at 10:44:23PM -0700, Jamey Sharp wrote: >> On Wed, May 07, 2014 at 04:55:18PM +0100, Chris Wilson wrote: >> > On Mon, May 05, 2014 at 11:05:07PM -0700, Jamey Sharp wrote: >> > > UXA was reporting page-flip completion as soon as the flip was sched= uled >> > > with the kernel, instead of waiting for the kernel to indicate that = the >> > > flip had actually completed. >> > >=20 >> > > Moving the DRI2SwapComplete call to the right place fixes all of our >> > > Piglit tests for OML_sync_control when run on xf86-video-intel/UXA, >> > > aside from a bit of difficult-to-reproduce flakiness when using a >> > > divisor > 1. >> >=20 >> > The violation is intentional, as it gives us triple buffering by >> > default. It can be disabled. >>=20 >> As far as I can tell, this patch has no effect on triple-buffering. I >> verified that by logging new_front->handle in intel_do_pageflip: It >> rotates through three different BO's on successive flips. > > The patch blocks clients in GetBuffers until the swap completes, > preventing them from rendering to the third buffer. I don't see where the client gets blocked in a swapbuffers. Can you point that out? --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJTa6jNAAoJELXWKTbR/J7ok4YP/3UCxZY/FsM/9vr5l5bs5EZP RKj/IqnmjyRG4DWHHc3vB+ISsv44Eg5iQZifdogNFcN4oS6xn2JjMzqJuKuWwjXT ypbFk8uGlVj0zzq6h9E5XDA3PYIO8rpwxDSRY0YpTV6sBblH59HvFk5c84VBdz5a NWy/NR16piO5VWBT9QW28PrB9TwhBXjDBZMu/Kvft30MmHocr8KGh+ke7nRBOBNV 7DFnY4eSnq4vhp1hXdHSM5nshjkINtFAo8lyaQSw29HbOGqTB5vUGWDrm6BYC1IX 4Q5dpRxgiWAszSHhRsVhWrrraqna28HRSE9/SJnmy8HSi+x8/oKpCz88cwGsaWne jqWpZvG7zontFoKj3lUOax6MrJXaavOJ9zRlr8JU8vsKUQLMGzbl5FMs9J4VFaI2 is4bpMc9b0FoJtxHWW7quBh8IemiQ9DYXLqSq8VOs2FQFYjXAaqrOJiFN2kF0U8/ G47IZUpxIeGHJ+HjH1hsiQGi48w6nPWhOCM9hMfza8yLGggWI/9MQL+lIEInvSBZ pZlEOBn16GC3z/KgxwPxztHxSqtfsHvmDrwEKoOnznjpAQzh1vs6izSp4LAlHH0F H11VfLR7MBlTcvdoX3Ph6yMIWhLeZqt382quf4L8CaJbNGonBtAwVoG4md1asyc4 lok+RH9flkteFN9lE9az =x2b+ -----END PGP SIGNATURE----- --=-=-=-- --===============1167979402== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx --===============1167979402==--