[PATCH v3 0/8] drm: Introduce sparse GEM shmem
Boris Brezillon
boris.brezillon at collabora.com
Fri Apr 4 09:26:26 UTC 2025
This patch series is a proposal for implementing sparse page allocations
for shmem objects. It was initially motivated by a kind of BO managed by
the Panfrost/Panthor and Lima drivers, the tiler heap, which grows on
demand every time the GPU faults on a virtual address within the heap BO
range.
Because keeping a struct page pointer array that can describe the entire
virtual range is wasteful when only a few backing pages have been
allocated, we thought a sparse allocation approach with xarrays was a
more efficient choice.
This sparse GEM shmem features takes the form of a new optional
drm_gem_shmem_sparse_backing object that can be attached to a
drm_gem_shmem_object at creation time if the driver wants. When this
sparse GEM shmem backing mode is enabled, the driver is allow to
partially populate the GEM pages, either at use time, or at fault
time. The page population can be done progressively as the need for
more memory arises. The new APIs takes explicit gfp_t flags to solve
a long standing issue reported by Sima a while ago: all allocations
happening in the fault handler path shouldn't block.
We also introduce two new helpers at the drm_gem.{c,h} level to
automate the partial xarray population which the GEM-SHMEM logic
relies on to populate its sparse page array.
A few details about the implementation now:
- Sparse GEM backing locking is deferred to the driver, because
we can't take the resv locks in the GPU fault handler path, and
since the page population can come from there, we have to let
the driver decide how to lock.
- The pin/get semantics for sparse GEM shmem objects is different,
in that it doesn't populate the pages, but just flag them as
being used/required by some GPU component. The page population
will happen explicitly at GEM creation time or when a GPU fault
happens. Once pages have been populated, they won't disappear
until the GEM object is destroyed, purged or evicted. This means
you can grow, but not shrink. If we ever need to discard
BO ranges, the API can be extended to allow it, but it's not
something we needed for the Lima/Panthor/Panfrost case.
- Panthor and Panfrost changes have been tested, but not extensively.
Lima changes have only been compile-tested.
Changes from v2:
- We decided to focus more on the DRM aspects and forget about the
sgt building optimizations (sgt helpers taking an xarray instead of
a plain array). If the xarray -> array copies happening in that
path ever become the bottleneck, we can resurrect those changes.
- We decided to make the sparse GEM changes less invasive by making
them an extra layer on top of drm_gem_shmem_object. What this means
is that sparse GEM shmem can now be used as regular GEM shmem
objects (vmap, pin, export, ... all work as they would on a regular
GEM). When that happens, we just force all pages to be populated,
so we kinda lose the benefit of sparse GEMs, but that's fine, because
in practice, such objects shouldn't be manipulated as regular GEMs.
It just serves as a safety guard to limit the risk of regressions
introduced by these sparse GEM shmem changes.
Discussion of previus revision can be found here[2][3].
For those used to review gitlab MRs, here's a link [1] to a Draft
MR grouping those changes, but I'm in no way asking that the review
happens on gitlab.
Regards,
Boris
[1]https://gitlab.freedesktop.org/panfrost/linux/-/merge_requests/16
[2]https://lore.kernel.org/lkml/20250326021433.772196-1-adrian.larumbe@collabora.com/T/
[3]https://lore.kernel.org/dri-devel/20250218232552.3450939-1-adrian.larumbe@collabora.com/
Adrián Larumbe (1):
drm/gem: Add helpers to request a range of pages on a GEM
Boris Brezillon (7):
drm/gem-shmem: Support sparse backing
drm/panfrost: Switch to sparse gem shmem to implement our
alloc-on-fault
drm/panthor: Add support for alloc-on-fault buffers
drm/panthor: Allow kernel BOs to pass DRM_PANTHOR_BO_ALLOC_ON_FAULT
drm/panthor: Add a panthor_vm_pre_fault_range() helper
drm/panthor: Make heap chunk allocation non-blocking
drm/lima: Use drm_gem_shmem_sparse_backing for heap buffers
drivers/gpu/drm/drm_gem.c | 134 +++++++
drivers/gpu/drm/drm_gem_shmem_helper.c | 404 +++++++++++++++++++-
drivers/gpu/drm/lima/lima_gem.c | 89 ++---
drivers/gpu/drm/lima/lima_gem.h | 1 +
drivers/gpu/drm/lima/lima_vm.c | 48 ++-
drivers/gpu/drm/panfrost/panfrost_drv.c | 2 +-
drivers/gpu/drm/panfrost/panfrost_gem.c | 37 +-
drivers/gpu/drm/panfrost/panfrost_gem.h | 8 +-
drivers/gpu/drm/panfrost/panfrost_mmu.c | 98 ++---
drivers/gpu/drm/panfrost/panfrost_mmu.h | 2 +
drivers/gpu/drm/panthor/panthor_drv.c | 20 +-
drivers/gpu/drm/panthor/panthor_fw.c | 6 +-
drivers/gpu/drm/panthor/panthor_gem.c | 18 +-
drivers/gpu/drm/panthor/panthor_gem.h | 12 +-
drivers/gpu/drm/panthor/panthor_heap.c | 222 ++++++-----
drivers/gpu/drm/panthor/panthor_mmu.c | 481 ++++++++++++++++++------
drivers/gpu/drm/panthor/panthor_mmu.h | 2 +
drivers/gpu/drm/panthor/panthor_sched.c | 6 +-
include/drm/drm_gem.h | 14 +
include/drm/drm_gem_shmem_helper.h | 285 +++++++++++++-
include/uapi/drm/panthor_drm.h | 19 +-
21 files changed, 1492 insertions(+), 416 deletions(-)
--
2.49.0
More information about the lima
mailing list