On Wed, 26 Nov 2025 17:20:08 +0100 Thomas Zimmermann <[email protected]> wrote:
> Hi > > Am 26.11.25 um 13:44 schrieb Boris Brezillon: > > This series implements cached maps and explicit flushing for both panfrost > > and panthor. To avoid code/bug duplication, the tricky guts of the cache > > flushing ioctl which walk the sg list are broken into a new common shmem > > helper which can be used by any driver. > > Gem-shmem is getting more and more complicated. I think gem-shmem would > be better off to be a simple implementation for all the drivers that use > shadow buffering and software rendering. There are plenty of them. And > drivers like the ones in sysfb/ are our failure-mode fallback. They > should have non-complicated memory management wherever possible. Just to be clear, none of the gem-shmem additions in this series are forced to existing gem-shmem users, and no extra field is added to drm_gem_shmem_object. Given how far were are, I'd be tempted to merge this series, and revisit things later. > > Therefore, could we first duplicate the existing gem-shmem code into > gem-uma as we discussed recently on IRC? The changes are simple: > > - copy the existing gem-shmem to gem-uma (plus renames) > - convert panthor and panfrost to the new interfaces Actually, I started a panthor patchset adding reclaim support, and one of the patch is parting ways with gem-shmem. I was planning on sending that after I've got all the pending panthor patches merged. Based on what we end up with, and if others are interested in moving to this new implementation, I'll extract the code into a gem-uma layer, as discussed. > > And on top of that, further improvements, such as the series at hand, > could be done. Later we'd convert other drivers to gem-uma where it > fits, such as lima. I'm fine with the request to fork gem-shmem in order to simplify the implementation for the non-GPU use cases, it's the ordering I'm not super happy with, because we're already at v6, and I was expecting those changes to be merged soon...
