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@xxxxxxxxxxxxxxxxxx> > >>>Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> > >> > >>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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
