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

[DarkZeros]

Hi Stefan,

Let me summarize here my discoveries.
First thing, is good that the tests are exercising properly all the fetch4
implementation.
We can solve the differences in results based on which platform we believe
is right or not.

*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 ):
[image: image.png]   [image: image.png]

- *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.
Anyway, if someone has some light on why the offset appears on the fetch4,
that would be helpful. @Henri

BR,
Daniel

El jue., 10 ene. 2019 a las 18:36, Stefan Dösinger (<
stefandoesinger at gmail.com>) escribió:

> And one last mail, here is a log from Windows 7 on my Radeon X1600 (r500)
> machine. This was the GPU where AMD originally introduced fetch4, and the
> result looks identical to the newer HD 5770 (r700 I think). 6 fewer
> failures, I assume a depth format is not supported.
>
>
> https://www.khronos.org/registry/OpenGL/extensions/AMD/AMD_texture_texture4.txt may
> also be an interesting read. The other interesting side-note is that r500
> does not support unconditional NP2 textures, so we'd have a case where
> FETCH4 could be used with GL_ARB_texture_rectangle, but I seriously doubt
> that this is worth the effort because this hardware is more than 10 years
> old. I doubt mesa exposes AMD_texture_texture4 on the r300g driver.
>
>
> Am 10.01.2019 um 18:52 schrieb Stefan Dösinger <stefandoesinger at gmail.com
> >:
>
> Another pile of screenshots, this time the format tests. Only FFP to
> reduce my work. I also assigned the names manually and might have screwed
> up.
>
> Two observations:
> *) AMD enables fetch4 on A8 and ARGB8 too.
> *) Comparing the expected and actual results reinforce my suspicion that
> the output swizzle differs
>
> I don't know how it picks the color in the multi-channel textures. The A8
> results suggest it doesn't just pick the red channel, and the R16F and R32F
> results suggest it doesn't just pick the alpha channel. I guess we're safe
> picking the red channel and can drop the fetch4 enable / disable based on
> texture formats.
>
>
> <A8R8G8B8_ffp.png><A8_ffp.png><L8_ffp.png><L16_ffp.png><R16F_ffp.png>
>
> Am 10.01.2019 um 18:30 schrieb Stefan Dösinger <stefandoesinger at gmail.com
> >:
>
> Hi,
>
> I tested the tests on Windows 7 with a Radeon HD 5770. There are plenty of
> failures, for some of which I have an explanation, but others I don't.
>
> Visual2.txt is the output of the test. I also attached various screenshots
>
> *) ffp_texld is the first test loop. The fixed function and texld output
> looks the same.
> *) texldp is the texldp shader. It appears that AMD still does the
> projected read at the same time it does the fetch4 lookup.
> *) texldl and texldd suggest that AMD drivers do not apply FETCH4 for
> those instructions
> *) texldb however behaves like texld. Presumably it also does that with
> fetch4 off on the single-level texture :-)
>
> What I can't explain is why the colors even in the FFP and texld case are
> wrong. Maybe intel applies a wrong swizzle?
>
> Please ignore the white border on some of the PNGs. I was sloppy cutting
> off the irrelevant parts of the screenshots, and somehow windows didn't
> want to screenshot the individual window.
>
> I'll look into the remaining failures and send more screenshots to avoid
> overshooting the mailing list size limit.
>
> Where can we go from here? Because apparently applications cannot rely on
> a specific GPU behavior we have more freedom. Generally I recommend to
> stick with AMDs behavior, but if it is too cumbersome in a corner case we
> can write a WARN or FIXME if an application even uses it. If the different
> colors are a result of a different swizzle and nobody seems to have noticed
> yet, it is even more likely that nobody actually uses FETCH4. In that case
> we could make the entire FETCH4 thing a FIXME, enable the DF24 depth format
> and see if any application ever hits the FIXME. It'd be a pity to have your
> work just gathering dust on the mailing list archives though.
>
> We could also implement FETCH4 the AMD way, and mark all intel results
> broken(). Or we even remove the more corner case tests that produce
> contrary results, like texldp and texldd, but keep the baseline tests like
> ffp and texld. The important thing is that we preserve the knowledge the
> tests have found in a comment.
>
> Stefan
>
> <texldb.png>
> <texldd_texldl.png>
> <visual2.txt><texldp.png><ffp_texld.png>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20190114/2c448fa5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 47324 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20190114/2c448fa5/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 6795 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20190114/2c448fa5/attachment-0003.png>