AF again

[darkblu]

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?

<shots snipped>

sebastian,

the shots you refer to are at 45 degr (i.e. pi/4 rad) - r300 does fine at that angle, as is shown by xmas' test, which, btw, covers the whole 2pi round.

 

[mboeller]

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?

Does the test really show that the R9700Pro has an lower image quality?

IMHO this test only shows that Nvidia and ATi are using different implementations for AF nothing more. Xmas didn't want to show the "weakness" of the ATi implementation but the difference to the implementation of Nvidia. As it seems (I have no R9700) both implementations have (nearly) the same image quality playing games, but the implementation from ATi is much faster (and IMHO better).

Xmas, sorry that I caused so much trouble. I didn't thought that the debate would be so heated.

 

[darkblu]

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.

AFAIK and IIRC, both implementations adhere to the same terms, effective to the number of samples per given degree of aniso.

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.

'colors closer to the center' mean only that higher lods were being used. as you mentioned, it may be a result of mips lod bias as well. that's why i said that this criterion is of lesser importance to me. actually, in the context of the previous question, i think both implementations tend to pick similar lod levels as aniso level advances (given no bias is present). and i think this can be seen in the 8x aniso shots for the best-case angles.

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.

the assumption is that the mip lod is selected such as to satisfy the pixel footprint sampling needs within the texture, and given that

a) both implementatios adhere to same/similar pixel footprints, and
b) the elongation of the footprint itself is the level of aniso,

picking a given mip lod for a given pixel is indicative for the perceived (by the implementation) level of aniso for that pixel.

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.

yes. that relates to the number 2 case. but i still have to do the math.

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.

because an "incorrect" shape of the gradient (which i think we both agree is the more important factor) suggests incorrect aniso level was calculated for the pixels which fall in the lower-lod "spikes" of the shape. that conclusion results from the clause that the algorithm attemts to pick sufficiently high lods to satisfy the perceived level of aniso.

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...

no, my concerns are based solely on the number 2 criterion - correctness of shape. i hope the above paragraphs explain why.

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.

i'm sure xmas will publish the sources as soon as he can. the code should ne really trivial and easy to understand by everybody.

 

[gking]

It's not really surprising that the GeForce 4 has an extrema at 45 degrees -- that is the suggested behavior in the OpenGL spec.

In the OpenGL spec, the level of detail calculation is performed by taking the longest partial derivative's length (the rate the texture coordinates are changing relative to the screen).

