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

[DarkZeros]

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: 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 at 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...
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20190122/c1611368/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 7445 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20190122/c1611368/attachment-0001.png>