Quoting Matthew Auld (2020-06-05 16:00:49) > On Fri, 5 Jun 2020 at 11:56, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx> > > Heebie-jeebies aside, > Reviewed-by: Matthew Auld <matthew.auld@xxxxxxxxx> 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
