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

Chris Wilson chris at chris-wilson.co.uk
Mon Jan 20 10:49:24 CET 2014


On Sun, Jan 19, 2014 at 10:55:26PM +0100, Daniel Vetter wrote:
> On Sun, Jan 19, 2014 at 10:20 PM, Chris Wilson <chris at chris-wilson.co.uk> 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.
> >
> > Reported-and-tested-by: dimon at gmx.net
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73696
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> 
> New subtest for kms_flip which submits such a blt buffer while a
> pageflip is still pending?

Correct.

> Also there's a certain chance we'll starve
> the unpin work, similar to the issues around flushing the unpin work
> in our pageflip implementation.

If you mean that we will never run the unpin workqueue, that's what the
implementation will fix, eventually, after a busy-spin in userspace since
set_need_resched() was removed. I can teach userspace to yield() after
an EAGAIN which seems a reasonable compromise (userspace gets a bonus
for being cooperative rather than penalized for using up its timeslice.)

> Finally I think this should be
> encapsulated into a little helper to be used in evict_something.

Yes, this should work for our ENOSPC due to pageflips as well.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre



More information about the Intel-gfx mailing list