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.
