[Intel-gfx] [PATCH 1/2] drm/i915: Discard a misplaced GGTT vma

[Chris Wilson]

Quoting Matthew Auld (2020-06-05 16:00:49)
> On Fri, 5 Jun 2020 at 11:56, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> >
> > Across the many users of the GGTT vma (internal objects, mmapings,
> > display etc), we may end up with conflicting requirements for the
> > placement. Currently, we try to resolve the conflict by unbinding the
> > vma and rebinding it to match the new constraints; over time we will end
> > up with a GGTT that matches the most strict constraints over all
> > concurrent users. However, this causes a problem if the vma is currently
> > in use as we must wait until it is idle before moving it. But there is
> > no restriction on the number of views we may use (apart from the limited
> > size of the GGTT itself), and so if the active vma does not meet our
> > requirements, try and build a new one!
> >
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> 
> Heebie-jeebies aside,
> Reviewed-by: Matthew Auld <matthew.auld at intel.com>

It's definitely "interesting". This is certainly one case where it would
be nice to decouple the vma and let it expire as soon as it becomes
inactive. As it stands, it has to wait around until it is evicted so
adding to the fragmentation pressure.

I'm sure it's not the only stall compositors see [changing to uncached
and clflushing is the major one]. The trick I used in the ddx was to
fault in a ggtt mmap, so that the framebuffer stood a chance of being in
the aperture prior to use, along with making it uncached before use. But
long gone are the days where userspace drivers control this.

But it does prevent at least one instance of an arbitrary lockup in igt,
so it probably helps somewhere.
-Chris