ATIs Filtertricks

[Leonidas]

http://www.3dcenter.org/artikel/2003/11-21_a.php

Wäre wichtig.

[huha]

Ich versuch mich mal dran, bin nur zur Zeit *SEHR* müde.
Ich werd' mal Seite 1 angehen lassen.

-huha

P.S.
Ich bin gerade beim Übersetzen.
Im deutschen Text ist ein kleiner Fehler, den könnte man auch mal rausmachen:
extreme Winkelabhängigkeit beim AF, sondern auch offenbare Schwächen bei der Bestimmung des MIP-Map-LODs: Unseres Wissens nach führten ATIs LOD-Berechnungen bei aktiviertem AF schon mal zu Textur-
Da gehört n n hin.

[huha]

So.
Mit nem Teil bin ich fertig, der Rest wird gerade vorbereitet... vielleicht schaff ichs noch heute, was ich allerdings aufgrund meiner fortgeschrittenen Müdigkeit bezweifle.

Alles einfach aus meinem Word-processing-Programm rauskopiert, damit man mal einen Überblick behält bzw. mich auch schon gleich mal berichtigen kann. Sind sicher tausende Fehler drin.

-huha


Einleitung

Introduction

Bei der Entwicklung eines Grafikchips muss aus verschiedenen Gründen auf den Transistor-Count geachtet werden. Das heißt, dass Prioritäten gesetzt werden, welche Features besonders wichtig sind und welche weniger. Zu jedem gegebenen Zeitpunkt ist die Komplexität eines Chips begrenzt, so dass die Entwickler immer einen Kompromiss zwischen Leistung und Features (im weiteren Sinne auch Bildqualität) schließen müssen.

When developing graphics chips there is a need to consider the transistor count for several reasons. Priorities about which features are very important and which are less have to be set. To every given time the complexity of a chip is limited, so that developers have to make a compromise between performance and features (including image quality)

Bei ATI hat es nun etwas Tradition, dass die Textur-Filterung zurückstecken muss. Beispiel R200 (Radeon 8500): Dem im zeitlichen Kontext gesehen sehr fortschrittlichem Pixel Shader und Eigenschaften wie Overbright Lighting (und vermutlich auch eine erhöhte interne Farbpräzision) stehen Nachteile bei der Texturfilterung, insbesondere bei anisotroper Filterung ("AF") gegenüber.

At ATI, it is tradition to //HIER FEHLT WAS// Let’s take the R200 (Radeon 8500) as an example: On the one hand, there is a – for this time – very progressive pixel shader and properties like overbrigt lighting (and supposedly an increased internal color precision), on the other hand there are disadvantages when coming to texture filtering, particularly when using anisotropic filtering (“AF”)

Damit meinen wir nicht nur die Limitierung auf bilineares Filtering ("BF") im Zusammenspiel mit AF und die extreme Winkelabhängigkeit beim AF, sondern auch offenbare Schwächen bei der Bestimmung des MIP-Map-LODs: Unseres Wissens nach führte ATIs LOD-Berechnungen bei aktiviertem AF schon mal zu Textur-Aliasing. Allerdings haben wir dies seinerzeit nie tiefgehender untersucht, so dass wir darauf nicht groß herumreiten wollen. Heute aber wollen wir uns die Zeit nehmen, um uns in diesen Filter-Fragen aktueller Hardware zu widmen: Der R3x0-Familie.

We do not mean limitation to bilinear Filtering (“BF”) in interaction with AF and the extreme angle-dependency of AF, but also obvious flaws with the determination of MIP-map-LODs: To our knowledge, ATIs LOD-calculations lead to texture aliasing with AF enabled, but we have never done in-depth research on this so that we don’t want to emphasize this too much. But today we want to dedicate some time to questions concerning filtering on the latest hardware: The R3x0-graphics card family.


ATI sah bei dieser endlich ein, dass trilineares AF sinnvoll ist, und hat außerdem die Winkelabhängigkeit reduziert. Trotzdem: Stellt man 16x AF ein, werden bestimmte Winkel nur mit 2x AF gefiltert. Obwohl es bei ATI nichts neues ist, dass der eingestellte AF-Grad nur partiell zum tragen kommt, möchten wir an dieser Stelle darauf noch einmal ausdrücklich hinweisen: Aktiviertes 16x AF führt bei einigen Winkeln nicht zu 16x, sondern nur zu 2x AF. Kann man angesichts dieser Tatsache das AF vom R300 überhaupt mit Fug und Recht "Anisotropes Filtering" nennen?

ATI finally understood that trilinear AF is senseful and has furthermore reduced the angle-dependency. Anyway, when adjusting AF to 16x, certain angles are just filtered with 2x AF. Although it is not unknown that the chosen AF level is just partially applied, we would like to point out //da fehtl nochmal was//
Activeted 16x AF is not leading to 16x, but only to 2x AF on certain angles. Can you call this“anisotropic filtering” without a doubt?

Ja, das kann man. An-isotrop heißt zunächst nur, nicht isotrop. ATIs R300-AF filtert in der Tat (jeden Winkel) nicht isotrop. Gibt es eine genauere Definition? Wir konnten keine "gültige", also verbindliche Definition für AF finden, aber: Es ist kein Geheimnis, welche Qualität "Lehrbuch-AF" haben muss. Mit den Interna von anisotroper Filterung beschäftigen wir uns in einem zukünftigen Artikel noch ausführlich, an dieser Stelle wollen wir nur darauf zu sprechen kommen, wie ein "perfektes" AF auszusehen hat. Nämlich genau wie trilineare Filterung (TF), jedoch pro Verdoppelung des AF-Grades müssen die MIP-Level um eine Stufe "nach hinten" geschoben sein. Reden wir nicht lange um den heißen Brei, "perfektes AF" wird praktisch auf keiner derzeitigen Hardware geboten.

