summaryrefslogtreecommitdiffstats
path: root/src/mesa/tnl/t_vb_points.c
diff options
context:
space:
mode:
authorNeil Roberts <[email protected]>2015-07-02 17:49:19 +0100
committerNeil Roberts <[email protected]>2015-07-03 09:39:09 +0100
commit7abc1e3286bc4729e144d3a247c2a275e46aaf53 (patch)
treee23da24325549eb09e1f3b5c4781434fca66c4b6 /src/mesa/tnl/t_vb_points.c
parent89bd5ee64c5aa1b977f4ba832cf7772e81ee286d (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/mesa/tnl/t_vb_points.c')
0 files changed, 0 insertions, 0 deletions