From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: Danilo Krummrich <dakr@redhat.com>,
airlied@gmail.com, daniel@ffwll.ch, matthew.brost@intel.com,
sarah.walker@imgtec.com, donald.robson@imgtec.com,
boris.brezillon@collabora.com, christian.koenig@amd.com,
faith@gfxstrand.net
Cc: dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH drm-misc-next v6 4/6] drm/gpuvm: track/lock/validate external/evicted objects
Date: Mon, 16 Oct 2023 12:55:42 +0200 [thread overview]
Message-ID: <b325ff2e-011b-98fd-9490-e02e21286c29@linux.intel.com> (raw)
In-Reply-To: <f5a025853885bd535188516853e87383879f9dc7.camel@linux.intel.com>
On 10/13/23 15:37, Thomas Hellström wrote:
> Hi,
>
> On Mon, 2023-10-09 at 01:32 +0200, Danilo Krummrich wrote:
>> Currently the DRM GPUVM offers common infrastructure to track GPU VA
>> allocations and mappings, generically connect GPU VA mappings to
>> their
>> backing buffers and perform more complex mapping operations on the
>> GPU VA
>> space.
>>
>> However, there are more design patterns commonly used by drivers,
>> which
>> can potentially be generalized in order to make the DRM GPUVM
>> represent
>> a basis for GPU-VM implementations. In this context, this patch aims
>> at generalizing the following elements.
>>
>> 1) Provide a common dma-resv for GEM objects not being used outside
>> of
>> this GPU-VM.
>>
>> 2) Provide tracking of external GEM objects (GEM objects which are
>> shared with other GPU-VMs).
>>
>> 3) Provide functions to efficiently lock all GEM objects dma-resv the
>> GPU-VM contains mappings of.
>>
>> 4) Provide tracking of evicted GEM objects the GPU-VM contains
>> mappings
>> of, such that validation of evicted GEM objects is accelerated.
>>
>> 5) Provide some convinience functions for common patterns.
>>
>> Big thanks to Boris Brezillon for his help to figure out locking for
>> drivers updating the GPU VA space within the fence signalling path.
>>
>> Suggested-by: Matthew Brost <matthew.brost@intel.com>
>> Signed-off-by: Danilo Krummrich <dakr@redhat.com>
>> ---
>> drivers/gpu/drm/drm_gpuvm.c | 646
>> ++++++++++++++++++++++++++++++++++++
>> include/drm/drm_gpuvm.h | 246 ++++++++++++++
>> 2 files changed, 892 insertions(+)
>>
> There's a checkpatch.pl warning and a number of random macro CHECKs if
> using --strict.
>
> Also the overall s/Returns:/Return/ (and possibly function line break).
>
>
>> diff --git a/drivers/gpu/drm/drm_gpuvm.c
>> b/drivers/gpu/drm/drm_gpuvm.c
>> index 28282283ddaf..6977bd30eca5 100644
>> --- a/drivers/gpu/drm/drm_gpuvm.c
>> +++ b/drivers/gpu/drm/drm_gpuvm.c
>> @@ -82,6 +82,21 @@
>> * &drm_gem_object list of &drm_gpuvm_bos for an existing instance
>> of this
>> * particular combination. If not existent a new instance is created
>> and linked
>> * to the &drm_gem_object.
>> + *
>> + * &drm_gpuvm_bo structures, since unique for a given &drm_gpuvm,
>> are also used
>> + * as entry for the &drm_gpuvm's lists of external and evicted
>> objects. Those
>> + * list are maintained in order to accelerate locking of dma-resv
>> locks and
> s/list/lists/
>> + * validation of evicted objects bound in a &drm_gpuvm. For
>> instance, all
>> + * &drm_gem_object's &dma_resv of a given &drm_gpuvm can be locked
>> by calling
>> + * drm_gpuvm_exec_lock(). Once locked drivers can call
>> drm_gpuvm_validate() in
>> + * order to validate all evicted &drm_gem_objects. It is also
>> possible to lock
>> + * additional &drm_gem_objects by providing the corresponding
>> parameters to
>> + * drm_gpuvm_exec_lock() as well as open code the &drm_exec loop
>> while making
>> + * use of helper functions such as drm_gpuvm_prepare_range() or
>> + * drm_gpuvm_prepare_objects().
>> + *
>> + * Every bound &drm_gem_object is treated as external object when
>> its &dma_resv
>> + * structure is different than the &drm_gpuvm's common &dma_resv
>> structure.
>> */
>>
>> /**
>> @@ -429,6 +444,20 @@
>> * Subsequent calls to drm_gpuvm_bo_obtain() for the same &drm_gpuvm
>> and
>> * &drm_gem_object must be able to observe previous creations and
>> destructions
>> * of &drm_gpuvm_bos in order to keep instances unique.
>> + *
>> + * The &drm_gpuvm's lists for keeping track of external and evicted
>> objects are
>> + * protected against concurrent insertion / removal and iteration
>> internally.
>> + *
>> + * However, drivers still need ensure to protect concurrent calls to
>> functions
>> + * iterating those lists, namely drm_gpuvm_prepare_objects() and
>> + * drm_gpuvm_validate().
>
>> + *
>> + * Alternatively, drivers can set the &DRM_GPUVM_RESV_PROTECTED flag
>> to indicate
>> + * that the corresponding &dma_resv locks are held in order to
>> protect the
>> + * lists. If &DRM_GPUVM_RESV_PROTECTED is set, internal locking is
>> disabled and
>> + * the corresponding lockdep checks are enabled. This is an
>> optimization for
>> + * drivers which are capable of taking the corresponding &dma_resv
>> locks and
>> + * hence do not require internal locking.
>> */
>>
>> /**
>> @@ -641,6 +670,195 @@
>> * }
>> */
>>
>> +/**
>> + * get_next_vm_bo_from_list() - get the next vm_bo element
> macros use a different kerneldoc syntax:
> https://return42.github.io/linuxdoc/linuxdoc-howto/kernel-doc-syntax.html#macro
The syntax for macros in that page does not appear to be valid from what
I can tell. Please ignore that.
/Thomas
next prev parent reply other threads:[~2023-10-16 10:56 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-08 23:32 [PATCH drm-misc-next v6 0/6] [RFC] DRM GPUVM features Danilo Krummrich
2023-10-08 23:32 ` [PATCH drm-misc-next v6 1/6] drm/gpuvm: add common dma-resv per struct drm_gpuvm Danilo Krummrich
2023-10-13 11:38 ` Thomas Hellström
2023-10-13 11:51 ` Danilo Krummrich
2023-10-13 13:00 ` Thomas Hellström
2023-10-17 13:18 ` Danilo Krummrich
2023-10-08 23:32 ` [PATCH drm-misc-next v6 2/6] drm/gpuvm: add drm_gpuvm_flags to drm_gpuvm Danilo Krummrich
2023-10-13 11:43 ` Thomas Hellström
2023-10-08 23:32 ` [PATCH drm-misc-next v6 3/6] drm/gpuvm: add an abstraction for a VM / BO combination Danilo Krummrich
2023-10-13 12:30 ` Thomas Hellström
2023-10-17 9:58 ` Danilo Krummrich
2023-10-17 10:54 ` Thomas Hellström
2023-10-13 12:33 ` Thomas Hellström
2023-10-08 23:32 ` [PATCH drm-misc-next v6 4/6] drm/gpuvm: track/lock/validate external/evicted objects Danilo Krummrich
2023-10-09 13:36 ` Thomas Hellström
2023-10-09 14:45 ` Danilo Krummrich
2023-10-09 20:54 ` Danilo Krummrich
2023-10-10 6:26 ` Thomas Hellström
2023-10-13 12:04 ` Danilo Krummrich
2023-10-13 13:02 ` Thomas Hellström
2023-10-10 6:40 ` Thomas Hellström
2023-10-13 12:05 ` Danilo Krummrich
2023-10-13 13:37 ` Thomas Hellström
2023-10-16 10:55 ` Thomas Hellström [this message]
2023-10-08 23:32 ` [PATCH drm-misc-next v6 5/6] drm/nouveau: make use of the GPUVM's shared dma-resv Danilo Krummrich
2023-10-08 23:32 ` [PATCH drm-misc-next v6 6/6] drm/nouveau: use GPUVM common infrastructure Danilo Krummrich
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=b325ff2e-011b-98fd-9490-e02e21286c29@linux.intel.com \
--to=thomas.hellstrom@linux.intel.com \
--cc=airlied@gmail.com \
--cc=boris.brezillon@collabora.com \
--cc=christian.koenig@amd.com \
--cc=dakr@redhat.com \
--cc=daniel@ffwll.ch \
--cc=donald.robson@imgtec.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=faith@gfxstrand.net \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew.brost@intel.com \
--cc=nouveau@lists.freedesktop.org \
--cc=sarah.walker@imgtec.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