Re: [Intel-gfx] [RFC PATCH v3 10/17] drm/i915/vm_bind: Implement I915_GEM_EXECBUFFER3 ioctl
On Mon, Sep 05, 2022 at 04:08:57PM +0100, Tvrtko Ursulin wrote: On 02/09/2022 06:41, Niranjana Vishwanathapura wrote: On Thu, Sep 01, 2022 at 08:58:57AM +0100, Tvrtko Ursulin wrote: On 01/09/2022 06:09, Niranjana Vishwanathapura wrote: On Wed, Aug 31, 2022 at 08:38:48AM +0100, Tvrtko Ursulin wrote: On 27/08/2022 20:43, Andi Shyti wrote: From: Niranjana Vishwanathapura Implement 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 list of objects to validate bind as all required objects binding would have been requested by the userspace before submitting the execbuf3. And the legacy support like relocations etc are removed. Signed-off-by: Niranjana Vishwanathapura Signed-off-by: Ramalingam C Signed-off-by: Andi Shyti --- [snip] +static void signal_fence_array(const struct i915_execbuffer *eb, + struct dma_fence * const fence) +{ + unsigned int n; + + for (n = 0; n < eb->num_fences; n++) { + struct drm_syncobj *syncobj; + unsigned int flags; + + syncobj = ptr_unpack_bits(eb->fences[n].syncobj, &flags, 2); + if (!(flags & I915_TIMELINE_FENCE_SIGNAL)) + continue; + + if (eb->fences[n].chain_fence) { + drm_syncobj_add_point(syncobj, + eb->fences[n].chain_fence, + fence, + eb->fences[n].value); + /* + * The chain's ownership is transferred to the + * timeline. + */ + eb->fences[n].chain_fence = NULL; + } else { + drm_syncobj_replace_fence(syncobj, fence); + } + } +} Semi-random place to ask - how many of the code here is direct copy of existing functions from i915_gem_execbuffer.c? There seems to be some 100% copies at least. And then some more with small tweaks. Spend some time and try to figure out some code sharing? During VM_BIND design review, maintainers expressed thought on keeping execbuf3 completely separate and not touch the legacy execbuf path. Got a link so this maintainer can see what exactly was said? Just to make sure there isn't any misunderstanding on what "completely separate" means to different people. Here is one (search for copypaste/copy-paste) https://patchwork.freedesktop.org/patch/486608/?series=93447&rev=3 It is hard to search for old discussion threads. May be maintainers can provide feedback here directly. Dave, Daniel? :) Thanks. I had a read and don't see a fundamental conflict with what I said. Conclusion seemed to be to go with a new ioctl and implement code sharing where it makes sense. Which is what TODO in the cover letter acknowledges so there should be no disagreement really. I also think, execbuf3 should be fully separate. We can do some code sharing where is a close 100% copy (there is a TODO in cover letter). There are some changes like the timeline fence array handling here which looks similar, but the uapi is not exactly the same. Probably, we should keep them separate and not try to force code sharing at least at this point. Okay did not spot that TODO in the cover. But fair since it is RFC to be unfinished. I do however think it should be improved before considering the merge. Because looking at the patch, 100% copies are: for_each_batch_create_order for_each_batch_add_order eb_throttle eb_pin_timeline eb_pin_engine eb_put_engine __free_fence_array put_fence_array await_fence_array signal_fence_array retire_requests eb_request_add eb_requests_get eb_requests_put eb_find_context Quite a lot. Then there is a bunch of almost same functions which could be shared if there weren't two incompatible local struct i915_execbuffer's. Especially given when the out fence TODO item gets handled a chunk more will also become a 100% copy. There are difinitely a few which is 100% copies hence should have a shared code. But some are not. Like, fence_array stuff though looks very similar, the uapi structures are different between execbuf3 and legacy execbuf. The internal flags are also different (eg., __EXEC3_ENGINE_PINNED vs __EXEC_ENGINE_PINNED) which causes minor differences hence not a 100% copy. So, I am not convinced if it is worth carrying legacy stuff into execbuf3 code. I think we need to look at these on a case by case basis and see if abstracting common functionality to a separate shared code makes sense or it is better to keep the code separate. No one is suggesting to carry any legacy stuff into eb3. What I'd suggest is to start something like i915_gem_eb_common.h|c and stuff the 100% copies from the above list in there. Common struct eb with struct eb2 and eb3 inheriting from it should do the trick. Similarly eb->flags shouldn't be a hard problem to solve. Then you see what remains and whether it makes sense to consolidate further. Tvrtko,
Re: [Intel-gfx] [RFC PATCH v3 10/17] drm/i915/vm_bind: Implement I915_GEM_EXECBUFFER3 ioctl
On 02/09/2022 06:41, Niranjana Vishwanathapura wrote: On Thu, Sep 01, 2022 at 08:58:57AM +0100, Tvrtko Ursulin wrote: On 01/09/2022 06:09, Niranjana Vishwanathapura wrote: On Wed, Aug 31, 2022 at 08:38:48AM +0100, Tvrtko Ursulin wrote: On 27/08/2022 20:43, Andi Shyti wrote: From: Niranjana Vishwanathapura Implement 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 list of objects to validate bind as all required objects binding would have been requested by the userspace before submitting the execbuf3. And the legacy support like relocations etc are removed. Signed-off-by: Niranjana Vishwanathapura Signed-off-by: Ramalingam C Signed-off-by: Andi Shyti --- [snip] +static void signal_fence_array(const struct i915_execbuffer *eb, + struct dma_fence * const fence) +{ + unsigned int n; + + for (n = 0; n < eb->num_fences; n++) { + struct drm_syncobj *syncobj; + unsigned int flags; + + syncobj = ptr_unpack_bits(eb->fences[n].syncobj, &flags, 2); + if (!(flags & I915_TIMELINE_FENCE_SIGNAL)) + continue; + + if (eb->fences[n].chain_fence) { + drm_syncobj_add_point(syncobj, + eb->fences[n].chain_fence, + fence, + eb->fences[n].value); + /* + * The chain's ownership is transferred to the + * timeline. + */ + eb->fences[n].chain_fence = NULL; + } else { + drm_syncobj_replace_fence(syncobj, fence); + } + } +} Semi-random place to ask - how many of the code here is direct copy of existing functions from i915_gem_execbuffer.c? There seems to be some 100% copies at least. And then some more with small tweaks. Spend some time and try to figure out some code sharing? During VM_BIND design review, maintainers expressed thought on keeping execbuf3 completely separate and not touch the legacy execbuf path. Got a link so this maintainer can see what exactly was said? Just to make sure there isn't any misunderstanding on what "completely separate" means to different people. Here is one (search for copypaste/copy-paste) https://patchwork.freedesktop.org/patch/486608/?series=93447&rev=3 It is hard to search for old discussion threads. May be maintainers can provide feedback here directly. Dave, Daniel? :) Thanks. I had a read and don't see a fundamental conflict with what I said. Conclusion seemed to be to go with a new ioctl and implement code sharing where it makes sense. Which is what TODO in the cover letter acknowledges so there should be no disagreement really. I also think, execbuf3 should be fully separate. We can do some code sharing where is a close 100% copy (there is a TODO in cover letter). There are some changes like the timeline fence array handling here which looks similar, but the uapi is not exactly the same. Probably, we should keep them separate and not try to force code sharing at least at this point. Okay did not spot that TODO in the cover. But fair since it is RFC to be unfinished. I do however think it should be improved before considering the merge. Because looking at the patch, 100% copies are: for_each_batch_create_order for_each_batch_add_order eb_throttle eb_pin_timeline eb_pin_engine eb_put_engine __free_fence_array put_fence_array await_fence_array signal_fence_array retire_requests eb_request_add eb_requests_get eb_requests_put eb_find_context Quite a lot. Then there is a bunch of almost same functions which could be shared if there weren't two incompatible local struct i915_execbuffer's. Especially given when the out fence TODO item gets handled a chunk more will also become a 100% copy. There are difinitely a few which is 100% copies hence should have a shared code. But some are not. Like, fence_array stuff though looks very similar, the uapi structures are different between execbuf3 and legacy execbuf. The internal flags are also different (eg., __EXEC3_ENGINE_PINNED vs __EXEC_ENGINE_PINNED) which causes minor differences hence not a 100% copy. So, I am not convinced if it is worth carrying legacy stuff into execbuf3 code. I think we need to look at these on a case by case basis and see if abstracting common functionality to a separate shared code makes sense or it is better to keep the code separate. No one is suggesting to carry any legacy stuff into eb3. What I'd suggest is to start something like i915_gem_eb_common.h|c and stuff the 100% copies from the above list in there. Common struct eb with struct eb2 and eb3 inheriting from it should do the trick. Similarly eb->flags shouldn't be a hard problem to solve. Then you see what remains and whether it makes sense to consolidate further. Regards, Tvrtko This could be done by having a common struct i915_execbuff
Re: [Intel-gfx] [RFC PATCH v3 10/17] drm/i915/vm_bind: Implement I915_GEM_EXECBUFFER3 ioctl
On Thu, Sep 01, 2022 at 08:58:57AM +0100, Tvrtko Ursulin wrote: On 01/09/2022 06:09, Niranjana Vishwanathapura wrote: On Wed, Aug 31, 2022 at 08:38:48AM +0100, Tvrtko Ursulin wrote: On 27/08/2022 20:43, Andi Shyti wrote: From: Niranjana Vishwanathapura Implement 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 list of objects to validate bind as all required objects binding would have been requested by the userspace before submitting the execbuf3. And the legacy support like relocations etc are removed. Signed-off-by: Niranjana Vishwanathapura Signed-off-by: Ramalingam C Signed-off-by: Andi Shyti --- [snip] +static void signal_fence_array(const struct i915_execbuffer *eb, + struct dma_fence * const fence) +{ + unsigned int n; + + for (n = 0; n < eb->num_fences; n++) { + struct drm_syncobj *syncobj; + unsigned int flags; + + syncobj = ptr_unpack_bits(eb->fences[n].syncobj, &flags, 2); + if (!(flags & I915_TIMELINE_FENCE_SIGNAL)) + continue; + + if (eb->fences[n].chain_fence) { + drm_syncobj_add_point(syncobj, + eb->fences[n].chain_fence, + fence, + eb->fences[n].value); + /* + * The chain's ownership is transferred to the + * timeline. + */ + eb->fences[n].chain_fence = NULL; + } else { + drm_syncobj_replace_fence(syncobj, fence); + } + } +} Semi-random place to ask - how many of the code here is direct copy of existing functions from i915_gem_execbuffer.c? There seems to be some 100% copies at least. And then some more with small tweaks. Spend some time and try to figure out some code sharing? During VM_BIND design review, maintainers expressed thought on keeping execbuf3 completely separate and not touch the legacy execbuf path. Got a link so this maintainer can see what exactly was said? Just to make sure there isn't any misunderstanding on what "completely separate" means to different people. Here is one (search for copypaste/copy-paste) https://patchwork.freedesktop.org/patch/486608/?series=93447&rev=3 It is hard to search for old discussion threads. May be maintainers can provide feedback here directly. Dave, Daniel? :) I also think, execbuf3 should be fully separate. We can do some code sharing where is a close 100% copy (there is a TODO in cover letter). There are some changes like the timeline fence array handling here which looks similar, but the uapi is not exactly the same. Probably, we should keep them separate and not try to force code sharing at least at this point. Okay did not spot that TODO in the cover. But fair since it is RFC to be unfinished. I do however think it should be improved before considering the merge. Because looking at the patch, 100% copies are: for_each_batch_create_order for_each_batch_add_order eb_throttle eb_pin_timeline eb_pin_engine eb_put_engine __free_fence_array put_fence_array await_fence_array signal_fence_array retire_requests eb_request_add eb_requests_get eb_requests_put eb_find_context Quite a lot. Then there is a bunch of almost same functions which could be shared if there weren't two incompatible local struct i915_execbuffer's. Especially given when the out fence TODO item gets handled a chunk more will also become a 100% copy. There are difinitely a few which is 100% copies hence should have a shared code. But some are not. Like, fence_array stuff though looks very similar, the uapi structures are different between execbuf3 and legacy execbuf. The internal flags are also different (eg., __EXEC3_ENGINE_PINNED vs __EXEC_ENGINE_PINNED) which causes minor differences hence not a 100% copy. So, I am not convinced if it is worth carrying legacy stuff into execbuf3 code. I think we need to look at these on a case by case basis and see if abstracting common functionality to a separate shared code makes sense or it is better to keep the code separate. This could be done by having a common struct i915_execbuffer and then eb2 and eb3 specific parts which inherit from it. After that is done it should be easier to see if it makes sense to do something more and how. I am not a big fan of it. I think we should not try to load the execbuf3 code with the legacy stuff. Niranjana Regards, Tvrtko
Re: [Intel-gfx] [RFC PATCH v3 10/17] drm/i915/vm_bind: Implement I915_GEM_EXECBUFFER3 ioctl
On 01/09/2022 06:09, Niranjana Vishwanathapura wrote: On Wed, Aug 31, 2022 at 08:38:48AM +0100, Tvrtko Ursulin wrote: On 27/08/2022 20:43, Andi Shyti wrote: From: Niranjana Vishwanathapura Implement 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 list of objects to validate bind as all required objects binding would have been requested by the userspace before submitting the execbuf3. And the legacy support like relocations etc are removed. Signed-off-by: Niranjana Vishwanathapura Signed-off-by: Ramalingam C Signed-off-by: Andi Shyti --- [snip] +static void signal_fence_array(const struct i915_execbuffer *eb, + struct dma_fence * const fence) +{ + unsigned int n; + + for (n = 0; n < eb->num_fences; n++) { + struct drm_syncobj *syncobj; + unsigned int flags; + + syncobj = ptr_unpack_bits(eb->fences[n].syncobj, &flags, 2); + if (!(flags & I915_TIMELINE_FENCE_SIGNAL)) + continue; + + if (eb->fences[n].chain_fence) { + drm_syncobj_add_point(syncobj, + eb->fences[n].chain_fence, + fence, + eb->fences[n].value); + /* + * The chain's ownership is transferred to the + * timeline. + */ + eb->fences[n].chain_fence = NULL; + } else { + drm_syncobj_replace_fence(syncobj, fence); + } + } +} Semi-random place to ask - how many of the code here is direct copy of existing functions from i915_gem_execbuffer.c? There seems to be some 100% copies at least. And then some more with small tweaks. Spend some time and try to figure out some code sharing? During VM_BIND design review, maintainers expressed thought on keeping execbuf3 completely separate and not touch the legacy execbuf path. Got a link so this maintainer can see what exactly was said? Just to make sure there isn't any misunderstanding on what "completely separate" means to different people. I also think, execbuf3 should be fully separate. We can do some code sharing where is a close 100% copy (there is a TODO in cover letter). There are some changes like the timeline fence array handling here which looks similar, but the uapi is not exactly the same. Probably, we should keep them separate and not try to force code sharing at least at this point. Okay did not spot that TODO in the cover. But fair since it is RFC to be unfinished. I do however think it should be improved before considering the merge. Because looking at the patch, 100% copies are: for_each_batch_create_order for_each_batch_add_order eb_throttle eb_pin_timeline eb_pin_engine eb_put_engine __free_fence_array put_fence_array await_fence_array signal_fence_array retire_requests eb_request_add eb_requests_get eb_requests_put eb_find_context Quite a lot. Then there is a bunch of almost same functions which could be shared if there weren't two incompatible local struct i915_execbuffer's. Especially given when the out fence TODO item gets handled a chunk more will also become a 100% copy. This could be done by having a common struct i915_execbuffer and then eb2 and eb3 specific parts which inherit from it. After that is done it should be easier to see if it makes sense to do something more and how. Regards, Tvrtko
Re: [Intel-gfx] [RFC PATCH v3 10/17] drm/i915/vm_bind: Implement I915_GEM_EXECBUFFER3 ioctl
On Wed, Aug 31, 2022 at 08:38:48AM +0100, Tvrtko Ursulin wrote: On 27/08/2022 20:43, Andi Shyti wrote: From: Niranjana Vishwanathapura Implement 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 list of objects to validate bind as all required objects binding would have been requested by the userspace before submitting the execbuf3. And the legacy support like relocations etc are removed. Signed-off-by: Niranjana Vishwanathapura Signed-off-by: Ramalingam C Signed-off-by: Andi Shyti --- drivers/gpu/drm/i915/Makefile |1 + .../gpu/drm/i915/gem/i915_gem_execbuffer3.c | 1000 + drivers/gpu/drm/i915/gem/i915_gem_ioctls.h|2 + include/uapi/drm/i915_drm.h | 62 + 4 files changed, 1065 insertions(+) create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index 4e1627e96c6e0..38cd1c5bc1a55 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -148,6 +148,7 @@ gem-y += \ gem/i915_gem_dmabuf.o \ gem/i915_gem_domain.o \ gem/i915_gem_execbuffer.o \ + gem/i915_gem_execbuffer3.o \ gem/i915_gem_internal.o \ gem/i915_gem_object.o \ gem/i915_gem_lmem.o \ diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c new file mode 100644 index 0..a3d767cd9f808 --- /dev/null +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c @@ -0,0 +1,1000 @@ +// SPDX-License-Identifier: MIT +/* + * Copyright © 2022 Intel Corporation + */ + +#include +#include +#include + +#include + +#include "gt/intel_context.h" +#include "gt/intel_gpu_commands.h" +#include "gt/intel_gt.h" +#include "gt/intel_gt_pm.h" +#include "gt/intel_ring.h" + +#include "i915_drv.h" +#include "i915_file_private.h" +#include "i915_gem_context.h" +#include "i915_gem_ioctls.h" +#include "i915_gem_vm_bind.h" +#include "i915_trace.h" + +#define __EXEC3_ENGINE_PINNED BIT_ULL(32) +#define __EXEC3_INTERNAL_FLAGS (~0ull << 32) + +/* Catch emission of unexpected errors for CI! */ +#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM) +#undef EINVAL +#define EINVAL ({ \ + DRM_DEBUG_DRIVER("EINVAL at %s:%d\n", __func__, __LINE__); \ + 22; \ +}) +#endif + +/** + * DOC: User command execution with execbuf3 ioctl + * + * A VM in VM_BIND mode will not support older execbuf mode of binding. + * The execbuf ioctl handling in VM_BIND mode differs significantly from the + * older execbuf2 ioctl (See struct drm_i915_gem_execbuffer2). + * Hence, a new execbuf3 ioctl has been added to support VM_BIND mode. (See + * struct drm_i915_gem_execbuffer3). The execbuf3 ioctl will not accept any + * execlist. Hence, no support for implicit sync. + * + * The new execbuf3 ioctl only works in VM_BIND mode and the VM_BIND mode only + * works with execbuf3 ioctl for submission. + * + * The execbuf3 ioctl directly specifies the batch addresses instead of as + * object handles as in execbuf2 ioctl. The execbuf3 ioctl will also not + * support many of the older features like in/out/submit fences, fence array, + * default gem context etc. (See struct drm_i915_gem_execbuffer3). + * + * In VM_BIND mode, VA allocation is completely managed by the user instead of + * the i915 driver. Hence all VA assignment, eviction are not applicable in + * VM_BIND mode. Also, for determining object activeness, VM_BIND mode will not + * be using the i915_vma active reference tracking. It will instead check the + * dma-resv object's fence list for that. + * + * So, a lot of code supporting execbuf2 ioctl, like relocations, VA evictions, + * vma lookup table, implicit sync, vma active reference tracking etc., are not + * applicable for execbuf3 ioctl. + */ + +struct eb_fence { + struct drm_syncobj *syncobj; + struct dma_fence *dma_fence; + u64 value; + struct dma_fence_chain *chain_fence; +}; + +/** + * struct i915_execbuffer - execbuf struct for execbuf3 + * @i915: reference to the i915 instance we run on + * @file: drm file reference + * args: execbuf3 ioctl structure + * @gt: reference to the gt instance ioctl submitted for + * @context: logical state for the request + * @gem_context: callers context + * @requests: requests to be build + * @composite_fence: used for excl fence in dma_resv objects when > 1 BB submitted + * @ww: i915_gem_ww_ctx instance + * @num_batches: number of batches submitted + * @batch_addresses: addresses corresponds to the submitted batches + * @batches: references to the i915_vmas corresponding to the batches + */ +struct i915_execbuffer { + struct drm_i915_private *i915; + struct drm_file *file; + struct drm_i915_gem_execbuffer3 *args; + + struct intel_gt *gt; + struct intel_context *context; +
Re: [Intel-gfx] [RFC PATCH v3 10/17] drm/i915/vm_bind: Implement I915_GEM_EXECBUFFER3 ioctl
On 27/08/2022 20:43, Andi Shyti wrote: From: Niranjana Vishwanathapura Implement 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 list of objects to validate bind as all required objects binding would have been requested by the userspace before submitting the execbuf3. And the legacy support like relocations etc are removed. Signed-off-by: Niranjana Vishwanathapura Signed-off-by: Ramalingam C Signed-off-by: Andi Shyti --- drivers/gpu/drm/i915/Makefile |1 + .../gpu/drm/i915/gem/i915_gem_execbuffer3.c | 1000 + drivers/gpu/drm/i915/gem/i915_gem_ioctls.h|2 + include/uapi/drm/i915_drm.h | 62 + 4 files changed, 1065 insertions(+) create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index 4e1627e96c6e0..38cd1c5bc1a55 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -148,6 +148,7 @@ gem-y += \ gem/i915_gem_dmabuf.o \ gem/i915_gem_domain.o \ gem/i915_gem_execbuffer.o \ + gem/i915_gem_execbuffer3.o \ gem/i915_gem_internal.o \ gem/i915_gem_object.o \ gem/i915_gem_lmem.o \ diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c new file mode 100644 index 0..a3d767cd9f808 --- /dev/null +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c @@ -0,0 +1,1000 @@ +// SPDX-License-Identifier: MIT +/* + * Copyright © 2022 Intel Corporation + */ + +#include +#include +#include + +#include + +#include "gt/intel_context.h" +#include "gt/intel_gpu_commands.h" +#include "gt/intel_gt.h" +#include "gt/intel_gt_pm.h" +#include "gt/intel_ring.h" + +#include "i915_drv.h" +#include "i915_file_private.h" +#include "i915_gem_context.h" +#include "i915_gem_ioctls.h" +#include "i915_gem_vm_bind.h" +#include "i915_trace.h" + +#define __EXEC3_ENGINE_PINNED BIT_ULL(32) +#define __EXEC3_INTERNAL_FLAGS (~0ull << 32) + +/* Catch emission of unexpected errors for CI! */ +#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM) +#undef EINVAL +#define EINVAL ({ \ + DRM_DEBUG_DRIVER("EINVAL at %s:%d\n", __func__, __LINE__); \ + 22; \ +}) +#endif + +/** + * DOC: User command execution with execbuf3 ioctl + * + * A VM in VM_BIND mode will not support older execbuf mode of binding. + * The execbuf ioctl handling in VM_BIND mode differs significantly from the + * older execbuf2 ioctl (See struct drm_i915_gem_execbuffer2). + * Hence, a new execbuf3 ioctl has been added to support VM_BIND mode. (See + * struct drm_i915_gem_execbuffer3). The execbuf3 ioctl will not accept any + * execlist. Hence, no support for implicit sync. + * + * The new execbuf3 ioctl only works in VM_BIND mode and the VM_BIND mode only + * works with execbuf3 ioctl for submission. + * + * The execbuf3 ioctl directly specifies the batch addresses instead of as + * object handles as in execbuf2 ioctl. The execbuf3 ioctl will also not + * support many of the older features like in/out/submit fences, fence array, + * default gem context etc. (See struct drm_i915_gem_execbuffer3). + * + * In VM_BIND mode, VA allocation is completely managed by the user instead of + * the i915 driver. Hence all VA assignment, eviction are not applicable in + * VM_BIND mode. Also, for determining object activeness, VM_BIND mode will not + * be using the i915_vma active reference tracking. It will instead check the + * dma-resv object's fence list for that. + * + * So, a lot of code supporting execbuf2 ioctl, like relocations, VA evictions, + * vma lookup table, implicit sync, vma active reference tracking etc., are not + * applicable for execbuf3 ioctl. + */ + +struct eb_fence { + struct drm_syncobj *syncobj; + struct dma_fence *dma_fence; + u64 value; + struct dma_fence_chain *chain_fence; +}; + +/** + * struct i915_execbuffer - execbuf struct for execbuf3 + * @i915: reference to the i915 instance we run on + * @file: drm file reference + * args: execbuf3 ioctl structure + * @gt: reference to the gt instance ioctl submitted for + * @context: logical state for the request + * @gem_context: callers context + * @requests: requests to be build + * @composite_fence: used for excl fence in dma_resv objects when > 1 BB submitted + * @ww: i915_gem_ww_ctx instance + * @num_batches: number of batches submitted + * @batch_addresses: addresses corresponds to the submitted batches + * @batches: references to the i915_vmas corresponding to the batches + */ +struct i915_execbuffer { + struct drm_i915_private *i915; + struct drm_file *file; + struct drm_i915_gem_execbuffer3 *args; + + struct intel_gt *gt; + struct intel_context *context; + struct i915_gem_context *gem_context; + + struct