Yes, you can. At first, An-isotropic just means “not isotropic”. ATIs R300-AF does indeed filter (every angle) non-isotropic. Is there a more detailed definition? We could not find a “valid”, that is binding definition for AF, but: It is no secret which quality schoolbook-AF should have. We well deal with the internals of anisotropic filtering in a future article. At this point, we just want to state how a “perfect AF” has to look. Namely exactly like trilinear filtering (TF), though with every doubling of the AF level, MIP levels have to be moved one stage “away”. Let’s don’t beat around the bush, “perfect” AF is virtually not available on any current hardware.

Löbliche Ausnahme ist 2x AF auf GeForce-Karten, doch schon 4x AF ist (bei 45°-Winkeln) leicht, 8x AF (ebenfalls bei 45°-Winkeln) deutlich "optimiert". Kyro-Karten können nur 2x AF, beherrschen diesen Modus jedoch in Perfektion. Die Formel für optimales AF ist so komplex, dass dort gerne gespart wird und man Abweichungen von der Perfektion in Kauf nimmt.

There is one laudable exception: 2x AF on GeForce series graphics cards, but 4x AF has (at 45° angles) small, at 8x AF (also at 45° angles) clear optimizations. Kyro series graphics cards are only able to do 2x AF, but handle this mode with perfection. The formula for optimal AF is so complex that it is common to tweak it a bit to save resources and to accept deviations from the “perfect AF”.

Transistoren zu sparen, war wohl auch der Hintergedanke bei ATI. Die exakte Implementierung ist natürlich nicht öffentlich zugänglich, doch ist es wahrscheinlich, dass ATI sich um die (Transistor-intensive) Implementierung der Wurzelfunktion beim AF drückte. Lässt man jene weg, gelangt man zunächst zu einer Lösung, nur volle 90°-Winkel anisotrop filtern zu können (was die Winkelabhängigkeit bei R100 und R200 erklären dürfte). Mit einer Erweiterung, welche vergleichsweise wenig Transistoren beansprucht, kann man weiterhin die Wurzel-Berechnung sparen, gewinnt jedoch zusätzlich volle 45°-Winkel hinzu.

One of the main thoughts at ATI was presumably to save transistors. Of course, the exact implementation is not accessible to the public, but it is likely that ATI did not implement the transistor-intensive square root function when using AF. If you leave that out, one arrives at the solution to just filter full 90° angles anisotropic (which should explain the angle-dependency of R100 and R200). By means of an extension, which uses comparatively few transistors, one can save resources at square root calculation but gains full 45° angles.

Dass dies der Fall sein könnte, wird von uns auf Basis einer Überlegung seitens Demirug derzeit vermutet. Unabhängig von diesen Theorien lassen sich jedoch zwei Dinge sicher sagen:

That this could be the case is presumed by us at the moment based on a thought from Demirug. Independent from this theories, one can savely notice two things:

* ATI spart Transistoren bei der Berechnung der AF-Sample-Koordinaten.
* Da der eingestellte AF-Grad über den Vollkreis verteilt nur partiell appliziert wird, spart man auch noch Füllrate.

*ATI saves transistors when calculating AF-sample coordinates.
*For the adjusted AF level is only partially applied over the full circle, fill rate is also saved.

[huha]

So. die erste Seite ist fertig. Zu mehr hab ich allerdings nur wenig Lust.

Enjoy!

-huha

Introduction

When developing graphics chips there is a need to consider the transistor count for several reasons. Priorities about which features are very important and which are less have to be set. To every given time the complexity of a chip is limited, so that developers have to make a compromise between performance and features (including image quality)

At ATI, it is tradition to //HIER FEHLT WAS// Let’s take the R200 (Radeon 8500) as an example: On the one hand, there is a – for this time – very progressive pixel shader and properties like overbrigt lighting (and supposedly an increased internal color precision), on the other hand there are disadvantages when coming to texture filtering, particularly when using anisotropic filtering (“AF”)

We do not mean limitation to bilinear Filtering (“BF”) in interaction with AF and the extreme angle-dependency of AF, but also obvious flaws with the determination of MIP-map-LODs: To our knowledge, ATIs LOD-calculations lead to texture aliasing with AF enabled, but we have never done in-depth research on this so that we don’t want to emphasize this too much. But today we want to dedicate some time to questions concerning filtering on the latest hardware: The R3x0-graphics card family.

ATI finally understood that trilinear AF is reasonable and has furthermore reduced the angle-dependency. Anyway, when adjusting AF to 16x, certain angles are just filtered with 2x AF. Although it is not unknown that the chosen AF level is just partially applied, we would like to point out //da fehtl nochmal was//
Activated 16x AF is not leading to 16x, but only to 2x AF on certain angles. Can you call this “anisotropic filtering” without a doubt?

Yes, you can. At first, An-isotropic just means “not isotropic”. ATIs R300-AF does indeed filter (every angle) non-isotropic. Is there a more detailed definition? We could not find a “valid”, that is binding definition for AF, but: It is no secret which quality schoolbook-AF should have. We well deal with the internals of anisotropic filtering in a future article. At this point, we just want to state how a “perfect AF” has to look. Namely exactly like trilinear filtering (TF), though with every doubling of the AF level, MIP levels have to be moved one stage “away”. Let’s don’t beat around the bush, “perfect” AF is virtually not available on any current hardware.

