[Intel-gfx] [PATCH 12/21] drm/i915: Mark up address spaces that may need to allocate

[Tvrtko Ursulin]

On 20/09/2019 17:35, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2019-09-20 17:22:42)
>>
>> On 02/09/2019 05:02, Chris Wilson wrote:
>>> Since we cannot allocate underneath the vm->mutex (it is used in the
>>> direct-reclaim paths), we need to shift the allocations off into a
>>> mutexless worker with fence recursion prevention. To know when we need
>>> this protection, we mark up the address spaces that do allocate before
>>> insertion.
>>>
>>> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
>>> ---
>>>    drivers/gpu/drm/i915/i915_gem_gtt.c | 3 +++
>>>    drivers/gpu/drm/i915/i915_gem_gtt.h | 2 ++
>>>    2 files changed, 5 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c
>>> index 9095f017162e..56d27cf09a3d 100644
>>> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
>>> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
>>> @@ -1500,6 +1500,7 @@ static struct i915_ppgtt *gen8_ppgtt_create(struct drm_i915_private *i915)
>>>                        goto err_free_pd;
>>>        }
>>>    
>>> +     ppgtt->vm.bind_alloc = I915_VMA_LOCAL_BIND;
>>
>> So this is re-using I915_VMA_LOCAL_BIND as a trick? Is it clear how that
>> works from these call sites? Should it be called bind_alloc*s*?
>> bind_allocates? Or be a boolean which is converted to a trick flag in
>> i915_vma_bind where a comment can be put explaining the trick?
> 
> Is it a trick? We need to differentiate between requests for LOCAL_BIND,
> GLOBAL_BIND, LOCAL_BIND | GLOBAL_BIND, for different types of vm. Then I
> have a plan on using the worker for GLOBAL_BIND on bsw/bxt to defer the
> stop_machine().

What's the connection between "mark up the address spaces that do 
allocate before insertion" and I915_VMA_LOCAL_BIND?

Regards,

Tvrtko