[Intel-gfx] [PATCH 2/2] drm/i915: Track GGTT writes on the vma

[Joonas Lahtinen]

On Wed, 2017-12-06 at 12:49 +0000, Chris Wilson wrote:
> As writes through the GTT and GGTT PTE updates do not share the same
> path, they are not strictly ordered and so we must explicitly flush the
> indirect writes prior to modifying the PTE. We do track outstanding GGTT
> writes on the object itself, but since the object may have multiple GGTT
> vma, that is overly coarse as we can track and flush individual vma as
> required.
> 
> Whilst here, update the GGTT flushing behaviour for Cannonlake.
> 
> v2: Hard-code ring offset to allow use during unload (after RCS may have
> been freed, or never existed!)
> 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=104002
> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> Cc: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>

One comment below, not strictly related to this patch.

Reviewed-by: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>

Regards, Joonas

> +static void
> +flush_write_domain(struct drm_i915_gem_object *obj, unsigned int flush_domains)
> +{
> +	struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
> +	struct i915_vma *vma;
> +
> +	if (!(obj->base.write_domain & flush_domains))
> +		return;
> +
>  	switch (obj->base.write_domain) {
>  	case I915_GEM_DOMAIN_GTT:
> -		if (!HAS_LLC(dev_priv)) {
> -			intel_runtime_pm_get(dev_priv);
> -			spin_lock_irq(&dev_priv->uncore.lock);
> -			POSTING_READ_FW(RING_HEAD(dev_priv->engine[RCS]->mmio_base));
> -			spin_unlock_irq(&dev_priv->uncore.lock);
> -			intel_runtime_pm_put(dev_priv);
> -		}
> +		i915_gem_flush_ggtt_writes(dev_priv);
>  
>  		intel_fb_obj_flush(obj,
>  				   fb_write_origin(obj, I915_GEM_DOMAIN_GTT));
> +
> +		list_for_each_entry(vma, &obj->vma_list, obj_link) {
> +			if (!i915_vma_is_ggtt(vma))

This pattern could use for_each_ggtt_vma() macro or such.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation