[PATCH] drm/imagination: drop redundant zeroing of new GEM objects
Guillaume La Roque
glaroque at baylibre.com
Wed Nov 11 01:43:18 PST 2026
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 at 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 at baylibre.com>
More information about the linux-riscv
mailing list