Oh, never mind - I see there's another hunk that my mailer had folded away for some reason. I'm happy that it's correct now :) <div class="gmail_quote">On Jul 13, 2015 23:33, "Neil Roberts" <<a href="mailto:neil@linux.intel.com">neil@linux.intel.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Chris Forbes <<a href="mailto:chrisf@ijw.co.nz">chrisf@ijw.co.nz</a>> writes: > Nitpicks aside, I don't think this is a great idea now that you've got > the SKL PI working. Can you explain why you don't think this is a good idea? Is it because it is an optimisation for something that is not known to be a big use case so carrying around the extra code just adds unnecessary maintenance burden? I could agree with that so I'm happy to abandon the patch for now if that's the general consensus. > I also think it's broken -- you need to arrange to have the centroid > barycentric coords delivered to the FS thread, which won't be > happening if this is the *only* use of them. Masked in the tests, > because they compare with a centroid-qualified input. [I'm assuming > you don't always get these delivered to the FS in SKL, but no docs > access...] The changes to brw_compute_barycentric_interp_modes in the patch ensure that the centroid barycentric coords are delivered whenever interpolateAtCentroid is used in a shader. I don't think this is a problem. At least it seems to work in a simple test without using a separate varying with the centroid qualifier. Regards, - Neil </blockquote></div>