[Mesa-dev] [PATCH] mesa/main: Advertise ARB_texture_filter_anisotropic

[Roland Scheidegger]

Am 08.08.2017 um 17:21 schrieb Ilia Mirkin:
> On Tue, Aug 8, 2017 at 11:16 AM, Adam Jackson <ajax at redhat.com> wrote:
>> On Wed, 2017-06-28 at 16:50 +0300, Plamena Manolova wrote:
>>> ARB_texture_filter_anisotropic is the ARB variation of
>>> EXT_texture_fitter_anisotropic and it operates in the
>>> same way, so there's no reason not to advertise it.
>>
>> Nak. The ARB version bups the minmax anisotropy to 16x, see issue 2 in
>> the spec. This patch would wrongly enable the ARB version for intel <
>> gen4 and nouveau < nv40.
> 
> Yeah, this needs a new ext enable bit which is flipped on in
> st_extensions.c and the relevant i965 file, conditional on the driver
> being able to handle >= 16x aniso. (There should be a PIPE_CAP for it
> on the gallium end of it. If you don't want to hook it up for st/mesa
> that's fine too, I or someone else can handle that one-liner.)
> 
> Well-noticed, ajax.
> 
>   -ilia
>

Does it really matter, though?
The spec does not require any specific implementation. About the
strongest wording I can find is that "However, when the texture's value
of TEXTURE_MAX_ANISOTROPY is greater than 1.0, the GL implementation
should use a texture filtering scheme that accounts for a degree of
anisotropy up to..."

So it's only "should".
Therefore implementations not really being able to handle 16xAF would
probably still be conformant with a lesser AF degree - they can just
pretend it's 16xAF with a crappy scheme :-).

FWIW d3d10 also requires 16xAF, but is quite fine with any filtering as
long as the filtering is no worse than simple trilinear (which is
exactly what llvmpipe does if you give it a sampler with AF filtering...).

Roland