[PATCH v2 1/2] drm/amdgpu: Auto-validate DMABuf imports in compute VMs

[Felix Kuehling]

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