ATi is ch**t**g in Filtering

Clear advice of this article would be that anyone in need of strict OpenGL conformance should not use ATI cards because they have reduced precision in logarithm calculation and because they do not follow OpenGL recommendations (Rho .vs. Lambda).

LOL! So we should avoid something because it doesn't follow a *reccomendation*? How stupid is that? If it's optional then it's optional, if the OpenGL body wanted it followed by everyone it wouldn't be a mere reccomendation.

Sounds like someone finding a way to back their favourite IHV.
 
Suspicious said:
Maybe I can help a bit with somewhat better Russian translation, I used to learn it in school (it was a long time ago though)
Pretty good translation, thank you for spending time on it :)
 
Agreed, thanks for the very readable translation, Suspicious.

It would appear that nV still offers more refined blends, and ATi still leans toward sharper (and potentially more shimmery) textures. Brandon and Lars have noted this, but not in very much depth (in all fairness, Lars appeared to mention this in one sentence, and Brandon noted it throughout his screenshot analysis). ATi's more detailed texturing is evident in Mike's AM3 screenshots, too.

Now I just have to figure out what it means that nV bases their linear interpolation on Lambda, and ATi on Rho (beyond potential patent issues)....
 
Pete said:
Now I just have to figure out what it means that nV bases their linear interpolation on Lambda, and ATi on Rho (beyond potential patent issues)....
If you look at the OpenGL spec (www.opengl.org), you'll find that lambda = log base 2 of rho(x,y). rho(x,y) = max { sqrt( (du/dx)^2 + (dv/dx)^2 ), sqrt( (du/dy)^2 + (dv/dy)^2 ) }. From the results at iXBT, it looks like ATI uses a linear approximation to log base 2. (natural log of x = ln x = 1 + x + x^2 / 2 + x^3 / 3 + ..., so 1 + x would be a linear approximation to ln x. For log base 2, just take ln x and divide by ln 2). However, since the D3D refrast does the same, I see no basis for complaints.

-FUDie
 
This is where Nvidia's LOD calculation are better then refrast. It is a slight improvement but in the big picture the devations are pretty small.
 
FUDie said:
(natural log of x = ln x = 1 + x + x^2 / 2 + x^3 / 3 + ..., so 1 + x would be a linear approximation to ln x. For log base 2, just take ln x and divide by ln 2). However, since the D3D refrast does the same, I see no basis for complaints.
Well, that's not true.

A correct formula is:
ln (1+x) = x - x^2 / 2 + x^3 / 3 - x^4 / 4 + ...

So, to first order, one can approximate the log by simply using ln(1+x) = x, or ln(x) = (x-1)/x.

As a side note, if you better-approximate the log, it can become easier to properly do the calculation:
sqrt(x^2 + y^2) that is necessary for LOD calculations, as the square root becomes trivial (a simple divide by two after the log).
 
Chalnoth said:
FUDie said:
(natural log of x = ln x = 1 + x + x^2 / 2 + x^3 / 3 + ..., so 1 + x would be a linear approximation to ln x. For log base 2, just take ln x and divide by ln 2). However, since the D3D refrast does the same, I see no basis for complaints.
Well, that's not true.

A correct formula is:
ln (1+x) = x - x^2 / 2 + x^3 / 3 - x^4 / 4 + ...

So, to first order, one can approximate the log by simply using ln(1+x) = x, or ln(x) = (x-1)/x.
You're right, I typed the above in haste.

-FUDie
 
Thanks again for taking the time to explain things, FUDie (and Chalnoth). I just need some time to understand rho as "scale," and from that, lamba. (Tau, I think I get, simple as it is.) Give me a few days before you waste more time on me, impatient as I am. :)
 
FUDie said:
(natural log of x = ln x = 1 + x + x^2 / 2 + x^3 / 3 + ..., so 1 + x would be a linear approximation to ln x.

For log base 2, just take ln x and divide by ln 2).
ACK! No one in their right mind would do it that way in computer HW! As an exercise to the reader think of floating point numbers.
 
Simon F said:
ACK! No one in their right mind would do it that way in computer HW! As an exercise to the reader think of floating point numbers.
Well, obviously with floating point numbers, to a first approximation, the log would just be the exponent. Then you could do successive approximations on the mantissa. But the real question is: How useful is this in the case of texture LOD calculations? Do they encompass enough dynamic range? Is the calculation even done in floating point?

