AF again

[Xmas]

You haven't seen the R200 shots yet

Make the program available to the public, I'd like ATI to look at it.

If it's about ATI, you don't seem to have a sense of humor...

I don't want to make it available to the public in its current state, for the reasons I posted above. I will make it available when I find the time to update the program.

 

[Dave Baumann]

And if webspace is really an issue then we should be able to find a home for it if you wish!

 

[Doomtrooper]

No Xmas we already have the usual suspects doing a fine job at sarcasm, pot shots on this and other forums that make big deals about small items, we have seen screen shots of games galore on this forum, and the Anisotropic image quality on a 8500 is as good/better than a Geforce 4 offering.

Yet the idea behind these discoveries is too show the flaws in any implementation, if it is made publicly aware and given even to a IHV member to look at there may be improvements made to future hardware and drivers.

I await your public release.

 

[Xmas]

No Xmas we already have the usual suspects doing a fine job at sarcasm, pot shots on this and other forums that make big deals about small items, we have seen screen shots of games galore on this forum, and the Anisotropic image quality on a 8500 is as good/better than a Geforce 4 offering.

Yet the idea behind these discoveries is too show the flaws in any implementation, if it is made publicly aware and given even to a IHV member to look at there may be improvements made to future hardware and drivers.

I await your public release.

Doom, I certainly don't want to blow anything out of proportion. What really counts is what is visible on screen in a game. Anyone can make up their mind based on their personal preferences (and my opinion doesn't match yours), that's just fine for me. My program can't subjectively decide for you which implementation is "better". But it allows for a technical analysis of AF implementations from different IHVs. That's the sole intention of the program, and if it shows IHVs where they can improve their algorithms, I'd be happy.
I don't consider it to be 'complete' though, and I don't want people using it to say "Look, here's the proof that ATIs AF sucks big time!" or such, that's why I havent made it available to the public yet. I only gave it away to a few people to get the results of different cards I don't own.

 

[noko]

Still this test makes no sense to me, sorry I am not an expert. Plus wouldn't the mipmap differences between how ATI and Nvidia does it throw off the results? Mipmap bias is changing per angle??? That isn't reflected as far as I know when mipmaps are colorized in a game.

 

[3dcgi]

The article states:

ATI's implementation of AF in the Radeon 9700 takes the slope information calculated during triangle setup (scan-line conversion) and retains it for use later in the pipeline for texture filtering operations. This slope information is determined on a per-polygon basis. ATI's approach not only determines whether to use AF or not, but also how much AF to apply, depending on how steeply sloped a surface is relative to the view camera.

This is incorrect, this was discussed before on this forum and ATI does it per pixel not per polygon. The AF requirements will vary in a polygon. Now Nvidia may do per polygon but ATI doesn't. This could very well be the reason why there is less performance loss with the ATI method over Nvidia's.

The article is not wrong in this case. You just mis-interpreted the sentence. Dave was correct in saying that the slope information is determined on a per-polygon basis. He did not say that the degree of AF is determined on a per-polygon basis. Of course since a triangle is planar the slope doesn't need to be calculated more often.

 

[Basic]

Doom:
If those images reveal anything to ATI that they didn't already know, then I'm realy disapointed. And if they actually was suprised and interested in the results, then they should already have written a program of their own by now, since it's both easy to understand what it does, and easy to implement. I'd say max 1hr progging if you start with an empty "gfx-app-skeleton", or use something like GLUT.

Btw, nice idea Xmas.

 

[darkblu]

Doom:
If those images reveal anything to ATI that they didn't already know, then I'm realy disapointed. And if they actually was suprised and interested in the results, then they should already have written a program of their own by now, since it's both easy to understand what it does, and easy to implement. I'd say max 1hr progging if you start with an empty "gfx-app-skeleton", or use something like GLUT.

Btw, nice idea Xmas.

i second the above. and indeed, xmas' idea is maybe the perfect AF visual test - thumbs up for that.

 

[demalion]

I'm confused by the "better" and "worse" labels. Let me explain.

