Re: [RFC][PATCH 00/13] drm: Introduce GEM-UMA memory management

[Boris Brezillon <boris.brezillon@collabora.com>]

On Tue, 9 Dec 2025 15:51:21 +0100
Thomas Zimmermann <tzimmermann@suse.de> wrote:

> 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.

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.