[Intel-gfx] [PATCH 4/8] drm/i915: Rename ctx->id to ctx->handle

Chris Wilson chris at chris-wilson.co.uk
Thu Jul 3 11:52:40 CEST 2014


On Thu, Jul 03, 2014 at 10:30:52AM +0100, Chris Wilson wrote:
> On Thu, Jun 26, 2014 at 02:24:15PM +0100, oscar.mateo at intel.com wrote:
> > From: Oscar Mateo <oscar.mateo at 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.mateo at 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



More information about the Intel-gfx mailing list