Looking at the images, the first impression is that the AF is more continuous on the GF. Looking closer, it is evident, however, that each AF is subdividing at the same times, but the R300 implementation is doing things:

1) sampling from a "closer" (EDIT: actually is it farther? I may have confused this...yeah, it looks "farther" to me) mip map (the impression of "smoother" for the GF4 is I think only from the "trilinear gradient" being applied over a more restricted range).

2) sampling "distance" varying more for the R300 between each adjacent angle


Now, to me one of the overall impression of "better" sampling is primarily based on the first, atleast for how I've understood some comments. My question here, this seems a meaningless criteria for evaluation of "better" unless we determine that one is not "close enough" (i.e., detail is lost). Given the other comparisons I'd have to say this is not the case, but I admit that my understanding of what this test application exposes may be inadequate. If I'm wrong and the images do show the R300 is not "close enough" and suffers quality-wise, please point it out to me...currently it just looks like the evaluation is a "prettier gradient" without any clarity as to what that means.

For the second, this seems a more valid criteria (IMO of course), but I haven't understood that to be the basis for the impressions people have given of the GF4 example being "better". The reason I see this as supporting a possibility of calling it better, however, is that it seems that this might result in "shimmer" (on the R300) as sampling levels change close together if the example were in motion. Is this one of the things Xmas will focus on with his unspecified changes? Again, educate me if I'm missing something.

 

[jb]

But, if both AF and FSAA are going to drag my frame rate down to an unacceptable level, then I'll jettison AF first, since FSAA helps clean up texture crawling and line jaggies, whereas AF only addresses texture quality. It's not a decree, it's an opinion, so please take it as such.

Actually if the AA method is using MS (multi-sample) then you still should have texture crawling? Yes? No?

dave_salvator did you see the differnce AF makes in the Counter Strike Screens in the article feedback thread over at your (extremtech forums)?

 

[darkblu]

I'm confused by the "better" and "worse" labels. Let me explain.

Looking at the images, the first impression is that the AF is more continuous on the GF. Looking closer, it is evident, however, that each AF is subdividing at the same times..

the "subdivision" you see comes from the different polygons forming the tunnel. these are discontinuities across adjacent polys - basically discontinuities in the filtering logic. ideally, it should not be there.

..but the R300 implementation is doing things:

1) sampling from a "closer" (EDIT: actually is it farther? I may have confused this...yeah, it looks "farther" to me) mip map (the impression of "smoother" for the GF4 is I think only from the "trilinear gradient" being applied over a more restricted range).

the only case where the 'closer/furhter mip' comparison is (more-or-less) applicable is the 8th degree aniso case - the only case with same aniso on both cards. as you see, the lod boundaries (ok, linearly-interpolated "boundaries") are more-or-less at the same distance along the tunnel (i.e. in the best cases, not the pi/4 and {pi/8, 3pi/8} on GF and r300, respectively, cases)

2) sampling "distance" varying more for the R300 between each adjacent angle

Now, to me one of the overall impression of "better" sampling is primarily based on the first, atleast for how I've understood some comments. My question here, this seems a meaningless criteria for evaluation of "better" unless we determine that one is not "close enough" (i.e., detail is lost)..

i don't know which comments you consider by the above, but yes, detail is possibly lost if appropriate mip was not selected. in an ideal case, the mip boundaries should form rings down the tunnel, as in this tunnel aniso could be measured as a function of depth along the tunnel, and given that at a certain depth mip N was selected, there's no reason that another (possibly lower lod) be selected there too (what produces the 'distance variances' in our sample). of course, in a discrete case, such as the display framebuffe grid, it's not that simple - IMO mip boundaries may exhibit a moire pattern see, just the same as when densly drawing line segments radially in a circle (though don't take my word on this on faith, i may need do some calculations to back that).

.. Given the other comparisons I'd have to say this is not the case, but I admit that my understanding of what this test application exposes may be inadequate. If I'm wrong and the images do show the R300 is not "close enough" and suffers quality-wise, please point it out to me...currently it just looks like the evaluation is a "prettier gradient" without any clarity as to what that means.

actually it's exactly the 'prettier gradient' what makes this test particularly good for visual testing of AF filtering - it's something which is easily seen. to clear it up, this gradient has two characteristics - correctness of shape and depth at which each lod occurs.

For the second, this seems a more valid criteria (IMO of course), but I haven't understood that to be the basis for the impressions people have given of the GF4 example being "better".

again, i don't know which people's impressions you're referring to; as i, too, think the second criterion is the more important one. it's another matter that by this criterion the r300 AF does not look better either.

The reason I see this as supporting a possibility of calling it better, however, is that it seems that this might result in "shimmer" (on the R300) as sampling levels change close together if the example were in motion. Is this one of the things Xmas will focus on with his unspecified changes? Again, educate me if I'm missing something.

well, i hope it's more clear now, though i didn't have time to word some things more clearly - gotta attend some reallife(tm) matter.

 

[demalion]

I'm confused by the "better" and "worse" labels. Let me explain.

Looking at the images, the first impression is that the AF is more continuous on the GF. Looking closer, it is evident, however, that each AF is subdividing at the same times..

the "subdivision" you see comes from the different polygons forming the tunnel. these are discontinuities across adjacent polys - basically discontinuities in the filtering logic. ideally, it should not be there.

I'm saying the subdivisions are there on both images. As I went on to specify they are less apparent on the GF4 since the gradients are more similar on each.

..but the R300 implementation is doing things:

1) sampling from a "closer" (EDIT: actually is it farther? I may have confused this...yeah, it looks "farther" to me) mip map (the impression of "smoother" for the GF4 is I think only from the "trilinear gradient" being applied over a more restricted range).

the only case where the 'closer/furhter mip' comparison is (more-or-less) applicable is the 8th degree aniso case - the only case with same aniso on both cards. as you see, the lod boundaries (ok, linearly-interpolated "boundaries") are more-or-less at the same distance along the tunnel (i.e. in the best cases, not the pi/4 and {pi/8, 3pi/8} on GF and r300, respectively, cases)

Hmm, but do they mean the same things even now (8x on each card)? A clear definition of what each of the terminologies mean for each would be handy here. Going by the article which inspired this thread, they do seem to mean the same thing, as far as the limit of sampling.

But I follow what you mean by best case.

2) sampling "distance" varying more for the R300 between each adjacent angle

Now, to me one of the overall impression of "better" sampling is primarily based on the first, atleast for how I've understood some comments. My question here, this seems a meaningless criteria for evaluation of "better" unless we determine that one is not "close enough" (i.e., detail is lost)..

i don't know which comments you consider by the above, but yes, detail is possibly lost if appropriate mip was not selected.

Oh, I understand how it is possible, I don't understand how the given pictures demonstrate it however. Comments I refer to include "colors closer to the center is better", and other places where "better" is evaluated based on the gradient spread.

in an ideal case, the mip boundaries should form rings down the tunnel, as in this tunnel aniso could be measured as a function of depth along the tunnel, and given that at a certain depth mip N was selected, there's no reason that another (possibly lower lod) be selected there too (what produces the 'distance variances' in our sample).

You say "possibly lower lod", but how do we know if it is lower lod, or rather "too low" for the position on the screen/texture used? I recognize that it might be indicated, but I don't see it as being indicated by the images. Maybe you can clear it up by addressing whether there is a set of assumptions about mip maps that are universal that guarantee that "sampling from this mip map level here will produce less than satisfactory filtering" in the case of the R300? My current recollection of the angled comparisons of the anisotropic filtering before would seem to indicate that this is not the case. Also, we have no real indication of what "base" lod is used for the set of mip maps between each card...what if the first 2 mip map levels were higher LOD on one than the other? Then when the gradient indicates one is sampling from a "closer mip map" it may not necessarily be higher "lod". This goes back to clearing up whether there is a set of assumption here I'm missing.

