Differences in AF quality betwen 6800 Ultra and 9800XT

[jimmyjames123]

Does anyone have any comments on the differences in anisotropic filtering quality between the 6800 Ultra and the 9800XT shown here:

http://www20.tomshardware.com/graphic/20040414/geforce_6800-44.html

Obviously, NVDA's new AF algorithm is much more similar to ATI's than not. However, you can see that ATI and NVDA's implementation is still different. THG also notices that, with trilinear optimizations disabled, anisotropic filtering quality is clearer/sharper on the 6800 Ultra vs the 9800XT.

Any thoughts on this?

 

[Althornin]

yeah - it KILLS me that nVidia didnt stick with its more correct AF.

 

[AlphaWolf]

yeah - it KILLS me that nVidia didnt stick with its more correct AF.

It was suggested that perhaps their original af still exists, but is not exposed in current drivers. Has this idea been dismissed?

 

[Tim Murray]

yeah - it KILLS me that nVidia didnt stick with its more correct AF.

It was suggested that perhaps their original af still exists, but is not exposed in current drivers. Has this idea been dismissed?

No, it's currently believed to be a simple driver "bug" as the highest quality AF mode is not working.

Hah.

 

[KimB]

It was suggested that perhaps their original af still exists, but is not exposed in current drivers. Has this idea been dismissed?

That's not necessarily the case, and it would take more transistors to support more than one anisotropic degree selection mode.

No, it's currently believed to be a simple driver "bug" as the highest quality AF mode is not working.

That's just an impossibility. The shape of the MIP borders on those screenshots is dependent solely upon the hardware's anisotropic degree selection algorithm. This is absolutely deliberate. It pisses me off, but it's deliberate. Well, actually, I'm mostly pissed off with the droves of people who supported ATI's crappy anisotropic filtering, calling it "adaptive," which I consider just plain idiotic: it was a worse approximation that used fewer transistors, and happened to have the side effect of better performance while reducing image quality.

Since nVidia got blasted for dropping the trilinear quality, they decided that the only way to improve performance with their next generation was to make the quality more similar to ATI's.

 

[Rolf N]

It was suggested that perhaps their original af still exists, but is not exposed in current drivers. Has this idea been dismissed?

That's not necessarily the case, and it would take more transistors to support more than one anisotropic degree selection mode.

No, it's currently believed to be a simple driver "bug" as the highest quality AF mode is not working.

That's just an impossibility. The shape of the MIP borders on those screenshots is dependent solely upon the hardware's anisotropic degree selection algorithm. This is absolutely deliberate. It pisses me off, but it's deliberate. Well, actually, I'm mostly pissed off with the droves of people who supported ATI's crappy anisotropic filtering, calling it "adaptive," which I consider just plain idiotic: it was a worse approximation that used fewer transistors, and happened to have the side effect of better performance while reducing image quality.

Since nVidia got blasted for dropping the trilinear quality, they decided that the only way to improve performance with their next generation was to make the quality more similar to ATI's.

Seconded, in all respects.
And it may also be that the transistors saved on the approximate aniso-logic vs the old NV20 sytle logic came in handy for sheer die size reasons.

 

[demalion]

"Crappy anisotropic filtering"?

Please, point me to where the "crappy anisotropic filtering" is actually worse than not using anisotropic filtering. I'm currently under the impression that it is significantly better, and that it isn't like "brilinear" because it isn't mislabelled at all.

Please, point me to the actual game scenes where its disadvantages manifest, without ignoring the parts of game scenes where it doesn't manifest or a higher degree of filtering might occur (if the alternative is limited to a lesser degree). I think this will manifest differently in an FPS, versus an overhead perspective game, versus a flight sim.

In conjunction with these, please put them both in the context of the actual impact on specific games and game types, in the context of how what types of texture layers/shader usage might or might not make sense to anisotropically filter, and, finally, in the context of whether 1) it is being forced in place of something that might be slower but higher quality or 2) is an option used in place of something that might or might not be prohibitively slow in some circumstance.

Then you'll be discussing the strengths and weaknesses of an AF method for texture filtering instead of focusing on a tunnel test mip level picture and a personal sense of purity without any of the above context.

...

Here, I'll start with some questions:

If this AF method saved transistors (i.e., if it is the only AF offered by the hardware, and it takes less transistors to implement), does a "more perfect" AF really offset any advantages that those transistor savings might have been spent on? Is it a transistor benefit that multiplies per pipeline? Per quad? How significant might the benefit be in total?

The question I'm shocked noone has asked (AFAICS): How about the savings for something like floating point texture filtering?

If this AF method doesn't save transistors, then the question becomes whether offering a performance benefit for the various NV40 configuration (16 and 12 as far as we know, right?) and the corresponding bandwidth available, justified however many extra transistors were required to implement a design capable of it. Is it a primarily computational savings? Bandwidth? How would that add up for all the quads/pipes in those configurations? Again, what about floating point texture filtering?