There is one laudable exception: 2x AF on GeForce series graphics cards, but 4x AF has (at 45° angles) small, at 8x AF (also at 45° angles) clear optimizations. Kyro series graphics cards are only able to do 2x AF, but handle this mode with perfection. The formula for optimal AF is so complex that it is common to tweak it a bit to save resources and to accept deviations from the “perfect AF”.

One of the main thoughts at ATI was presumably to save transistors. Of course, the exact implementation is not accessible to the public, but it is likely that ATI did not implement the transistor-intensive square root function when using AF. If you leave that out, one arrives at the solution to just filter full 90° angles anisotropic (which should explain the angle-dependency of R100 and R200). By means of an extension, which uses comparatively few transistors, one can save resources at square root calculation but gains full 45° angles.

That this could be the case is presumed by us at the moment based on a thought from Demirug. Independent from this theories, one can savely notice two things:

*ATI saves transistors when calculating AF-sample coordinates.
*For the adjusted AF level is only partially applied over the full circle, fill rate is also saved.

On this basis, it is easy to assert ATI has the faster AF. For a long time, AF was more or less a checklist-feature with questionable implementation. GeForce series graphics cards were one of the first productions which delivered “reasonable” AF, but were limited on 2x. The GeForce 3 could do up to 8x AF, which, however, did not play an important role in marketing. Presumably one was afraid to recommend this “slow-maker”. It is the merit of 3dconcept creator Raphael auf der Maur to point to this feature very soon and to judge its picture quality, instead of just looking at the frame rate like the majority.

ATIs original Radeon (R100) appeared before the GeForce3 and could do 16x AF at this time – but just with constraints and limitations, so that this card is not regarded as a good “AF graphics card” by us. The GeForce4 Ti (NV25/NV28) has a limitation concerning bilinear AF performance, obviously due to the transistor count. The GeForce FX (NV3x) includes the ability to reduce AF quality in favor of performance.

For us, this is a less reasonable progression; At the aspect of “fill rate per quality”, “schoolbook-AF” would be optimal. NVIDIA offers a relatively good AF sample position calculation since the NV20, so it is a pity when “8x AF” is offered for the performance of conventional 4x AF, making the overall anisotropy worse. Just because a small number of pixels are filtered with 8x AF, this mode can truly be called so, but our claim is to exhaust a given level of anisotropy as much as possible before switching to a higher level. Maybe NVIDIA was driven by ATI to show a higher performance at higher AF levels instead of ensuring that a AF level creates the best image quality possible (which one should expect of a quality feature)

We’d like to point out a potentially mistakable formulation on our part: It is not a problem that ATI does not filter everything 16x when having 16x AF on. Depending on how much is needed, the decision is made if 1x, 2x, 4x, 8x or 16x is taken (NVIDIAs hardware also does this when 8x AF is enabled). This depends on how distorted the texture is displayed: With a distortion at the rate of 1:2, more than 2 AF samples do not deliver any higher amount of additional quality. What ATI did introduce is a extreme angle-dependency when calculating the pixel’s actual AF stage. A (smaller) angle-dependency is also found at NVIDIAs levels, beginning at 4x AF.

Unfortunately, this is not the only point where ATI simplified filter calculations in favor of the transistor count and moved away from schoolbook-quality more than the competition.

[zeckensack]

*anmeld*

Ich mache die Korrektur und die Seite 2.

*anfang*

[zeckensack]

Seite 1, ~erste Hälfte (basierend auf huha)


Introduction

For several reasons, the development of graphics chips is constrained by transistor budgets. Features are subject to priorities, some are important, some are less important. Chip complexity has been and always will be limited so that developers need to strike a balance between performance and functionality - which includes image quality.

ATI have traditionally cut corners in the texture filtering department. Take, for instance, R200 (Radeon 8500): on the one hand quite sophisticated - for its time - pixel shading, support for overbright lighting (and apparently increased internal color precision), on the other hand there are disadvantages when it comes to texture filtering, in particular when using anisotropic filtering ("AF").

We do not only refer to the AF being bilinear only, or its extreme dependence on surface angle, but also to obvious flaws with the determination of mip map lod: as far as we know ATI's lod calculations can sometimes lead to texture aliasing with AF enabled. As we have never done in-depth research on this we don't want to press this point. Instead, we'd like to focus on filtering issues with more current hardware: the R3x0 family.

ATI finally realized that trilinear AF does make, and they also reduced the dependency on surface angle. Yet there are still certain angles that get only a 2x AF treatment with 16x AF selected. Although it is old news with ATI, we'd like to point out - again - that activating 16x AF will yield not 16x AF but only 2x AF for certain angles. Does this truly deserve the name "anisotropic filtering"?

Yes, it does. Anisotropic means just that: not isotropic. The R300's AF isn't isotropic (at any surface angle). When looking for a more precise, binding definition of AF we came up empty, but: the quality to be expected from "textbook AF" is no secret. We will deal with the inner workings of anisotropic filtering in a future article. At this point, we just want to state how a "perfect AF" needs to look. It must look exactly like trilinear filtering (TF) but with the mip maps pushed "away" by one level for each doubling of the degree of anisotropy. But enough rambling, "perfect" AF is virtually not available on any current hardware.

