On Wed, Jun 01, 2022 at 05:25:49PM +0300, Lionel Landwerlin wrote:
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?
My opinion is rework this but make the ordering via an engine param optional.
e.g. A VM can be configured so all binds are ordered within the VM
e.g. A VM can be configured so all binds accept an engine argument (in the case of the i915 likely this is a gem context handle) and binds ordered with respect to that engine.
This gives UMDs options as the later likely consumes more KMD resources so if a different UMD can live with binds being ordered within the VM they can use a mode consuming less resources.
Matt
Sorry I noticed this late.
-Lionel