[Intel-gfx] [PATCH] drm/i915: Wait and retry if there is no space in the aperture mappable area

[Daniel Vetter]

On Thu, Dec 5, 2013 at 3:28 PM, Daniel Vetter <daniel at ffwll.ch> wrote:
>
> On Tue, Oct 22, 2013 at 2:04 PM, Siluvery, Arun <arun.siluvery at intel.com> wrote:
>> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
>> index e7b39d7..927a27b 100644
>> --- a/drivers/gpu/drm/i915/i915_gem.c
>> +++ b/drivers/gpu/drm/i915/i915_gem.c
>> @@ -3275,6 +3275,10 @@ search_free:
>>                                                obj->cache_level,
>>                                                map_and_fenceable,
>>                                                nonblocking);
>> +
>> +               if (ret == -ENOSPC)
>> +                       ret = i915_gem_evict_everything(dev);
>> +
>
> Despite my earlier claim this is indeed a real bugfix - compared to
> evict_something this will move away any hw context objects. So this
> isn't just purely duct-tape.
>
> I think the right approach for this patch would be to create a
> i915_gem_evict_unpin_special_objects function or similar which atm
> just does the do_switch to the default context. We can then call this
> here and in evict_everything.
>
> Can you please look into that and test whether that helps as well as
> your current hack?
>
> I've noticed this while trying to create a testcase for the recently
> fought do_switch eviction related oops. I just couldn't and that got
> me thinking a bit ;-)

Fyi I've just pushed out igt/gem_ctx_exec/eviction which exercises our
current failure to evict the current contxt. It's going through
execbuf though and doesn't test the gtt mmap path. Fixing up that is
imo only worth it as part of the large plan I've outlined somewhere
else in this thread. Atm the test fails, but it should work with
proper context eviction. So this should be useful for a more minimal
testcase.

Since the testcase starts with a too-big execbuf that should also
exercise the endless loop you've outlined in the internal mail, but I
think for safety we want to add one more execbuf call in the eviction
test with a 3rd context and just 1 buffer too much in the reloc list.
That should perfectly reproduce your failure case.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch