Hi Stefan,

Instead of keeping the discussion private I prefer to send it to the same thread.

I got a new file for you to test. https://www.dropbox.com/s/9a3t1j2nsy3nlm0/d3d9_crosstest.exe?dl=0 
I made some big mistakes on the first one (like wine and windows flags were inverted).
This new one will hopefully only fail on the middle of the projection (due to rounding i will fix tomorrow), and DFXX.

The screenshot of texldp and DF16/24 are the only ones I need to finalize the implementation.
For reference, these are my screenshots of DF16/DF24 on wine.
image.png

BTW, according to your data, the R500 and HD5700 behave differently on the texldl/texldd/texldb.
The "HD 5700" has fetch4 off, while the R500 has fetch4 ON and behaves like "texld".
I am making wine behave like the R500 / Intel and keep those ON with Fetch4.
I have a suspicion that this may have been affected due to the change of D3DTEXF_LINEAR / D3DTEXF_POINT. But I don't think so....

BR,
Daniel

El mar., 15 ene. 2019 a las 10:45, Stefan Dösinger (<stefandoesinger@gmail.com>) escribió:
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...