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

[Stefan Dösinger]

More quick testing, this time without screenshots: It seems AMD does do fetch4 on volume textures. Colors mismatch, presumably the same swizzle difference.

There is something going on with the depth format tests, but I can't quite interpret the results. I'll look at it closer once we have answers to the swizzle question.

> 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 <mailto: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/20190110/aab3f0e7/attachment.html>