On 20/11/2019 16:02, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-11-20 15:58:49)
On 20/11/2019 13:41, Chris Wilson wrote:
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
Bugzilla: ?
It's been in CI since before the w/e (the test itself is much, much
older), I guess it hasn't been vetted yet as no bug has been filed.
This test gets permanently stuck on some platforms?
All !full-ppgtt platforms.
How it will cope with actual ggtt pressure? Wait for presumably there
for a reason and now it will only retire what's already done and send an
idle pulse down the engines.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
