[Intel-gfx] [PATCH 1/2] drm/i915: Wait for completion of pending flips when starved of fences

[Daniel Vetter]

On Mon, Jan 20, 2014 at 9:30 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> On Mon, Jan 20, 2014 at 10:17:36AM +0000, Chris Wilson wrote:
>> On older generations (gen2, gen3) the GPU requires fences for many
>> operations, such as blits. The display hardware also requires fences for
>> scanouts and this leads to a situation where an arbitrary number of
>> fences may be pinned by old scanouts following a pageflip but before we
>> have executed the unpin workqueue. This is unpredictable by userspace
>> and leads to random EDEADLK when submitting an otherwise benign
>> execbuffer. However, we can detect when we have an outstanding flip and
>> so cause userspace to wait upon their completion before finally
>> declaring that the system is starved of fences. This is really no worse
>> than forcing the GPU to stall waiting for older execbuffer to retire and
>> release their fences before we can reallocate them for the next
>> execbuffer.
>>
>> v2: move the test for a pending fb unpin to a common routine for
>> later reuse during eviction
>>
>> Reported-and-tested-by: dimon at gmx.net
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73696
> Testcase: i-g-t/kms_flip/flip-vs-fences
>> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
>
> The testcase is only for the trivial reproduction scenario, not the more
> sporadic situation involving a slightly hungry workqueue, but it is
> enough to demonstrate the issue and the effectiveness of the simple
> workaround (for typical userspace).

Testcase convinced me, this is better than status quo ;-) I guess I'll
add a short comment though when merging that busy-looping through
EAGAIN is a but un-neat.

Jon, since this ties into the evict_something fun we've had last year
can you please review this patch plus the follow-up one?

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch