[PATCH v2 1/4] d3d9/tests: Add Fetch4 tests

[Stefan Dösinger]

Am 14.01.19 um 23:22 schrieb DarkZeros:
> *_Differences_:*
> - *Fetch4 offset*. It looks to me that what my result match the spec,
> while your results are different.
> The spec states that fetch4 "/allows the fetching of four unfiltered
> neighboring texels (2x2 texel block) in a single texture instruction./"
> Also points to DirectX11 Gather as a similar instruction with different
> swizzle. Gather: "/Gets the four samples (red component only) that would
> be used for bilinear interpolation when sampling a texture/."
> So if we assume that is true then the results need to have an offset,
> like in the newest Intel implementation (see screenshot with OFF/ON, I
> highlighted the texels locations in linear filtering ):
Yes, I think you are right, the results you get on your Intel GPU make
more sense than the ones I get on my slightly older Intel and the AMD GPU.

At the edges of the output image you'd expect a wrap-around to the other
side of the texture. That this does not happen on AMD suggests that they
add a 0.5x0.5 texel offset when fetch4 is used. Why they would do that
is beyond me though.

I haven't found any Microsoft documents that explicitly state that the
texture coordinates in d3d9 are at the center of the texel (like they
are in GL and d3d10), unlike the viewport coordinates, that are in the
corner of the framebuffer pixels. However, a number of third party
documentation suggests this. That would also explain why we never had to
worry about a half texel offset with textures.

I guess AMD incorrectly tried to correct the d3d9 weirdness.

Since AMD invented fetch4 we should stick to their behavior, if possible.

> - *Swizzle*. Checking the spec, it looks like yours is what the spec
> says and mine has completely different values.
> In the spec is says that it should be:
> A R
> G B
> But mine are:
> G A
> R B
> 
> My theory is that this might be an error in the Intel implementation,
> simply because they implemented it with the same swizzle as in
> Gather/textureGather.
If it were
G B
A R

I could try to explain it away with a top left vs bottom left coordinate
origin, but the swizzle you actually see I have no idea...