On Thu, Jun 26, 2014 at 02:24:15PM +0100, oscar.mateo@xxxxxxxxx wrote: > From: Oscar Mateo <oscar.mateo@xxxxxxxxx> > > This is an Execlists preparatory patch, since they make context ID become an > overloaded term: > > - In the software, it was used to distinguish which context userspace was > trying to use. > - In the BSpec, the term is used to describe the 20-bits long field the > hardware uses to it to discriminate the contexts that are submitted to > the ELSP and inform the driver about their current status (via Context > Switch Interrupts and Context Status Buffers). > > Initially, I tried to make the different meanings converge, but it proved > impossible: > > - The software ctx->id is per-filp, while the hardware one needs to be > globally unique. > - Also, we multiplex several backing states objects per intel_context, > and all of them need unique HW IDs. > - I tried adding a per-filp ID and then composing the HW context ID as: > ctx->id + file_priv->id + ring->id, but the fact that the hardware only > uses 20-bits means we have to artificially limit the number of filps or > contexts the userspace can create. > > The ctx->handle bits are done with this Cocci patch (plus manual frobbing > of the struct declaration): > > @@ > struct intel_context c; > @@ > - (c).id > + c.handle > > @@ > struct intel_context *c; > @@ > - (c)->id > + c->handle > > Also, while we are at it, s/DEFAULT_CONTEXT_ID/DEFAULT_CONTEXT_HANDLE. > > Signed-off-by: Oscar Mateo <oscar.mateo@xxxxxxxxx> Let's go whole hog here and call it ctx->user_handle. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
