Hi
Am 09.12.25 um 16:30 schrieb Boris Brezillon:
On Tue, 9 Dec 2025 15:51:21 +0100
Thomas Zimmermann <[email protected]> wrote:
Hi
Am 09.12.25 um 15:27 schrieb Boris Brezillon:
On Tue, 9 Dec 2025 14:41:57 +0100
Thomas Zimmermann <[email protected]> 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.
Problem is, we'll be stuck trying to evolve gem-uma to something
cleaner because of the existing abuse of gem-shmem that you're moving
to gem-uma, so I'm not sure I like the idea to be honest. I'm all for
this gem-uma thing, but I'm not convinced rushing it in is the right
solution.
The abuse you're talking about is what you mentioned about ivpu? How it
uses the gem-shmem internals, right? Ivpu can get its own copy of
gem-shmem, so that the developers can work it out. There's no benefit in
sharing code at all cost. Code sharing only make sense if the callers
are conceptually aligned on what the callee does.
Also what stops you from fixing any of this in the context of gem-uma?
It should even be easier, as you won't have to keep my use cases in mind.
In parallel, gem-shmem could go in its own direction. I'd like to do
some changes and simplifications there, which conflict with where
gem-uma will be heading.
Best regards
Thomas
--
--
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)
