From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Siluvery, Arun" Subject: Re: [PATCH] drm/i915: Emit even number of dwords when emitting LRIs Date: Thu, 23 Oct 2014 14:55:27 +0100 Message-ID: <544908CF.9060107@linux.intel.com> References: <1414000792-16111-1-git-send-email-arun.siluvery@linux.intel.com> <20141023122102.GJ26941@phenom.ffwll.local> <20141023124238.GC10367@strange.ger.corp.intel.com> <20141023125023.GL13512@nuc-i3427.alporthouse.com> <20141023134142.GZ4284@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; Format="flowed" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by gabe.freedesktop.org (Postfix) with ESMTP id 5A7DA6E482 for ; Thu, 23 Oct 2014 06:55:30 -0700 (PDT) In-Reply-To: <20141023134142.GZ4284@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: =?windows-1252?Q?Ville_Syrj=E4l=E4?= , Chris Wilson , Damien Lespiau , Daniel Vetter , intel-gfx@lists.freedesktop.org, Mika Kuoppala List-Id: intel-gfx@lists.freedesktop.org On 23/10/2014 14:41, Ville Syrj=E4l=E4 wrote: > On Thu, Oct 23, 2014 at 01:50:23PM +0100, Chris Wilson wrote: >> On Thu, Oct 23, 2014 at 01:42:38PM +0100, Damien Lespiau wrote: >>> On Thu, Oct 23, 2014 at 02:21:02PM +0200, Daniel Vetter wrote: >>>> On Wed, Oct 22, 2014 at 06:59:52PM +0100, Arun Siluvery wrote: >>>>> The number of DWords should be even when doing ring emits as >>>>> command sequences require QWord alignment. >>>>> >>>>> v2: user LRI variant that can write multiple regs in one go (Damien). >>>>> We can simply insert one NOP at the end instead of one per register w= rite. >>>>> >>>>> Cc: Mika Kuoppala >>>>> Signed-off-by: Arun Siluvery >>>>> --- >>>>> drivers/gpu/drm/i915/intel_ringbuffer.c | 5 +++-- >>>>> 1 file changed, 3 insertions(+), 2 deletions(-) >>>>> >>>>> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/dr= m/i915/intel_ringbuffer.c >>>>> index 497b836..a8f72e8 100644 >>>>> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c >>>>> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c >>>>> @@ -680,15 +680,16 @@ static int intel_ring_workarounds_emit(struct i= ntel_engine_cs *ring) >>>>> if (ret) >>>>> return ret; >>>>> >>>>> - ret =3D intel_ring_begin(ring, w->count * 3); >>>>> + ret =3D intel_ring_begin(ring, (w->count * 2 + 2)); >>>>> if (ret) >>>>> return ret; >>>>> >>>>> + intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(w->count)); >>>> >>>> Afaik there's a limit to the size of an MI_LRI. Where's the check for >>>> that (probably with a WARN_ON for now to avoid unecessary complexity)? >>> >>> I guess there's always the size of the length field, I don't see any >>> other indication. Note that I can find the documentation of the >>> multi-registers version of LRI either. So, well, we probably should >>> double check it does work. >> >> It does work. The max is around 60 iirc (the max length of the >> command). > > The maximum length seems to be 0xff on gen6+ and 0x3f before that, > which would mean at most 128 or 32 registers. > > Also the context image is full of these multi register LRIs. Based on a > quick glance the longest LRI in there is 0x5f on IVB, 0xcf on HSW, and > 0xdf on BDW, which translate to 48, 104, and 108 registers per LRI. So > we know at least those must work or context restore would not work. > Before gen7 the context doesn't seem to resemble a batch, so I can't > tell anything about those platforms based on the context image. > w->count is already checked against max workarounds which is 16 now so = we are well within the limit; I think additional check would be = redundant here and it is unlikely to have more than 128 workarounds. regards Arun