[Intel-gfx] [RFC v3 3/3] drm/doc/rfc: VM_BIND uapi definition
Niranjana Vishwanathapura
niranjana.vishwanathapura at intel.com
Thu Jun 9 18:53:03 UTC 2022
On Thu, Jun 09, 2022 at 09:36:48AM +0100, Matthew Auld wrote:
>On 08/06/2022 22:32, Niranjana Vishwanathapura wrote:
>>On Wed, Jun 08, 2022 at 10:12:05AM +0100, Matthew Auld wrote:
>>>On 08/06/2022 08:17, Tvrtko Ursulin wrote:
>>>>
>>>>On 07/06/2022 20:37, Niranjana Vishwanathapura wrote:
>>>>>On Tue, Jun 07, 2022 at 11:27:14AM +0100, Tvrtko Ursulin wrote:
>>>>>>
>>>>>>On 17/05/2022 19:32, Niranjana Vishwanathapura wrote:
>>>>>>>VM_BIND and related uapi definitions
>>>>>>>
>>>>>>>v2: Ensure proper kernel-doc formatting with cross references.
>>>>>>> Also add new uapi and documentation as per review comments
>>>>>>> from Daniel.
>>>>>>>
>>>>>>>Signed-off-by: Niranjana Vishwanathapura
>>>>>>><niranjana.vishwanathapura at intel.com>
>>>>>>>---
>>>>>>> Documentation/gpu/rfc/i915_vm_bind.h | 399
>>>>>>>+++++++++++++++++++++++++++
>>>>>>> 1 file changed, 399 insertions(+)
>>>>>>> create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h
>>>>>>>
>>>>>>>diff --git a/Documentation/gpu/rfc/i915_vm_bind.h
>>>>>>>b/Documentation/gpu/rfc/i915_vm_bind.h
>>>>>>>new file mode 100644
>>>>>>>index 000000000000..589c0a009107
>>>>>>>--- /dev/null
>>>>>>>+++ b/Documentation/gpu/rfc/i915_vm_bind.h
>>>>>>>@@ -0,0 +1,399 @@
>>>>>>>+/* SPDX-License-Identifier: MIT */
>>>>>>>+/*
>>>>>>>+ * Copyright © 2022 Intel Corporation
>>>>>>>+ */
>>>>>>>+
>>>>>>>+/**
>>>>>>>+ * DOC: I915_PARAM_HAS_VM_BIND
>>>>>>>+ *
>>>>>>>+ * VM_BIND feature availability.
>>>>>>>+ * See typedef drm_i915_getparam_t param.
>>>>>>>+ */
>>>>>>>+#define I915_PARAM_HAS_VM_BIND 57
>>>>>>>+
>>>>>>>+/**
>>>>>>>+ * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
>>>>>>>+ *
>>>>>>>+ * Flag to opt-in for VM_BIND mode of binding during VM creation.
>>>>>>>+ * See struct drm_i915_gem_vm_control flags.
>>>>>>>+ *
>>>>>>>+ * A VM in VM_BIND mode will not support the older
>>>>>>>execbuff mode of binding.
>>>>>>>+ * In VM_BIND mode, execbuff ioctl will not accept any
>>>>>>>execlist (ie., the
>>>>>>>+ * &drm_i915_gem_execbuffer2.buffer_count must be 0).
>>>>>>>+ * Also, &drm_i915_gem_execbuffer2.batch_start_offset and
>>>>>>>+ * &drm_i915_gem_execbuffer2.batch_len must be 0.
>>>>>>>+ * DRM_I915_GEM_EXECBUFFER_EXT_BATCH_ADDRESSES extension
>>>>>>>must be provided
>>>>>>>+ * to pass in the batch buffer addresses.
>>>>>>>+ *
>>>>>>>+ * Additionally, I915_EXEC_NO_RELOC, I915_EXEC_HANDLE_LUT and
>>>>>>>+ * I915_EXEC_BATCH_FIRST of
>>>>>>>&drm_i915_gem_execbuffer2.flags must be 0
>>>>>>>+ * (not used) in VM_BIND mode. I915_EXEC_USE_EXTENSIONS
>>>>>>>flag must always be
>>>>>>>+ * set (See struct drm_i915_gem_execbuffer_ext_batch_addresses).
>>>>>>>+ * The buffers_ptr, buffer_count, batch_start_offset and
>>>>>>>batch_len fields
>>>>>>>+ * of struct drm_i915_gem_execbuffer2 are also not used
>>>>>>>and must be 0.
>>>>>>>+ */
>>>>>>>+#define I915_VM_CREATE_FLAGS_USE_VM_BIND (1 << 0)
>>>>>>>+
>>>>>>>+/**
>>>>>>>+ * DOC: I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING
>>>>>>>+ *
>>>>>>>+ * Flag to declare context as long running.
>>>>>>>+ * See struct drm_i915_gem_context_create_ext flags.
>>>>>>>+ *
>>>>>>>+ * Usage of dma-fence expects that they complete in
>>>>>>>reasonable amount of time.
>>>>>>>+ * Compute on the other hand can be long running. Hence
>>>>>>>it is not appropriate
>>>>>>>+ * for compute contexts to export request completion
>>>>>>>dma-fence to user.
>>>>>>>+ * The dma-fence usage will be limited to in-kernel
>>>>>>>consumption only.
>>>>>>>+ * Compute contexts need to use user/memory fence.
>>>>>>>+ *
>>>>>>>+ * So, long running contexts do not support output fences. Hence,
>>>>>>>+ * I915_EXEC_FENCE_OUT (See &drm_i915_gem_execbuffer2.flags and
>>>>>>>+ * I915_EXEC_FENCE_SIGNAL (See
>>>>>>>&drm_i915_gem_exec_fence.flags) are expected
>>>>>>>+ * to be not used.
>>>>>>>+ *
>>>>>>>+ * DRM_I915_GEM_WAIT ioctl call is also not supported for
>>>>>>>objects mapped
>>>>>>>+ * to long running contexts.
>>>>>>>+ */
>>>>>>>+#define I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING (1u << 2)
>>>>>>>+
>>>>>>>+/* VM_BIND related ioctls */
>>>>>>>+#define DRM_I915_GEM_VM_BIND 0x3d
>>>>>>>+#define DRM_I915_GEM_VM_UNBIND 0x3e
>>>>>>>+#define DRM_I915_GEM_WAIT_USER_FENCE 0x3f
>>>>>>>+
>>>>>>>+#define DRM_IOCTL_I915_GEM_VM_BIND
>>>>>>>DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_VM_BIND, struct
>>>>>>>drm_i915_gem_vm_bind)
>>>>>>>+#define DRM_IOCTL_I915_GEM_VM_UNBIND
>>>>>>>DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_VM_UNBIND, struct
>>>>>>>drm_i915_gem_vm_bind)
>>>>>>>+#define DRM_IOCTL_I915_GEM_WAIT_USER_FENCE
>>>>>>>DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_WAIT_USER_FENCE,
>>>>>>>struct drm_i915_gem_wait_user_fence)
>>>>>>>+
>>>>>>>+/**
>>>>>>>+ * struct drm_i915_gem_vm_bind - VA to object mapping to bind.
>>>>>>>+ *
>>>>>>>+ * This structure is passed to VM_BIND ioctl and
>>>>>>>specifies the mapping of GPU
>>>>>>>+ * virtual address (VA) range to the section of an object
>>>>>>>that should be bound
>>>>>>>+ * in the device page table of the specified address space (VM).
>>>>>>>+ * The VA range specified must be unique (ie., not
>>>>>>>currently bound) and can
>>>>>>>+ * be mapped to whole object or a section of the object
>>>>>>>(partial binding).
>>>>>>>+ * Multiple VA mappings can be created to the same
>>>>>>>section of the object
>>>>>>>+ * (aliasing).
>>>>>>>+ */
>>>>>>>+struct drm_i915_gem_vm_bind {
>>>>>>>+ /** @vm_id: VM (address space) id to bind */
>>>>>>>+ __u32 vm_id;
>>>>>>>+
>>>>>>>+ /** @handle: Object handle */
>>>>>>>+ __u32 handle;
>>>>>>>+
>>>>>>>+ /** @start: Virtual Address start to bind */
>>>>>>>+ __u64 start;
>>>>>>>+
>>>>>>>+ /** @offset: Offset in object to bind */
>>>>>>>+ __u64 offset;
>>>>>>>+
>>>>>>>+ /** @length: Length of mapping to bind */
>>>>>>>+ __u64 length;
>>>>>>
>>>>>>Does it support, or should it, equivalent of
>>>>>>EXEC_OBJECT_PAD_TO_SIZE? Or if not userspace is expected to
>>>>>>map the remainder of the space to a dummy object? In which
>>>>>>case would there be any alignment/padding issues preventing
>>>>>>the two bind to be placed next to each other?
>>>>>>
>>>>>>I ask because someone from the compute side asked me about a
>>>>>>problem with their strategy of dealing with overfetch and I
>>>>>>suggested pad to size.
>>>>>>
>>>>>
>>>>>Thanks Tvrtko,
>>>>>I think we shouldn't be needing it. As with VM_BIND VA assignment
>>>>>is completely pushed to userspace, no padding should be necessary
>>>>>once the 'start' and 'size' alignment conditions are met.
>>>>>
>>>>>I will add some documentation on alignment requirement here.
>>>>>Generally, 'start' and 'size' should be 4K aligned. But, I think
>>>>>when we have 64K lmem page sizes (dg2 and xehpsdv), they need to
>>>>>be 64K aligned.
>>>>
>>>>+ Matt
>>>>
>>>>Align to 64k is enough for all overfetch issues?
>>>>
>>>>Apparently compute has a situation where a buffer is received by
>>>>one component and another has to apply more alignment to it, to
>>>>deal with overfetch. Since they cannot grow the actual BO if
>>>>they wanted to VM_BIND a scratch area on top? Or perhaps none of
>>>>this is a problem on discrete and original BO should be
>>>>correctly allocated to start with.
>>>>
>>>>Side question - what about the align to 2MiB mentioned in
>>>>i915_vma_insert to avoid mixing 4k and 64k PTEs? That does not
>>>>apply to discrete?
>>>
>>>Not sure about the overfetch thing, but yeah dg2 & xehpsdv both
>>>require a minimum of 64K pages underneath for local memory, and
>>>the BO size will also be rounded up accordingly. And yeah the
>>>complication arises due to not being able to mix 4K + 64K GTT
>>>pages within the same page-table (existed since even gen8). Note
>>>that 4K here is what we typically get for system memory.
>>>
>>>Originally we had a memory coloring scheme to track the "color" of
>>>each page-table, which basically ensures that userspace can't do
>>>something nasty like mixing page sizes. The advantage of that
>>>scheme is that we would only require 64K GTT alignment and no
>>>extra padding, but is perhaps a little complex.
>>>
>>>The merged solution is just to align and pad (i.e vma->node.size
>>>and not vma->size) out of the vma to 2M, which is dead simple
>>>implementation wise, but does potentially waste some GTT space and
>>>some of the local memory used for the actual page-table. For the
>>>alignment the kernel just validates that the GTT address is
>>>aligned to 2M in vma_insert(), and then for the padding it just
>>>inflates it to 2M, if userspace hasn't already.
>>>
>>>See the kernel-doc for @size: https://dri.freedesktop.org/docs/drm/gpu/driver-uapi.html?#c.drm_i915_gem_create_ext
>>>
>>>
>>
>>Ok, those requirements (2M VA alignment) will apply to VM_BIND also.
>>This is unfortunate, but it is not something new enforced by VM_BIND.
>>Other option is to go with 64K alignment and in VM_BIND case, user
>>must ensure there is no mix-matching of 64K (lmem) and 4k (smem)
>>mappings in the same 2M range. But this is not VM_BIND specific
>>(will apply to soft-pinning in execbuf2 also).
>>
>>I don't think we need any VA padding here as with VM_BIND VA is
>>managed fully by the user. If we enforce VA to be 2M aligned, it
>>will leave holes (if BOs are smaller then 2M), but nobody is going
>>to allocate anything form there.
>
>Note that we only apply the 2M alignment + padding for local memory
>pages, for system memory we don't have/need such restrictions. The VA
>padding then importantly prevents userspace from incorrectly (or
>maliciously) inserting 4K system memory object in some page-table
>operating in 64K GTT mode.
>
Thanks Matt.
I also, syned offline with Matt a bit on this.
We don't need explicit 'pad_to_size' size. i915 driver is implicitly
padding the size to 2M boundary for LMEM BOs which will apply for
VM_BIND also.
The remaining question is whether we enforce 2M VA alignment for
lmem BOs (just like legacy execbuff path) on dg2 & xehpsdv, or go with
just 64K alignment but ensure there is no mixing of 4K and 64K
mappings in same 2M range. I think we can go with 2M alignment
requirement for VM_BIND also. So, no new requirements here for VM_BIND.
I will update the documentation.
Niranjana
>>
>>Niranjana
>>
>>>>
>>>>Regards,
>>>>
>>>>Tvrtko
>>>>
>>>>>
>>>>>Niranjana
>>>>>
>>>>>>Regards,
>>>>>>
>>>>>>Tvrtko
>>>>>>
>>>>>>>+
>>>>>>>+ /**
>>>>>>>+ * @flags: Supported flags are,
>>>>>>>+ *
>>>>>>>+ * I915_GEM_VM_BIND_READONLY:
>>>>>>>+ * Mapping is read-only.
>>>>>>>+ *
>>>>>>>+ * I915_GEM_VM_BIND_CAPTURE:
>>>>>>>+ * Capture this mapping in the dump upon GPU error.
>>>>>>>+ */
>>>>>>>+ __u64 flags;
>>>>>>>+#define I915_GEM_VM_BIND_READONLY (1 << 0)
>>>>>>>+#define I915_GEM_VM_BIND_CAPTURE (1 << 1)
>>>>>>>+
>>>>>>>+ /** @extensions: 0-terminated chain of extensions for
>>>>>>>this mapping. */
>>>>>>>+ __u64 extensions;
>>>>>>>+};
>>>>>>>+
>>>>>>>+/**
>>>>>>>+ * struct drm_i915_gem_vm_unbind - VA to object mapping to unbind.
>>>>>>>+ *
>>>>>>>+ * This structure is passed to VM_UNBIND ioctl and
>>>>>>>specifies the GPU virtual
>>>>>>>+ * address (VA) range that should be unbound from the
>>>>>>>device page table of the
>>>>>>>+ * specified address space (VM). The specified VA range
>>>>>>>must match one of the
>>>>>>>+ * mappings created with the VM_BIND ioctl. TLB is
>>>>>>>flushed upon unbind
>>>>>>>+ * completion.
>>>>>>>+ */
>>>>>>>+struct drm_i915_gem_vm_unbind {
>>>>>>>+ /** @vm_id: VM (address space) id to bind */
>>>>>>>+ __u32 vm_id;
>>>>>>>+
>>>>>>>+ /** @rsvd: Reserved for future use; must be zero. */
>>>>>>>+ __u32 rsvd;
>>>>>>>+
>>>>>>>+ /** @start: Virtual Address start to unbind */
>>>>>>>+ __u64 start;
>>>>>>>+
>>>>>>>+ /** @length: Length of mapping to unbind */
>>>>>>>+ __u64 length;
>>>>>>>+
>>>>>>>+ /** @flags: reserved for future usage, currently MBZ */
>>>>>>>+ __u64 flags;
>>>>>>>+
>>>>>>>+ /** @extensions: 0-terminated chain of extensions for
>>>>>>>this mapping. */
>>>>>>>+ __u64 extensions;
>>>>>>>+};
>>>>>>>+
>>>>>>>+/**
>>>>>>>+ * struct drm_i915_vm_bind_fence - An input or output
>>>>>>>fence for the vm_bind
>>>>>>>+ * or the vm_unbind work.
>>>>>>>+ *
>>>>>>>+ * The vm_bind or vm_unbind aync worker will wait for
>>>>>>>input fence to signal
>>>>>>>+ * before starting the binding or unbinding.
>>>>>>>+ *
>>>>>>>+ * The vm_bind or vm_unbind async worker will signal the
>>>>>>>returned output fence
>>>>>>>+ * after the completion of binding or unbinding.
>>>>>>>+ */
>>>>>>>+struct drm_i915_vm_bind_fence {
>>>>>>>+ /** @handle: User's handle for a drm_syncobj to wait
>>>>>>>on or signal. */
>>>>>>>+ __u32 handle;
>>>>>>>+
>>>>>>>+ /**
>>>>>>>+ * @flags: Supported flags are,
>>>>>>>+ *
>>>>>>>+ * I915_VM_BIND_FENCE_WAIT:
>>>>>>>+ * Wait for the input fence before binding/unbinding
>>>>>>>+ *
>>>>>>>+ * I915_VM_BIND_FENCE_SIGNAL:
>>>>>>>+ * Return bind/unbind completion fence as output
>>>>>>>+ */
>>>>>>>+ __u32 flags;
>>>>>>>+#define I915_VM_BIND_FENCE_WAIT (1<<0)
>>>>>>>+#define I915_VM_BIND_FENCE_SIGNAL (1<<1)
>>>>>>>+#define __I915_VM_BIND_FENCE_UNKNOWN_FLAGS
>>>>>>>(-(I915_VM_BIND_FENCE_SIGNAL << 1))
>>>>>>>+};
>>>>>>>+
>>>>>>>+/**
>>>>>>>+ * struct drm_i915_vm_bind_ext_timeline_fences - Timeline
>>>>>>>fences for vm_bind
>>>>>>>+ * and vm_unbind.
>>>>>>>+ *
>>>>>>>+ * This structure describes an array of timeline
>>>>>>>drm_syncobj and associated
>>>>>>>+ * points for timeline variants of drm_syncobj. These
>>>>>>>timeline 'drm_syncobj's
>>>>>>>+ * can be input or output fences (See struct
>>>>>>>drm_i915_vm_bind_fence).
>>>>>>>+ */
>>>>>>>+struct drm_i915_vm_bind_ext_timeline_fences {
>>>>>>>+#define I915_VM_BIND_EXT_timeline_FENCES 0
>>>>>>>+ /** @base: Extension link. See struct i915_user_extension. */
>>>>>>>+ struct i915_user_extension base;
>>>>>>>+
>>>>>>>+ /**
>>>>>>>+ * @fence_count: Number of elements in the
>>>>>>>@handles_ptr & @value_ptr
>>>>>>>+ * arrays.
>>>>>>>+ */
>>>>>>>+ __u64 fence_count;
>>>>>>>+
>>>>>>>+ /**
>>>>>>>+ * @handles_ptr: Pointer to an array of struct
>>>>>>>drm_i915_vm_bind_fence
>>>>>>>+ * of length @fence_count.
>>>>>>>+ */
>>>>>>>+ __u64 handles_ptr;
>>>>>>>+
>>>>>>>+ /**
>>>>>>>+ * @values_ptr: Pointer to an array of u64 values of length
>>>>>>>+ * @fence_count.
>>>>>>>+ * Values must be 0 for a binary drm_syncobj. A Value of 0 for a
>>>>>>>+ * timeline drm_syncobj is invalid as it turns a
>>>>>>>drm_syncobj into a
>>>>>>>+ * binary one.
>>>>>>>+ */
>>>>>>>+ __u64 values_ptr;
>>>>>>>+};
>>>>>>>+
>>>>>>>+/**
>>>>>>>+ * struct drm_i915_vm_bind_user_fence - An input or
>>>>>>>output user fence for the
>>>>>>>+ * vm_bind or the vm_unbind work.
>>>>>>>+ *
>>>>>>>+ * The vm_bind or vm_unbind aync worker will wait for the
>>>>>>>input fence (value at
>>>>>>>+ * @addr to become equal to @val) before starting the
>>>>>>>binding or unbinding.
>>>>>>>+ *
>>>>>>>+ * The vm_bind or vm_unbind async worker will signal the
>>>>>>>output fence after
>>>>>>>+ * the completion of binding or unbinding by writing @val
>>>>>>>to memory location at
>>>>>>>+ * @addr
>>>>>>>+ */
>>>>>>>+struct drm_i915_vm_bind_user_fence {
>>>>>>>+ /** @addr: User/Memory fence qword aligned process
>>>>>>>virtual address */
>>>>>>>+ __u64 addr;
>>>>>>>+
>>>>>>>+ /** @val: User/Memory fence value to be written after
>>>>>>>bind completion */
>>>>>>>+ __u64 val;
>>>>>>>+
>>>>>>>+ /**
>>>>>>>+ * @flags: Supported flags are,
>>>>>>>+ *
>>>>>>>+ * I915_VM_BIND_USER_FENCE_WAIT:
>>>>>>>+ * Wait for the input fence before binding/unbinding
>>>>>>>+ *
>>>>>>>+ * I915_VM_BIND_USER_FENCE_SIGNAL:
>>>>>>>+ * Return bind/unbind completion fence as output
>>>>>>>+ */
>>>>>>>+ __u32 flags;
>>>>>>>+#define I915_VM_BIND_USER_FENCE_WAIT (1<<0)
>>>>>>>+#define I915_VM_BIND_USER_FENCE_SIGNAL (1<<1)
>>>>>>>+#define __I915_VM_BIND_USER_FENCE_UNKNOWN_FLAGS \
>>>>>>>+ (-(I915_VM_BIND_USER_FENCE_SIGNAL << 1))
>>>>>>>+};
>>>>>>>+
>>>>>>>+/**
>>>>>>>+ * struct drm_i915_vm_bind_ext_user_fence - User/memory
>>>>>>>fences for vm_bind
>>>>>>>+ * and vm_unbind.
>>>>>>>+ *
>>>>>>>+ * These user fences can be input or output fences
>>>>>>>+ * (See struct drm_i915_vm_bind_user_fence).
>>>>>>>+ */
>>>>>>>+struct drm_i915_vm_bind_ext_user_fence {
>>>>>>>+#define I915_VM_BIND_EXT_USER_FENCES 1
>>>>>>>+ /** @base: Extension link. See struct i915_user_extension. */
>>>>>>>+ struct i915_user_extension base;
>>>>>>>+
>>>>>>>+ /** @fence_count: Number of elements in the
>>>>>>>@user_fence_ptr array. */
>>>>>>>+ __u64 fence_count;
>>>>>>>+
>>>>>>>+ /**
>>>>>>>+ * @user_fence_ptr: Pointer to an array of
>>>>>>>+ * struct drm_i915_vm_bind_user_fence of length @fence_count.
>>>>>>>+ */
>>>>>>>+ __u64 user_fence_ptr;
>>>>>>>+};
>>>>>>>+
>>>>>>>+/**
>>>>>>>+ * struct drm_i915_gem_execbuffer_ext_batch_addresses -
>>>>>>>Array of batch buffer
>>>>>>>+ * gpu virtual addresses.
>>>>>>>+ *
>>>>>>>+ * In the execbuff ioctl (See struct
>>>>>>>drm_i915_gem_execbuffer2), this extension
>>>>>>>+ * must always be appended in the VM_BIND mode and it
>>>>>>>will be an error to
>>>>>>>+ * append this extension in older non-VM_BIND mode.
>>>>>>>+ */
>>>>>>>+struct drm_i915_gem_execbuffer_ext_batch_addresses {
>>>>>>>+#define DRM_I915_GEM_EXECBUFFER_EXT_BATCH_ADDRESSES 1
>>>>>>>+ /** @base: Extension link. See struct i915_user_extension. */
>>>>>>>+ struct i915_user_extension base;
>>>>>>>+
>>>>>>>+ /** @count: Number of addresses in the addr array. */
>>>>>>>+ __u32 count;
>>>>>>>+
>>>>>>>+ /** @addr: An array of batch gpu virtual addresses. */
>>>>>>>+ __u64 addr[0];
>>>>>>>+};
>>>>>>>+
>>>>>>>+/**
>>>>>>>+ * struct drm_i915_gem_execbuffer_ext_user_fence - First
>>>>>>>level batch completion
>>>>>>>+ * signaling extension.
>>>>>>>+ *
>>>>>>>+ * This extension allows user to attach a user fence
>>>>>>>(@addr, @value pair) to an
>>>>>>>+ * execbuf to be signaled by the command streamer after
>>>>>>>the completion of first
>>>>>>>+ * level batch, by writing the @value at specified @addr
>>>>>>>and triggering an
>>>>>>>+ * interrupt.
>>>>>>>+ * User can either poll for this user fence to signal or
>>>>>>>can also wait on it
>>>>>>>+ * with i915_gem_wait_user_fence ioctl.
>>>>>>>+ * This is very much usefaul for long running contexts
>>>>>>>where waiting on dma-fence
>>>>>>>+ * by user (like i915_gem_wait ioctl) is not supported.
>>>>>>>+ */
>>>>>>>+struct drm_i915_gem_execbuffer_ext_user_fence {
>>>>>>>+#define DRM_I915_GEM_EXECBUFFER_EXT_USER_FENCE 2
>>>>>>>+ /** @base: Extension link. See struct i915_user_extension. */
>>>>>>>+ struct i915_user_extension base;
>>>>>>>+
>>>>>>>+ /**
>>>>>>>+ * @addr: User/Memory fence qword aligned GPU virtual address.
>>>>>>>+ *
>>>>>>>+ * Address has to be a valid GPU virtual address at the time of
>>>>>>>+ * first level batch completion.
>>>>>>>+ */
>>>>>>>+ __u64 addr;
>>>>>>>+
>>>>>>>+ /**
>>>>>>>+ * @value: User/Memory fence Value to be written to
>>>>>>>above address
>>>>>>>+ * after first level batch completes.
>>>>>>>+ */
>>>>>>>+ __u64 value;
>>>>>>>+
>>>>>>>+ /** @rsvd: Reserved for future extensions, MBZ */
>>>>>>>+ __u64 rsvd;
>>>>>>>+};
>>>>>>>+
>>>>>>>+/**
>>>>>>>+ * struct drm_i915_gem_create_ext_vm_private - Extension
>>>>>>>to make the object
>>>>>>>+ * private to the specified VM.
>>>>>>>+ *
>>>>>>>+ * See struct drm_i915_gem_create_ext.
>>>>>>>+ */
>>>>>>>+struct drm_i915_gem_create_ext_vm_private {
>>>>>>>+#define I915_GEM_CREATE_EXT_VM_PRIVATE 2
>>>>>>>+ /** @base: Extension link. See struct i915_user_extension. */
>>>>>>>+ struct i915_user_extension base;
>>>>>>>+
>>>>>>>+ /** @vm_id: Id of the VM to which the object is private */
>>>>>>>+ __u32 vm_id;
>>>>>>>+};
>>>>>>>+
>>>>>>>+/**
>>>>>>>+ * struct drm_i915_gem_wait_user_fence - Wait on user/memory fence.
>>>>>>>+ *
>>>>>>>+ * User/Memory fence can be woken up either by:
>>>>>>>+ *
>>>>>>>+ * 1. GPU context indicated by @ctx_id, or,
>>>>>>>+ * 2. Kerrnel driver async worker upon I915_UFENCE_WAIT_SOFT.
>>>>>>>+ * @ctx_id is ignored when this flag is set.
>>>>>>>+ *
>>>>>>>+ * Wakeup condition is,
>>>>>>>+ * ``((*addr & mask) op (value & mask))``
>>>>>>>+ *
>>>>>>>+ * See :ref:`Documentation/driver-api/dma-buf.rst
>>>>>>><indefinite_dma_fences>`
>>>>>>>+ */
>>>>>>>+struct drm_i915_gem_wait_user_fence {
>>>>>>>+ /** @extensions: Zero-terminated chain of extensions. */
>>>>>>>+ __u64 extensions;
>>>>>>>+
>>>>>>>+ /** @addr: User/Memory fence address */
>>>>>>>+ __u64 addr;
>>>>>>>+
>>>>>>>+ /** @ctx_id: Id of the Context which will signal the fence. */
>>>>>>>+ __u32 ctx_id;
>>>>>>>+
>>>>>>>+ /** @op: Wakeup condition operator */
>>>>>>>+ __u16 op;
>>>>>>>+#define I915_UFENCE_WAIT_EQ 0
>>>>>>>+#define I915_UFENCE_WAIT_NEQ 1
>>>>>>>+#define I915_UFENCE_WAIT_GT 2
>>>>>>>+#define I915_UFENCE_WAIT_GTE 3
>>>>>>>+#define I915_UFENCE_WAIT_LT 4
>>>>>>>+#define I915_UFENCE_WAIT_LTE 5
>>>>>>>+#define I915_UFENCE_WAIT_BEFORE 6
>>>>>>>+#define I915_UFENCE_WAIT_AFTER 7
>>>>>>>+
>>>>>>>+ /**
>>>>>>>+ * @flags: Supported flags are,
>>>>>>>+ *
>>>>>>>+ * I915_UFENCE_WAIT_SOFT:
>>>>>>>+ *
>>>>>>>+ * To be woken up by i915 driver async worker (not by GPU).
>>>>>>>+ *
>>>>>>>+ * I915_UFENCE_WAIT_ABSTIME:
>>>>>>>+ *
>>>>>>>+ * Wait timeout specified as absolute time.
>>>>>>>+ */
>>>>>>>+ __u16 flags;
>>>>>>>+#define I915_UFENCE_WAIT_SOFT 0x1
>>>>>>>+#define I915_UFENCE_WAIT_ABSTIME 0x2
>>>>>>>+
>>>>>>>+ /** @value: Wakeup value */
>>>>>>>+ __u64 value;
>>>>>>>+
>>>>>>>+ /** @mask: Wakeup mask */
>>>>>>>+ __u64 mask;
>>>>>>>+#define I915_UFENCE_WAIT_U8 0xffu
>>>>>>>+#define I915_UFENCE_WAIT_U16 0xffffu
>>>>>>>+#define I915_UFENCE_WAIT_U32 0xfffffffful
>>>>>>>+#define I915_UFENCE_WAIT_U64 0xffffffffffffffffull
>>>>>>>+
>>>>>>>+ /**
>>>>>>>+ * @timeout: Wait timeout in nanoseconds.
>>>>>>>+ *
>>>>>>>+ * If I915_UFENCE_WAIT_ABSTIME flag is set, then time
>>>>>>>timeout is the
>>>>>>>+ * absolute time in nsec.
>>>>>>>+ */
>>>>>>>+ __s64 timeout;
>>>>>>>+};
More information about the Intel-gfx
mailing list