It is easy to see that the tunnel test pictures look like a windmill for the "crappy" aniso, but it has never made sense to me how some people justify dismissing AF as crappy based on a sense of purity they don't restrict to the context of what the technique is supposed to actually achieve (which seems to me to be better texture detail with reduced aliasing compared to point sampling/simply using higher LOD, please provide an alternate expectation if you have one in mind).
Could we perhaps have a useful discussion that goes beyond repeatedly calling it "crappy" or whatever dismissive label, and touch on some critical analysis on what it means on the NV40?

 

[Ailuros]

Well, actually, I'm mostly pissed off with the droves of people who supported ATI's crappy anisotropic filtering, calling it "adaptive," which I consider just plain idiotic: it was a worse approximation that used fewer transistors, and happened to have the side effect of better performance while reducing image quality.

Support is relative. Let's just say I personally wasn't willing to "support" on the flip side of the coin for a third time NVIDIA's 4xOGMS implementation. Users set priorities and I don't think I was alone in that.

 

[KimB]

"Crappy anisotropic filtering"?

Please, point me to where the "crappy anisotropic filtering" is actually worse than not using anisotropic filtering. I'm currently under the impression that it is significantly better, and that it isn't like "brilinear" because it isn't mislabelled at all.

It's very, very simple, demalion.

The speed of this crappy anisotropic degree selection algorithm comes from only from selecting pixels to be at a lower degree of anisotropy than a more correct algorithm. Every ounce of speed that you get out of it is cost by a pixel that is displayed with less detail (or more texture aliasing) than you'd get with, say, the GeForce4's anisotropic.

 

[KimB]

Support is relative. Let's just say I personally wasn't willing to "support" on the flip side of the coin for a third time NVIDIA's 4xOGMS implementation. Users set priorities and I don't think I was alone in that.

Well, that's fine. I'm just upset at people who think that this is an improvement....demalion....

 

[darkblu]

Every ounce of speed that you get out of it is cost by a pixel that is displayed with less detail (or more texture aliasing) than you'd get with, say, the GeForce4's anisotropic.

less detail is correct, more aliasing is exactly the opposite - unless you meant devs pushing up lod manually to compensate for the AF deficiency.

 

[KimB]

less detail is correct, more aliasing is exactly the opposite - unless you meant devs pushing up lod manually to compensate for the AF deficiency.

You get one or the other depending on the LOD, yes.

 

[demalion]

"Crappy anisotropic filtering"?

Please, point me to where the "crappy anisotropic filtering" is actually worse than not using anisotropic filtering. I'm currently under the impression that it is significantly better, and that it isn't like "brilinear" because it isn't mislabelled at all.

It's very, very simple, demalion.

Get back to me when you can usefully tackle the rest of my post. With the points in it and stuff.

The speed of this crappy anisotropic degree selection algorithm comes from only from selecting pixels to be at a lower degree of anisotropy than a more correct algorithm.

I thought it was primarily from the approximation used for sampling selection? Wouldn't this allow a computational savings even when the output was the same? What about allowing more efficient texture cache usage, which might allow bandwidth savings in the same circumstance?

Of course, why answer my questions related to this, just be "upset at me". Much more useful to do that and keep saying "crappy" over and over.

Ah...because it is very very simple to do this instead?

Every ounce of speed that you get out of it is cost by a pixel that is displayed with less detail (or more texture aliasing) than you'd get with, say, the GeForce4's anisotropic.

Please, don't hesitate to propose beliefs as facts or let any of the rest of my discussion get in the way of your bias.

 

[DemoCoder]

demalion, should I be flattered or insulted that your posts are so terse with Chalnoth, but you reserve your really long ones for me?

 

[demalion]

Support is relative. Let's just say I personally wasn't willing to "support" on the flip side of the coin for a third time NVIDIA's 4xOGMS implementation. Users set priorities and I don't think I was alone in that.

Well, that's fine. I'm just upset at people who think that this is an improvement....demalion....

Chalnoth.

Please either finish reading my post, or don't comment until you do. I don't think this is too much to ask.

I personally don't see how any speed increase from higher speed aniso (or any shortcut in filtering) on a 16 pipe card like the 6800U matters in a game like Quake 3, or CoD, or the current UT franchise, so I don't see how any speed increase would matter, in those cases, for 16 degree "GF 4 aniso". I have a feeling you'd agree it wouldn't be an improvement for this situation.

But the NV40 design, and those related to it, are not limited to 16 pipe configurations, nor are games limited to the texture usage from Quake 3 and UT. That's why I discussed the things I did in my post.
Any particular reason you seemed to have missed them when you responded?

 

[darkblu]

Every ounce of speed that you get out of it is cost by a pixel that is displayed with less detail (or more texture aliasing) than you'd get with, say, the GeForce4's anisotropic.

Please, don't hesitate to propose beliefs as facts or let any of the rest of my discussion get in the way of your bias.

saying that a lower LOD does not affect the bandwidth is an indication of really strong beliefs, demalion. on your part.

 

[demalion]

demalion, should I be flattered or insulted that your posts are so terse with Chalnoth, but you reserve your really long ones for me?

Well, perhaps insulted perhaps because I have to dig through name-calling and the issues concerning the discussions I mention, and have many not nice things to say about it, and also perhaps flattered, because I bother because there are also points worth addressing mixed in with it, and occurences of worthwhile technical discussions at some point through most exchanges.

*shrug* From my perspective, you're entitled to both, and shouldn't be either flattered or insulted.

 

[Ailuros]

Another minor interruption: there's a difference between "not noticing the negatives of an implementation in the majority of cases" and claiming that a implementation is optimal.

Angle dependancy is in my book not optimal and yes I do notice it rarely, yet it's still annoying. I'd be equally offset with an edge AA algorithm for instance that would - yes even rarely - leave parts of my scene aliased.

Allow me though to put a different perspective on that one: I would have much less to object against angle-dependancy if the degradation on specific angles would be to 4x sample AF and not 2x. It probably wouldn't save nearly as much transistors or fill-rate in the end, yet the ballpark in real time between 2x and 16x samples is times bigger than from 4x to 16x.

 

[demalion]

Every ounce of speed that you get out of it is cost by a pixel that is displayed with less detail (or more texture aliasing) than you'd get with, say, the GeForce4's anisotropic.

Please, don't hesitate to propose beliefs as facts or let any of the rest of my discussion get in the way of your bias.

saying that a lower LOD does not affect the bandwidth is an indication of really strong beliefs, demalion. on your part.

Pardon? Where is your logic?

Of course lower LOD affects bandwidth (well, depending on your texture cache behavior and the texture), darkblu, I'm simply saying that "every ounce of speed that you get" from these aniso methods is not from less detail or more texture aliasing. It is quite literally that comment that I addressed, so I don't see how you missed it.

For example, for your question regarding detail, doesn't bilinear filtering result in a lower level of detail than point sampling? Is it automatically faster, or is it the same speed because of architectural decisions made to make bilinear filtering as fast? What opportunities might exist for an implementation of a sampling determination approximation to spend transistors on bandwidth savings that don't depend on less texture samples for gain?

For Chalnoth's original question, for "either aliasing or loss of detail" in order to gain performance, I don't see any basis for his assumption other than a long string of selective perception and where he sees "issues". Aliasing and detail would be determined by how efficiently, per clock and resource usage, you implemented the implementation, and usability would be determined by how efficiently, per transistor, you could implement it...what he says is impossible is not.

What about fast trilinear, or any of a host of other hardware implementations? Has this been proven to be a performance saving shortcut that loses image quality? I'm under the impression that it sets a bar that exceeds brilinear (both nVidia's and ATI's relatively unexposed RV versions) tradeoff without disqualifying disadvantages...am I mistaken?

What about the rest of my questions asking not to bypass any discussion of cost benefit simply because it is inconvenient to preference, for example floating point textures?

 

[Xmas]

"Crappy anisotropic filtering"?

Please, point me to where the "crappy anisotropic filtering" is actually worse than not using anisotropic filtering. I'm currently under the impression that it is significantly better, and that it isn't like "brilinear" because it isn't mislabelled at all.

That is not the point. Just because it is significantly better than something else doesn't make it good. Bilinear filtering is significantly better than point sampling, still it's crappy (for the purpose of simple texturing, not math lookups).

Angle-dependent AF is better than no AF at all, certainly, but seeing the huge impact AF has on IQ, it should be a priority.

I think the qualitiy of a texture filtering method is inversely proportional to the obtrusiveness of the artifacts it exhibits.
Therefore, I think a "balanced" AF (that is hardly affected by rotation around the Z axis, texture rotation, or the position of the moon) even at 4x is better than some 1024x AF that regularly breaks down to 2x on some surfaces.

The question I'm shocked noone has asked (AFAICS): How about the savings for something like floating point texture filtering?

What do you mean? The AF algorithm shouldn't affect the data format used for filtering at all.

If this AF method doesn't save transistors, then the question becomes whether offering a performance benefit for the various NV40 configuration (16 and 12 as far as we know, right?) and the corresponding bandwidth available, justified however many extra transistors were required to implement a design capable of it. Is it a primarily computational savings? Bandwidth? How would that add up for all the quads/pipes in those configurations? Again, what about floating point texture filtering?

If it doesn't save transistors, it's not justified at all IMO.

It trades image quality for performance. So does reducing the AF degree, but not locally selective.