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
