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@xxxxxxxxxxxxxxxxxx> 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@xxxxxxx > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73696 > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