of course, in a discrete case, such as the display framebuffe grid, it's not that simple - IMO mip boundaries may exhibit a moire pattern see, just the same as when densly drawing line segments radially in a circle (though don't take my word on this on faith, i may need do some calculations to back that).

For densely drawn lines, the pattern would be due to pixel resolution limitations causing aliasing wouldn't it? For mip maps, the same thing should occur if the filtering does not occur at polygon edges, and there are enough polygons for the given screen resolution, correct? This sort of relates to my number "2" case I think, albeit slightly indirectly.

.. Given the other comparisons I'd have to say this is not the case, but I admit that my understanding of what this test application exposes may be inadequate. If I'm wrong and the images do show the R300 is not "close enough" and suffers quality-wise, please point it out to me...currently it just looks like the evaluation is a "prettier gradient" without any clarity as to what that means.

actually it's exactly the 'prettier gradient' what makes this test particularly good for visual testing of AF filtering - it's something which is easily seen. to clear it up, this gradient has two characteristics - correctness of shape and depth at which each lod occurs.

I understand what the "prettier gradient" is saying about the "depth" of lod, and with your explanation of what you mean by "correctness of shape" I understand that it shows that too. What I don't understand is why this is enough to define better sampling (I understand that it assures a certain level of sampling) except as I outlined it might possibly do in my "2" case.

For the second, this seems a more valid criteria (IMO of course), but I haven't understood that to be the basis for the impressions people have given of the GF4 example being "better".

again, i don't know which people's impressions you're referring to; as i, too, think the second criterion is the more important one. it's another matter that by this criterion the r300 AF does not look better either.

I've pointed out which evaluations I meant and why I think so above. I'm a bit confused by your use of "either" here. We are sharing the concern for my second example, but you are referring to having reason to say my "1" case also qualifies as a reason for better results even though I don't see why this observation equates to that conclusion...do I understand what you mean here correctly? When you get back provide more info on that then...

The reason I see this as supporting a possibility of calling it better, however, is that it seems that this might result in "shimmer" (on the R300) as sampling levels change close together if the example were in motion. Is this one of the things Xmas will focus on with his unspecified changes? Again, educate me if I'm missing something.

well, i hope it's more clear now, though i didn't have time to word some things more clearly - gotta attend some reallife(tm) matter.

Hmm, well we seem to be on the same page for my "2" case, and maybe Xmas will address that, but I still don't see why the color indication is meaningful in the context of "1" as demonstrating less detail. I'm pretty sure this will be clarified in the final application though.

 

[RussSchultz]

Are these patterns fixed, or does it change if the tunnel rotates?

