[PATCH] drm/amdgpu: re-validate per VM BOs if required
zhoucm1
zhoucm1 at amd.com
Wed Mar 21 10:31:46 UTC 2018
On 2018年03月20日 17:13, zhoucm1 wrote:
>
>
> On 2018年03月20日 15:49, zhoucm1 wrote:
>>
>>
>> On 2018年03月19日 18:50, Christian König wrote:
>>> If a per VM BO ends up in a allowed domain it never moves back into the
>>> prefered domain.
>>>
>>> Signed-off-by: Christian König <christian.koenig at amd.com>
>> Yeah, it's better than mine, Reviewed-by: Chunming Zhou
>> <david1.zhou at amd.com>
>>
>> the left problem is BOs validation order.
>> For old bo list usage, it has fixed order for BOs in bo list,
>> but for per-vm-bo feature, the order isn't fixed, which will result
>> in the performance is undulate.
>> e.g. steam game F1 generally is 40fps when using old bo list, it's
>> very stable, but when enabling per-vm-bo feature, the fps is between
>> 37~40fps.
> even worse, sometime, fps could drop to 18fps.
> the root cause is some *KEY* BOs are randomly placed to allowed domain
> without fixed validation order.
> For old bo list case, its later BOs can be evictable, so the front BOs
> are validated with preferred domain first, that is also why the
> performance is stable to 40fps when using old bo list.
>
> Some more thinking:
> Could user space pass validation order for per-vm BOs? or set BOs
> index for every per-vm BO?
Ping...
If no objection, I will try to make a bo list for per-vm case to
determine the validation order.
Regards,
David Zhou
>
> Any comment?
>
>
> Regards,
> David Zhou
>
>>
>> Any thought?
>>
>> Regards,
>> David Zhou
>>
>>> ---
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 15 +++++++++++++--
>>> 1 file changed, 13 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>> index 24474294c92a..e8b515dd032c 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>> @@ -1770,14 +1770,16 @@ int amdgpu_vm_handle_moved(struct
>>> amdgpu_device *adev,
>>> spin_lock(&vm->status_lock);
>>> while (!list_empty(&vm->moved)) {
>>> - struct amdgpu_bo_va *bo_va;
>>> struct reservation_object *resv;
>>> + struct amdgpu_bo_va *bo_va;
>>> + struct amdgpu_bo *bo;
>>> bo_va = list_first_entry(&vm->moved,
>>> struct amdgpu_bo_va, base.vm_status);
>>> spin_unlock(&vm->status_lock);
>>> - resv = bo_va->base.bo->tbo.resv;
>>> + bo = bo_va->base.bo;
>>> + resv = bo->tbo.resv;
>>> /* Per VM BOs never need to bo cleared in the page
>>> tables */
>>> if (resv == vm->root.base.bo->tbo.resv)
>>> @@ -1797,6 +1799,15 @@ int amdgpu_vm_handle_moved(struct
>>> amdgpu_device *adev,
>>> reservation_object_unlock(resv);
>>> spin_lock(&vm->status_lock);
>>> +
>>> + /* If the BO prefers to be in VRAM, but currently isn't add it
>>> + * back to the evicted list so that it gets validated again on
>>> + * the next command submission.
>>> + */
>>> + if (resv == vm->root.base.bo->tbo.resv &&
>>> + bo->preferred_domains == AMDGPU_GEM_DOMAIN_VRAM &&
>>> + bo->tbo.mem.mem_type != TTM_PL_VRAM)
>>> + list_add_tail(&bo_va->base.vm_status, &vm->evicted);
>>> }
>>> spin_unlock(&vm->status_lock);
>>
>
More information about the amd-gfx
mailing list