On Thu, Jul 03, 2014 at 10:30:52AM +0100, Chris Wilson wrote: > On Thu, Jun 26, 2014 at 02:24:15PM +0100, oscar.ma...@intel.com wrote: > > From: Oscar Mateo <oscar.ma...@intel.com> > > > > 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.ma...@intel.com> > > Let's go whole hog here and call it ctx->user_handle.
And it's unsigned and only 32bits... -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
