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
