[Intel-gfx] [PATCH v3 13/21] drm/i915: Replace the pinned context address with its unique ID

[Chris Wilson]

On Tue, Apr 26, 2016 at 09:06:00AM +0100, Dave Gordon wrote:
> On 25/04/16 16:48, Chris Wilson wrote:
> >On Mon, Apr 25, 2016 at 04:21:58PM +0100, Dave Gordon wrote:
> >>On 24/04/16 19:10, Chris Wilson wrote:
> >>>Rather than reuse the current location of the context in the global GTT
> >>>for its hardware identifier, use the context's unique ID assigned to it
> >>>for its whole lifetime.
> >>>
> >>>Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> >>>Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> >>
> >>Hmmm I wonder whether this will work with the GuC?
> >>IIRC the GuC firmware requires the LRCA to be used as the CTX ID :(
> >>Or at least it used to, maybe that has changed now.
> >
> >I know you raised it last time, as far as I can tell the two are
> >distinct in i915_guc_submission and you never pass the high 32 bits of
> >the LRC context descriptor (the context id) to the GuC. i.e.
> >
> >guc_init_ctx_desc:
> >	ctx_desc = intel_lr_context_descriptor(ctx, engine);
> >	lrc->context_desc = (u32)ctx_desc;
> >
> >	lrc->ring_lrca = i915_gem_object_gtt_offset(ctx_obj) + PAGE;
> >	lrc->context_id = client->ctx_index | engine->guc_id;
> >
> >The guc hasn't fared any worse then it did before applying the change...
> >-Chris
> 
> I found a comment in the GuC firmware,
> 
> // SubmissionByProxy: if KMD or other context submitted this
> //		context. This means, ContextID is LRCA[31:20]
> 
> But it turns out that's referring to the field that we always set to
> the LRCA anyway (since we DO use submission by proxy), but which
> would be used for other purposes in some other mode. So all OK :)
> 
> Also, I've tested this patchset on SKL and we're not getting any
> complaints from the GuC :)
> 
> One other thing I've noticed in the BSpec: it says the "s/w context
> id" is 21 bits rather than 20 (bits 52-32 inclusive).

Yup. Double checked, we can have 2x as many active contexts, yay!

> Then bits
> 53-54 are MBZ, and then the remaining 9 bits (55-63) are "GroupID"
> which seems to be a per-process identifier which is *also* required
> to be unique among active contexts. But maybe that's only when taken
> in combination with the LRCA, which is automatically unique among
> active contexts anyway?

In theory, it holds that LRCA pinned whilst we think the context is
active from the hardware point of view (certainly we never want to
change the pages behind the GGTT whilst the hw is reading/writing from
them). But keeping the context id alive for longer papers over some
random GPU hangs on Braswell (when continually creating, using and
destroinyg contexts).

Afaict, the group id need to be only alive for as long as all contexts
belonging to the group are active. It would be easy to just give a
unique id to drm_i915_file, but as it is only a u8, we probably do have
to track live groups. Not a big challenge, but it will add some runtime
cost. A bridge to be crossed in future.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre