Anisotropic filtering weirdness

[Reverend]

In case some of you missed our VisionTek GF4 Ti4400 review recently published, do read it now. The reason for this particular post is on Page 6, specifically the part about the missing pixels in the fence when anisotropic filtering is applied.

Anyone have an explanation for this?

 

[gking]

My guess is that the fence is being alpha tested and the reference value is set too high.

The fence is definitely being alpha tested, and missing pixel artifacts would will occur if the reference alpha value was set to greater than .03 (1 / num_texel_samples, assuming that the alpha for all pixels that should be drawn in the texture is 1.0). The higher the ref value, the more pixels are lost.

 

[Sharkfood]

Hmmm.. interesting how it only occurs when anisotropic filtering is enabled though...

I wonder if a more aggressive z-compression ("lossless" becomes "lossful") is used in those particular drivers to help improve anisotropic filtering performance?

Is this the case with the original/slow anisotropic filtering drivers?

 

[Dave B(TotalVR)]

Huh, how can fuddling with the z-buffer help aniso performance?

Ok you mightsavesome bandwidth overall, but that will help *all* performance, surely.

 

[Sharkfood]

That's the whole point.

Do *something* to offer a boost in performance, and if it has adverse effects, limit it's usage for when anisotropic filtering is enabled. That is clearly what these screenshots display...

Anisotropic filtering on the GF4 was originally hammered for it's poor performance, from which it has improved a tad since then in most recent drivers.

 

[Dave B(TotalVR)]

People should stop moaning about low aniso performance and start realising just how much more of a complex operation that it is over a normal trilinear op.

 

[pcchen]

I agree with gking's theory. On the other hand, if Z compression becomes lossy when anisotropic filtering is enabled, and it produces such significant differences, we shall see much more problems everywhere. Therefore, I doubt that a lossy Z compression is responsible for this.

 

[gking]

Hmmm.. interesting how it only occurs when anisotropic filtering is enabled though...

Nope -- my theory predicts that behavior.

Only 4 texel samples are taken when you bilinear filter a texture, so given the same set of assumptions I make above (all texels have an alpha of 1 if the fence exists, 0 if it doesn't), the reference value would have to be set >= .25 (1/num_texel_samples) for the rasterizer to discard the pixel. Since anisotropic filtering increases the number of texels sampled, the reference value would have to decrease if you want to ensure that every pixel that has some of the fence in it is drawn.

I wonder if a more aggressive z-compression ("lossless" becomes "lossful") is used in those particular drivers to help improve anisotropic filtering performance?

First, that's not the case at all.

Second, if it were, the Z compression would become so bad as to confuse pixels in the Skybox (which probably wasn't written to the Zbuffer, anyway) with pixels in the foreground! There's absolutely no way that *anything* would be rendered properly on the GeForce4 if the Z compression were that poor.

 

[Humus]

gking's theory is correct. Something that would further supports this theory is that if you look closer on the pictures you'll see that the effect gets worse the steeper the viewing angle is, that is, when more samples are taken.