[Intel-gfx] [PATCH v2 3b/3] drm/i915: Kill i915_gem_execbuffer_wait_for_flips()

[Kristian Høgsberg]

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