[Intel-gfx] [PATCH 09/24] drm/i915: make lockdep slightly happier about execbuf.

Maarten Lankhorst maarten.lankhorst at linux.intel.com
Tue Aug 11 11:56:19 UTC 2020


Op 11-08-2020 om 09:34 schreef Thomas Hellström (Intel):
>
> On 8/10/20 12:30 PM, Maarten Lankhorst wrote:
>> As soon as we install fences, we should stop allocating memory
>> in order to prevent any potential deadlocks.
>>
>> This is required later on, when we start adding support for
>> dma-fence annotations, and also required for userptr.
>>
>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
>> ---
>>   drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 18 ++++++++++++------
>>   drivers/gpu/drm/i915/i915_vma.c                |  8 +++++---
>>   drivers/gpu/drm/i915/i915_vma.h                |  3 +++
>>   3 files changed, 20 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>> index 5d08ce71f341..12397fbc0971 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>> @@ -48,11 +48,12 @@ enum {
>>   #define DBG_FORCE_RELOC 0 /* choose one of the above! */
>>   };
>>   -#define __EXEC_OBJECT_HAS_PIN        BIT(31)
>> -#define __EXEC_OBJECT_HAS_FENCE        BIT(30)
>> -#define __EXEC_OBJECT_NEEDS_MAP        BIT(29)
>> -#define __EXEC_OBJECT_NEEDS_BIAS    BIT(28)
>> -#define __EXEC_OBJECT_INTERNAL_FLAGS    (~0u << 28) /* all of the above */
>> +/* __EXEC_OBJECT_NO_RESERVE is BIT(31), defined in i915_vma.h */
>
> Hmm. Could we either move all these flag definitions to a header or add an i915_vma_move_to_active()? 


I have dropped this patch for now. The real fix is a removal of that chunk in
i915_vma_move_to_active. We need to stop allocating memory that late, and only
install fences and submit.

Specifically, eb_submit() should not be allowed to allocate memory after a certain
point and then complete without error. There are too many places that do this to
fix it up in this series, but this will definitely have to be done in the future.



More information about the Intel-gfx mailing list