On 28/01/2019 11:16, Stefan Dösinger wrote:
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?
I'm not able to say, I guess you'd have to ask an AMD dev.
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.
Well I think it makes sense to use DF24 over INTZ if one doesn't need stencil.
As for the apps, apparently some old AMD demos are supposed to use it, but I haven't tested.
Axel