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. 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.
