[Intel-gfx] [PATCH] drm/i915/gem: Reduce flush_ggtt() from a wait-for-idle to a mere barrier flush
Tvrtko Ursulin
tvrtko.ursulin at linux.intel.com
Wed Nov 20 16:14:40 UTC 2019
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
More information about the Intel-gfx
mailing list