Re: [PATCH v5 00/11] Support repeated mappings in GPUVM and Panthor

["Adrián Larumbe" <adrian.larumbe@collabora.com>]

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