Re: [Intel-gfx] [RFC PATCH v3 00/17] drm/i915/vm_bind: Add VM_BIND functionality

[Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>]

On 27/08/2022 20:43, Andi Shyti wrote:
> Hi,
> 
> just sending the original Niranjana's patch as an RFC. It's v3 as
> the v2 has been reviewed offline with Ramalingam.
> 
> I'm still keeping most of the structure even though some further
> discussion can be done starting from here.
> 
> Copy pasting Niranjana's original cover letter message:
> 
> DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM
> buffer objects (BOs) or sections of a BOs at specified GPU virtual
> addresses on a specified address space (VM). Multiple mappings can map
> to the same physical pages of an object (aliasing). These mappings (also
> referred to as persistent mappings) will be persistent across multiple
> GPU submissions (execbuf calls) issued by the UMD, without user having
> to provide a list of all required mappings during each submission (as
> required by older execbuf mode).
> 
> This patch series support VM_BIND version 1, as described by the param
> I915_PARAM_VM_BIND_VERSION.
> 
> Add new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only works in
> vm_bind mode. The vm_bind mode only works with this new execbuf3 ioctl.
> The new execbuf3 ioctl will not have any execlist support and all the
> legacy support like relocations etc., are removed.

We should consider not overloading the term execlists when really 
talking about the array of struct gem_exec_object2. Before it gets too 
confusing. At least I assume that's what it is meant and eb3 is not 
intended to be used only with the GuC. Alternatively, correct me if I am 
wrong that the term is somehow already established and I did not realise.

Regards,

Tvrtko