[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