The one laudable exception is 2x AF on the GeForce series, but 4x AF is already sligtly "optimized" (at 45° angles), which becomes more apparent at 8x AF (also at 45° angles). Kyro graphics cards are limited to 2x AF, but handle this mode with perfection. The formula for optimal AF is so complex that it is common to tweak it, deviations from "pure AF" are accepted for the savings in transistor budget.

Transistoren zu sparen, war wohl auch der Hintergedanke bei ATI. Die exakte Implementierung ist natürlich nicht öffentlich zugänglich, doch ist es wahrscheinlich, dass ATI sich um die (Transistor-intensive) Implementierung der Wurzelfunktion beim AF drückte. Lässt man jene weg, gelangt man zunächst zu einer Lösung, nur volle 90°-Winkel anisotrop filtern zu können (was die Winkelabhängigkeit bei R100 und R200 erklären dürfte). Mit einer Erweiterung, welche vergleichsweise wenig Transistoren beansprucht, kann man weiterhin die Wurzel-Berechnung sparen, gewinnt jedoch zusätzlich volle 45°-Winkel hinzu.

Saving transistors has apparently been ATI's goal, too. Implementation details are not available to the public, of course, but it is likely that ATI shied away from implementing the transistor consuming square root function required for AF. If you leave that out, the resulting circuit can only apply anisotropy at angles that are multiples of 90° (which handily explains the angle-dependency of R100 and R200). With a rather simple extension, still not implementing the square root circuitry, multiples of 45° become doable.

We arrived at this theory based on some of Demirug's ideas. Leaving theory aside for a moment, two things are for sure:
*ATI reduced the transistor count of the AF sampling point calculation
*Fillrate is saved because the full degree of anisotropy is only partially applied over the full circle


Die Passage in rot kann man IMO komplett streichen, auch im Original, weil sie lediglich - rhetorisch unfein - das wiederholt, was im unmittelbar davorstehenden Satz gesagt wurde.

Link einfügen nicht vergessen

Ich hab' ziemlich viel rumgewürfelt, bitte nicht hauen :)

[zeckensack]

Seite 1, ~zweite Hälfte (huha! huha! huha!)

This makes it is easy to assert ATI has the faster AF. For a long time, AF was more or less just a checklist feature with questionable implementation. GeForce series graphics cards were about the first which delivered "reasonable" AF but were limited to 2x. The GeForce 3 could do up to 8x AF which, however, wasn't exposed by marketing. Presumably it wasn't deemed beneficial to recommend this "make everything slow" feature. Properly investigating this feature early on, and judging it by quality instead of frame rate, like the majority at the time, was an achievement of 3DConcept founder Raphael auf der Maur (ram).

ATI's original Radeon (R100) hit the market earlier than the GeForce3 and could do 16x AF – albeit with limitations so severe that we don't think it's a useful "AF solution". The GeForce4 Ti's (NV25/NV28) bilinear AF performance is hampered, apparently because of transistor count considerations. And the GeForce FX (NV3x) can exchange AF quality for performance.
________________________

That isn't exactly our idea of progress. When balancing fill rate against quality, "textbook AF" is simply the optimum. Since NV20, NVIDIA implements a pretty nice calculation of AF sampling points anyway, so it's a real pity that "8x AF" is offered at performance levels of 4x AF but with overall quality that's worse than that. It's fair enough to call this mode "8x AF" because some pixels are treated this way, but, of course, we'd rather utilize a given mode to its fullest before activating a higher one. Maybe NVIDIA merely reacted to the pressure ATI put them under and wanted to show off high frame rates rather than making any given AF levels work as good as possible (as it should actually be expected out of a quality feature).

Before we jump in, we'd like to clear up a possible source of confusion up front: we don't take issue with ATI's 16x AF not filtering everything at 16x. 1x, 2x, 4x, 8x, and finally 16x filtering is selected dynamically, as required (NVIDIA's hardware performs the same dynamic selection). The selection process depends upon the angle of incidence of the surface in question. If the texture is distorted at a 1:2 ratio, 2x AF is enough. There aren't any tangible quality gains to be had beyond that. What's different at ATI is the extreme dependency on surface angle. A weaker form of this dependency can be observed on NVIDIA hardware, too, starting at 4x AF.

Unfortunately ATI went a bit further than the competition did with respect to texture filtering logic simplifications and, as a consequence, deviations from textbook quality.

Bitte klärt mich mal auf, ob er die Seite gegründet hat. Ansonsten ginge noch (von blah bis cool sortiert) "editor", "guru", "god", "senior vice president" :D ...

Dürfte den meisten bekannter vorkommen :)

[color=red]Dieser Teil ist IMO geradezu grauenhaft unklar, auch im Original. Da wird zwischen Verzerrung und Winkel gewechselt, ohne daß klare Worte fallen, was denn nun überhaupt gemeint ist.[/red]

[aths]

1. Rote Passage: Ist doppelt gemoppelt, aber mit Absicht. Durch die Wiederholung soll sicher gestellt werden, dass das nicht überlesen wird.

2. rote Passage: Bei "Verzerrungen" wird hier schwierig, da es nicht nur um das du:dv-Ratio geht, ich müsste hier mal fix die Transformation in den Texture Space erklären, dass man auf ein Parallelogramm vereinfacht und wo die Line of Anisotropy ist, und wie man dann den maximalen sinnvollen AF-Grad bestimmt.

Erst wird erklärt, dass bei einem bestimmten AF-Grad nicht immer der volle Grad appliziert werden muss, weil das nicht immer Sinn macht. Dann wird gesagt, dass ATI zusätzlich den AF-Grad nicht nur nach "Sinn machen" verringert (bzw. bis zum eingestellten Level erhöht) sondern noch winkelabhängig verringert. Es gibt ja immer noch zwei Missverständnisse:

