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

[Rob Clark]

On Wed, Mar 25, 2026 at 11:12 AM Adrián Larumbe
<adrian.larumbe@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> 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