From: Danilo Krummrich <dakr@redhat.com>
To: "Thomas Hellström" <thomas.hellstrom@linux.intel.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 1/6] drm/gpuvm: add common dma-resv per struct drm_gpuvm
Date: Fri, 13 Oct 2023 13:51:47 +0200 [thread overview]
Message-ID: <d3409417-444b-4a7a-adde-8d6fab8f1e77@redhat.com> (raw)
In-Reply-To: <65e96c3465a47440ca44b3182e257cb40e745f8b.camel@linux.intel.com>
On 10/13/23 13:38, Thomas Hellström wrote:
> On Mon, 2023-10-09 at 01:32 +0200, Danilo Krummrich wrote:
>> Provide a common dma-resv for GEM objects not being used outside of
>> this
>> GPU-VM. This is used in a subsequent patch to generalize dma-resv,
>> external and evicted object handling and GEM validation.
>>
>> Signed-off-by: Danilo Krummrich <dakr@redhat.com>
>> ---
>> drivers/gpu/drm/drm_gpuvm.c | 56
>> +++++++++++++++++++++++++-
>> drivers/gpu/drm/nouveau/nouveau_uvmm.c | 13 +++++-
>> include/drm/drm_gpuvm.h | 35 +++++++++++++++-
>> 3 files changed, 99 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_gpuvm.c
>> b/drivers/gpu/drm/drm_gpuvm.c
>> index 02ecb45a2544..ebda9d594165 100644
>> --- a/drivers/gpu/drm/drm_gpuvm.c
>> +++ b/drivers/gpu/drm/drm_gpuvm.c
>> @@ -61,6 +61,15 @@
>> * contained within struct drm_gpuva already. Hence, for inserting
>> &drm_gpuva
>> * entries from within dma-fence signalling critical sections it is
>> enough to
>> * pre-allocate the &drm_gpuva structures.
>> + *
>> + * &drm_gem_objects which are private to a single VM can share a
>> common
>> + * &dma_resv in order to improve locking efficiency (e.g. with
>> &drm_exec).
>> + * For this purpose drivers must pass a &drm_gem_object to
>> drm_gpuvm_init(), in
>> + * the following called 'root object', which serves as the container
>
> Nit: Perhaps resv object altough it might typically be the root page-
> table object, that doesn't have any meaning to drm_gpuvm, which uses it
> solely as a container for the resv?
With "root" I didn't want to refer to the object representing the root
page-table object, but being *the* object every other (internal) object
needs to keep a reference to. Maybe I should be more explicit here and say
that drivers need to make sure every internal object requires a reference
to take a reference to this root object.
>
>> of the
>> + * GPUVM's shared &dma_resv. This root object can be a driver
>> specific
>> + * &drm_gem_object, such as the &drm_gem_object containing the root
>> page table,
>> + * but it can also be a 'dummy' object, which can be allocated with
>> + * drm_gpuvm_root_object_alloc().
>> */
>>
>> /**
>> @@ -652,9 +661,47 @@ drm_gpuvm_range_valid(struct drm_gpuvm *gpuvm,
>> !drm_gpuvm_in_kernel_node(gpuvm, addr, range);
>> }
>>
>> +static void
>> +drm_gpuvm_gem_object_free(struct drm_gem_object *obj)
>> +{
>> + drm_gem_object_release(obj);
>> + kfree(obj);
>> +}
>> +
>> +static const struct drm_gem_object_funcs drm_gpuvm_object_funcs = {
>> + .free = drm_gpuvm_gem_object_free,
>> +};
>> +
>> +/**
>> + * drm_gpuvm_root_object_alloc() - allocate a dummy &drm_gem_object
>> + * @drm: the drivers &drm_device
>> + *
>> + * Allocates a dummy &drm_gem_object which can be passed to
>> drm_gpuvm_init() in
>> + * order to serve as root GEM object providing the &drm_resv shared
>> across
>> + * &drm_gem_objects local to a single GPUVM.
>> + *
>> + * Returns: the &drm_gem_object on success, NULL on failure
>> + */
>> +struct drm_gem_object *
>> +drm_gpuvm_root_object_alloc(struct drm_device *drm)
>> +{
>> + struct drm_gem_object *obj;
>> +
>> + obj = kzalloc(sizeof(*obj), GFP_KERNEL);
>> + if (!obj)
>> + return NULL;
>> +
>> + obj->funcs = &drm_gpuvm_object_funcs;
>> + drm_gem_private_object_init(drm, obj, 0);
>> +
>> + return obj;
>> +}
>> +EXPORT_SYMBOL_GPL(drm_gpuvm_root_object_alloc);
>> +
>> /**
>> * drm_gpuvm_init() - initialize a &drm_gpuvm
>> * @gpuvm: pointer to the &drm_gpuvm to initialize
>> + * @r_obj: the root &drm_gem_object providing the GPUVM's common
>> &dma_resv
>> * @name: the name of the GPU VA space
>> * @start_offset: the start offset of the GPU VA space
>> * @range: the size of the GPU VA space
>> @@ -668,7 +715,7 @@ drm_gpuvm_range_valid(struct drm_gpuvm *gpuvm,
>> * &name is expected to be managed by the surrounding driver
>> structures.
>> */
>> void
>> -drm_gpuvm_init(struct drm_gpuvm *gpuvm,
>> +drm_gpuvm_init(struct drm_gpuvm *gpuvm, struct drm_gem_object
>> *r_obj,
>> const char *name,
>> u64 start_offset, u64 range,
>> u64 reserve_offset, u64 reserve_range,
>> @@ -683,6 +730,9 @@ drm_gpuvm_init(struct drm_gpuvm *gpuvm,
>>
>> gpuvm->name = name ? name : "unknown";
>> gpuvm->ops = ops;
>> + gpuvm->r_obj = r_obj;
>> +
>> + drm_gem_object_get(r_obj);
>>
>> memset(&gpuvm->kernel_alloc_node, 0, sizeof(struct
>> drm_gpuva));
>>
>> @@ -713,7 +763,9 @@ drm_gpuvm_destroy(struct drm_gpuvm *gpuvm)
>> __drm_gpuva_remove(&gpuvm->kernel_alloc_node);
>>
>> WARN(!RB_EMPTY_ROOT(&gpuvm->rb.tree.rb_root),
>> - "GPUVA tree is not empty, potentially leaking memory.");
>> + "GPUVA tree is not empty, potentially leaking
>> memory.\n");
>
> Should we cache the drm device in struct drm_gpuvm and use drm_warn()
> here instead of WARN?
I'd guess the additional backtrace of WARN() isn't overly useful in this
case. However, it might be a bit more obvious in dmesg due to its
verboseness. Not a strong opinion on that, though.
>
>> +
>> + drm_gem_object_put(gpuvm->r_obj);
>> }
>> EXPORT_SYMBOL_GPL(drm_gpuvm_destroy);
>>
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_uvmm.c
>> b/drivers/gpu/drm/nouveau/nouveau_uvmm.c
>> index 5cf892c50f43..4dea847ef989 100644
>> --- a/drivers/gpu/drm/nouveau/nouveau_uvmm.c
>> +++ b/drivers/gpu/drm/nouveau/nouveau_uvmm.c
>> @@ -1808,8 +1808,9 @@ int
>> nouveau_uvmm_init(struct nouveau_uvmm *uvmm, struct nouveau_cli
>> *cli,
>> u64 kernel_managed_addr, u64 kernel_managed_size)
>> {
>> - int ret;
>> + struct drm_gem_object *r_obj;
>> u64 kernel_managed_end = kernel_managed_addr +
>> kernel_managed_size;
>> + int ret;
>>
>> mutex_init(&uvmm->mutex);
>> dma_resv_init(&uvmm->resv);
>> @@ -1833,14 +1834,22 @@ nouveau_uvmm_init(struct nouveau_uvmm *uvmm,
>> struct nouveau_cli *cli,
>> goto out_unlock;
>> }
>>
>> + r_obj = drm_gpuvm_root_object_alloc(cli->drm->dev);
>> + if (!r_obj) {
>> + ret = -ENOMEM;
>> + goto out_unlock;
>> + }
>> +
>> uvmm->kernel_managed_addr = kernel_managed_addr;
>> uvmm->kernel_managed_size = kernel_managed_size;
>>
>> - drm_gpuvm_init(&uvmm->base, cli->name,
>> + drm_gpuvm_init(&uvmm->base, r_obj, cli->name,
>> NOUVEAU_VA_SPACE_START,
>> NOUVEAU_VA_SPACE_END,
>> kernel_managed_addr, kernel_managed_size,
>> NULL);
>> + /* GPUVM takes care from here on. */
>> + drm_gem_object_put(r_obj);
>>
>> ret = nvif_vmm_ctor(&cli->mmu, "uvmm",
>> cli->vmm.vmm.object.oclass, RAW,
>> diff --git a/include/drm/drm_gpuvm.h b/include/drm/drm_gpuvm.h
>> index c7ed6bf441d4..0aec14d8b259 100644
>> --- a/include/drm/drm_gpuvm.h
>> +++ b/include/drm/drm_gpuvm.h
>> @@ -238,9 +238,15 @@ struct drm_gpuvm {
>> * @ops: &drm_gpuvm_ops providing the split/merge steps to
>> drivers
>> */
>> const struct drm_gpuvm_ops *ops;
>> +
>> + /**
>> + * @r_obj: Root GEM object; representing the GPUVM's common
>> &dma_resv.
>> + */
>> + struct drm_gem_object *r_obj;
>> };
>>
>> -void drm_gpuvm_init(struct drm_gpuvm *gpuvm, const char *name,
>> +void drm_gpuvm_init(struct drm_gpuvm *gpuvm, struct drm_gem_object
>> *r_obj,
>> + const char *name,
>> u64 start_offset, u64 range,
>> u64 reserve_offset, u64 reserve_range,
>> const struct drm_gpuvm_ops *ops);
>> @@ -248,6 +254,33 @@ void drm_gpuvm_destroy(struct drm_gpuvm *gpuvm);
>>
>> bool drm_gpuvm_interval_empty(struct drm_gpuvm *gpuvm, u64 addr, u64
>> range);
>>
>> +struct drm_gem_object *
>> +drm_gpuvm_root_object_alloc(struct drm_device *drm);
>> +
>> +/**
>> + * drm_gpuvm_resv() - returns the &drm_gpuvm's &dma_resv
>> + * @gpuvm__: the &drm_gpuvm
>> + *
>> + * Returns: a pointer to the &drm_gpuvm's shared &dma_resv
>> + */
>> +#define drm_gpuvm_resv(gpuvm__) ((gpuvm__)->r_obj->resv)
>> +
>> +/**
>> + * drm_gpuvm_resv_obj() - returns the &drm_gem_object holding the
>> &drm_gpuvm's
>> + * &dma_resv
>> + * @gpuvm__: the &drm_gpuvm
>> + *
>> + * Returns: a pointer to the &drm_gem_object holding the
>> &drm_gpuvm's shared
>> + * &dma_resv
>> + */
>> +#define drm_gpuvm_resv_obj(gpuvm__) ((gpuvm__)->r_obj)
>> +
>> +#define drm_gpuvm_resv_held(gpuvm__) \
>> + dma_resv_held(drm_gpuvm_resv(gpuvm__))
>> +
>> +#define drm_gpuvm_resv_assert_held(gpuvm__) \
>> + dma_resv_assert_held(drm_gpuvm_resv(gpuvm__))
>> +
>> static inline struct drm_gpuva *
>> __drm_gpuva_next(struct drm_gpuva *va)
>> {
>
> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
>
>
next prev parent reply other threads:[~2023-10-13 11:52 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 [this message]
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
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=d3409417-444b-4a7a-adde-8d6fab8f1e77@redhat.com \
--to=dakr@redhat.com \
--cc=airlied@gmail.com \
--cc=boris.brezillon@collabora.com \
--cc=christian.koenig@amd.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 \
--cc=thomas.hellstrom@linux.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
all inboxes | Powered by JetHome®