- X° AF heißt, unbedingt immer X Samples zu nehmen.

- ATIs AF hingegen arbeitet adaptiv, im Gegensatz zu Nvidias, weshalb ATIs AF schneller sei. Dabei nutzt ATI offenbar nicht mal die mögliche Vereinfachung beim tri-AF, aus dem höheren MIP-Level nur die halbe Sample-Zahl zu nehmen.

[zeckensack]

Original geschrieben von aths
1. Rote Passage: Ist doppelt gemoppelt, aber mit Absicht. Durch die Wiederholung soll sicher gestellt werden, dass das nicht überlesen wird.Ich find's dennoch - sorry - rhetorisch unterste Schublade. Es steht direkt im Satz davor. Dadurch, dass das ein eigener Absatz ist, wird dem Wunsch nach Hervorhebung IMO Genüge getan.
2. rote Passage: Bei "Verzerrungen" wird hier schwierig, da es nicht nur um das du:dv-Ratio geht, ich müsste hier mal fix die Transformation in den Texture Space erklären, dass man auf ein Parallelogramm vereinfacht und wo die Line of Anisotropy ist, und wie man dann den maximalen sinnvollen AF-Grad bestimmt.Diese Anpassung an "Verzerrung" ist aber auch gleichzeitig eine Winkelabhängigkeit. Dabei geht's um die Neigung "nach innen". Das ist mir schon klar, und das ist richtig so, dass die Hersteller das adaptiv handhaben. ATI's Sünde ist nun die stark ausgeprägte Abhängigkeit von der Rotation um die Z-Achse.

Nur die Begrifflichkeit ist wirklich nicht eindeutig. Beides sind Winkel, und beides sind Verzerrungen. Du wählst dir die beiden Begriffe aus, um das zu trennen, aber die Trennung geht daraus einfach nicht hervor. Jemand der nicht vorher schon weiss worum es geht, wird IMO grosse Schwierigkeiten haben, diesen Absatz zu verstehen.


*seite2mach*

Btw, ich wollt's eigentlich schon längst fertig haben, nachdem ich aber heute morgen drei Stunden erfolglos versucht habe, den vBB-Code zu korrigieren (ich hab' mir zwischendurch Black Hawk Down reingezogen :|), hatte ich erstmal die Schnauze voll ;(

[zeckensack]

Seite 2, Teil 1(me ganz alleine, bitte um Lesung)

Base filter simplifications

A trilinear filter is a linear interpolation between two bilinear samples, requiring a weight between 0 and 1. ATI allocate five bits for this weight, which matches Direct3D's reference rasterizer (however, higher precision is allowed by Direct3D and in fact desirable). In OpenGL, SGI - who spearheaded the inception of this API - use eight bits. That's also the standard that's followed by, eg, Nvidia's GeForce range that implements the 8 bit linear interpolation weight for both OpenGL and Direct3D.

These three additional bits result in an eightfold increase in definition. Do we "need" that? In our opinion, at least six bits of "LOD fraction" are desirable to minimize banding artifacts. Five bits are okay for most cases, while four bits are definitely too few. Eight bits may be slightly overkill but then there's no disadvantage to precise texture filters. Anyway, textbook quality is eight bits, this guarantees zero banding and also constitutes SGI's recommendation for OpenGL.

"5 bit LOD fraction" issues are hard to demonstrate using screen shots, significantly harder than pointing out the issues with Nvidia's "brilinear" filtering. We still can't help wondering why it would be necessary to make savings in this area, while at the same time there's pixel shading hardware operating on 96 bits (4x 24 bits floating point), and 6x sparse, gamma corrected multisampling anti-aliasing. ATI apparently went for maximum savings in texture filtering logic. Even bilinear filtering fell victim to these "optimizations".

<hier kommt das erste Bild>

Künstlerische Freiheit. Das stand im Original nicht drin.

[zeckensack]

Seite 2, Teil 2 (me ganz alleine, bitte um Lesung)

We're not quite sure what causes these block artifacts. But we do know how a bilinear filter should look, and that the competition does offer texbook quality - as would be expected from any current graphics card. While we're at it, this "optimization" has been done since R200 at the latest.

Creating the bilinear sample requires knowledge of the exact sampling position for the filter kernel. Similar to the borderline acceptable lod fraction precision, ATI appear to have made some savings in this area. The sample coordinates' fraction bits are used to calculate a weighting matrix for the source texels. Maybe this calculation was subject to complexity reductions, involving lookups to skip some arithmetic.

These artifacts won't be seen with tiny textures, we can only speculate at this time about the reasons. We don't know where and how savings were made, we only know that they have been made. In short: current Radeon based cards can't deliver textbook quality bilinear filtering in certain circumstances. GeForce base cards don't have these issues.

This also applies to the weight matrix's quantization. While GeForce chips implement eight bits, ATI chips have to make do with six. More than eight bits wouldn't make much sense because the textures' and framebuffer's color channels are only eight bits wide. However, if even a single bit less is used, ie seven bits, the full color range of the frame buffer can't be used anymore. There would still be more than 2^7=128 gradients in total, but that doesn't help with pixel lines that sit exactly between two texels. To wrap it up: less than 8 bits of resolution lead to block artifacts under heavy zoom.

__________________________
Anmerkung: Warum so kompliziert? Wenn die Gewichte für die einzelnen Texel auch nur mit 5 (oder 6) Bit aufgelöst wären, wäre das schon eine zufriedenstellende Erklärung. Die Lookup-Positionen selbst sind (wie bereits diskutiert) sowieso auf dem Texel-Raster fixiert und unveränderlich. Es gibt keine halben Texel.

Häääääää?

[zeckensack]

<hier kommt das zweite Bild hin>

[zeckensack]

Seite 2, Teil 3 (me, Lesung erwünsch0rt)

This, too, is very hard to prove with "realistic" (ie in-game) screen shots. As long as there are higher resolution mip map levels to use, the bilinear filter will at most zoom a mip level to double size, obscuring these artifacts. To reveal them, a high contrast, high frequency texture must be heavily magnified.

So these issues are hard to spot, doesn't that make it alright? We don't think it's okay to go below textbook quality on bilinear filters. These are the foundation for eg function lookups used in pixel shading. The better the bilinear filter, the better the end result - pretty obvious. The most simple of all texture filters is bilinear. We'd expect it to be implemented without compromise.

Unfortunately ATI set their priorities a bit differently, as demonstrated by mip map LOD calculation:

<Bild #3>
____________________
Nicht korrekt: "Solange trilineare Filterung genutzt wird, wird intern maximal um den Faktor 2 bilinear gezoomt."
1)hat nichts mit trilinear zu tun (bilinear => same)
2)hat nur mit Vergrößerung oder nicht zu tun.
Vorschlag:
"Solange noch höher aufgelöste mip maps zur Verfügung stehen, wird intern maximal um den Faktor 2 bilinear gezoomt."
Wurde dementsprechend 'übersetzt'.