Mathematically, what you want to do is ensure that a rectangle with sides of length dSdx and dTdX maintains its area through any rotation (this would correspond to perfectly circular rings in Xmas' app). However, the behavior in the OpenGL spec doesn't do this. Since you are taking the length of the longest partial derivative, rather than the 2D crossproduct of the vectors (or the length of the 2 partial derivative's hypotenuse), the LOD will be most wrong at pi/4. In fact, the MIP boundaries will be a factor of 1/.707 further from the viewer than they should be.

I'm not sure why the L1 MIP boundaryis closer to the viewer with 8x aniso on NV25. That seems odd, but there isn't any defined behavior for how anisotropic filtering should work, so it might be due to some internal rho clamping for small LODs.

 

[darkblu]

Mathematically, what you want to do is ensure that a rectangle with sides of length dSdx and dTdX maintains its area through any rotation (this would correspond to perfectly circular rings in Xmas' app). However, the behavior in the OpenGL spec doesn't do this. Since you are taking the length of the longest partial derivative, rather than the 2D crossproduct of the vectors (or the length of the 2 partial derivative's hypotenuse), the LOD will be most wrong at pi/4. In fact, the MIP boundaries will be a factor of 1/.707 further from the viewer than they should be.

i fail with following you here. you probably meant the rectangle with sides {hypotenuse(dSdX, dSdY) , hypotenuse(dTdX, dTdY) } to maintain its area through any rotation (though i believe it'd be more essential that it kept the ratio, not the product but nevermind), as i don't see how a rectangle with 'sides of length dSdx and dTdX' could maintain its area through any rotation.

I'm not sure why the L1 MIP boundaryis closer to the viewer with 8x aniso on NV25. That seems odd, but there isn't any defined behavior for how anisotropic filtering should work, so it might be due to some internal rho clamping for small LODs.

sorry for the stupid question, but what's 'rho'?

 

[gking]

Oops, my bad. It should read, the parallelogram with sides (dSdX, dTdX) and (dSdY, dTdY).

OpenGL defines rho to be the larger of the magnitude of these two vectors (so lg2(rho) is the desired LOD). There are some rules regarding when to clamp rho.

Everything else I said still applies.

though i believe it'd be more essential that it kept the ratio, not the product but nevermind

For mipmapping, you really do want to know how many texels are inside the current pixel, which you can get from the area. For additional filtering (i.e., anisotropic), the ratio of the two partial derivatives, among other things, would probably be very useful, too.

 

[Xmas]

So anybody has some webspace left for an 48kb exe and a 17kb zipped VC60 project?

 

[Dave Baumann]

wavey@beyond3d.com

(Although I'm just about to hit the sack, so if you wanna send it to me I'll probably put it up tomorrow)

 

[Xmas]

Sent.

 

[darkblu]

OpenGL defines rho to be the larger of the magnitude of these two vectors (so lg2(rho) is the desired LOD). There are some rules regarding when to clamp rho.

ah, ok.

though i believe it'd be more essential that it kept the ratio, not the product but nevermind

For mipmapping, you really do want to know how many texels are inside the current pixel, which you can get from the area. For additional filtering (i.e., anisotropic), the ratio of the two partial derivatives, among other things, would probably be very useful, too.

yes, that's what i meant - measuring anisotropy.

 

[OpenGL guy]

[quote="darkblusorry for the stupid question, but what's 'rho'?[/quote]
Get the full details here:
http://www.opengl.org/developers/documentation/Specs/glspec1.1/node83.html

 

[darkblu]

thank you, ogl guy, but my sole problem was i didn't recognize the 'rho' letter (as my knowledge of greek is nothing to be proud of; i initially took 'rho' for an acronym (e.g. reciprocal homogeneous something) )

 

[Sharkfood]

The long quote from Kirk was from an email I got from him, and I put it into the article because it was a good succint explanation of how nVidia is doing AF. I spent a lot of time talking with both companies about their respective implementations.

As for bringing an agenda to the article, there was no such motivation.

I would simply add that the chart you have on the 2nd/3rd page of the article be modified to match Mr. Kirk's description as you current have ATI as displayed "up to" on the samples, and nVidia with just number of samples.

You then use a case example of the GF4 at 8x and explain mathematically how much bandwidth 64 samples per pixel would consume. This leads to a possible conclusion (along with the context of the article) that nVidia's implementation is not adaptive, with the only hint of nVidia's algorithm being so are found hidden in Mr. Kirk's comments:
"Our anisotropic is a weighted average of up to 8 trilinear samples, along the major axis of anisotropy. So, we may include up to 64 samples, but the samples may be taken from only two MIP maps.."

For this reason, your chart should make no "up to" specification for ATI and no such "up to" for nVidia. You should either remove the "up to" for ATI or include the "up to" for nVidia.

 

[gking]

It's not necessary.

Up to 8 trilinear samples may be used (1x, 2x, 4x, and 8x are all valid aniso modes), resulting in up to 64 texel samples (8, 16, 32, and 64); however, the degree of anisotropy won't change relative to surface orientation.

It's been shown that Radeons change the number of samples relative to surface orientation, so it's reasonable to conclude that the number of samples is adaptive. Similarly, performance is constant on GeForces regardless of surface orientation (the only differences are the selected degree of anisotropy), so it's reasonable to conclude that the number of samples isn't adaptive.

The "up tos" are referring to different quantities (on the chart it corresponds to max possible samples at a given degree of anisotropy, in the interview it corresponds to the max possible degree of anisotropy).

 

[Sabastian]

Hrm my geforce DDR AF looks similair to the NV25.... Does that mean that my geforceDDR AF is superior to the Radeon 9700s? I think not. With full coloration my old gf256DDR looks nearly identical to the nv25.

 

[Xmas]

Hrm my geforce DDR AF looks similair to the NV25.... Does that mean that my geforceDDR AF is superior to the Radeon 9700s? I think not. With full coloration my old gf256DDR looks nearly identical to the nv25.

Identical to NV25 2xAF, you mean?

 

[darkblu]

It's not necessary.

Up to 8 trilinear samples may be used (1x, 2x, 4x, and 8x are all valid aniso modes), resulting in up to 64 texel samples (8, 16, 32, and 64); however, the degree of anisotropy won't change relative to surface orientation.

what do you mean by 'will not change realtive to surface orientation'?

Similarly, performance is constant on GeForces regardless of surface orientation (the only differences are the selected degree of anisotropy), so it's reasonable to conclude that the number of samples isn't adaptive.

what would they do with 64 samples when exhibited aniso is, say 2? and from what addresses would those excessive texels be fetched from?

 

[Sabastian]

Hrm my geforce DDR AF looks similair to the NV25.... Does that mean that my geforceDDR AF is superior to the Radeon 9700s? I think not. With full coloration my old gf256DDR looks nearly identical to the nv25.

Identical to NV25 2xAF, you mean?

Yes.

EDIT: It doesn't appear to test the hardware.(With the exception of different levels of AF.... for example I cannot do 8X tri AF on my card.) Correct me if I am wrong here but this seems to be some measure of the driver performance. In which case the results would only differ depending on what driver you are using and the actual hardware means little unless you are talking about different levels. But this means rather little. I mean if games work and look better then the GF4 using Radeon 9700 16X AF then what is the point of this test? Clearly something is missing from the picture here. How do you conclude that the Radeon 9700s AF is inferior when in games the Radeon 9700 is clearly better?

At any rate it is a cool little test but I am not sure if it can be concluded that the Radeon 9700 has inferior AF using the test results. If anything since ATIs implement gives superior AF quality with less of a performance hit then the only real logical conclusion is that the Geforce 4s AF implement is inferior and nvidia should work to change their method so that it is more in line with ATIs. Just my 2 cents.

 

[Xmas]

EDIT: It doesn't appear to test the hardware.(With the exception of different levels of AF.... for example I cannot do 8X tri AF on my card.) Correct me if I am wrong here but this seems to be some measure of the driver performance. In which case the results would only differ depending on what driver you are using and the actual hardware means little unless you are talking about different levels.

I'm not sure if I understand you correctly. The results usually depend on the hardware, not on the driver. It should be consistent across driver revisions, but not necessarily across different chips.
Anyway, you always have to test a hardware/driver combination because one doesn't work without the other.

But this means rather little. I mean if games work and look better then the GF4 using Radeon 9700 16X AF then what is the point of this test? Clearly something is missing from the picture here. How do you conclude that the Radeon 9700s AF is inferior when in games the Radeon 9700 is clearly better?

At any rate it is a cool little test but I am not sure if it can be concluded that the Radeon 9700 has inferior AF using the test results. If anything since ATIs implement gives superior AF quality with less of a performance hit then the only real logical conclusion is that the Geforce 4s AF implement is inferior and nvidia should work to change their method so that it is more in line with ATIs. Just my 2 cents.

The tool is for technical analysis. It is subjective which one is better.

And I don't agree with you that the R9700 AF method is clearly superior. It is faster, no doubt. Sometimes it looks better, sometimes worse IMHO. But that's because it can do 16x AF. Comparing 8x AF modes I would always prefer NVidia's method quality-wise.
So talking about the AF method I'd prefer NVidia to add 16x support to theirs and make it faster.

 

[Sabastian]

The GF256 DDR 2xAF is exactly the same as the GF4 2xAF AFAIK the hardware is quite different but I am using the 40.71 DETs (Unified driver.) So I just assumed that it was the driver implement that was making the outcome the same. But your argument seems to make more sence in that it has to be hardware/driver test not just one or the other. I just found it funny that the GF4 2xAF is exactly the same looking as my old GF1.

On the issue of nvidia 8xAF vs ATIs 16xAF well.... I don't think I have seen too many situations where ATIs 16xAF was worse looking. On the flip side of that I have however seen a noticeable difference in ATIs 16xAF looking better then nvidias 8xAF ... and AFAIK ATIs method is also considerably faster. My guess is if nvidia took their method to 16x it would cause such a performance hit that you would never use the multiple agian.