Re: [Intel-gfx] [RFC v3 1/3] drm/doc/rfc: VM_BIND feature design document

From: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
To: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	daniel.vetter@intel.com
Cc: thomas.hellstrom@intel.com, christian.koenig@amd.com,
	chris.p.wilson@intel.com
Subject: Re: [Intel-gfx] [RFC v3 1/3] drm/doc/rfc: VM_BIND feature design document
Date: Wed, 1 Jun 2022 17:25:49 +0300	[thread overview]
Message-ID: <43746609-4f60-f347-5934-6680516297dd@intel.com> (raw)
In-Reply-To: <20220517183212.20274-2-niranjana.vishwanathapura@intel.com>

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