[zeckensack]

Seite 3, letzter Teil (...)

The GeForce card exhibits imperfections the size of a quad in this example (a quad is a 2x2 pixel block, and lod calculations are performed per quad, not per pixel). On the other hand the Radeon card produces a chaotic pattern, with wildly varying LOD. Apparently the LOD calculation was implemented with as few transistors as possible, sacrificing accuracy. GeForce cards aren't outright perfect either, we can produce situations where they, too, show "dithering" patterns. Still, the Radeon cards start doing it much earlier.

<Seite 2 zu Ende>

[zeckensack]

Seite 3, Teil 1 (ich, du lesen)

Save to the max

ATI hardware is very carefully designed. The cut corners in texture filtering we've been criticizing are hardly noticed in practice. It seem's to have been a basic design philosophy for R300 to offer only the precision that's needed. This is how we'd like to prove it:

ATI's pixel shading hardware is running at 24 bits of floating point (FP) precision, formally "s16e7" (ie sign, 16 bits for the normalized mantissa, 7 bits for a two-based exponent - we defer a discussion about what exactly that means to a later point in time). For purely color operations FP24 is in fact already "too much". Let's investigate.

Textures usually yield 8 bits of integer precision per color channel. That's exactly frame buffer precision. It's still desirable to use higher levels of precision for shader calculations, because they can involve many operations.

Nvidia's 16 bit floating point format is sufficient for a lot of cases but not for all: floating point is not per se better than fixed point, there are cases where a 16 bit fixed point format (FX16) is better than FP16. Thus NVidia will presumably offer FX16 on NV40. FP24's precision however is always as good or higher than the CineFX proprietary FX12, FX16 and of course FP16.

______________________________
Die gebräuchliche Dokumentation von FP-Formaten ordnet die Bezeichnung so an. Zb s10e5. Zuerst das s, dann die Mantissen-Bits (kein m), dann der Exponent.

[zeckensack]

Original geschrieben von zeckensack
Seite 3, letzter Teil (...)

The GeForce card exhibits imperfections the size of a quad in this example (a quad is a 2x2 pixel block, and lod calculations are performed per quad, not per pixel). On the other hand the Radeon card produces a chaotic pattern, with wildly varying LOD. Apparently the LOD calculation was implemented with as few transistors as possible, sacrificing accuracy. GeForce cards aren't outright perfect either, we can produce situations where they, too, show "dithering" patterns. Still, the Radeon cards start doing it much earlier.

<Seite 2 zu Ende>

Das sollte natürlich "Seite 2, letzter Teil (...)" lauten :)

[zeckensack]

Seite 3, Teil zwö :karate:
___________________________________
Alternative Einleitungen ("So weit, so gut.")
1)Ho hum.
2)Alrighty then.
3)*cough*
4)But we want more ... :o
5)So what?
6)Just when you think you've seen it all, there's freaking dependent reads coming down yo street, man!
___________________________________

So far, so good. Apart from color operations, there are also operations that modify sampling points, eg matrix multiplications (2D transformations) or dependent reads (for eg environment mapped bump mapping). This is the realm of texture coordinates, modified inside the shader. Texture coords usually lie in the [0...1] range, values outside of that range are however just as valid.

With a 16 bit mantissaw we get 2^16=65536 distinct values in the [0.5...1] range. Sounds like a lot of precision. With large textures, eg 2048x2048, that leaves us with 64 steps between two texels, ie 6 bits of "fraction". Isn't that enough?

It is - for isotropic filters. When using AF, this coordinate is a starting point for calculating more sampling positions. These calculations are most likely performed with FP32. We already learned that the bilinear filter (the fundamental building block for both trilinear and anisotropic filters) has been heavily "optimized", it's not as precise as it should be.

Because of AF's adaptive nature, many samples are generated from smaller resolution mip map levels, so precision issues are somewhat reduced. FP24 is adequate for coordinate calculations with the level of effects we expect from pixel shader 2.0, even though some pixel shader 1.1 texture operations are already performed with FP32 on the GeForce 3.

