From: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> To: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org Cc: paulo.r.zanoni@intel.com, jani.nikula@intel.com, thomas.hellstrom@intel.com, matthew.auld@intel.com, daniel.vetter@intel.com, christian.koenig@amd.com Subject: [Intel-gfx] [PATCH v8 19/22] drm/i915/vm_bind: Render VM_BIND documentation Date: Mon, 28 Nov 2022 23:26:32 -0800 [thread overview] Message-ID: <20221129072635.847-20-niranjana.vishwanathapura@intel.com> (raw) In-Reply-To: <20221129072635.847-1-niranjana.vishwanathapura@intel.com> Update i915 documentation to include VM_BIND changes and render all VM_BIND related documentation. Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> --- Documentation/gpu/i915.rst | 78 ++++++++++++++++++++++++++++---------- 1 file changed, 59 insertions(+), 19 deletions(-) diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 60ea21734902..01429a8f0d6c 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -283,15 +283,18 @@ An Intel GPU has multiple engines. There are several engine types. The Intel GPU family is a family of integrated GPU's using Unified Memory Access. For having the GPU "do work", user space will feed the -GPU batch buffers via one of the ioctls `DRM_IOCTL_I915_GEM_EXECBUFFER2` -or `DRM_IOCTL_I915_GEM_EXECBUFFER2_WR`. Most such batchbuffers will -instruct the GPU to perform work (for example rendering) and that work -needs memory from which to read and memory to which to write. All memory -is encapsulated within GEM buffer objects (usually created with the ioctl -`DRM_IOCTL_I915_GEM_CREATE`). An ioctl providing a batchbuffer for the GPU -to create will also list all GEM buffer objects that the batchbuffer reads -and/or writes. For implementation details of memory management see -`GEM BO Management Implementation Details`_. +GPU batch buffers via one of the ioctls `DRM_IOCTL_I915_GEM_EXECBUFFER2`, +`DRM_IOCTL_I915_GEM_EXECBUFFER2_WR` or `DRM_IOCTL_I915_GEM_EXECBUFFER3`. +Most such batchbuffers will instruct the GPU to perform work (for example +rendering) and that work needs memory from which to read and memory to +which to write. All memory is encapsulated within GEM buffer objects +(usually created with the ioctl `DRM_IOCTL_I915_GEM_CREATE`). In vm_bind mode +(see `VM_BIND mode`_), the batch buffer and all the GEM buffer objects that +it reads and/or writes should be bound with vm_bind ioctl before submitting +the batch buffer to GPU. In legacy (non-VM_BIND) mode, an ioctl providing a +batchbuffer for the GPU to create will also list all GEM buffer objects that +the batchbuffer reads and/or writes. For implementation details of memory +management see `GEM BO Management Implementation Details`_. The i915 driver allows user space to create a context via the ioctl `DRM_IOCTL_I915_GEM_CONTEXT_CREATE` which is identified by a 32-bit @@ -309,8 +312,9 @@ In addition to the ordering guarantees, the kernel will restore GPU state via HW context when commands are issued to a context, this saves user space the need to restore (most of atleast) the GPU state at the start of each batchbuffer. The non-deprecated ioctls to submit batchbuffer -work can pass that ID (in the lower bits of drm_i915_gem_execbuffer2::rsvd1) -to identify what context to use with the command. +work can pass that ID (drm_i915_gem_execbuffer3::ctx_id, or in the lower +bits of drm_i915_gem_execbuffer2::rsvd1) to identify what context to use +with the command. The GPU has its own memory management and address space. The kernel driver maintains the memory translation table for the GPU. For older @@ -318,14 +322,14 @@ GPUs (i.e. those before Gen8), there is a single global such translation table, a global Graphics Translation Table (GTT). For newer generation GPUs each context has its own translation table, called Per-Process Graphics Translation Table (PPGTT). Of important note, is that although -PPGTT is named per-process it is actually per context. When user space -submits a batchbuffer, the kernel walks the list of GEM buffer objects -used by the batchbuffer and guarantees that not only is the memory of -each such GEM buffer object resident but it is also present in the -(PP)GTT. If the GEM buffer object is not yet placed in the (PP)GTT, -then it is given an address. Two consequences of this are: the kernel -needs to edit the batchbuffer submitted to write the correct value of -the GPU address when a GEM BO is assigned a GPU address and the kernel +PPGTT is named per-process it is actually per context. In legacy +(non-vm_bind) mode, when user space submits a batchbuffer, the kernel walks +the list of GEM buffer objects used by the batchbuffer and guarantees that +not only is the memory of each such GEM buffer object resident but it is +also present in the (PP)GTT. If the GEM buffer object is not yet placed in +the (PP)GTT, then it is given an address. Two consequences of this are: the +kernel needs to edit the batchbuffer submitted to write the correct value +of the GPU address when a GEM BO is assigned a GPU address and the kernel might evict a different GEM BO from the (PP)GTT to make address room for another GEM BO. Consequently, the ioctls submitting a batchbuffer for execution also include a list of all locations within buffers that @@ -407,6 +411,15 @@ objects, which has the goal to make space in gpu virtual address spaces. .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_shrinker.c :internal: +VM_BIND mode +------------ + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c + :doc: VM_BIND/UNBIND ioctls + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c + :internal: + Batchbuffer Parsing ------------------- @@ -419,11 +432,38 @@ Batchbuffer Parsing User Batchbuffer Execution -------------------------- +Client state +~~~~~~~~~~~~ + .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_context_types.h +User command execution +~~~~~~~~~~~~~~~~~~~~~~ + .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c :doc: User command execution +User command execution in vm_bind mode +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c + :doc: User command execution in vm_bind mode + +Common execbuff utilities +~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.h + :internal: + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.c + :internal: + +Execbuf3 ioctl path +~~~~~~~~~~~~~~~~~~~ + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c + :internal: + Scheduling ---------- .. kernel-doc:: drivers/gpu/drm/i915/i915_scheduler_types.h -- 2.21.0.rc0.32.g243a4c7e27
WARNING: multiple messages have this Message-ID (diff)
From: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> To: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org Cc: matthew.brost@intel.com, paulo.r.zanoni@intel.com, tvrtko.ursulin@intel.com, jani.nikula@intel.com, lionel.g.landwerlin@intel.com, thomas.hellstrom@intel.com, matthew.auld@intel.com, jason@jlekstrand.net, andi.shyti@linux.intel.com, daniel.vetter@intel.com, christian.koenig@amd.com Subject: [PATCH v8 19/22] drm/i915/vm_bind: Render VM_BIND documentation Date: Mon, 28 Nov 2022 23:26:32 -0800 [thread overview] Message-ID: <20221129072635.847-20-niranjana.vishwanathapura@intel.com> (raw) In-Reply-To: <20221129072635.847-1-niranjana.vishwanathapura@intel.com> Update i915 documentation to include VM_BIND changes and render all VM_BIND related documentation. Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> --- Documentation/gpu/i915.rst | 78 ++++++++++++++++++++++++++++---------- 1 file changed, 59 insertions(+), 19 deletions(-) diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 60ea21734902..01429a8f0d6c 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -283,15 +283,18 @@ An Intel GPU has multiple engines. There are several engine types. The Intel GPU family is a family of integrated GPU's using Unified Memory Access. For having the GPU "do work", user space will feed the -GPU batch buffers via one of the ioctls `DRM_IOCTL_I915_GEM_EXECBUFFER2` -or `DRM_IOCTL_I915_GEM_EXECBUFFER2_WR`. Most such batchbuffers will -instruct the GPU to perform work (for example rendering) and that work -needs memory from which to read and memory to which to write. All memory -is encapsulated within GEM buffer objects (usually created with the ioctl -`DRM_IOCTL_I915_GEM_CREATE`). An ioctl providing a batchbuffer for the GPU -to create will also list all GEM buffer objects that the batchbuffer reads -and/or writes. For implementation details of memory management see -`GEM BO Management Implementation Details`_. +GPU batch buffers via one of the ioctls `DRM_IOCTL_I915_GEM_EXECBUFFER2`, +`DRM_IOCTL_I915_GEM_EXECBUFFER2_WR` or `DRM_IOCTL_I915_GEM_EXECBUFFER3`. +Most such batchbuffers will instruct the GPU to perform work (for example +rendering) and that work needs memory from which to read and memory to +which to write. All memory is encapsulated within GEM buffer objects +(usually created with the ioctl `DRM_IOCTL_I915_GEM_CREATE`). In vm_bind mode +(see `VM_BIND mode`_), the batch buffer and all the GEM buffer objects that +it reads and/or writes should be bound with vm_bind ioctl before submitting +the batch buffer to GPU. In legacy (non-VM_BIND) mode, an ioctl providing a +batchbuffer for the GPU to create will also list all GEM buffer objects that +the batchbuffer reads and/or writes. For implementation details of memory +management see `GEM BO Management Implementation Details`_. The i915 driver allows user space to create a context via the ioctl `DRM_IOCTL_I915_GEM_CONTEXT_CREATE` which is identified by a 32-bit @@ -309,8 +312,9 @@ In addition to the ordering guarantees, the kernel will restore GPU state via HW context when commands are issued to a context, this saves user space the need to restore (most of atleast) the GPU state at the start of each batchbuffer. The non-deprecated ioctls to submit batchbuffer -work can pass that ID (in the lower bits of drm_i915_gem_execbuffer2::rsvd1) -to identify what context to use with the command. +work can pass that ID (drm_i915_gem_execbuffer3::ctx_id, or in the lower +bits of drm_i915_gem_execbuffer2::rsvd1) to identify what context to use +with the command. The GPU has its own memory management and address space. The kernel driver maintains the memory translation table for the GPU. For older @@ -318,14 +322,14 @@ GPUs (i.e. those before Gen8), there is a single global such translation table, a global Graphics Translation Table (GTT). For newer generation GPUs each context has its own translation table, called Per-Process Graphics Translation Table (PPGTT). Of important note, is that although -PPGTT is named per-process it is actually per context. When user space -submits a batchbuffer, the kernel walks the list of GEM buffer objects -used by the batchbuffer and guarantees that not only is the memory of -each such GEM buffer object resident but it is also present in the -(PP)GTT. If the GEM buffer object is not yet placed in the (PP)GTT, -then it is given an address. Two consequences of this are: the kernel -needs to edit the batchbuffer submitted to write the correct value of -the GPU address when a GEM BO is assigned a GPU address and the kernel +PPGTT is named per-process it is actually per context. In legacy +(non-vm_bind) mode, when user space submits a batchbuffer, the kernel walks +the list of GEM buffer objects used by the batchbuffer and guarantees that +not only is the memory of each such GEM buffer object resident but it is +also present in the (PP)GTT. If the GEM buffer object is not yet placed in +the (PP)GTT, then it is given an address. Two consequences of this are: the +kernel needs to edit the batchbuffer submitted to write the correct value +of the GPU address when a GEM BO is assigned a GPU address and the kernel might evict a different GEM BO from the (PP)GTT to make address room for another GEM BO. Consequently, the ioctls submitting a batchbuffer for execution also include a list of all locations within buffers that @@ -407,6 +411,15 @@ objects, which has the goal to make space in gpu virtual address spaces. .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_shrinker.c :internal: +VM_BIND mode +------------ + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c + :doc: VM_BIND/UNBIND ioctls + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c + :internal: + Batchbuffer Parsing ------------------- @@ -419,11 +432,38 @@ Batchbuffer Parsing User Batchbuffer Execution -------------------------- +Client state +~~~~~~~~~~~~ + .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_context_types.h +User command execution +~~~~~~~~~~~~~~~~~~~~~~ + .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c :doc: User command execution +User command execution in vm_bind mode +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c + :doc: User command execution in vm_bind mode + +Common execbuff utilities +~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.h + :internal: + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.c + :internal: + +Execbuf3 ioctl path +~~~~~~~~~~~~~~~~~~~ + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c + :internal: + Scheduling ---------- .. kernel-doc:: drivers/gpu/drm/i915/i915_scheduler_types.h -- 2.21.0.rc0.32.g243a4c7e27
next prev parent reply other threads:[~2022-11-29 7:27 UTC|newest] Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-11-29 7:26 [PATCH v8 00/22] drm/i915/vm_bind: Add VM_BIND functionality Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] " Niranjana Vishwanathapura 2022-11-29 7:26 ` [PATCH v8 01/22] drm/i915/vm_bind: Expose vm lookup function Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] " Niranjana Vishwanathapura 2022-11-29 7:26 ` [PATCH v8 02/22] drm/i915/vm_bind: Add __i915_sw_fence_await_reservation() Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] " Niranjana Vishwanathapura 2022-11-29 7:26 ` [PATCH v8 03/22] drm/i915/vm_bind: Expose i915_gem_object_max_page_size() Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] " Niranjana Vishwanathapura 2022-11-29 7:26 ` [PATCH v8 04/22] drm/i915/vm_bind: Add support to create persistent vma Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] " Niranjana Vishwanathapura 2022-11-29 7:26 ` [PATCH v8 05/22] drm/i915/vm_bind: Implement bind and unbind of object Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] " Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] [PATCH v8 06/22] drm/i915/vm_bind: Support for VM private BOs Niranjana Vishwanathapura 2022-11-29 7:26 ` Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] [PATCH v8 07/22] drm/i915/vm_bind: Add support to handle object evictions Niranjana Vishwanathapura 2022-11-29 7:26 ` Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] [PATCH v8 08/22] drm/i915/vm_bind: Support persistent vma activeness tracking Niranjana Vishwanathapura 2022-11-29 7:26 ` Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] [PATCH v8 09/22] drm/i915/vm_bind: Add out fence support Niranjana Vishwanathapura 2022-11-29 7:26 ` Niranjana Vishwanathapura 2022-11-29 7:26 ` [PATCH v8 10/22] drm/i915/vm_bind: Abstract out common execbuf functions Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] " Niranjana Vishwanathapura 2022-11-29 7:26 ` [PATCH v8 11/22] drm/i915/vm_bind: Use common execbuf functions in execbuf path Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] " Niranjana Vishwanathapura 2022-11-29 7:26 ` [PATCH v8 12/22] drm/i915/vm_bind: Implement I915_GEM_EXECBUFFER3 ioctl Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] " Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] [PATCH v8 13/22] drm/i915/vm_bind: Update i915_vma_verify_bind_complete() Niranjana Vishwanathapura 2022-11-29 7:26 ` Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] [PATCH v8 14/22] drm/i915/vm_bind: Expose i915_request_await_bind() Niranjana Vishwanathapura 2022-11-29 7:26 ` Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] [PATCH v8 15/22] drm/i915/vm_bind: Handle persistent vmas in execbuf3 Niranjana Vishwanathapura 2022-11-29 7:26 ` Niranjana Vishwanathapura 2022-11-29 7:26 ` [PATCH v8 16/22] drm/i915/vm_bind: userptr dma-resv changes Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] " Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] [PATCH v8 17/22] drm/i915/vm_bind: Limit vm_bind mode to non-recoverable contexts Niranjana Vishwanathapura 2022-11-29 7:26 ` Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] [PATCH v8 18/22] drm/i915/vm_bind: Add uapi for user to enable vm_bind_mode Niranjana Vishwanathapura 2022-11-29 7:26 ` Niranjana Vishwanathapura 2022-11-29 7:26 ` Niranjana Vishwanathapura [this message] 2022-11-29 7:26 ` [PATCH v8 19/22] drm/i915/vm_bind: Render VM_BIND documentation Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] [PATCH v8 20/22] drm/i915/vm_bind: Async vm_unbind support Niranjana Vishwanathapura 2022-11-29 7:26 ` Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] [PATCH v8 21/22] drm/i915/vm_bind: Properly build persistent map sg table Niranjana Vishwanathapura 2022-11-29 7:26 ` Niranjana Vishwanathapura 2022-12-12 18:17 ` Matthew Auld 2022-12-12 18:17 ` [Intel-gfx] " Matthew Auld 2022-12-14 4:58 ` Niranjana Vishwanathapura 2022-12-14 4:58 ` [Intel-gfx] " Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] [PATCH v8 22/22] drm/i915/vm_bind: Support capture of persistent mappings Niranjana Vishwanathapura 2022-11-29 7:26 ` Niranjana Vishwanathapura 2022-12-01 10:49 ` Matthew Auld 2022-12-01 10:49 ` [Intel-gfx] " Matthew Auld 2022-12-01 15:27 ` Niranjana Vishwanathapura 2022-12-01 15:27 ` [Intel-gfx] " Niranjana Vishwanathapura 2022-12-01 18:43 ` Niranjana Vishwanathapura 2022-12-06 17:40 ` Matthew Auld 2022-12-08 13:54 ` Niranjana Vishwanathapura 2022-11-29 8:24 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/vm_bind: Add VM_BIND functionality (rev11) Patchwork 2022-11-29 8:24 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork 2022-11-29 8:46 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork 2022-11-29 11:29 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " 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=20221129072635.847-20-niranjana.vishwanathapura@intel.com \ --to=niranjana.vishwanathapura@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=jani.nikula@intel.com \ --cc=matthew.auld@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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.