On Fri, Nov 2, 2012 at 9:29 AM, Chris Wilson <chris at chris-wilson.co.uk> wrote: > On Thu, 1 Nov 2012 20:06:03 +0200, ville.syrjala at linux.intel.com wrote: >> From: Ville Syrj?l? <ville.syrjala at linux.intel.com> >> >> As per Chris Wilson's suggestion make >> i915_gem_execbuffer_wait_for_flips() go away. >> >> This was used to stall the GPU ring while there are pending >> page flips involving the relevant BO. Ie. while the BO is still >> being scanned out by the display controller. >> >> The recommended alternative is to use the page flip events to >> wait for the page flips to fully complete before reusing the BO >> of the old front buffer. Or use more buffers. >> >> Signed-off-by: Ville Syrj?l? <ville.syrjala at linux.intel.com> > Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk> > > Needs an ack from either Jesse or Kristian. I wouldn't mind seeing this go; we don't rely on this behavior in Weston, we use the events. However, this is a user visible change in behavior of the pageflip ioctl. I don't remember if X needs this for the case where it's pageflipping to fullscreen client buffers... I think it might (or at least might have), since we did it this way so that the client wouldn't have to wait for a protocol event before starting the next frame. With this the client can start rendering and submit the first batch before it has to block. It also minimizes the time from pageflip done to the client can start rendering, since the kernel now just unblocks the client directly. Of course you can argue that we can fix that with more buffers, and maybe it's fixed in newer servers / ddx drivers, but it doesn't change that this is how it used to work. Without this, the client doesn't know when it's new backbuffer done scanning out. Kristian