(I presume they're pretty much fixed, though the R300's 'spikes' suggest there's something up that might have to do with polygon edges)

 

[tamattack]

... I don't want people using it to say "Look, here's the proof that ATIs AF sucks big time!" or such, that's why I havent made it available to the public yet. I only gave it away to a few people to get the results of different cards I don't own.

The problem is, by releasing the screenshots, you have effectively given people the "proof" anyways. If you were to release the source/executable, then at least the community could validate your methodology (or not).

As it stands, all we have are screenshots which appear to make ATI look bad, with no way to validate the process you have followed. It would have been better if you had not released the screenshots in the first place.

I think we have seen that the way you program for a feature can have a profound impact on the performance/quality of the results.

We have seen Derek Smart claim that multi-texturing is broken on the R9000 (or was it R9700? Can't remember...) drivers, with his game engine as the "proof". At the same time, we can clearly see that multi-texturing does work in other games. From DS's perspective, his game is the proof that multi-texturing is broken. From someone else's perspective, other games are proof that multi-texturing works. Clearly, DS's code (while potentially technically correct) isn't getting along with ATI's drivers. This is why programmers have different codepaths for different architectures.

Without calling into question either your intentions or programming skills, it's possible that there may be some "quirky" code in your app which is causing the ATI drivers to "hiccup" leading to worse results than expected. By withholding the source/executable, there is no way to "prove" (a better word would be "demonstrate") anything.

BTW, I think it's a good idea, except that I think your app needs to be released.

 

[Xmas]

Doom:
If those images reveal anything to ATI that they didn't already know, then I'm realy disapointed. And if they actually was suprised and interested in the results, then they should already have written a program of their own by now, since it's both easy to understand what it does, and easy to implement. I'd say max 1hr progging if you start with an empty "gfx-app-skeleton", or use something like GLUT.

Btw, nice idea Xmas.

Thx. Sometimes it's really surprising how long it takes to see the obvious
And yes, you're right. Much less than one hour of coding - as long as you don't want to code a user interface with VC++

 

[tamattack]

Anybody notice this?:

"nVidia contacted us a few weeks ago, and accused ATI of possible AF corner-cutting. At the same time, nVidia product marketing management told us that the GeForce Ti actually applied AF to every pixel on the screen. Subsequently, nVidia engineers contradicted that explanation.
After a lot of back and forth, we finally got to the bottom of the mess. It turns out that nVidia also uses an adaptive implementation, although nVidia's AF uses trilinear filtering plus AF (equivalent to ATI's "Quality" setting for AF). The differences between ATI's and nVidia's implementations turn out to be more subtle than we first suspected, or were first told by nVidia."

Good catch, Geo. Now we know where all these claims about nv's af being "honest" compared to ATI's af really came from: nv marketing. Marketing bs is marketing bs is marketing bs (and this coming from someone who works in marketing).

Funny... I'm reminded of how 3dfx changed their tune from performance to image quality back in the V5 days. Ironic, that nv is now doing the same.

 

[Xmas]

Are these patterns fixed, or does it change if the tunnel rotates?

(I presume they're pretty much fixed, though the R300's 'spikes' suggest there's something up that might have to do with polygon edges)

Speaking for GF3, the patterns are fixed (besides a couple of pixels changing), whether you rotate the tunnel or the textures (or more precisely, the texture coordinates)

 

[Xmas]

... I don't want people using it to say "Look, here's the proof that ATIs AF sucks big time!" or such, that's why I havent made it available to the public yet. I only gave it away to a few people to get the results of different cards I don't own.

The problem is, by releasing the screenshots, you have effectively given people the "proof" anyways. If you were to release the source/executable, then at least the community could validate your methodology (or not).

As it stands, all we have are screenshots which appear to make ATI look bad, with no way to validate the process you have followed. It would have been better if you had not released the screenshots in the first place.

I think we have seen that the way you program for a feature can have a profound impact on the performance/quality of the results.

We have seen Derek Smart claim that multi-texturing is broken on the R9000 (or was it R9700? Can't remember...) drivers, with his game engine as the "proof". At the same time, we can clearly see that multi-texturing does work in other games. From DS's perspective, his game is the proof that multi-texturing is broken. From someone else's perspective, other games are proof that multi-texturing works. Clearly, DS's code (while potentially technically correct) isn't getting along with ATI's drivers. This is why programmers have different codepaths for different architectures.

Without calling into question either your intentions or programming skills, it's possible that there may be some "quirky" code in your app which is causing the ATI drivers to "hiccup" leading to worse results than expected. By withholding the source/executable, there is no way to "prove" (a better word would be "demonstrate") anything.

BTW, I think it's a good idea, except that I think your app needs to be released.

You're right, and I should've realized this earlier. Sorry for that. I'm trying to find the time to finish it tomorrow. Source will be available too.

 

[tamattack]

You're right, and I should've realized this earlier. Sorry for that. I'm trying to find the time to finish it tomorrow. Source will be available too.

Nice. Thanks for seeing my point.

 

[Sabastian]

If indeed the Radeon 9700 AF is so flawed why does this AF test show the Radeon 9700 with superior IQ? There was another test that was posted but I am unable to find the post. Further if this is an accurate test why does the Radeon 9700 have supperior AF in games? Seems that there is something missing from your picture here. What is the discrepency between your test xmas and the example I am providing below?