On 17/05/2022 21:32, Niranjana Vishwanathapura wrote:
+VM_BIND/UNBIND ioctl will immediately start binding/unbinding the mapping in an
+async worker. The binding and unbinding will work like a special GPU engine.
+The binding and unbinding operations are serialized and will wait on specified
+input fences before the operation and will signal the output fences upon the
+completion of the operation. Due to serialization, completion of an operation
+will also indicate that all previous operations are also complete.
I guess we should avoid saying "will immediately start
binding/unbinding" if there are fences involved.
And the fact that it's happening in an async worker seem to imply it's
not immediate.
I have a question on the behavior of the bind operation when no input
fence is provided. Let say I do :
VM_BIND (out_fence=fence1)
VM_BIND (out_fence=fence2)
VM_BIND (out_fence=fence3)
In what order are the fences going to be signaled?
In the order of VM_BIND ioctls? Or out of order?
Because you wrote "serialized I assume it's : in order
One thing I didn't realize is that because we only get one "VM_BIND"
engine, there is a disconnect from the Vulkan specification.
In Vulkan VM_BIND operations are serialized but per engine.
So you could have something like this :
VM_BIND (engine=rcs0, in_fence=fence1, out_fence=fence2)
VM_BIND (engine=ccs0, in_fence=fence3, out_fence=fence4)
fence1 is not signaled
fence3 is signaled
So the second VM_BIND will proceed before the first VM_BIND.
I guess we can deal with that scenario in userspace by doing the wait
ourselves in one thread per engines.
But then it makes the VM_BIND input fences useless.
Daniel : what do you think? Should be rework this or just deal with wait
fences in userspace?
Sorry I noticed this late.
-Lionel
