[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