On Wed, Mar 25, 2026 at 06:51:55AM +1000, Dave Airlie wrote: > On Sat, 14 Mar 2026 at 01:19, Adrián Larumbe > <[email protected]> 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
