<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, May 26, 2018 at 6:33 PM, Francisco Jerez <span dir="ltr"><<a href="mailto:currojerez@riseup.net" target="_blank">currojerez@riseup.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_-3306280786556062542HOEnZb"><div class="m_-3306280786556062542h5">Jason Ekstrand <<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>> writes:<br>
<br>
> On Sat, May 26, 2018 at 3:36 PM, Francisco Jerez <<a href="mailto:currojerez@riseup.net" target="_blank">currojerez@riseup.net</a>><br>
> wrote:<br>
><br>
>> Jason Ekstrand <<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>> writes:<br>
>><br>
>> > On Sat, May 26, 2018 at 2:03 PM, Francisco Jerez <<a href="mailto:currojerez@riseup.net" target="_blank">currojerez@riseup.net</a>><br>
>> > wrote:<br>
>> ><br>
>> >> Jason Ekstrand <<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>> writes:<br>
>> >><br>
>> >> > On Sat, May 26, 2018 at 12:21 PM, Francisco Jerez <<br>
>> <a href="mailto:currojerez@riseup.net" target="_blank">currojerez@riseup.net</a><br>
>> >> ><br>
>> >> > wrote:<br>
>> >> ><br>
>> >> >> Jason Ekstrand <<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>> writes:<br>
>> >> >><br>
>> >> >> > On Sat, May 26, 2018 at 11:10 AM, Francisco Jerez <<br>
>> >> <a href="mailto:currojerez@riseup.net" target="_blank">currojerez@riseup.net</a><br>
>> >> >> ><br>
>> >> >> > wrote:<br>
>> >> >> ><br>
>> >> >> >> Jason Ekstrand <<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>> writes:<br>
>> >> >> >><br>
>> >> >> >> > From: Francisco Jerez <<a href="mailto:currojerez@riseup.net" target="_blank">currojerez@riseup.net</a>><br>
>> >> >> >> ><br>
>> >> >> >> > When we don't have PLN (gen4 and gen11+), we implement LINTERP<br>
>> as<br>
>> >> >> either<br>
>> >> >> >> > LINE+MAC or a pair of MADs.  In both cases, the accumulator is<br>
>> >> written<br>
>> >> >> >> > by the first of the two instructions and read by the second.<br>
>> Even<br>
>> >> >> >> > though the accumulator value isn't actually ever used from a<br>
>> >> logical<br>
>> >> >> >> > instruction perspective, it is trashed so we need to make the<br>
>> >> >> scheduler<br>
>> >> >> >> > aware.  Otherwise, the scheduler could end up re-ordering<br>
>> >> instructions<br>
>> >> >> >> > and putting a LINTERP between another an instruction which<br>
>> writes<br>
>> >> the<br>
>> >> >> >> > accumulator and another which tries to use that result.<br>
>> >> >> >> ><br>
>> >> >> >> > Cc: <a href="mailto:mesa-stable@lists.freedesktop.org" target="_blank">mesa-stable@lists.freedesktop.<wbr>org</a><br>
>> >> >> >> > ---<br>
>> >> >> >> >  src/intel/compiler/brw_shader.<wbr>cpp | 3 ++-<br>
>> >> >> >> >  1 file changed, 2 insertions(+), 1 deletion(-)<br>
>> >> >> >> ><br>
>> >> >> >> > diff --git a/src/intel/compiler/brw_shade<wbr>r.cpp<br>
>> >> >> b/src/intel/compiler/brw_<br>
>> >> >> >> shader.cpp<br>
>> >> >> >> > index 141b64e..dfd2c5c 100644<br>
>> >> >> >> > --- a/src/intel/compiler/brw_shade<wbr>r.cpp<br>
>> >> >> >> > +++ b/src/intel/compiler/brw_shade<wbr>r.cpp<br>
>> >> >> >> > @@ -984,7 +984,8 @@ backend_instruction::writes_<br>
>> >> >> accumulator_implicitly(const<br>
>> >> >> >> struct gen_device_info<br>
>> >> >> >> >     return writes_accumulator ||<br>
>> >> >> >> >            (devinfo->gen < 6 &&<br>
>> >> >> >> >             ((opcode >= BRW_OPCODE_ADD && opcode <<br>
>> BRW_OPCODE_NOP)<br>
>> >> ||<br>
>> >> >> >> > -            (opcode >= FS_OPCODE_DDX_COARSE && opcode <=<br>
>> >> >> >> FS_OPCODE_LINTERP)));<br>
>> >> >> >> > +            (opcode >= FS_OPCODE_DDX_COARSE && opcode <=<br>
>> >> >> >> FS_OPCODE_LINTERP))) ||<br>
>> >> >> >> > +          (opcode == FS_OPCODE_LINTERP && !devinfo->has_pln);<br>
>> >> >> >><br>
>> >> >> >> The devinfo->has_pln condition is technically inaccurate, because<br>
>> >> even<br>
>> >> >> >> SNB will fall back to the non-PLN path which overwrites the<br>
>> >> accumulator<br>
>> >> >> >> for certain valid IR, which yeah I'm aware is not *typically*<br>
>> >> >> >> encountered before this series,<br>
>> >> >> ><br>
>> >> >> ><br>
>> >> >> > I'm pretty sure it's impossible before this series because, without<br>
>> >> >> SIMD32,<br>
>> >> >> > the barycentric coordinates always start at g2 and get incremented<br>
>> by<br>
>> >> 2<br>
>> >> >> > every time.  The only other way to get something into the<br>
>> coordinates<br>
>> >> >> > source of the PLN is with a pixel interpolator message.  For that,<br>
>> the<br>
>> >> >> > register allocator has a workaround to ensure that it's assigned an<br>
>> >> even<br>
>> >> >> > register on SNB.  One of the early patches in my series replaces<br>
>> the<br>
>> >> >> broken<br>
>> >> >> > gen4.5-6 PLN fall-back (it didn't work in SIMD16 because it assumed<br>
>> >> the<br>
>> >> >> > wrong register layout for coordinates) with an assert and Jenkins<br>
>> is<br>
>> >> just<br>
>> >> >> > fine with the assert.<br>
>> >> >> ><br>
>> >> >><br>
>> >> >> I know the conditions for the non-PLN fall-back are not typically<br>
>> >> >> encountered on Gen5-6, but it's still valid IR, so this<br>
>> implementation<br>
>> >> >> of writes_accumulator_implicitly(<wbr>) relies on the behavior of the<br>
>> >> >> register allocator, the NIR-to-i965 translation pass and the rest of<br>
>> the<br>
>> >> >> visitor being exactly what you expect in every possible codepath for<br>
>> >> >> correctness.<br>
>> >> ><br>
>> >> ><br>
>> >> > It's already relied on for correctness because the LINE+MAC fallback<br>
>> that<br>
>> >> > we had before is wrong in SIMD16 (see patch 33).<br>
>> >> ><br>
>> >><br>
>> >> Yes, I had to do basically the same fix on my SIMD32 branch in order for<br>
>> >> it to pass piglit on Gen4-5.  Still hardly an excuse to make more code<br>
>> >> rely on the same broken assumption which wasn't doing it before.<br></div></div></blockquote><div> </div><div>I think this is the fundamental point of disagreement.  What I would argue (and what this series does) is that it's not possible to hit odd register case and, if we do, so badly broken on g4x-SNB (uses the wrong register layout in SIMD16 and doesn't actually bother to write the accumulator on gen6) that we're better off if we just stop pretending it works.  Patch 1/53 of this series just removes the fall-back and replaces it with an assert at which point the odd register fall-back path does not exist.  Jenkins is happy with us doing so.  This patch then fixes writes_accumulator_implicitly for the !has_pln case and the next patch makes re-implements the the odd register case correctly because it really is needed for SIMD32.</div><div><br></div><div>If you're really concerned about the odd register case on the stable branch, I'm happy to back port all three patches.  It won't do any good but it also won't cause any harm either.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_-3306280786556062542HOEnZb"><div class="m_-3306280786556062542h5">
>> > I'm very confused by what you mean here.  The old code assumed the<br>
>> LINE+MAC<br>
>> > layout register layout which is different from the PLN layout.  This<br>
>> means<br>
>> > that the fallback is broken for g45-gen6 because the hardware supports<br>
>> PLN<br>
>> > so we use the PLN layout which arranges thing x1y1x2y2 but the LINE+MAC<br>
>> > fallback assumes x1x2y1y2.  The reason why we need so much more code is<br>
>> > because we have to split it all the way down to 8-wide in order to handle<br>
>> > the PLN layout with LINE+MAC.  Looking at the code in your branch, I have<br>
>> > no idea how it could possibly work correctly.<br>
>> ><br>
>><br>
>> It worked correctly with the LINE/MAC path (and in fact it passed piglit<br>
>> with SIMD32 enabled on Gen4-5) in exactly the same way PATCH 33 of this<br>
>> series does, but it used a loop instead of the 3x hand-unrolled code of<br>
>> PATCH 33, and it took advantage of the two accumulator registers for<br>
>> better pipelining.<br>
><br>
><br>
> I dug around a bit more in your your branch and I think I know what's going<br>
> on now.  In your patch "i965/fs: Fix LINTERP instruction codegen for<br>
> misaligned regs on pre-Gen7 hw", you changed the LINE+MAC emit code to use<br>
> a loop to generate 1, 2, or 4 8-wide instructions.  This implicitly<br>
> switches the assumed layout of barycentric coordinates in the fall-back<br>
> code to the PLN convention (x1y1x2y2) and breaks SIMD16 on gen4 which lays<br>
> the barycentric coordinates out as x1x2y1y2.  In "i965/fs: Fix Gen4-5<br>
> interpolation setup for SIMD32", you silently change the barycentric<br>
> coordinate layout convention on gen4 to be the PLN convention and it gets<br>
> fixed again.<br>
<br>
</div></div>Yes, that's right, it relies on the other patch that makes the payload<br>
barycentric layout consistent across generations.  And yes, I didn't<br>
spend any effort documenting the changes nor ordering things in a way<br>
that would allow bisection, since that branch wasn't meant to be<br>
reviewed nor merged upstream yet.<span><br></span></blockquote></div><div class="gmail_quote"><br></div><div class="gmail_quote">Ok, at least we're now on the same page about how various branches work.<br></div><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
> I'm also very confused about accumulators since the SNB documentation<br>
> says that we have 16 floats worth (two accumulators) and your branch<br>
> definitely does 4 8-wide LINE instructions followed by 4 8-wide MAC<br>
> instructions.  I agree that taking advantage of the two accumulators<br>
> would be good, but the patch I see in your branch seems to be<br>
> incorrect.<br>
><br>
</span>No, my branch wasn't doing 4 8-wide instructions in a row, that would<br>
require four accumulators -- It was relying on SIMD lowering to split<br>
things up into 16-wide LINTERP instructions, just like your patch is.<br><div class="m_-3306280786556062542HOEnZb"><div class="m_-3306280786556062542h5"></div></div></blockquote><div><br></div><div>Ok, I see that now.  Also, I just realized how creepy it is to have the SIMD lowering pass lower LINTERP.  It's not going to do it correctly because it doesn't understand the channel layout of the payload when it's set up for PLN.  We get by because none of those MOVs ever happen in the end.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_-3306280786556062542HOEnZb"><div class="m_-3306280786556062542h5">
> All in all, changing the gen4 barycentric coordinate convention doesn't<br>
> seem like all that bad of a thing.  It's a bit odd that we lay them out<br>
> differently on exactly one platform.  I suppose, though, that we might be<br>
> able to generate SIMD16 MADs on gen11 if we started using the LINE<br>
> convention again.  Not sure if it's worth it.<br>
><br>
><br>
>> I can send you the patch as a replacement for PATCH<br>
>> 33 if you care at all about performance of this corner case on Gen4-6...<br>
>><br>
>> > My point is that the odd register fallback on g4x-gen6 was never used and<br>
>> > didn't work even if it was.<br>
>> ><br>
>><br>
>> My point was that it doesn't matter for correctness of this patch<br>
>> whether another codepath in the compiler is buggy under approximately<br>
>> the same conditions.  If you think there is some sort of benefit from<br>
>> committing knowingly broken code just so you can fix it in the next<br>
>> commit, feel free, but please drop my name from the author tag since I<br>
>> didn't intend it to.<br></div></div></blockquote><div><br></div><div>Done.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_-3306280786556062542HOEnZb"><div class="m_-3306280786556062542h5">
>> > --Jason<br>
>> ><br>
>> ><br>
>> >> ><br>
>> >> >> That wasn't the case in my original patch, nor in your<br>
>> >> >> series after PATCHv2 33 because this inaccuracy actually becomes a<br>
>> >> >> problem.  Instead of introducing code which we know is dubiously<br>
>> >> >> correct, CC'ing mesa-stable, and then fixing it immediately, why<br>
>> don't<br>
>> >> >> we just do the obviously correct thing from the start?<br>
>> >> >><br>
>> >> ><br>
>> >> > Sure, we can squash them together if you really want.  But if you're<br>
>> >> > concerned about this restriction being valid in live code, then 33/53<br>
>> >> also<br>
>> >> > needs to go to stable.  I'm fine with that if you're unconvinced by my<br>
>> >> > argument that LINTERP with an odd coordinate never occurs.<br>
>> >> ><br>
>> >> > --Jason<br>
>> >> ><br>
>> >> ><br>
>> >> >> ><br>
>> >> >> >> but why make things more inaccurate than<br>
>> >> >> >> the original only to revert back to a devinfo->gen based check in<br>
>> >> >> >> PATCHv2 33?<br>
>> >> >> >><br>
>> >> >> ><br>
>> >> >> > See above.<br>
>> >> >> ><br>
>> >> >> ><br>
>> >> >> >> I think I'd squash the last hunk of PATCHv2 33 into this one which<br>
>> >> would<br>
>> >> >> >> give you something functionally equivalent to v1 but updated to<br>
>> >> handle<br>
>> >> >> >> Gen11 correctly.<br>
>> >> >> >><br>
>> >> >> >> >  }<br>
>> >> >> >> ><br>
>> >> >> >> >  bool<br>
>> >> >> >> > --<br>
>> >> >> >> > 2.5.0.400.gff86faf<br>
>> >> >> >><br>
>> >> >><br>
>> >><br>
>><br>
</div></div></blockquote></div><br></div></div>