Quoting Ville Syrjälä (2021-02-03 09:00:54) > On Wed, Feb 03, 2021 at 08:38:41AM +0000, Chris Wilson wrote: > > Currently, we allocate exactly the VMA requested for the framebuffer and > > rely on filling the whole of the GGTT with scratch pages to catch when > > VT-d prefetches beyond the bounds of the surface. However, this means > > that we have to scrub the GGTT on startup and resume, and on recent HW > > this is made even slower as the only access to GSM is uncached. > > > > Since we do fill the pad-to-size PTE with scratch pages, and this is > > also reapplied on resume, we can forgo the overzealous clearing of the > > entire GGTT and instead pad the VMA to avoid the VT-d prefetches going > > outside of the VMA. > > We have a lot of these "allocate a huge pile of extra PTEs > after (or before for rotation) the scanout surface" workarounds > we're not handling at all. Not sure ths is sufficient to cover > those. I am being optimistic in that we should have a lot of weird cases covered in CI and with iommu enabled, we will get splats. But if it's pages/after before regardless of alignment, then this is insufficient. Also, the case of remapped pages we don't want obj->size here, but vma->size. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
