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

[Roland Scheidegger]

Am 08.08.2017 um 17:45 schrieb Ilia Mirkin:
> On Tue, Aug 8, 2017 at 11:34 AM, Roland Scheidegger  
> wrote:
>> Am 08.08.2017 um 17:21 schrieb Ilia Mirkin:
>>> On Tue, Aug 8, 2017 at 11:16 AM, Adam Jackson  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.
> 
Ahh right. So you either have to lie about the max anisotropy or not
advertize the ARB version indeed. Unless you want to violate the spec
there, but there's probably no good reason to (unlike for instance the
min multisample level required for GL 3.0).

Roland

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [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  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


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Ilia Mirkin]

On Tue, Aug 8, 2017 at 11:34 AM, Roland Scheidegger  wrote:
> Am 08.08.2017 um 17:21 schrieb Ilia Mirkin:
>> On Tue, Aug 8, 2017 at 11:16 AM, Adam Jackson  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.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Ilia Mirkin]

On Tue, Aug 8, 2017 at 11:16 AM, Adam Jackson  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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Adam Jackson]

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.

- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Ian Romanick]

On 06/28/2017 06:50 AM, 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.
> 
> Signed-off-by: Plamena Manolova 
> ---
>  src/mesa/main/extensions_table.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/src/mesa/main/extensions_table.h 
> b/src/mesa/main/extensions_table.h
> index 757b7bf..009a119 100644
> --- a/src/mesa/main/extensions_table.h
> +++ b/src/mesa/main/extensions_table.h
> @@ -144,6 +144,7 @@ EXT(ARB_texture_env_add , dummy_true
>  EXT(ARB_texture_env_combine , ARB_texture_env_combine
> , GLL,  x ,  x ,  x , 2001)
>  EXT(ARB_texture_env_crossbar, ARB_texture_env_crossbar   
> , GLL,  x ,  x ,  x , 2001)
>  EXT(ARB_texture_env_dot3, ARB_texture_env_dot3   
> , GLL,  x ,  x ,  x , 2001)
> +EXT(ARB_texture_filter_anisotropic  , EXT_texture_filter_anisotropic 
> , GLL, GLC, ES1, ES2, 2017)


This should be  
  GLL, GLC,  x,   x,  2017

With that fixed and docs/features.txt updated, this patch is

Reviewed-by: Ian Romanick 

>  EXT(ARB_texture_float   , ARB_texture_float  
> , GLL, GLC,  x ,  x , 2004)
>  EXT(ARB_texture_gather  , ARB_texture_gather 
> , GLL, GLC,  x ,  x , 2009)
>  EXT(ARB_texture_mirror_clamp_to_edge, 
> ARB_texture_mirror_clamp_to_edge   , GLL, GLC,  x ,  x , 2013)
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev