Quoting Chris Wilson (2019-11-20 13:41:13)
> Since we use barriers, we need only explicitly flush those barriers to
> ensure tha we can reclaim the available ggtt for ourselves. The barrier
> flush was implicit inside the intel_gt_wait_for_idle() -- except because
> we use i915_gem_evict from inside an active timeline during execbuf, we
> could easily end up waiting upon ourselves.
>
> Fixes: 7936a22dd466 ("drm/i915/gt: Wait for new requests in intel_gt_retire_requests()")
> Fixes: a46bfdc83fee ("drm/i915/gt: Wait for new requests in intel_gt_retire_requests()")
> Testcase: igt/gem_exec_reloc/basic-range
> Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
I think we might as well just revert 7936a22dd466 and take another look
at how to repeat the waits; I'm optimistic that with
commit 1683d24c1470fb47716bd3ccd4e06547eb0ce0ed
Author: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
Date: Tue Nov 19 16:25:58 2019 +0000
drm/i915/gt: Move new timelines to the end of active_list
the problem (e.g. igt/live_late_gt_pm) has mostly evaporated.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
