[Intel-gfx] [PATCH 3/3] drm/i915: Refine VT-d scanout workaround
Matthew Auld
matthew.william.auld at gmail.com
Mon Feb 15 18:07:24 UTC 2021
On Mon, 15 Feb 2021 at 15:56, Chris Wilson <chris at chris-wilson.co.uk> wrote:
>
> VT-d may cause overfetch of the scanout PTE, both before and after the
> vma (depending on the scanout orientation). bspec recommends that we
> provide a tile-row in either directions, and suggests using 160 PTE,
> warning that the accesses will wrap around the ends of the GGTT.
> Currently, we fill the entire GGTT with scratch pages when using VT-d to
> always ensure there are valid entries around every vma, including
> scanout. However, writing every PTE is slow as on recent devices we
> perform 8MiB of uncached writes, incurring an extra 100ms during resume.
>
> If instead we focus on only putting guard pages around scanout, we can
> avoid touching the whole GGTT. To avoid having to introduce extra nodes
> around each scanout vma, we adjust the scanout drm_mm_node to be smaller
> than the allocated space, and fixup the extra PTE during dma binding.
>
> v2: Move the guard from modifying drm_mm_node.start which is still used
> by the drm_mm itself, into an adjustment of node.start at the point of
> use.
>
> v3: Pass the requested guard padding from the caller, so we can drop the
> VT-d w/a knowledge from the i915_vma allocator.
>
> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> Cc: Ville Syrjälä <ville.syrjala at linux.intel.com>
> Cc: Matthew Auld <matthew.auld at intel.com>
> Reviewed-by: Matthew Auld <matthew.auld at intel.com> # v2
Looks good,
Reviewed-by: Matthew Auld <matthew.auld at intel.com>
More information about the Intel-gfx
mailing list