> -----Original Message----- > From: Chris Wilson [mailto:chris@xxxxxxxxxxxxxxxxxx] > Sent: Thursday, July 03, 2014 10:53 AM > To: Mateo Lozano, Oscar; intel-gfx@xxxxxxxxxxxxxxxxxxxxx > Subject: Re: [PATCH 4/8] drm/i915: Rename ctx->id to ctx->handle > > 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@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. ACK > And it's unsigned and only 32bits... ACK, I´ll change the type to unit32_t _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