Unless there's heavy magnification involved, the block artifacts in ATI's bilinear filtering only show up as slight color skew and is hardly visible. AF still requires exact positioning of AF samples. As far as we know, the FP32 precision that's used for texture lookups doesn't quite produce the same quality as competing products.

__________________________
Künstlerische Freiheit: Jo! So wie's da steht.
Ä? War hier evtl FP24 gemeint?

[zeckensack]

Seite 3, Teil dry :flower:

It all fits together: there's only FP24 for operations on texture coordinates, yet there's no apparent disadvantage because of the simplifications in BF, TF and AF. This is how R300 offers unmatched performance, but doesn't deliver the best image quality. From an "ethics" point of view (whatever that means to ATI and NVidia) the competition can easily reduce image quality through drivers, to squeeze a bit of extra performance out of the chips and keep up.

Of course, hardware solutions must work in practice, and optimal texture filtering implementations come at a premium in transistors. It's not per se wrong to investigate this aspect for possible savings. As long as side effects are negligible. Even though ATI's isotropic filtering is mostly sufficient for gaming, we criticize their going below textbook quality (ie SGI's 8 bit). Isotropic filtering close to perfection is something we expect from any gaming hardware.

ATI, however, are agressive when it comes to savings: only 5 bits of LOD fraction, only 6 bits of resolution for filter weights. On top of that a rather peculiar LOD determination scheme that seems to lack a lot of precision in some situations.

When it comes to AF we're also skeptical of the extreme angle dependency: it's something we're used to with ATI, but this doesn't make it a valid solution going forward to have great pixel shading on the one hand, and on the other hand to be restricted to performance optimized filtering schemes with definite drawbacks in quality.

[zeckensack]

Seite 3, Tile phier :freak:

R300's texture filtering logic is an improvement upon R200's: BF block artifacts are still there, AF was an improvement over R200 but still won't match the competition's quality. The presumed LOD bug in R200's AF makes a comeback in R300, albeit in a slightly different form. With LOD biases greater than zero there's LOD clamping instead of biasing (ie the highest resolution mip map level is never used alone, which reduces maximum detail).

We believe it's a hardware issue, even though it can likely be worked around with drivers. Even though the LOD bias should always be exactly zero: R300's texture filtering does leave a lot of room for improvement, both for isotropic and anisotropic modes.

This is somewhat disappointing: whatever area of R300 we were poking at, we've always found something that could have been done better, as demonstrated by the competition's textbook quality. It's likely that there are even more filtering simplifications on the Radeon, that we simply haven't found yet.

We'll make filtering quality an important part of our testing methods for future hardware, regardless of vendor. Frame rate is only one partt of the equation, a fair benchmark should always consider image quality as well. Texture filtering is the foundation of all 3D realtime rendering, regardless of whether you use a multitexture pipeline or pixel shaders. Optimum filtering quality isn't an added bonus, it's a requirement.



Thanks go out to Demirug, whose ideas were invaluable to our investigation on filter quality, to Xmas for hints, corrections and screen shots, to Argo Zero and Axel for screen shots, and also to Ailuros, who unintentionally got the ball rolling :-)


<Ende>
:laola:

[Leonidas]

War es das, soll ich HTMLisieren?

[aths]

Ich geb noch einige Anmerkungen. Mom.

[zeckensack]

Leo,
Original geschrieben von zeckensack
Seite 3, Teil zwö :karate:

<...>

With a 16 bit mantissaw we get 2^16=65536 distinct values in the [0.5...1] range. Sounds like a lot of precision. With large textures, eg 2048x2048, that leaves us with 64 steps between two texels, ie 6 bits of "fraction". Isn't that enough?Muss natürlich "mantissa" heissen, ohne w :)

Ansonsten von der Übersetzung her fertig - die 'umstrittenen' Teile stehen bis auf eine Ausnahme (in blau) alle sinngemäß so drin, wie im Original.

Fehler sind sicher noch drin, aber ich sehe sie nicht ;( :)

[aths]

Original geschrieben von zeckensack
Ä? War hier evtl FP24 gemeint? Xmas meint, ATI sagt dass Textur-Zugriffe letztlich mit FP32 gemacht würden. Die du/dv-Rechnungen etc. würden ja tatsächlich FP32 brauchen.

[aths]

Zur Texelsache: Beim 6-Bit-LERP von 0 .. 1 (0x00 - 0xFF) hat man 64 Stufen. Aber diese 64 Stufen stellen nicht die ganze Menge dar, die man haben kann. Bei 0.4 .. 0.6 mit einem 6 Bit LERP kommen auch Farben raus, wo die beiden LS-Bits eine Rolle spielen.

[zeckensack]

