[PATCH 15/40] drm/i915/guc: Exclude the upper end of the Global GTT for the GuC

[Chris Wilson]

On Thu, Jan 05, 2017 at 05:04:32PM +0000, Tvrtko Ursulin wrote:
> 
> On 05/01/2017 14:54, Chris Wilson wrote:
> >The GuC uses a special mapping for the upper end of the Global GTT,
> >similar to the way it uses a special mapping for the lower end, so
> >exclude it from our drm_mm to prevent us using it.
> >
> >v2: Rename to reflect that it is unmappable similar to the region at the
> >bottom of the GGTT, and couple it into the assertion that we don't feed
> >unmappable addresses to the GuC.
> >
> >Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> >Cc: Michal Wajdeczko <michal.wajdeczko at intel.com>
> >Cc: Arkadiusz Hiler <arkadiusz.hiler at intel.com>
> >Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio at intel.com>
> >---
> > drivers/gpu/drm/i915/i915_gem_gtt.c | 10 ++++++++++
> > drivers/gpu/drm/i915/i915_guc_reg.h |  3 +++
> > drivers/gpu/drm/i915/intel_uc.h     |  1 +
> > 3 files changed, 14 insertions(+)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c
> >index 11aeba60b5d7..00520f27bea6 100644
> >--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> >+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> >@@ -3178,6 +3178,16 @@ int i915_ggtt_probe_hw(struct drm_i915_private *dev_priv)
> > 	if (ret)
> > 		return ret;
> >
> >+	/* Trim the GGTT to fit the GuC mappable upper range (when enabled).
> >+	 * This is easier than doing range restriction on the fly, as we
> >+	 * currently don't have any bits spare to pass in this upper
> >+	 * restriction!
> >+	 */
> >+	if (HAS_GUC(dev_priv) && i915.enable_guc_loading) {
> >+		ggtt->base.total = min_t(u64, ggtt->base.total, GUC_GGTT_TOP);
> >+		ggtt->mappable_end = min(ggtt->mappable_end, ggtt->base.total);
> >+	}
> >+
> 
> We are short of which bits? PIN_ flags? BIT(4) looks free there. So
> we could add PIN_ZONE_GUC (or something, similar to PIN_ZONE_4G) and
> teach i915_vma_insert what that means? It could handle both start
> and end in that case.

BIT(4) has been left free for NOEVICT.
 
> Otherwise 18 MiB seems a lot to lose. At least it would be good to
> gate it on enable_guc_submissions and not enable_guc_loading, no?

It's unclear to me whether or not the HuC needs the same treatment, so
went with both just in case.

Current plan is to pass u64 start, end to i915_vma_pin() and see how that
fares. I'm hoping that gcc is smart enough to do the inline first before
passing around the extra parameters. Alternatively, we make the
ggtt/ppgtt paths more distinct.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre