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

[Ilia Mirkin]

On Tue, Aug 8, 2017 at 11:34 AM, Roland Scheidegger <sroland at vmware.com> wrote:
> 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...).

In practice though, MAX_TEXTURE_MAX_ANISOTROPY will continue to be
reported as 4 or whatever it was, against the spec, without additional
changes.