[PATCH v2] drm/amdgpu: Reserve shared fence slot in amdgpu_vm_update_directories

[Christian König]

Am 03.07.2018 um 10:12 schrieb Zhang, Jerry (Junwei):
> On 07/03/2018 02:58 PM, Christian König wrote:
>> Am 03.07.2018 um 03:59 schrieb Zhang, Jerry (Junwei):
>>> On 07/02/2018 05:23 PM, Christian König wrote:
>>>> [SNIP]
>> The reservation_object_reserve_shared() function needs to be called 
>> before you make submissions to the hardware to make sure that you 
>> have a free slot after you made the submission.
>>
>> The problem is now that we always reserve one free slot during 
>> command submission, but for the page directory reservation object it 
>> can happen that this free slot is used by VM updates.
>>
>> So the safest approach is to make sure that we have another free slot 
>> after the VM updates are done.
>>
>> Michel's patch nearly did that, because we rarely have only one 
>> submission in amdgpu_vm_update_directories(). But it isn't 100% correct.
>
> Thanks to explain that, I think got your meaning that we should 
> reserve slot for command submission after VM update.
>
> if so, shall we add reservation_object_reserve_shared() for both of 
> them, since any of place may run out of slot.
>
> While the gap from me is I fail to find reserving slot during command 
> submission,

That's done by ttm_eu_reserve_buffers().

> the root bo reservation seems to be used by VM update only(if not 
> correct me).

No, that is not correct. The root BO is also part of the list of BOs for 
the command submission used by ttm_eu_reserve_buffers() and 
ttm_eu_fence_buffer_objects().

All VM updates will use the same slot, so we just need one extra 
reservation_object_reserve_shared() after all the VM updates are done.

Regards,
Christian.

> command submission is likely to use bo's reservation from bo list 
> rather than root bo reservation.
>
> BTW, reservation_object_reserve_shared() will extend the max num as 2 
> times if it's not enough.
> (default value is 4)
>
> Jerry