[PATCH] drm/amdgpu: add VM update fences back to the root PD v2
Christian König
christian.koenig at amd.com
Wed Feb 19 16:34:30 UTC 2020
For amd-staging-drm-next you need the first version of the patch.
For drm-misc-next or drm-next you need the second version of the patch.
We probably need to merge the patch through drm-misc-next anyway since
there is also the patch which causes the problems.
Christian.
Am 19.02.20 um 16:47 schrieb Tom St Denis:
> The tip of origin/amd-staging-drm-next for me is:
>
> commit 7fd3b632e17e55c5ffd008f9f025754e7daa1b66
> Refs: {origin/amd-staging-drm-next}, v5.4-rc7-2847-g7fd3b632e17e
> Author: Monk Liu <Monk.Liu at amd.com>
> AuthorDate: Thu Feb 6 23:55:58 2020 +0800
> Commit: Monk Liu <Monk.Liu at amd.com>
> CommitDate: Wed Feb 19 13:33:02 2020 +0800
>
> drm/amdgpu: fix colliding of preemption
>
> what:
> some os preemption path is messed up with world switch preemption
>
> fix:
> cleanup those logics so os preemption not mixed with world switch
>
> this patch is a general fix for issues comes from SRIOV MCBP, but
> there is still UMD side issues not resovlved yet, so this patch
> cannot fix all world switch bug.
>
> Signed-off-by: Monk Liu <Monk.Liu at amd.com>
> Acked-by: Hawking Zhang <Hawking.Zhang at amd.com>
>
> Which I had fetched just an hour ago.
>
> On 2020-02-19 10:41 a.m., Christian König wrote:
>> Well what branch are you trying to merge that into?
>>
>> The conflict resolution should be simple, just keep the
>> vm->update_funcs->prepare(...) line as it is in your branch.
>>
>> When you get those errors then something went wrong in your rebase.
>>
>> Christian.
>>
>> Am 19.02.20 um 16:14 schrieb Tom St Denis:
>>> Doesn't build even with conflict resolved:
>>>
>>> [root at raven linux]# make
>>> CALL scripts/checksyscalls.sh
>>> CALL scripts/atomic/check-atomics.sh
>>> DESCEND objtool
>>> CHK include/generated/compile.h
>>> CC [M] drivers/gpu/drm/amd/amdgpu/amdgpu_vm.o
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c: In function
>>> ‘amdgpu_vm_bo_update_mapping’:
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1612:41: error: ‘owner’
>>> undeclared (first use in this function)
>>> 1612 | r = vm->update_funcs->prepare(¶ms, owner, exclusive);
>>> | ^~~~~
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1612:41: note: each
>>> undeclared identifier is reported only once for each function it
>>> appears in
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1612:48: error: ‘exclusive’
>>> undeclared (first use in this function)
>>> 1612 | r = vm->update_funcs->prepare(¶ms, owner, exclusive);
>>> | ^~~~~~~~~
>>> make[4]: *** [scripts/Makefile.build:266:
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.o] Error 1
>>> make[3]: *** [scripts/Makefile.build:509:
>>> drivers/gpu/drm/amd/amdgpu] Error 2
>>> make[2]: *** [scripts/Makefile.build:509: drivers/gpu/drm] Error 2
>>> make[1]: *** [scripts/Makefile.build:509: drivers/gpu] Error 2
>>> make: *** [Makefile:1649: drivers] Error 2
>>>
>>> Should I just move to drm-misc-next?
>>>
>>> tom
>>>
>>> On 2020-02-19 10:02 a.m., Christian König wrote:
>>>> Add update fences to the root PD while mapping BOs.
>>>>
>>>> Otherwise PDs freed during the mapping won't wait for
>>>> updates to finish and can cause corruptions.
>>>>
>>>> v2: rebased on drm-misc-next
>>>>
>>>> Signed-off-by: Christian König <christian.koenig at amd.com>
>>>> Fixes: 90b69cdc5f159 drm/amdgpu: stop adding VM updates fences to
>>>> the resv obj
>>>> ---
>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 14 ++++++++++++--
>>>> 1 file changed, 12 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>>> index d16231d6a790..ef73fa94f357 100644
>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>>> @@ -588,8 +588,8 @@ void amdgpu_vm_get_pd_bo(struct amdgpu_vm *vm,
>>>> {
>>>> entry->priority = 0;
>>>> entry->tv.bo = &vm->root.base.bo->tbo;
>>>> - /* One for TTM and one for the CS job */
>>>> - entry->tv.num_shared = 2;
>>>> + /* Two for VM updates, one for TTM and one for the CS job */
>>>> + entry->tv.num_shared = 4;
>>>> entry->user_pages = NULL;
>>>> list_add(&entry->tv.head, validated);
>>>> }
>>>> @@ -1591,6 +1591,16 @@ static int
>>>> amdgpu_vm_bo_update_mapping(struct amdgpu_device *adev,
>>>> goto error_unlock;
>>>> }
>>>> + if (flags & AMDGPU_PTE_VALID) {
>>>> + struct amdgpu_bo *root = vm->root.base.bo;
>>>> +
>>>> + if (!dma_fence_is_signaled(vm->last_direct))
>>>> + amdgpu_bo_fence(root, vm->last_direct, true);
>>>> +
>>>> + if (!dma_fence_is_signaled(vm->last_delayed))
>>>> + amdgpu_bo_fence(root, vm->last_delayed, true);
>>>> + }
>>>> +
>>>> r = vm->update_funcs->prepare(¶ms, owner, exclusive);
>>>> if (r)
>>>> goto error_unlock;
>>
More information about the amd-gfx
mailing list