Re: [Intel-gfx] [PATCH] drm/i915: Refine VT-d scanout workaround

From: Chris Wilson <chris@chris-wilson.co.uk>
To: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org, Matthew Auld <matthew.auld@intel.com>
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Refine VT-d scanout workaround
Date: Thu, 11 Feb 2021 16:24:52 +0000	[thread overview]
Message-ID: <161306069289.7731.1304191156152290264@build.alporthouse.com> (raw)
In-Reply-To: <YCVV5zgZZi6T9yRp@intel.com>

Quoting Ville Syrjälä (2021-02-11 16:05:59)
> On Wed, Feb 10, 2021 at 11:39:46PM +0000, Chris Wilson wrote:
> > @@ -637,6 +642,13 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64 alignment, u64 flags)
> >                                 alignment, vma->fence_alignment);
> >       }
> >  
> > +     /* VT-d requires padding before/after the vma */
> > +     if (flags & PIN_VTD) {
> > +             alignment = max_t(typeof(alignment), alignment, VTD_GUARD);
> > +             vma->guard = alignment;
> > +             size += 2 * vma->guard;
> > +     }
> > +
> >       GEM_BUG_ON(!IS_ALIGNED(size, I915_GTT_PAGE_SIZE));
> >       GEM_BUG_ON(!IS_ALIGNED(alignment, I915_GTT_MIN_ALIGNMENT));
> >       GEM_BUG_ON(!is_power_of_2(alignment));
> someh> @@ -725,6 +737,11 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64 alignment, u64 flags)
> >  
> >       list_add_tail(&vma->vm_link, &vma->vm->bound_list);
> >  
> > +     if (flags & PIN_VTD) {
> > +             vma->node.start += vma->guard;
> 
> Was a bit worried for a second that this might give the display
> a potentially misaligned vma start. But looks like you did consider
> all that: VTD_GUARD==POT, alignment + guard both get bumped
> to the max(). So AFAICS should guarantee everyone is happy.
> 
> I guess we're now wasting a lot more ggtt address space though?
> Not sure if anyone has ever been at risk of running out though.
> And DPT should help with this on new platforms.

Definitely this is a considerable bloat to most scanout buffers, which
for the sake of argument lets say are 8MiB. Still enough room for a flip
chain within the mappable portion, and when we get to scanouts that are
large enough to consume the majority of the GGTT, the fixed 2MiB of
padding is lost in the noise.

So handwaving it shouldn't lead to noticeably more thrashing of the
GGTT for existing platforms. There's too much recycling and too little
reuse of scanouts in current display systems for my liking, so the extra
25% overhead in GGTT updates is more likely to be a concern. (Though it
does balance out in that we now skip the clear after use.)
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx