I have only tested this bug with r300 drivers. diff -uNr dri.orig/r200/r200_tex.c dri/r200/r200_tex.c --- dri.orig/r200/r200_tex.c Sun Feb 20 01:48:09 2005 +++ dri/r200/r200_tex.c Sun Feb 20 01:49:05 2005 @@ -182,7 +182,7 @@ { t->pp_txfilter &= ~R200_MAX_ANISO_MASK; - if ( max == 1.0 ) { + if ( max <= 1.0 ) { t->pp_txfilter |= R200_MAX_ANISO_1_TO_1; } else if ( max <= 2.0 ) { t->pp_txfilter |= R200_MAX_ANISO_2_TO_1; diff -uNr dri.orig/radeon/radeon_tex.c dri/radeon/radeon_tex.c --- dri.orig/radeon/radeon_tex.c Sun Feb 20 01:48:10 2005 +++ dri/radeon/radeon_tex.c Sun Feb 20 01:48:45 2005 @@ -147,7 +147,7 @@ { t->pp_txfilter &= ~RADEON_MAX_ANISO_MASK; - if ( max == 1.0 ) { + if ( max <= 1.0 ) { t->pp_txfilter |= RADEON_MAX_ANISO_1_TO_1; } else if ( max <= 2.0 ) { t->pp_txfilter |= RADEON_MAX_ANISO_2_TO_1;
This is not a bug. Values below 1.0 are not valid according to the extension, and in fact Mesa returns an error if you try setting it below 1.0 (at least the code suggests that, I haven't actually tried...), so values below 1.0 will never hit the driver code.
This turns out to be true. Mesa never did pass user defined value but instead missing default max anisotropy configuration leaked 0.0 in there.
I don't understand your last comment, but I'm checking in a change to glTexParameter which clamps the user-specified anisotropy against GL_MAX_TEXTURE_MAX_ANISOTROPY. That's what NVIDIA's driver seems to do.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.