i965/fs: Don't disable SIMD16 when using the pixel interpolator
authorNeil Roberts <neil@linux.intel.com>
Thu, 2 Jul 2015 16:49:19 +0000 (17:49 +0100)
committerNeil Roberts <neil@linux.intel.com>
Fri, 3 Jul 2015 08:39:09 +0000 (09:39 +0100)
commit7abc1e3286bc4729e144d3a247c2a275e46aaf53
treee23da24325549eb09e1f3b5c4781434fca66c4b6
parent89bd5ee64c5aa1b977f4ba832cf7772e81ee286d
i965/fs: Don't disable SIMD16 when using the pixel interpolator

There was a comment saying that in SIMD16 mode the pixel interpolator
returns coords interleaved 8 channels at a time and that this requires
extra work to support. However, this interleaved format is exactly
what the PLN instruction requires so I don't think anything needs to
be done to support it apart from removing the line to disable it and
to ensure that the message lengths for the send message are correct.

I am more convinced that this is correct because as it says in the
comment this interleaved output is identical to what is given in the
thread payload. The code generated to apply the plane equation to
these coordinates is identical on SIMD16 and SIMD8 except that the
dispatch width is larger which implies no special unmangling is
needed.

Perhaps the confusion stems from the fact that the description of the
PLN instruction in the IVB PRM seems to imply that the src1 inputs are
not interleaved so it wouldn't work. However, in the HSW and BDW PRMs,
the pseudo-code is different and looks like it expects the interleaved
format. Mesa doesn't seem to generate different code on IVB to
uninterleave the payload registers and everything is working so I can
only assume that the PRM is wrong.

I tested the interpolateAt tests on HSW and did a full Piglit run on
IVB on there were no regressions.

Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
src/mesa/drivers/dri/i965/brw_fs_nir.cpp