Using this method would basically be useful to make the geometric series converge (as the log of a number between 1 and 2, which would be the mantissa, is pretty stable), and, I'm sure, could be used similarly on integers.
 
Simon F said:
ACK! No one in their right mind would do it that way in computer HW! As an exercise to the reader think of floating point numbers.
I just implemented my own LOD formula on the PS2 thinking in that way..;)
 
nAo said:
Simon F said:
ACK! No one in their right mind would do it that way in computer HW! As an exercise to the reader think of floating point numbers.
I just implemented my own LOD formula on the PS2 thinking in that way..;)
I'm sorry, I didn't understand what you meant. Do you mean that you are using bit tricks to extract the exponent and mantissa or that you are using the C "math.h" library "log" function and multiplying by 1/log(2) ?

If it's the latter, remember I said "in computer HW" :)
 
Simon F said:
Do you mean that you are using bit tricks to extract the exponent and mantissa
Yes, I mean that :) I just use a VU instruction to convert an integer number to a float representation on a floating point number.
Another couple instructions to unbias and to fix the result and I have a good (at least in my case..) log2 approximation ;)

ciao,
Marco
 
Did you use:
(mantissa) - 1 + (exponent) ?
...because that would be a little bit better than just using the exponent.
 
Chalnoth said:
Did you use:
(mantissa) - 1 + (exponent) ?
...because that would be a little bit better than just using the exponent.
yeah. In fact you don't need to subtract 1 at all, cause it's implicit in the FP representation, but the integer to float conversion instruction doesn't 'know' that :)
 
I haven't followed this thread and I'm not going to read 54 pages anyway. Those who can't understand german, just pop it into a online translator:

Deutlich ist zu erkennen, dass die R420-Karte inklusive der trilinearen Optimierung zusätzlich, und das konnten wir auf unserer Radeon 9600 XT bislang nicht entdecken (!), das LOD leicht anhebt, so dass ein auf Standbildern schärferes Bild erzeugt wird, welches in der Bewegung allerdings eher zum Flimmern neigen dürfte, denn umsonst wird der Nullpunkt beim LOD im allgemeinen nicht eingehalten. Durch diesen angehobenen LOD filtert man länger aus der hochauflösenderen Mip-Stufe, kommt dabei aber auch länger mit einer, im Verhältnis zum korrekten LOD gesehen, niedrigeren Anzahl an Textursamples bsw. bei anisotroper Filterung aus. Wenn man jetzt noch zwei und zwei zusammenzählt und bedenkt, dass die Catalyst-Treiber per default nur auf Textur-Stage 1 trilineares AF, auf allen anderen sieben dagegen nur bilineares AF bieten, erklärt sich sicherlich ein großer Teil der erstaunlichen FPS-Raten, die die X800-Serie bietet, wenn man alle Optimierungen in Aktion belässt.
Weiterhin interessant zu beobachten ist zudem, dass diese LOD-Anhebung nur in Bereichen wirksam ist, in denen die Winkelabhängigkeit des AF nicht schon einen großen Teil der zu leistenden Arbeit einspart.

That's far from an ideal situation. Very interesting article (kudos to whoever wrote it) and I'd also like to applause the closing comment of the specific article. Cliff notes: a plead to both IHVs to get rid of the optimisations when it comes to texture filtering.
 
I dont paticularly agree that there should be no filtering optimisations. I like having the choices between bilinear, Trilinear, and texture stage optimisations.

But they need to have the option to shut them off.
 
ChrisRay said:
Demirug said:
Images with and without R420 "AF-optimization"

Sorry, the text is only in german but pictures should show the differences.

It's amazing how the German/French, Asian sites figure this stuff out before us.

Very Interesting find. Thank you. Reading up :)

well the simple reason for that is that those sites are not in the IHVs pockets. That's why they often have to try hard to get any review samples unlike other big sites who just write down what is trendy and what the majority wants to hear. 1 1/2 years ago and the time before it was praising Nvidia.
The last 1 1/2 year it was all about praising ATI and bashing "evil" Nvidia.
I trust them as much as i would trust PR or marketing departments.
 
Back
Top