All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@collabora.com>
To: "Adrián Larumbe" <adrian.larumbe@collabora.com>
Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	Steven Price <steven.price@arm.com>,
	Rob Herring <robh@kernel.org>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
	kernel@collabora.com
Subject: Re: [RFC PATCH 6/7] drm/panfrost: Use shmem sparse allocation for heap BOs
Date: Tue, 25 Feb 2025 16:04:59 +0100	[thread overview]
Message-ID: <20250225160459.664ce342@collabora.com> (raw)
In-Reply-To: <20250218232552.3450939-7-adrian.larumbe@collabora.com>

On Tue, 18 Feb 2025 23:25:36 +0000
Adrián Larumbe <adrian.larumbe@collabora.com> wrote:

> Panfrost heap BOs grow on demand when the GPU triggers a page fault after
> accessing an address within the BO's virtual range.
> 
> We still store the sgts we get back from the shmem sparse allocation function,
> since it was decided management of sparse memory SGTs should be done by client
> drivers rather than the shmem subsystem.
> 
> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
> ---
>  drivers/gpu/drm/panfrost/panfrost_gem.c | 12 ++--
>  drivers/gpu/drm/panfrost/panfrost_gem.h |  2 +-
>  drivers/gpu/drm/panfrost/panfrost_mmu.c | 85 +++++--------------------
>  3 files changed, 25 insertions(+), 74 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c b/drivers/gpu/drm/panfrost/panfrost_gem.c
> index 8e0ff3efede7..0cda2c4e524f 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_gem.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_gem.c
> @@ -40,10 +40,10 @@ static void panfrost_gem_free_object(struct drm_gem_object *obj)
>  		int n_sgt = bo->base.base.size / SZ_2M;
>  
>  		for (i = 0; i < n_sgt; i++) {
> -			if (bo->sgts[i].sgl) {
> -				dma_unmap_sgtable(pfdev->dev, &bo->sgts[i],
> +			if (bo->sgts[i]) {
> +				dma_unmap_sgtable(pfdev->dev, bo->sgts[i],
>  						  DMA_BIDIRECTIONAL, 0);
> -				sg_free_table(&bo->sgts[i]);
> +				sg_free_table(bo->sgts[i]);
>  			}
>  		}
>  		kvfree(bo->sgts);
> @@ -274,7 +274,11 @@ panfrost_gem_create(struct drm_device *dev, size_t size, u32 flags)
>  	if (flags & PANFROST_BO_HEAP)
>  		size = roundup(size, SZ_2M);
>  
> -	shmem = drm_gem_shmem_create(dev, size);
> +	if (flags & PANFROST_BO_HEAP)
> +		shmem = drm_gem_shmem_create_sparse(dev, size);
> +	else
> +		shmem = drm_gem_shmem_create(dev, size);
> +
>  	if (IS_ERR(shmem))
>  		return ERR_CAST(shmem);
>  
> diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.h b/drivers/gpu/drm/panfrost/panfrost_gem.h
> index 7516b7ecf7fe..2a8d0752011e 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_gem.h
> +++ b/drivers/gpu/drm/panfrost/panfrost_gem.h
> @@ -11,7 +11,7 @@ struct panfrost_mmu;
>  
>  struct panfrost_gem_object {
>  	struct drm_gem_shmem_object base;
> -	struct sg_table *sgts;
> +	struct sg_table **sgts;

I guess using an xarray here would make sense. Or maybe even an
sg_append_table, since we don't expect holes in the populated pages.
This makes me wonder if we really want the gem_shmem layer to automate
sgt creation for sparse GEM objects. Looks like something the driver
can easily optimize for its use-case.

  reply	other threads:[~2025-02-25 15:05 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-18 23:25 [RFC PATCH 0/7] Introduce sparse DRM shmem object allocations Adrián Larumbe
2025-02-18 23:25 ` [RFC PATCH 1/7] shmem: Introduce non-blocking allocation of shmem pages Adrián Larumbe
2025-02-25 12:43   ` Boris Brezillon
2025-02-18 23:25 ` [RFC PATCH 2/7] lib/scatterlist.c: Support constructing sgt from page xarray Adrián Larumbe
2025-02-25 12:57   ` Boris Brezillon
2025-02-18 23:25 ` [RFC PATCH 3/7] drm/prime: Let drm_prime_pages_to_sg use the page_array interface Adrián Larumbe
2025-02-18 23:25 ` [RFC PATCH 4/7] drm/shmem: Introduce the notion of sparse objects Adrián Larumbe
2025-02-25 13:28   ` Boris Brezillon
2025-02-18 23:25 ` [RFC PATCH 5/7] drm/shmem: Implement sparse allocation of pages for shmem objects Adrián Larumbe
2025-02-25 14:39   ` Boris Brezillon
2025-02-18 23:25 ` [RFC PATCH 6/7] drm/panfrost: Use shmem sparse allocation for heap BOs Adrián Larumbe
2025-02-25 15:04   ` Boris Brezillon [this message]
2025-02-18 23:25 ` [RFC PATCH 7/7] drm/panfrost/panthor: Take sparse objects into account for fdinfo Adrián Larumbe
2025-02-25 15:09   ` Boris Brezillon

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=20250225160459.664ce342@collabora.com \
    --to=boris.brezillon@collabora.com \
    --cc=adrian.larumbe@collabora.com \
    --cc=airlied@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kernel@collabora.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=robh@kernel.org \
    --cc=simona@ffwll.ch \
    --cc=steven.price@arm.com \
    --cc=tzimmermann@suse.de \
    /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 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.