[Mesa-dev] [PATCH] mesa/meta: Use interpolateAtSample for 16x MSAA copy blit

[Neil Roberts]

Ilia Mirkin <imirkin at 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