From: Thomas Zimmermann <tzimmermann@suse.de>
To: Boris Brezillon <boris.brezillon@collabora.com>
Cc: simona@ffwll.ch, airlied@gmail.com, mripard@kernel.org,
maarten.lankhorst@linux.intel.com, ogabbay@kernel.org,
mamin506@gmail.com, lizhi.hou@amd.com,
maciej.falkowski@linux.intel.com,
karol.wachowski@linux.intel.com, tomeu@tomeuvizoso.net,
frank.binns@imgtec.com, matt.coster@imgtec.com, yuq825@gmail.com,
robh@kernel.org, steven.price@arm.com,
adrian.larumbe@collabora.com, liviu.dudau@arm.com,
mwen@igalia.com, kraxel@redhat.com,
dmitry.osipenko@collabora.com, gurchetansingh@chromium.org,
olvaffe@gmail.com, corbet@lwn.net,
dri-devel@lists.freedesktop.org, lima@lists.freedesktop.org,
virtualization@lists.linux.dev, linux-doc@vger.kernel.org
Subject: Re: [RFC][PATCH 00/13] drm: Introduce GEM-UMA memory management
Date: Tue, 9 Dec 2025 15:51:21 +0100 [thread overview]
Message-ID: <2b95d76e-2672-4cae-a545-73c407f2b20c@suse.de> (raw)
In-Reply-To: <20251209152734.6851f3ac@fedora>
Hi
Am 09.12.25 um 15:27 schrieb Boris Brezillon:
> On Tue, 9 Dec 2025 14:41:57 +0100
> Thomas Zimmermann <tzimmermann@suse.de> wrote:
>
>> Duplicate GEM-SHMEM to GEM-UMA. Convert all DRM drivers for UMA
>> systems if they currently use GEM-SHMEM.
>>
>> Many DRM drivers for hardware with Unified Memory Architecture (UMA)
>> currently builds upon GEM-SHMEM and extends the helpers with features
>> for managing the GPU MMU. This allows the GPU to access the GEM buffer
>> content for its operation.
>>
>> There is another, larger, set of DRM drivers that use GEM-SHMEM merely
>> as buffer management with no hardware support. These drivers copy the
>> buffer content to the GPU on each page flip. The GPU itself has no direct
>> access. Hardware of this type is usually in servers, behind slow busses
>> (SPI, USB), or provided by firmware (drivers in sysfb/).
>>
>> After some discussion with Boris on the future of GEM-SHMEM, it seems
>> to me that both use cases more and more diverge from each other. The
>> most prominent example is the implementation of gem_prime_import,
>> where both use cases use distinct approaches.
>>
>> So we discussed the introduction of a GEM-UMA helper library for
>> UMA-based hardware. GEM-UMA will remain flexible enough for drivers
>> to extend it for their use case. GEM-SHMEM will become focused on the
>> simple-hardware use case. The benefit for both libraries is that they
>> will be easier to understand and maintain. GEM-SHMEM can be simplified
>> signiifcantly, I think.
>>
>> This RFC series introduces GEM-UMA and converts the UMA-related drivers.
>>
>> Patches 1 and 2 fix issues in GEM-SHMEM, so that we don't duplicate
>> errornous code.
>>
>> Patch 3 copies GEM-SHMEM to GEM-UMA. Patch 4 then does soem obvious
>> cleanups of unnecessary code.
> Instead of copying the code as-is, I'd rather take a step back and think
> about what we need and how we want to handle more complex stuff, like
> reclaim. I've started working on a shrinker for panthor [1], and as part
> of this series, I've added a commit implementing just enough to replace
> what gem-shmem currently provides. Feels like the new GEM-UMA thing
> could be designed on a composition rather than inheritance model,
> where we have sub-components (backing, cpu_map, gpu_map) that can be
> pulled in and re-used by the driver implementation. The common helpers
> would take those sub-components instead of a plain GEM object. That
> would leave the drivers free of how their internal gem_object fields are
> laid out and wouldn't require overloading the ->gem_create_object()
> function. It seems to be that it would better match the model you were
> describing the other day.
Yeah, I've seen your update to that series. Making individual parts of
the memory manager freely composable with each other is a fine idea.
But the flipside is that I also want the simple drivers to move away
from the flexible approach that GEM-SHMEM currently takes. There are
many drivers that do not need or want that. These drivers benefit from
something that is self contained. Many of the drivers are also hardly
maintained, so simplifying things will also be helpful.
I could have added a new GEM implementation for these drivers, but there
are less UMA drivers to convert and the GEM-UMA naming generally fits
better than GEM-SHMEM.
I'd rather have GEM-UMA and evolve it from where it stands now; and also
evolve GEM-SHMEM in a different direction. There's a difference in
concepts here.
Best regards
Thomas
>
>> Patches 5 to 13 update the drivers that can be converted to GEM-UMA.
>> These changes are just symbol renaming. There are so far no functional
>> differences between the memory managers.
>>
>> A gave GEM-UMA some smoke testing by running virtgpu.
> [1]https://gitlab.freedesktop.org/bbrezillon/linux/-/commits/panthor-shrinker-revisited/drivers?ref_type=heads
> [2]https://gitlab.freedesktop.org/bbrezillon/linux/-/commit/4e6927fc2c60265b77a5a88013f55377bc4f4ab3
>
>> Thomas Zimmermann (13):
>> drm/gem-shmem: Fix typos in documentation
>> drm/gem-shmem: Fix the MODULE_LICENSE() string
>> drm: Add GEM-UMA helpers for memory management
>> drm/gem-uma: Remove unused interfaces
>> drm/imagination: Use GEM-UMA helpers for memory management
>> drm/lima: Use GEM-UMA helpers for memory management
>> drm/panfrost: Use GEM-UMA helpers for memory management
>> drm/panthor: Use GEM-UMA helpers for memory management
>> drm/v3d: Use GEM-UMA helpers for memory management
>> drm/virtgpu: Use GEM-UMA helpers for memory management
>> accel/amdxdna: Use GEM-UMA helpers for memory management
>> accel/ivpu: Use GEM-UMA helpers for memory management
>> accel/rocket: Use GEM-UMA helpers for memory management
>>
>> Documentation/gpu/drm-mm.rst | 12 +
>> drivers/accel/amdxdna/Kconfig | 2 +-
>> drivers/accel/amdxdna/aie2_ctx.c | 1 -
>> drivers/accel/amdxdna/aie2_message.c | 1 -
>> drivers/accel/amdxdna/aie2_pci.c | 1 -
>> drivers/accel/amdxdna/aie2_psp.c | 1 -
>> drivers/accel/amdxdna/aie2_smu.c | 1 -
>> drivers/accel/amdxdna/amdxdna_ctx.c | 7 +-
>> drivers/accel/amdxdna/amdxdna_gem.c | 49 +-
>> drivers/accel/amdxdna/amdxdna_gem.h | 5 +-
>> .../accel/amdxdna/amdxdna_mailbox_helper.c | 1 -
>> drivers/accel/amdxdna/amdxdna_pci_drv.c | 1 -
>> drivers/accel/amdxdna/amdxdna_sysfs.c | 1 -
>> drivers/accel/ivpu/Kconfig | 2 +-
>> drivers/accel/ivpu/ivpu_gem.c | 36 +-
>> drivers/accel/ivpu/ivpu_gem.h | 4 +-
>> drivers/accel/rocket/Kconfig | 2 +-
>> drivers/accel/rocket/rocket_gem.c | 46 +-
>> drivers/accel/rocket/rocket_gem.h | 6 +-
>> drivers/gpu/drm/Kconfig | 9 +
>> drivers/gpu/drm/Kconfig.debug | 1 +
>> drivers/gpu/drm/Makefile | 4 +
>> drivers/gpu/drm/drm_fbdev_uma.c | 203 +++++
>> drivers/gpu/drm/drm_gem_shmem_helper.c | 5 +-
>> drivers/gpu/drm/drm_gem_uma_helper.c | 787 ++++++++++++++++++
>> drivers/gpu/drm/imagination/Kconfig | 4 +-
>> drivers/gpu/drm/imagination/pvr_drv.c | 2 +-
>> drivers/gpu/drm/imagination/pvr_free_list.c | 2 +-
>> drivers/gpu/drm/imagination/pvr_gem.c | 74 +-
>> drivers/gpu/drm/imagination/pvr_gem.h | 12 +-
>> drivers/gpu/drm/lima/Kconfig | 4 +-
>> drivers/gpu/drm/lima/lima_drv.c | 2 +-
>> drivers/gpu/drm/lima/lima_gem.c | 30 +-
>> drivers/gpu/drm/lima/lima_gem.h | 6 +-
>> drivers/gpu/drm/panfrost/Kconfig | 2 +-
>> drivers/gpu/drm/panfrost/panfrost_drv.c | 2 +-
>> drivers/gpu/drm/panfrost/panfrost_gem.c | 30 +-
>> drivers/gpu/drm/panfrost/panfrost_gem.h | 6 +-
>> .../gpu/drm/panfrost/panfrost_gem_shrinker.c | 30 +-
>> drivers/gpu/drm/panfrost/panfrost_mmu.c | 8 +-
>> drivers/gpu/drm/panfrost/panfrost_perfcnt.c | 6 +-
>> drivers/gpu/drm/panthor/Kconfig | 2 +-
>> drivers/gpu/drm/panthor/panthor_drv.c | 2 +-
>> drivers/gpu/drm/panthor/panthor_fw.c | 4 +-
>> drivers/gpu/drm/panthor/panthor_gem.c | 40 +-
>> drivers/gpu/drm/panthor/panthor_gem.h | 8 +-
>> drivers/gpu/drm/panthor/panthor_mmu.c | 10 +-
>> drivers/gpu/drm/panthor/panthor_sched.c | 1 -
>> drivers/gpu/drm/tests/Makefile | 1 +
>> drivers/gpu/drm/tests/drm_gem_uma_test.c | 385 +++++++++
>> drivers/gpu/drm/v3d/Kconfig | 2 +-
>> drivers/gpu/drm/v3d/v3d_bo.c | 45 +-
>> drivers/gpu/drm/v3d/v3d_drv.h | 4 +-
>> drivers/gpu/drm/v3d/v3d_mmu.c | 9 +-
>> drivers/gpu/drm/virtio/Kconfig | 4 +-
>> drivers/gpu/drm/virtio/virtgpu_drv.c | 4 +-
>> drivers/gpu/drm/virtio/virtgpu_drv.h | 12 +-
>> drivers/gpu/drm/virtio/virtgpu_object.c | 64 +-
>> drivers/gpu/drm/virtio/virtgpu_plane.c | 6 +-
>> drivers/gpu/drm/virtio/virtgpu_vq.c | 6 +-
>> include/drm/drm_fbdev_uma.h | 20 +
>> include/drm/drm_gem_uma_helper.h | 293 +++++++
>> 62 files changed, 2018 insertions(+), 312 deletions(-)
>> create mode 100644 drivers/gpu/drm/drm_fbdev_uma.c
>> create mode 100644 drivers/gpu/drm/drm_gem_uma_helper.c
>> create mode 100644 drivers/gpu/drm/tests/drm_gem_uma_test.c
>> create mode 100644 include/drm/drm_fbdev_uma.h
>> create mode 100644 include/drm/drm_gem_uma_helper.h
>>
>>
>> base-commit: 0a21e96e0b6840d2a4e0b45a957679eeddeb4362
>> prerequisite-patch-id: c67e5d886a47b7d0266d81100837557fda34cb24
>> prerequisite-patch-id: a5a973e527c88a5b47053d7a72aefe0b550197cb
>> prerequisite-patch-id: 719d09751d38f5da743beed6266585ee063e1e29
>> prerequisite-patch-id: 0bbc85bc6b528c32592e07f4ceafa51795c4cad9
>> prerequisite-patch-id: c856d9c8a026e3244c44ec829e426e0ad4a685ab
>> prerequisite-patch-id: 13441c9ed3062ae1448a53086559dfcbbd578177
>> prerequisite-patch-id: 951c039657c1f58e4b6e36bc01c7a1c69ed59767
>> prerequisite-patch-id: 4370b8b803ca439666fb9d2beb862f6e78347ce3
>> prerequisite-patch-id: ebbaad226ed599f7aad4784fb3f4aaebe34cb110
>> prerequisite-patch-id: cb907c3e3e14de7f4d13b429f3a2a88621a8a9fe
>> prerequisite-patch-id: 0e243b426742122b239af59e36d742da5795a8b1
>> prerequisite-patch-id: 120f97fa1af9891375a0dcf52c51c1907b01fe6a
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
next prev parent reply other threads:[~2025-12-09 14:51 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-09 13:41 [RFC][PATCH 00/13] drm: Introduce GEM-UMA memory management Thomas Zimmermann
2025-12-09 13:41 ` [PATCH 01/13] drm/gem-shmem: Fix typos in documentation Thomas Zimmermann
2025-12-11 10:00 ` Boris Brezillon
2025-12-11 12:03 ` Thomas Zimmermann
2025-12-09 13:41 ` [PATCH 02/13] drm/gem-shmem: Fix the MODULE_LICENSE() string Thomas Zimmermann
2025-12-11 10:01 ` Boris Brezillon
2025-12-11 12:04 ` Thomas Zimmermann
2025-12-09 13:42 ` [PATCH 03/13] drm: Add GEM-UMA helpers for memory management Thomas Zimmermann
2025-12-09 13:42 ` [PATCH 04/13] drm/gem-uma: Remove unused interfaces Thomas Zimmermann
2025-12-09 13:42 ` [PATCH 05/13] drm/imagination: Use GEM-UMA helpers for memory management Thomas Zimmermann
2025-12-09 13:42 ` [PATCH 06/13] drm/lima: " Thomas Zimmermann
2025-12-09 13:42 ` [PATCH 07/13] drm/panfrost: " Thomas Zimmermann
2025-12-09 13:42 ` [PATCH 08/13] drm/panthor: " Thomas Zimmermann
2025-12-09 13:42 ` [PATCH 09/13] drm/v3d: " Thomas Zimmermann
2025-12-09 13:42 ` [PATCH 10/13] drm/virtgpu: " Thomas Zimmermann
2025-12-09 13:42 ` [PATCH 11/13] accel/amdxdna: " Thomas Zimmermann
2025-12-09 13:42 ` [PATCH 12/13] accel/ivpu: " Thomas Zimmermann
2025-12-09 14:24 ` Karol Wachowski
2025-12-09 14:25 ` Karol Wachowski
2025-12-09 13:42 ` [PATCH 13/13] accel/rocket: " Thomas Zimmermann
2025-12-09 14:27 ` [RFC][PATCH 00/13] drm: Introduce GEM-UMA " Boris Brezillon
2025-12-09 14:51 ` Thomas Zimmermann [this message]
2025-12-09 15:30 ` Boris Brezillon
2025-12-10 7:34 ` Thomas Zimmermann
2025-12-10 9:21 ` Boris Brezillon
2025-12-10 9:57 ` Thomas Zimmermann
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=2b95d76e-2672-4cae-a545-73c407f2b20c@suse.de \
--to=tzimmermann@suse.de \
--cc=adrian.larumbe@collabora.com \
--cc=airlied@gmail.com \
--cc=boris.brezillon@collabora.com \
--cc=corbet@lwn.net \
--cc=dmitry.osipenko@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=frank.binns@imgtec.com \
--cc=gurchetansingh@chromium.org \
--cc=karol.wachowski@linux.intel.com \
--cc=kraxel@redhat.com \
--cc=lima@lists.freedesktop.org \
--cc=linux-doc@vger.kernel.org \
--cc=liviu.dudau@arm.com \
--cc=lizhi.hou@amd.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=maciej.falkowski@linux.intel.com \
--cc=mamin506@gmail.com \
--cc=matt.coster@imgtec.com \
--cc=mripard@kernel.org \
--cc=mwen@igalia.com \
--cc=ogabbay@kernel.org \
--cc=olvaffe@gmail.com \
--cc=robh@kernel.org \
--cc=simona@ffwll.ch \
--cc=steven.price@arm.com \
--cc=tomeu@tomeuvizoso.net \
--cc=virtualization@lists.linux.dev \
--cc=yuq825@gmail.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;
as well as URLs for NNTP newsgroup(s).