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 > >
