Re: [PATCH 2/3] drm/i915: Enable render context support for gen4 (Broadwater to Cantiga)

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Thu, Nov 23, 2017 at 04:27:49PM +0000, Chris Wilson wrote:
> Broadwater and the rest of gen4  do support being able to saving and
> reloading context specific registers between contexts, providing isolation
> of the basic GPU state (as programmable by userspace). This allows
> userspace to assume that the GPU retains their state from one batch to the
> next, minimising the amount of state it needs to reload.
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
>  drivers/gpu/drm/i915/intel_engine_cs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c
> index 88ef00faf576..2c9b67e21d48 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -175,9 +175,9 @@ __intel_engine_context_size(struct drm_i915_private *dev_priv, u8 class)
>  			return round_up(GEN6_CXT_TOTAL_SIZE(cxt_size) * 64,
>  					PAGE_SIZE);
>  		case 5:
> +		case 4:
>  			cxt_size = I915_READ(CXT_SIZE);
>  			return round_up(cxt_size * 64, PAGE_SIZE);

On 965 the CXT_SIZE does seem to match the full context image size.
At least my 965 matches the docs perfectly. So just an off by one error
here for 965.

ctg/elk seem to require the same treatment as ilk. Except the extra
we need this time is 9 cachelines. That still can't make the numbers I
see match up with the spec though. I have: CXT_SIZE=0x29,
CTX_SIZE_NOEXT=0x5. The NOEXT value seems to be 2 cachelines too
small. And the full size seems to be 5 cachelines too small. So I wonder
if the full size doesn't account for the media PRT part either? On ILK
we seemed to miss one cacheline there, on ctg/elk 3 cachelines. Or was
it actually two cachelines on ILK, not sure anymore.

Hmm. I wonder if it's the 'Media PRT' part (+ one or two preceding
cachlines) we're missing from this on both platforms. If that's the case
the I guess 0x9+3 and 0xb+2 might be the correct number of extra
cachlines we need on ctg/elk and ilk respectively. Or maybe just add
a comment that we may be missing a few cachelines from the total, but
it doesn't matter?

> -		case 4:
>  		case 3:
>  		case 2:
>  		/* For the special day when i810 gets merged. */
> -- 
> 2.15.0
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx