Chris Forbes <chr...@ijw.co.nz> 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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
