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? 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. Finally I think this should be encapsulated into a little helper to be used in evict_something. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
