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.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
