Ilia Mirkin <imir...@alum.mit.edu> writes: > A couple of fairly generic comments: > > - It is not at all clear to me why it's OK to interpolate at sample 0
Yes, this was cheating a little bit. At least on Intel hardware the samples are supposed to be sorted by order of distance from the centre so sample 0 will be the furthest from the edges. > -- this was previously interpolated at the sample, but apparently it > doesn't matter where it's interpolated? Why not? [A future reader of > the code might have a similar question.] It doesn't matter where it's interpolated within the pixel because the coordinates get clamped to an integer anyway so anywhere within the pixel will result in the same texture coordinates. I think this is not made any less clear by my patch so I'm inclined to leave the long comment as it is. > - I think that it should be possible to force interpolating at pixel > center -- by having any varying with the 'sample' keyword, all the > other ones don't end up getting per-sample interpolated. Not 100% sure > though. Hrm, that could work. I tried to find some clarification of where the input is interpolated if neither centroid nor sample is specified but I couldn't find any explicit mention so perhaps it is implementation-dependant. It just occured to me that we can use interpolateAtOffset to force it to interpolate the inputs at the pixel centre instead of interpolateAtSample. This avoids the problem of having to pick a sample location that we can assume isn't on the edge. I think this is probably the most explicit solution so I will post a v2 with that. Thanks for looking at the patch. Regards, - Neil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
