From: Guillaume La Roque <glaroque@baylibre.com>
To: Alessio Belle <alessio.belle@imgtec.com>,
Luigi Santivetti <luigi.santivetti@imgtec.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>, Paul Walmsley <pjw@kernel.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Alexandre Ghiti <alex@ghiti.fr>
Cc: imagination@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
linux-riscv@lists.infradead.org,
Guillaume La Roque <glaroque@baylibre.com>
Subject: [PATCH] drm/imagination: drop redundant zeroing of new GEM objects
Date: Wed, 11 Nov 2026 10:43:18 +0100 [thread overview]
Message-ID: <20261111-pvr-gem-drop-zeroing-v1-1-2dc725857053@baylibre.com> (raw)
pvr_gem_object_create() clears every new object through a CPU mapping
so that userspace never sees data left by a previous owner of the
pages [1]. shmem already guarantees that: it clears each page it
allocates, and the dma_sync_sgtable_for_device() call that follows
makes those zeroes visible to the GPU. The second pass, write-combined
on non-coherent devices, only adds latency.
Link: https://lore.kernel.org/dd2ceacc-f59b-9c3c-e4ce-30b3bbd6939b@mailbox.org [1]
Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
---
pvr_gem_object_create() clears every new object through a CPU mapping,
on top of the zeroing shmem already does. Dropping that pass speeds up
object creation, most visibly where it goes through a write-combined
mapping on a non-coherent platform.
Testing: drm-misc-next (41ecf852c073) with a Debian rootfs, on a TI
J722S EVM (BXS-4-64, arm64) and a SpacemiT K3 Pico-ITX (BXM-4-64,
riscv64). The K3 also needs local patches that are not upstream yet:
its GPU DT node, an RPMI power domain fix for its firmware and BVNC
36.56.104.183. Each board ran two small test programs, once without and
once with the patch:
- The first one only uses the powervr DRM ioctls. It fills 250 objects
with a pattern through their CPU mapping, frees them, creates new
objects of the same size and checks they read back as zero. It also
times DRM_IOCTL_PVR_CREATE_BO. Result, without -> with the patch:
J722S: 0 -> 0 non-zero bytes, 16 MiB object in 20.6 -> 17.4 ms
K3: 0 -> 0 non-zero bytes, 16 MiB object in 41.6 -> 9.2 ms
- The second one does the same check through Mesa's Vulkan driver,
and also reads the new memory from the GPU: the GPU copies it into a
buffer that the CPU then checks. 80 allocations, on the J722S only, as
Mesa is not built on the K3 yet. Result: 0 non-zero bytes without and
with the patch.
The test programs were written and run with the help of an LLM.
---
drivers/gpu/drm/imagination/pvr_gem.c | 34 ----------------------------------
1 file changed, 34 deletions(-)
diff --git a/drivers/gpu/drm/imagination/pvr_gem.c b/drivers/gpu/drm/imagination/pvr_gem.c
index d8660d6a8e01..01b8e08d12f0 100644
--- a/drivers/gpu/drm/imagination/pvr_gem.c
+++ b/drivers/gpu/drm/imagination/pvr_gem.c
@@ -275,34 +275,6 @@ pvr_gem_object_vunmap(struct pvr_gem_object *pvr_obj)
dma_resv_unlock(obj->resv);
}
-/**
- * pvr_gem_object_zero() - Zeroes the physical memory behind an object.
- * @pvr_obj: Target PowerVR GEM object.
- *
- * Return:
- * * 0 on success, or
- * * Any error encountered while attempting to map @pvr_obj to the CPU (see
- * pvr_gem_object_vmap()).
- */
-static int
-pvr_gem_object_zero(struct pvr_gem_object *pvr_obj)
-{
- void *cpu_ptr;
-
- cpu_ptr = pvr_gem_object_vmap(pvr_obj);
- if (IS_ERR(cpu_ptr))
- return PTR_ERR(cpu_ptr);
-
- memset(cpu_ptr, 0, pvr_gem_object_size(pvr_obj));
-
- /* Make sure the zero-ing is done before vumap-ing the object. */
- wmb();
-
- pvr_gem_object_vunmap(pvr_obj);
-
- return 0;
-}
-
/**
* pvr_gem_create_object() - Allocate and pre-initializes a pvr_gem_object
* @drm_dev: DRM device creating this object.
@@ -378,12 +350,6 @@ pvr_gem_object_create(struct pvr_device *pvr_dev, size_t size, u64 flags)
dma_sync_sgtable_for_device(drm_dev->dev, sgt, DMA_BIDIRECTIONAL);
- /*
- * Do this last because pvr_gem_object_zero() requires a fully
- * configured instance of struct pvr_gem_object.
- */
- pvr_gem_object_zero(pvr_obj);
-
return pvr_obj;
err_shmem_object_free:
---
base-commit: 41b5458595c60143d0ebaa1e032c9cda5d764dff
change-id: 20261105-pvr-gem-drop-zeroing-67cc98380a55
Best regards,
--
Guillaume La Roque <glaroque@baylibre.com>
reply other threads:[~2026-11-11 9:43 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20261111-pvr-gem-drop-zeroing-v1-1-2dc725857053@baylibre.com \
--to=glaroque@baylibre.com \
--cc=airlied@gmail.com \
--cc=alessio.belle@imgtec.com \
--cc=alex@ghiti.fr \
--cc=aou@eecs.berkeley.edu \
--cc=dri-devel@lists.freedesktop.org \
--cc=imagination@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=luigi.santivetti@imgtec.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.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 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®