On 27/01/2019 01:04, Axel Davy wrote:
Hi,
Another info about the 0.5 offset is the following comments in the r600 gallium driver: /* Gather4 should follow the same rules as bilinear filtering, but the hardware * incorrectly forces nearest filtering if the texture format is integer. * The only effect it has on Gather4, which always returns 4 texels for * bilinear filtering, is that the final coordinates are off by 0.5 of * the texel size.
This is interesting, and I guess it explains why I saw this behavior on r500 only when point mag filtering was enabled, but not when linear mag filters were set.
Does that also apply for minification filters?
r600's GATHER4 is likely to be the original instruction meant for FETCH4, as except for Cayman, the driver reorders the result to match the gl's version.
Ya, that was my impression from GL_AMD_texture_texture4. I guess this extension could in theory be implemented in r300g for r500 cards but currently isn't.
I experimented with 3DMark06, disabling support for D24X8 texturing to force FETCH4.
Do you know any application that uses fetch4 without having an alternative codepath, or insisting on using it on AMD cards even though an alternative codepath like PCF is supported by the application and used on Nvidia cards? For us, the reason to implement fetch4 is because DF24 implies it, and there are games like CS:GO that insist on using DF24 on AMD cards even though it happily uses INTZ on Nvidia cards.