[PATCH v2 1/2] drm/amdgpu: Auto-validate DMABuf imports in compute VMs
Felix Kuehling
felix.kuehling at amd.com
Thu Dec 14 21:57:38 UTC 2023
On 2023-12-14 16:40, Felix Kuehling wrote:
>> Fence slot reservation should bet done by the caller and not here.
>
> The caller doesn't necessarily have the BO list to create all those
> fences. The whole point of doing this in the VM code was, to use the
> "BO lists" maintained by the VM state machine. Having to find all the
> BOs in the caller to add these fences kind of defeats the purpose.
> Then I can do the validation there too, and I don't need to do the
> validation in the VM code at all.
>
> The idea here is, that I reserve the fence slots in amdgpu_vm_validate
> and use the fence slots in amdgpu_vm_fence_imports. Conceptually,
> amdgpu_vm_validate is where we enumerate and validate BOs before
> command submission. This is a convenient place because I already
> require that the BOs must be reserved. amdgpu_vm_fence_imports is
> where we add the fences after command submission. At that point the
> BOs are not reserved any more, and I cannot reserve them without
> risking race conditions, because I'm holding the VM state spinlock.
>
OK, I rethought this. The imports share the reservation (and all the
fences) with the exported BOs. If I have the exported BOs reserved and
in a DRM exec context, I don't even need amdgpu_vm_fence_imports at all.
So I don't need the extra fence slots either. I'll simplify this.
If I add support later for dynamically reserving imports of things that
aren't in the drm_exec context yet, then I will need to add back code to
reserve and add fences in the VM code again.
Regards,
Felix
More information about the amd-gfx
mailing list