drivers/gpu/drm/drm_gpuvm.c | 214 ++++++++++++++++++----- drivers/gpu/drm/panthor/panthor_device.h | 3 + drivers/gpu/drm/panthor/panthor_drv.c | 12 +- drivers/gpu/drm/panthor/panthor_mmu.c | 176 +++++++++++++++---- include/drm/drm_gpuvm.h | 63 ++++++- include/uapi/drm/panthor_drm.h | 33 ++++ 6 files changed, 427 insertions(+), 74 deletions(-)
This patch series adds OP_MAP_REPEAT flag, which lets the user map a BO region over an address range repeatedly with just one map operation. Sparse resources in the Vulkan API let the user leave regions of a resource unmapped (from the API perspective.) Accesses to such regions must not result in program termination, but loads produce undefined values. To implement this feature on Mali hardware, Vulkan sparse unmap is implemented by mapping the specified region to a "dummy bo" so that the accesses do not fault. A newly created sparse resource starts off unmapped, and therefore also has to be mapped to the "dummy bo". This "dummy bo" is small (a page size) in comparison to the sizes of va ranges that we might want to map to it, and a large number of vm_bind ops can be necessary. For example, if the user were to create a 100e6-byte sparse resident resource, we'd have to poke VM_BIND with ceil(100e6/0x1000)=24415 map operations. OP_MAP_REPEAT addresses this particular inefficiency by letting us implement a single Vulkan sparse unmap operation and sparse resident resource initialization with just one map operation. The panvk changes making use of this uapi can be found at [1] Link to the conversation for the previous patch series revision at [2] [1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40400 [2] https://lore.kernel.org/dri-devel/20250707170442.1437009-1-caterina.shablia@collabora.com/ Changes in v5: - Minor fixes to drm_gpuvm.c. - Add panthor MMU page sizes device queriable param. - Add helper to make sure unmaps of repeated regions are correct. - Some fixes to Panthor's repeat mappings implementation. - Lump arguments to panthor_vm_prepare_map_op_ctx into a single struct. Changes in v4: - Fixed the warnings reported by the kernel test robot. https://lore.kernel.org/oe-kbuild-all/202507041635.WyDu3TQ1-lkp@intel.com/ - Fixed the warnings reported by the CI. https://patchwork.freedesktop.org/series/151264/ No changes in v3. Changes in v2: - Make panthor use this stuff. - Make it possible to express a repeated mappina of any suitably sized and aligned range of a BO, rather than strictly the page size -sized prefix, generalizing the API. Rename DRM_GPUVA_SINGLE_PAGE to DRM_GPUVA_REPEAT. - Clean up parts of drm/gpuvm affected by these changes. Adrián Larumbe (7): drm/panthor: Expose GPU page sizes to UM drm/gpuvm: Remove dead code drm/gpuvm: Fix comment to reflect remap operation operand status drm/gpuvm: Ensure correctness of unmap/remaps of repeated regions drm/panthor: Handle remap case for repeated mappings drm/panthor: Pass vm_bind_op to vm_prepare_map_op_ctx drm/panthor: Bump the driver version to 1.8 Asahi Lina (2): drm/gpuvm: Add a flags field to drm_gpuva_op_map drm/gpuvm: Add DRM_GPUVA_REPEAT flag and logic Boris Brezillon (2): drm/gpuvm: Add a helper to check if two VA can be merged drm/panthor: Add support for repeated mappings drivers/gpu/drm/drm_gpuvm.c | 214 ++++++++++++++++++----- drivers/gpu/drm/panthor/panthor_device.h | 3 + drivers/gpu/drm/panthor/panthor_drv.c | 12 +- drivers/gpu/drm/panthor/panthor_mmu.c | 176 +++++++++++++++---- include/drm/drm_gpuvm.h | 63 ++++++- include/uapi/drm/panthor_drm.h | 33 ++++ 6 files changed, 427 insertions(+), 74 deletions(-) -- 2.53.0
On Sat, 14 Mar 2026 at 01:19, Adrián Larumbe <adrian.larumbe@collabora.com> wrote: > > This patch series adds OP_MAP_REPEAT flag, which lets the user map a BO > region over an address range repeatedly with just one map operation. > > Sparse resources in the Vulkan API let the user leave regions of a > resource unmapped (from the API perspective.) Accesses to such regions > must not result in program termination, but loads produce undefined > values. > > To implement this feature on Mali hardware, Vulkan sparse unmap is > implemented by mapping the specified region to a "dummy bo" so that the > accesses do not fault. A newly created sparse resource starts off > unmapped, and therefore also has to be mapped to the "dummy bo". This > "dummy bo" is small (a page size) in comparison to the sizes of va > ranges that we might want to map to it, and a large number of vm_bind > ops can be necessary. For example, if the user were to create a > 100e6-byte sparse resident resource, we'd have to poke VM_BIND with > ceil(100e6/0x1000)=24415 map operations. So other drivers pass a NULL (xe) operation to their VM BIND which then goes into the kernel and is handled in the backend to write the special sparse PT entry. Can't you just do the same thing in the driver backend, have a dummy bo allocated in the kernel and map the pages to it when you see a NULL mapping, or does this mess up some accounting or refcounts? Dave.
On Wed, Mar 25, 2026 at 06:51:55AM +1000, Dave Airlie wrote: > On Sat, 14 Mar 2026 at 01:19, Adrián Larumbe > <adrian.larumbe@collabora.com> wrote: > > > > This patch series adds OP_MAP_REPEAT flag, which lets the user map a BO > > region over an address range repeatedly with just one map operation. > > > > Sparse resources in the Vulkan API let the user leave regions of a > > resource unmapped (from the API perspective.) Accesses to such regions > > must not result in program termination, but loads produce undefined > > values. > > > > To implement this feature on Mali hardware, Vulkan sparse unmap is > > implemented by mapping the specified region to a "dummy bo" so that the > > accesses do not fault. A newly created sparse resource starts off > > unmapped, and therefore also has to be mapped to the "dummy bo". This > > "dummy bo" is small (a page size) in comparison to the sizes of va > > ranges that we might want to map to it, and a large number of vm_bind > > ops can be necessary. For example, if the user were to create a > > 100e6-byte sparse resident resource, we'd have to poke VM_BIND with > > ceil(100e6/0x1000)=24415 map operations. > > So other drivers pass a NULL (xe) operation to their VM BIND which > then goes into the kernel and is handled in the backend to write the > special sparse PT entry. Other drivers (asahi) have repeated repeated mapping of a single page baked in their UAPI, see DRM_ASAHI_BIND_SINGLE_PAGE. The out of tree downstream driver uses an earlier version of the DRM gpuvm changes to support DRM_ASAHI_BIND_SINGLE_PAGE. The upstream mesa driver uses this to implement Vulkan sparse resources. > Can't you just do the same thing in the driver backend, have a dummy > bo allocated in the kernel and map the pages to it when you see a NULL > mapping, > > or does this mess up some accounting or refcounts? I suppose this might have worked as well. I don't know what led to the asahi UAPI but I suspect leaving things up to user-space manage to manage was one goal. Janne
Hi Dave, On 25.03.2026 06:51, Dave Airlie wrote: > On Sat, 14 Mar 2026 at 01:19, Adrián Larumbe > <adrian.larumbe@collabora.com> wrote: > > > > This patch series adds OP_MAP_REPEAT flag, which lets the user map a BO > > region over an address range repeatedly with just one map operation. > > > > Sparse resources in the Vulkan API let the user leave regions of a > > resource unmapped (from the API perspective.) Accesses to such regions > > must not result in program termination, but loads produce undefined > > values. > > > > To implement this feature on Mali hardware, Vulkan sparse unmap is > > implemented by mapping the specified region to a "dummy bo" so that the > > accesses do not fault. A newly created sparse resource starts off > > unmapped, and therefore also has to be mapped to the "dummy bo". This > > "dummy bo" is small (a page size) in comparison to the sizes of va > > ranges that we might want to map to it, and a large number of vm_bind > > ops can be necessary. For example, if the user were to create a > > 100e6-byte sparse resident resource, we'd have to poke VM_BIND with > > ceil(100e6/0x1000)=24415 map operations. > > So other drivers pass a NULL (xe) operation to their VM BIND which > then goes into the kernel and is handled in the backend to write the > special sparse PT entry. > > Can't you just do the same thing in the driver backend, have a dummy > bo allocated in the kernel and map the pages to it when you see a NULL > mapping, We could. There's been some ongoing talk among Collaborans about whether to move all this functionality into the driver backend. We decided to keep it part of the gpuvm core because we thought other drivers might profit from it, but if there's no such interest, I think it's best to leave the DRM core untouched and handle repeated mappings the way you suggested. > or does this mess up some accounting or refcounts? > > Dave. Adrian Larumbe
On Wed, Mar 25, 2026 at 11:12 AM Adrián Larumbe <adrian.larumbe@collabora.com> wrote: > > Hi Dave, > > On 25.03.2026 06:51, Dave Airlie wrote: > > On Sat, 14 Mar 2026 at 01:19, Adrián Larumbe > > <adrian.larumbe@collabora.com> wrote: > > > > > > This patch series adds OP_MAP_REPEAT flag, which lets the user map a BO > > > region over an address range repeatedly with just one map operation. > > > > > > Sparse resources in the Vulkan API let the user leave regions of a > > > resource unmapped (from the API perspective.) Accesses to such regions > > > must not result in program termination, but loads produce undefined > > > values. > > > > > > To implement this feature on Mali hardware, Vulkan sparse unmap is > > > implemented by mapping the specified region to a "dummy bo" so that the > > > accesses do not fault. A newly created sparse resource starts off > > > unmapped, and therefore also has to be mapped to the "dummy bo". This > > > "dummy bo" is small (a page size) in comparison to the sizes of va > > > ranges that we might want to map to it, and a large number of vm_bind > > > ops can be necessary. For example, if the user were to create a > > > 100e6-byte sparse resident resource, we'd have to poke VM_BIND with > > > ceil(100e6/0x1000)=24415 map operations. > > > > So other drivers pass a NULL (xe) operation to their VM BIND which > > then goes into the kernel and is handled in the backend to write the > > special sparse PT entry. > > > > Can't you just do the same thing in the driver backend, have a dummy > > bo allocated in the kernel and map the pages to it when you see a NULL > > mapping, > > We could. There's been some ongoing talk among Collaborans about whether to move > all this functionality into the driver backend. We decided to keep it part of the > gpuvm core because we thought other drivers might profit from it, but if there's > no such interest, I think it's best to leave the DRM core untouched and handle > repeated mappings the way you suggested. fwiw, msm handles this on the kernel side with a dummy page. (No point really in it being a full fledged gem obj) BR, -R > > or does this mess up some accounting or refcounts? > > > > Dave. > > Adrian Larumbe
© 2016 - 2026 Red Hat, Inc.