> -----Original Message----- > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > Sent: Thursday, July 03, 2014 1:28 PM > To: Mateo Lozano, Oscar > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH 2/8] drm/i915: Rename ctx->obj to ctx- > >rcs_state > > On Thu, Jul 03, 2014 at 12:08:42PM +0000, Mateo Lozano, Oscar wrote: > > > -----Original Message----- > > > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > > > Sent: Thursday, July 03, 2014 10:47 AM > > > To: Mateo Lozano, Oscar > > > Cc: intel-gfx@lists.freedesktop.org > > > Subject: Re: [Intel-gfx] [PATCH 2/8] drm/i915: Rename ctx->obj to > > > ctx- > > > >rcs_state > > > > > > On Thu, Jun 26, 2014 at 02:24:13PM +0100, oscar.ma...@intel.com > wrote: > > > > From: Oscar Mateo <oscar.ma...@intel.com> > > > > > > > > This is Execlists preparatory work. > > > > > > > > We have already advanced that Logical Ring Contexts have their own > > > > kind ob backing objects, but everything will be better explained > > > > in the Execlists series. For now, suffice it to say that this > > > > backing object is only ever used with the render ring, so we're > > > > making this fact more explicit (which is a good reason on its own). > > > > > > > > Done with the following Coccinelle patch (plus manual renaming of > > > > the struct field): > > > > > > > > @@ > > > > struct intel_context c; > > > > @@ > > > > - (c).obj > > > > + c.rcs_state > > > > > > > > @@ > > > > *c; > > > > @@ > > > > - (c)->obj > > > > + c->rcs_state > > > > > > > > No functional changes. > > > > > > > > v2: Go with rcs_state instead of render_obj, as suggested by Chris > Wilson. > > > > > > Another little change here is ctx->is_initialised if you create > > > struct { > > > struct drm_i915_gem_object *rcs_state; > > > bool initialised; > > > } legacy_hw_ctx; > > > that should also address Daniel's confusion. > > > -Chris > > > > Daniel said exactly the same thing, but I´m reusing the rcs_initialized > > field in > Execlists to mark the default render context as ready after setting the > golden/null state (so that I only do it after module load, and not after > reset/thaw). I can add a new field for this, but IMHO this one makes sense. > > I would isolate the two. The use may be mutually exclusive, but the > semantics are not...
But... are we arguing or *debating* semantics? :) Ok, I´ll rearrange the HW context stuff and create a separate initialized flag for the Execlists case. _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
