Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> writes: > On Thu, May 08, 2014 at 08:54:52AM -0700, Eric Anholt wrote: >> Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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 scheduled >> >> > > with the kernel, instead of waiting for the kernel to indicate that the >> >> > > flip had actually completed. >> >> > > >> >> > > 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. >> >> > >> >> > The violation is intentional, as it gives us triple buffering by >> >> > default. It can be disabled. >> >> >> >> 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? > > DRI2ThrottleClient() called by GetBuffers and SwapBuffers will call > IgnoreClient() if swapsPending >= swap_limit and will only wake the > client on calling DRI2SwapComplete(). The premature SwapComplete is to > allow the clients next call to GetBuffers to succeed promptly returning > the third buffer prior to the page flip completing. Oh, so swap_limit is just set wrong?
Attachment:
pgpPly5aZ24gv.pgp
Description: PGP signature
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
