From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Cc: paulo.r.zanoni@intel.com, chris.p.wilson@intel.com,
thomas.hellstrom@intel.com, matthew.auld@intel.com,
daniel.vetter@intel.com, christian.koenig@amd.com
Subject: Re: [Intel-gfx] [PATCH v5 3/3] drm/doc/rfc: VM_BIND uapi definition
Date: Fri, 24 Jun 2022 09:11:35 +0100 [thread overview]
Message-ID: <e6291691-d792-7ba5-5676-fe79b9c96c1e@linux.intel.com> (raw)
In-Reply-To: <20220624053208.23723-4-niranjana.vishwanathapura@intel.com>
On 24/06/2022 06:32, Niranjana Vishwanathapura wrote:
> VM_BIND and related uapi definitions
>
> v2: Reduce the scope to simple Mesa use case.
> v3: Expand VM_UNBIND documentation and add
> I915_GEM_VM_BIND/UNBIND_FENCE_VALID
> and I915_GEM_VM_BIND_TLB_FLUSH flags.
> v4: Remove I915_GEM_VM_BIND_TLB_FLUSH flag and add additional
> documentation for vm_bind/unbind.
> v5: Remove TLB flush requirement on VM_UNBIND.
> Add version support to stage implementation.
Mostly LGTM with one final question.
Would an extension to execbuf3 saying "async wait on any ongoing
bind/unbind activity on this vm"? Would such an easy "fire and forget"
mechanism be useful to userspace? Or are separate "queues" the minimal
useful thing?
Regards,
Tvrtko
> Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
> ---
> Documentation/gpu/rfc/i915_vm_bind.h | 256 +++++++++++++++++++++++++++
> 1 file changed, 256 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..8af6c035ccf4
> --- /dev/null
> +++ b/Documentation/gpu/rfc/i915_vm_bind.h
> @@ -0,0 +1,256 @@
> +/* 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.
> + * bit[0]: If set, VM_BIND is supported, otherwise not.
> + * bits[8-15]: VM_BIND implementation version.
> + * Version 0 requires in VM_UNBIND call, UMDs to specify the exact mapping
> + * created previously with the VM_BIND call. i.e., i915 will not support
> + * splitting/merging of the mappings created with VM_BIND call (See
> + * struct drm_i915_gem_vm_bind and struct drm_i915_gem_vm_unbind).
> + */
> +#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.
> + *
> + * The older execbuf2 ioctl will not support VM_BIND mode of operation.
> + * For VM_BIND mode, we have new execbuf3 ioctl which will not accept any
> + * execlist (See struct drm_i915_gem_execbuffer3 for more details).
> + *
> + */
> +#define I915_VM_CREATE_FLAGS_USE_VM_BIND (1 << 0)
> +
> +/* VM_BIND related ioctls */
> +#define DRM_I915_GEM_VM_BIND 0x3d
> +#define DRM_I915_GEM_VM_UNBIND 0x3e
> +#define DRM_I915_GEM_EXECBUFFER3 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_EXECBUFFER3 DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_EXECBUFFER3, struct drm_i915_gem_execbuffer3)
> +
> +/**
> + * struct drm_i915_gem_vm_bind_fence - Bind/unbind completion notification.
> + *
> + * A timeline out fence for vm_bind/unbind completion notification.
> + */
> +struct drm_i915_gem_vm_bind_fence {
> + /** @handle: User's handle for a drm_syncobj to signal. */
> + __u32 handle;
> +
> + /** @rsvd: Reserved, MBZ */
> + __u32 rsvd;
> +
> + /**
> + * @value: A point in the timeline.
> + * Value 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 value;
> +};
> +
> +/**
> + * 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).
> + *
> + * The @start, @offset and @length should be 4K page aligned. However the DG2
> + * and XEHPSDV has 64K page size for device local-memory and has compact page
> + * table. On those platforms, for binding device local-memory objects, the
> + * @start should be 2M aligned, @offset and @length should be 64K aligned.
> + * Also, on those platforms, error -ENOSPC will be returned if user tries to
> + * bind a device local-memory object and a system memory object in a single 2M
> + * section of VA range.
> + *
> + * Error code -EINVAL will be returned if @start, @offset and @length are not
> + * properly aligned. Error code of -ENOSPC will be returned if the VA range
> + * specified can't be reserved.
> + *
> + * The bind operation can get completed asynchronously and out of submission
> + * order. When I915_GEM_VM_BIND_FENCE_VALID flag is set, the @fence will be
> + * signaled upon completion of bind operation.
> + */
> +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;
> +
> + /**
> + * @flags: Supported flags are:
> + *
> + * I915_GEM_VM_BIND_FENCE_VALID:
> + * @fence is valid, needs bind completion notification.
> + *
> + * 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_FENCE_VALID (1 << 0)
> +#define I915_GEM_VM_BIND_READONLY (1 << 1)
> +#define I915_GEM_VM_BIND_CAPTURE (1 << 2)
> +
> + /** @fence: Timeline fence for bind completion signaling */
> + struct drm_i915_gem_vm_bind_fence fence;
> +
> + /** @extensions: 0-terminated chain of extensions */
> + __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). VM_UNBIND will force unbind the specified
> + * range from device page table without waiting for any GPU job to complete.
> + * It is UMDs responsibility to ensure the mapping is no longer in use before
> + * calling VM_UNBIND.
> + *
> + * If the specified mapping is not found, the ioctl will simply return without
> + * any error.
> + *
> + * The unbind operation can get completed asynchronously and out of submission
> + * order. When I915_GEM_VM_UNBIND_FENCE_VALID flag is set, the @fence will be
> + * signaled upon completion of unbind operation.
> + */
> +struct drm_i915_gem_vm_unbind {
> + /** @vm_id: VM (address space) id to bind */
> + __u32 vm_id;
> +
> + /** @rsvd: Reserved, MBZ */
> + __u32 rsvd;
> +
> + /** @start: Virtual Address start to unbind */
> + __u64 start;
> +
> + /** @length: Length of mapping to unbind */
> + __u64 length;
> +
> + /**
> + * @flags: Supported flags are:
> + *
> + * I915_GEM_VM_UNBIND_FENCE_VALID:
> + * @fence is valid, needs unbind completion notification.
> + */
> + __u64 flags;
> +#define I915_GEM_VM_UNBIND_FENCE_VALID (1 << 0)
> +
> + /** @fence: Timeline fence for unbind completion signaling */
> + struct drm_i915_gem_vm_bind_fence fence;
> +
> + /** @extensions: 0-terminated chain of extensions */
> + __u64 extensions;
> +};
> +
> +/**
> + * struct drm_i915_gem_execbuffer3 - Structure for DRM_I915_GEM_EXECBUFFER3
> + * ioctl.
> + *
> + * DRM_I915_GEM_EXECBUFFER3 ioctl only works in VM_BIND mode and VM_BIND mode
> + * only works with this ioctl for submission.
> + * See I915_VM_CREATE_FLAGS_USE_VM_BIND.
> + */
> +struct drm_i915_gem_execbuffer3 {
> + /**
> + * @ctx_id: Context id
> + *
> + * Only contexts with user engine map are allowed.
> + */
> + __u32 ctx_id;
> +
> + /**
> + * @engine_idx: Engine index
> + *
> + * An index in the user engine map of the context specified by @ctx_id.
> + */
> + __u32 engine_idx;
> +
> + /** @rsvd1: Reserved, MBZ */
> + __u32 rsvd1;
> +
> + /**
> + * @batch_count: Number of batches in @batch_address array.
> + *
> + * 0 is invalid. For parallel submission, it should be equal to the
> + * number of (parallel) engines involved in that submission.
> + */
> + __u32 batch_count;
> +
> + /**
> + * @batch_address: Array of batch gpu virtual addresses.
> + *
> + * If @batch_count is 1, then it is the gpu virtual address of the
> + * batch buffer. If @batch_count > 1, then it is a pointer to an array
> + * of batch buffer gpu virtual addresses.
> + */
> + __u64 batch_address;
> +
> + /**
> + * @flags: Supported flags are:
> + *
> + * I915_EXEC3_SECURE:
> + * Request a privileged ("secure") batch buffer/s.
> + * It is only available for DRM_ROOT_ONLY | DRM_MASTER processes.
> + */
> + __u64 flags;
> +#define I915_EXEC3_SECURE (1<<0)
> +
> + /** @rsvd2: Reserved, MBZ */
> + __u64 rsvd2;
> +
> + /**
> + * @extensions: Zero-terminated chain of extensions.
> + *
> + * DRM_I915_GEM_EXECBUFFER3_EXT_TIMELINE_FENCES:
> + * It has same format as DRM_I915_GEM_EXECBUFFER_EXT_TIMELINE_FENCES.
> + * See struct drm_i915_gem_execbuffer_ext_timeline_fences.
> + */
> + __u64 extensions;
> +#define DRM_I915_GEM_EXECBUFFER3_EXT_TIMELINE_FENCES 0
> +};
> +
> +/**
> + * 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;
> +};
next prev parent reply other threads:[~2022-06-24 8:11 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-24 5:32 [Intel-gfx] [PATCH v5 0/3] drm/doc/rfc: i915 VM_BIND feature design + uapi Niranjana Vishwanathapura
2022-06-24 5:32 ` [Intel-gfx] [PATCH v5 1/3] drm/doc/rfc: VM_BIND feature design document Niranjana Vishwanathapura
2022-06-24 5:32 ` [Intel-gfx] [PATCH v5 2/3] drm/i915: Update i915 uapi documentation Niranjana Vishwanathapura
2022-06-24 5:32 ` [Intel-gfx] [PATCH v5 3/3] drm/doc/rfc: VM_BIND uapi definition Niranjana Vishwanathapura
2022-06-24 5:45 ` Niranjana Vishwanathapura
2022-06-24 8:11 ` Tvrtko Ursulin [this message]
2022-06-24 14:59 ` Niranjana Vishwanathapura
2022-06-24 6:10 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/doc/rfc: i915 VM_BIND feature design + uapi Patchwork
2022-06-24 6:10 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-06-24 6:32 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-06-27 18:07 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e6291691-d792-7ba5-5676-fe79b9c96c1e@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=chris.p.wilson@intel.com \
--cc=christian.koenig@amd.com \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=matthew.auld@intel.com \
--cc=niranjana.vishwanathapura@intel.com \
--cc=paulo.r.zanoni@intel.com \
--cc=thomas.hellstrom@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).