Quoting Tvrtko Ursulin (2019-11-20 16:14:40)
>
> 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.
Same it did previously... I've vacillated between using a flush and a
wait. Originally, it was meant to just be a flush as we would wait on
individual objects. But now context pinning requires waiting on
barriers. Hmm, actually that would be a simple way of obtaining the
previous behaviour when required.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
