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.... 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@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@gmail.com mailto:stefandoesinger@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>