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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx