diff options
author | Neil Roberts <[email protected]> | 2015-07-02 17:49:19 +0100 |
---|---|---|
committer | Neil Roberts <[email protected]> | 2015-07-03 09:39:09 +0100 |
commit | 7abc1e3286bc4729e144d3a247c2a275e46aaf53 (patch) | |
tree | e23da24325549eb09e1f3b5c4781434fca66c4b6 /src/gallium/docs | |
parent | 89bd5ee64c5aa1b977f4ba832cf7772e81ee286d (diff) |
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 <[email protected]>
Diffstat (limited to 'src/gallium/docs')
0 files changed, 0 insertions, 0 deletions