Should be safe to do. Writers of BOOKKEEP fences: - amdgpu_vm_tlb_flush: Per the comments, only to prevent frees. - amdgpu_vm_sdma_commit: Uses AMDGPU_FENCE_OWNER_VM, which was already ignored by amdgpu_sync_test_fence for cs submissions. - amdgpu_amdkfd_remove_eviction_fence: Adds a stub fence, so always signaled. - amdgpu_amdkfd_bo_validate_and_fence: This is used for eviction fences which shouldn't interact with amdgpu userspace submissions, as we detect owner as AMDGPU_FENCE_OWNER_KFD and then it should be ignored by amdgpu_sync_test_fence for userspace submissions. I've done this for just submissions instead of all dma_sync_resv users as there are some that need to wait for BOOKKEEP fences, at least for now, like the VM update operations. (Yes, I know there is a series to make VM updates less implicit, which currently works through AMDGPU_SYNC_EQ_OWNER/EXPLICIT. I think this doesn't conflict and would like to leave the VM side out of it as much as possible in this series to land something to resolve some radv/radeonsi issues for cross process sharing) Signed-off-by: Bas Nieuwenhuizen <bas@xxxxxxxxxxxxxxxxxxx> --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c index a578da8e2da5..b4f55f40ce0e 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c @@ -1199,7 +1199,7 @@ static int amdgpu_cs_sync_rings(struct amdgpu_cs_parser *p) sync_mode = amdgpu_bo_explicit_sync(bo) ? AMDGPU_SYNC_EXPLICIT : AMDGPU_SYNC_NE_OWNER; r = amdgpu_sync_resv(p->adev, &p->sync, resv, - DMA_RESV_USAGE_BOOKKEEP, sync_mode, + DMA_RESV_USAGE_READ, sync_mode, &fpriv->vm); if (r) return r; -- 2.45.2
