[PATCH] drm/amdgpu: Reserve fence slots for command submission

[Michel Dänzer]

On 2018-07-04 11:01 AM, Christian König wrote:
> Am 04.07.2018 um 09:57 schrieb Zhang, Jerry (Junwei):
>> On 07/04/2018 03:21 PM, Michel Dänzer wrote:
>>> On 2018-07-04 08:55 AM, Zhang, Jerry (Junwei) wrote:
>>>> On 07/04/2018 02:34 PM, Christian König wrote:
>>>>> Am 04.07.2018 um 05:02 schrieb Junwei Zhang:
>>>>>> From: Michel Dänzer <michel.daenzer at amd.com>
>>>>>>
>>>>>> Without this, there could not be enough slots, which could trigger
>>>>>> the
>>>>>> BUG_ON in reservation_object_add_shared_fence.
>>>>>>
>>>>>> v2:
>>>>>> * Jump to the error label instead of returning directly (Jerry Zhang)
>>>>>> v3:
>>>>>> * Reserve slots for command submission after VM updates (Christian
>>>>>> König)
>>>>>>
>>>>>> Cc: stable at vger.kernel.org
>>>>>> Bugzilla: https://bugs.freedesktop.org/106418
>>>>>> Reported-by: mikhail.v.gavrilov at gmail.com
>>>>>> Signed-off-by: Michel Dänzer <michel.daenzer at amd.com>
>>>>>> Signed-off-by: Junwei Zhang <Jerry.Zhang at amd.com>
>>>>>
>>>>> I would put that at the end of amdgpu_bo_vm_update_pte(), but that is
>>>>> only a minor nit pick.
>>>>
>>>> At first, I really put it at the end of amdgpu_bo_vm_update_pte().
>>>> On the 2nd thought, that func may be called by others(although it's not
>>>> for now), so I move it out of there to the caller.
> 
> Well that is exactly the reason I wanted to have it in
> amdgpu_bo_vm_update_pte() :)
> 
> But you are right, there are good arguments for both approach and as
> long as we don't have a second user it doesn't matter.

In general, I think it's better to keep the
reservation_object_reserve_shared calls as close as possible to the
corresponding reservation_object_add_shared_fence calls, otherwise it's
hard to keep track of whether or not a slot is reserved at any given point.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer