From: "Danilo Krummrich" <dakr@kernel.org>
To: "Mohamed Ahmed" <mohamedahmedegypt2001@gmail.com>
Cc: <linux-kernel@vger.kernel.org>, <dri-devel@lists.freedesktop.org>,
"Mary Guillemard" <mary@mary.zone>,
"Faith Ekstrand" <faith.ekstrand@collabora.com>,
"Lyude Paul" <lyude@redhat.com>,
"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>,
<nouveau@lists.freedesktop.org>
Subject: Re: [PATCH 2/5] drm/nouveau/uvmm: Allow larger pages
Date: Mon, 06 Oct 2025 22:26:24 +0200 [thread overview]
Message-ID: <DDBISJ2DUDF6.150HCB14ZRPH3@kernel.org> (raw)
In-Reply-To: <20251006191329.277485-3-mohamedahmedegypt2001@gmail.com>
On Mon Oct 6, 2025 at 9:13 PM CEST, Mohamed Ahmed wrote:
> From: Mary Guillemard <mary@mary.zone>
>
> Now that everything in UVMM knows about the variable page shift, we can
> select larger values.
>
> The proposed approach rely on nouveau_bo::page unless it would cause
> alignment issues (in which case we fall back to searching an appropriate
> shift)
>
> Co-developed-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com>
> Signed-off-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com>
> Signed-off-by: Mary Guillemard <mary@mary.zone>
NIT: Both of your tags should come after Mary's tag. The same applied to some of
the other patches.
> ---
> drivers/gpu/drm/nouveau/nouveau_uvmm.c | 55 +++++++++++++++++++++++++-
> 1 file changed, 53 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_uvmm.c b/drivers/gpu/drm/nouveau/nouveau_uvmm.c
> index a92c729600d6..c336a121e320 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_uvmm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_uvmm.c
> @@ -454,6 +454,56 @@ op_unmap_prepare_unwind(struct drm_gpuva *va)
> drm_gpuva_insert(va->vm, va);
> }
>
> +static bool
> +op_map_aligned_to_page_shift(const struct drm_gpuva_op_map *op, u8 page_shift)
> +{
> + u64 page_size = 1ULL << page_shift;
> +
> + return op->va.addr % page_size == 0 && op->va.range % page_size == 0 &&
> + op->gem.offset % page_size == 0;
> +}
> +
> +static u8
> +select_page_shift(struct nouveau_uvmm *uvmm, struct drm_gpuva_op_map *op)
> +{
> + struct nouveau_bo *nvbo = nouveau_gem_object(op->gem.obj);
> +
> + if (nvbo) {
In nouveau a struct drm_gpuva_op_map always has a valid GEM object set; we bail
out if userspace gives us an invalid GEM handle.
> + /* If the BO preferred page shift already fits, use it. */
> + if (op_map_aligned_to_page_shift(op, nvbo->page))
> + return nvbo->page;
> +
> + struct nouveau_mem *mem = nouveau_mem(nvbo->bo.resource);
> + struct nvif_vmm *vmm = &uvmm->vmm.vmm;
> + int i;
> +
> + /* Otherwise let's find a granuality that will fit. */
Do we ever run into the "otherwise" case? nouveau_bo_fixup_align() seems to
already ensure that your previous call will never fail?
> + for (i = 0; i < vmm->page_nr; i++) {
> + /* Ignore anything that is bigger or identical to the BO preference. */
> + if (vmm->page[i].shift >= nvbo->page)
> + continue;
> +
> + /* Skip incompatible domains. */
> + if ((mem->mem.type & NVIF_MEM_VRAM) && !vmm->page[i].vram)
> + continue;
> + if ((mem->mem.type & NVIF_MEM_HOST) &&
> + (!vmm->page[i].host || vmm->page[i].shift > PAGE_SHIFT))
> + continue;
> +
> + /* If it fits, return the proposed shift. */
> + if (op_map_aligned_to_page_shift(op, vmm->page[i].shift))
> + return vmm->page[i].shift;
> + }
> +
> + /* If we get here then nothing can reconcile the requirements. This should never
> + * happen.
> + */
> + WARN_ON(1);
> + }
> +
> + return PAGE_SHIFT;
> +}
> +
> static void
> nouveau_uvmm_sm_prepare_unwind(struct nouveau_uvmm *uvmm,
> struct nouveau_uvma_prealloc *new,
> @@ -506,7 +556,7 @@ nouveau_uvmm_sm_prepare_unwind(struct nouveau_uvmm *uvmm,
> if (vmm_get_range)
> nouveau_uvmm_vmm_put(uvmm, vmm_get_start,
> vmm_get_range,
> - PAGE_SHIFT);
> + select_page_shift(uvmm, &op->map));
> break;
> }
> case DRM_GPUVA_OP_REMAP: {
> @@ -636,7 +686,8 @@ nouveau_uvmm_sm_prepare(struct nouveau_uvmm *uvmm,
> case DRM_GPUVA_OP_MAP: {
> u64 vmm_get_range = vmm_get_end - vmm_get_start;
>
> - ret = op_map_prepare(uvmm, &new->map, &op->map, args, PAGE_SHIFT);
> + ret = op_map_prepare(uvmm, &new->map, &op->map, args,
> + select_page_shift(uvmm, &op->map));
Let's move the call to select_page_shift() into op_map_prepare().
> if (ret)
> goto unwind;
>
> --
> 2.51.0
next prev parent reply other threads:[~2025-10-06 20:26 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-06 19:13 [PATCH 0/5] drm/nouveau: Enable variable page sizes and compression Mohamed Ahmed
2025-10-06 19:13 ` [PATCH 1/5] drm/nouveau/uvmm: Prepare for larger pages Mohamed Ahmed
2025-10-06 19:13 ` [PATCH 2/5] drm/nouveau/uvmm: Allow " Mohamed Ahmed
2025-10-06 20:26 ` Danilo Krummrich [this message]
2025-10-09 16:51 ` Mohamed Ahmed
2025-10-09 20:09 ` Danilo Krummrich
2025-10-09 23:40 ` Mohamed Ahmed
2025-10-06 19:13 ` [PATCH 3/5] drm/nouveau/mmu/gp100: Remove unused/broken support for compression Mohamed Ahmed
2025-10-06 20:27 ` Danilo Krummrich
2025-10-06 19:13 ` [PATCH 4/5] drm/nouveau/mmu/tu102: Add support for compressed kinds Mohamed Ahmed
2025-10-06 19:13 ` [PATCH 5/5] drm/nouveau/drm: Bump the driver version to 1.4.1 to report new features Mohamed Ahmed
2025-10-06 20:29 ` Danilo Krummrich
-- strict thread matches above, loose matches on Subject: below --
2025-10-09 23:38 [PATCH 0/5 v2] drm/nouveau: Enable variable page sizes and compression Mohamed Ahmed
2025-10-09 23:38 ` [PATCH 2/5] drm/nouveau/uvmm: Allow larger pages Mohamed Ahmed
2025-10-22 10:16 ` Mohamed Ahmed
2025-10-22 20:56 ` Danilo Krummrich
2025-10-22 21:09 ` Lyude Paul
2025-10-22 21:39 ` Mary Guillemard
2025-10-23 10:14 ` Mohamed Ahmed
2025-10-23 20:51 ` Lyude Paul
2025-10-24 18:38 ` M Henning
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=DDBISJ2DUDF6.150HCB14ZRPH3@kernel.org \
--to=dakr@kernel.org \
--cc=airlied@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=faith.ekstrand@collabora.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lyude@redhat.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mary@mary.zone \
--cc=mohamedahmedegypt2001@gmail.com \
--cc=mripard@kernel.org \
--cc=nouveau@lists.freedesktop.org \
--cc=simona@ffwll.ch \
--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.