Original geschrieben von aths
Xmas meint, ATI sagt dass Textur-Zugriffe letztlich mit FP32 gemacht würden. Die du/dv-Rechnungen etc. würden ja tatsächlich FP32 brauchen. Ja. Du schreibst dann, dass die Konkurrenz das noch besser macht, was ja bedeuten würde, dass mehr als FP32 zum Einsatz kommt. Das hat mich gewundert, weil ich FP32 bisher für die höchste in (Grafik-)Hardware gegossene Auflösung gehalten habe ?(

[aths]

Die Konkurrenz nutzt FP32, aber "optimiert" nicht am BF/TF rum, und rechnet wohl auch im Shader die Koordinaten mit FP32. Für AF wird ATI in jedem Fall FP32 brauchen, die müssen auch FP32-Logik haben, aber die Samples gehen dann halt von expandierten FP24 aus (wie auch sonst) und bei BF/TF werden fürs LERP weniger als 8 Bit genommen, so dass ATI aus den FP32, die irgendwo ja noch vorkommen, weniger macht, als die Konkurrenz.

[aths]

Ich hasse es, nicht editieren zu können. Aus meinem Posting wird doch sicher kein Mensch schlau http://www.aths.net/files/smilies/devil.gif

[Leonidas]

Hab es erstmal online gestellt:
http://www.3dcenter.org/artikel/2003/11-21_a.php

[Gast]

hab ein paar fehler in der engl. übersetzung gefunden, die ich eigentlich schon im ht4u-thread gepostet habe (ist anscheinend aber übersehen worden):


seite 1

4. absatz unter dem bild:
ATI finally realized that trilinear AF does make [sense],...

der komplette siebte absatz ist in deutsch!!!
(ist die übersetzung des achten)


seite 2

hier ist die überschrift: "ATIs Filtertricks" nicht auf "ATI's filtering tricks" geändert worden.

ein hinweis darauf dass die bilder mit mouseover wechseln wäre nicht schlecht (auch in der deutschen fassung), ich bin da jetzt nur durch zufall draufgestossen.

4. absatz:
and that the competition does offer textbook quality

6. absatz:
GeForce based cards don't have these issues.

7. absatz:
However, if even [besser: only?] a single bit less is used, ...


seite 3

6. absatz:
With a 16 bit mantissaw we get...

letzter absatz:
Frame rate is only one partt of the equation, ...


ausserdem steht auf allen seiten oft "eg" und "ie" - vielleicht wärs besser "e.g." und "i.e." zu schreiben (auf deutsch schreiben wir ja auch z.B. und nicht zB).

ansonsten ne recht gelungene übersetzung.

[zeckensack]

Gast,
ich zumindest hatte dich auf HT4U nicht übersehen. Vielen Dank nochmal :wink:


Zu deinem Punkt 7:
ich würde es bei "even" belassen. Vgl "nur" und "sogar". Das englische "only" ist meinem Empfinden nach zu restriktiv, und bringt den Sinn nicht genug heraus ("ein Bit weniger reicht bereits aus, um <...>"; wurde hier umgeformt zu "sogar wenn man [nur] ein einziges Bit weniger nimmt" - "nur" ist bereits implizit in "single" enthalten).

Die Konstruktion ist IMO 'besser' :)

Alles andere sind natürlich echte Fehler, vielen Dank für's aufmerksame Lesen und Finden :massa:

[aths]

Vielen Dank an zecki für diese hervorragende Übersetzung!!! Da macht das Lesen ja schon alleine aufgrund des guten Englisch Spaß — Hut ab!

[Leonidas]

Thx @ all.

[Gast]

Original geschrieben von zeckensack
ich würde es bei "even" belassen. Vgl "nur" und "sogar". Das englische "only" ist meinem Empfinden nach zu restriktiv, und bringt den Sinn nicht genug heraus ("ein Bit weniger reicht bereits aus, um <...>"; wurde hier umgeformt zu "sogar wenn man [nur] ein einziges Bit weniger nimmt" - "nur" ist bereits implizit in "single" enthalten).

Die Konstruktion ist IMO 'besser' :)
hmm.. ok so kann man das auch sehen..
aber ich hab 'even' noch nie in so einem zusammenhang auf englisch gelesen. kommt mir irgendwie etwas.. hmm.. konstruiert vor.
vielleicht denk ich aber auch einfach nur etwas zu 'deutsch' :)


wegen der artikel-überschrift nochmal:
wie quasar hier auf b3d (http://www.beyond3d.com/forum/viewtopic.php?t=9213&postdays=0&postorder=asc&start=80) schon anmerkte hat "tricks" auf englisch einen etwas negativen beigeschmack, der so direkt in deutsch nicht existiert. vielleicht wärs besser das auf "optimizations" oder etwas ähnliches abzuändern. das hat zwar seit dem FM/NV-debakel auch nen negativen beigeschmack, ist aber imho immer noch objektiver als "tricks".

[Gast]

hmm.. werden die fehler auch irgendwann nochmal ausgebessert?
der deutsche absatz wirkt doch ein wenig unprofessionell, besonders wo jetzt doch schon einige grosse seiten (nvnews, etc.) auf den artikel verlinken.

ich mein, bei den sonstigen artikeln und den news geht das doch auch immer ziemlich fix?

[Leonidas]

Sorry, hab den deutschen Absatz einfach übersehen.


Deine Änderungen sind aber schon drin - abzüglich Zecki´s Re-Korrektur.

[Gast]

ok, habs gesehen, thx.

ein paar sachen sind aber noch nicht ausgebessert worden (um mich mal selbst zu quoten =) ):

Original geschrieben von Gast
seite 1

4. absatz unter dem bild:
ATI finally realized that trilinear AF does make [sense],...


seite 2

hier ist die überschrift: "ATIs Filtertricks" nicht auf "ATI's filtering tricks" geändert worden.

4. absatz:
..., and that the competition does offer textbook quality - ...


ausserdem steht auf seite 2 & 3 oft "eg" und "ie" - vielleicht wärs besser "e.g." und "i.e." zu schreiben (auf deutsch schreiben wir ja auch z.B. und nicht zB).

[Leonidas]

Nun aber: Alles gefixt. Aber ohne ie und eg, den Zbag-Stil behalte ich erstmal.