ATIs Filtertricks

21. November 2003 / von aths / Seite 3 von 3

  Click here for an english version of this article

   Sparen, wo immer möglich

ATIs Hardware ist von vorne bis hinten durchdacht. Die von uns kritisierten Vereinfachungen der "Grundfilter" fallen in der Praxis kaum auf. Nur das an Genauigkeit zu liefern, was eben dafür notwendig ist, hat beim R300 allerdings durchgehend Methode. Und dies wollen wir nachfolgend beweisen:

ATIs Pixelshader-Hardware rechnet durchgehend mit 24 Bit Floating Point (FP), konkret im Format "s16e7" (also Vorzeichen, 16 Bit normalisierte Mantisse, 7 Bit Exponent zur Basis 2 - wir werden uns zu einem gegebenen Zeitpunkt dem Floating Point Format ausführlich widmen und diese Komponten erläutern).

Gängige Texturen liefern 8 Bit Integer-Genauigkeit pro Farbkanal. Exakt diese Genauigkeit ist auch für den Framebuffer vorgesehen. Doch da innerhalb eines Shaders mehrere mathematische Verknüpfungen stattfinden, ist es sinnvoll, für die Zeit der Berechnung eine feinere Farbabstufung, als mit 8 Bit Integer möglich.

Nvidias 16 Bit Floating Point wäre oftmals ausreichend, doch wo Licht ist, ist auch Schatten: Die Vorteile des Floating Point Formates werden mit bestimmten Nachteilen erkauft, so dass in vielen Fällen ein 16 Bit Fixpoint Format (FX) besser wäre. Vermutlich wird Nvidia im NV40 deshalb FX16 anbieten. (Update: Wie sich nun herausstellte, setzt NV40 für DirectX-Multitexturing und Pixelshader 1.x weiterhin auf das FX12-Format.) FP24 ist jedoch auf jeden Fall genau genug, so dass garantiert besser als mit dem CineFX-proprietären FX12 gerechnet wird, ebenso besser als mit FX16 und natürlich erst recht besser als mit FP16.

Soweit, so gut. Neben Farbverknüpfungen gibt es auch Anweisungen, um die eigentliche Sampling-Koordinate noch zu verändern, bevor sie gesampelt wird, beispielsweise mit einer Matrix-Multiplikation (also einer 2D-Transformation) oder per Dependend Read (wichtig für Enviromental Bumpmapping). Man hantiert dann mit Textur-Koordinaten herum, die im Shader modifiziert werden. Textur-Koordinaten werden üblicherweise im Bereich von 0,0 - 1,0 angegeben, in bestimmten Fällen sind auch Werte >1,0 möglich.

Bei 16 Bit Mantisse gibt es somit 2^16 = 65536 unterschiedliche Stufen für den Bereich von 0,5 - 1,0. Das klingt erst einmal nach sehr viel. Bei großen Texturen, zum Beispiel 2048er Texturen, bleiben dann im Texel noch 64 Abstufungen, das entspricht einer "Nachkomma-Auflösung" von 6 Bits. Ist das gut genug?

Das ist ausreichend - für isotrope Filterung jedenfalls. Kommt AF ins Spiel, werden von dieser Koordinate ausgehend weitere Sample-Koordinaten berechnet. Diese Berechnungen werden wahrscheinlich aber mit FP32 ausgeführt. Nun wissen wir inzwischen, dass das bilineare Filtering (worauf sowohl trilineares als auch anisotropes Filtering aufbauen) bei ATI seltsam "optimiert" wird, es ist weniger genau, als es sein sollte.

Da winkelabhängig oftmals ein kleinerer AF-Grad appliziert wird, als eigentlich eingestellt, sampelt man hierfür ja aus einer geringer aufgelösten MIP-Map, so dass mögliche Genauigkeitsprobleme bei sehr großen Texturen entsprechend weniger oft auftreten. Für Effekte mit einer Komplexität, die einem Pixel Shader 2.0 angemessen sind, ist FP24 für Koordinaten-Berechnungen durchaus vertretbar, wenn auch bereits die GeForce3 bestimmte Pixel Shader 1.1 Texture Ops mit FP32 berechnet.

Die Block-Artefakte, die ATIs bilinearer Filter zeigt, äußern sich bei weniger starker Vergrößerung "nur" im minimalen Versatz der gesampelten Farben, was zunächst kaum wahrnehmbar ist. Jedoch bleibt es für das AF wichtig, die AF-Samples möglichst genau positionieren zu können. Doch die FP32-Genauigkeit für Textur-Zugriffe resultiert nach dem Stand unseres Wissens nicht in der Qualität, die andere anbieten.

Es ist also alles verknüpft: Nur FP24 für das Verrechnen von Textur-Koordinaten, doch die Nachteile fallen wegen den Vereinfachungen beim BF, TF und AF praktisch nicht auf. Die R300-basierende Radeon-Reihe ist damit zwar konkurrenzlos schnell, liefert jedoch nicht die beste Bildqualität. Die Konkurrenz hat es aus "moralischer" Sicht (bzw. was ATI und Nvidia darunter verstehen) dementsprechend leicht, treiberseitig die Bildqualität zu senken, um ein paar Frames zu schinden und so zu versuchen, leistungsmäßig den Anschluss zu halten.

Eine Hardware-Lösung muss natürlich praxisgerecht sein, optimale Textur-Filter ziehen einen hohen Transistor-Count mit sich. Es ist somit sicher nicht per se falsch, zu überlegen, hier etwas zu sparen. Jedenfalls, sofern die Nachteile vernachlässigbar sind. Obwohl ATIs isotrope Filter in der Spiele-Praxis meist ausreichen, kritisieren wir die fehlende Lehrbuch-Qualität (worunter wir die 8 Bit von SGI sehen). Den Anspruch, isotrope Texturfilterung in Quasi-Perfektion zu bieten, stellen wir nun einmal an jede Gamer-Hardware.

ATI spart jedoch, wo es geht: Beim trilinearer Filterung nur 5 Bit LOD-Fraction, bei bilinearer Filterung nur 6 Bit Auflösung bei der Umwandlung der Sampleposition-Nachkommastelle in die Texel-Gewichtungs-Faktoren. Dazu eine recht seltsame LOD-Berechnung, welche je nach Situtation über größere Bereiche uneinsichtig ungenau arbeitet.

Beim AF kritisieren wir zudem die extreme Winkelabhängigkeit: Zwar sind wir da von ATI nichts anderes gewohnt, doch kann es ja kein Dauerzustand sein, auf der einen Seite tolle Pixel Shader zu haben, auf der anderen Seite jedoch eine Beschränkung auf performance-optimierte Filtertechnik unter Inkaufnahme echter Qualitätsnachteile auferlegt zu bekommen.

Die Textur-Filter des R300 sind überarbeitete R200-Filter: Beim BF blieben die Block-Artefakte leider erhalten, AF wurde aufbauend auf dem R200-AF verbessert, kann aber mit der Qualität der Konkurrenz weiterhin nicht mithalten. Der bereits angesprochene mutmaßliche LOD-Bug im R200-AF feiert im R300 in veränderter Form seine Wiederkehr. Zumindest mit einem LOD-Bias größer Null findet nämlich LOD-Clamping statt LOD-Biasing statt (was heißt, dass nie alleine die hochaufgelöste Basis-Textur verwendet wird, so dass die sonst maximal mögliche Schärfe nicht erreicht wird).

Den Fehler vermuten wir in der Hardware, auch wenn er wahrscheinlich treiberseitig umgangen werden kann, und auch wenn man eigentlich immer mit einem LOD-Bias von exakt 0,0 arbeiten sollte: Bei den R300-Texturfilter bleibt im erheblichem Maße Verbesserungspotenzial, das gilt durch die Bank für iso- und anisotrope Techniken.

Es bleibt somit ein unguter Nachgeschmack: Wo wir auch bei ATI stocherten, immer haben wir etwas gefunden, und immer zeigt die Konkurrenz, dass eine bessere Filterung in Lehrbuchqualität machbar ist. Vermutlich gibt es noch weitere, bislang unentdeckte Simplifizierungen in den implementierten Radeon-Texturfiltern, welche uns bislang durch die Lappen gingen.

Zukünftige Hardware, egal von welchem Hersteller, werden wir verstärkt auch von der Filter-Qualität her beurteilen. Die Framerate ist nur eine Seite der Medallie, gerechterweise müsste in das Benchmark-Ergebnis auch die Bildqualität einfließen. Da 3D-Echtzeitrendering sowohl mit einer Multitexturing-Pipeline als auch mit Pixel Shadern massiv auf Texturen zurückgreift, ist eine möglichst optimale Textur-Filterung für uns nicht nur eine Kür, sondern Pflicht.

Dank geht an Demirug, dessen Überlegungen den Anstoss zur Kontrolle der Filterqualität gaben, an Xmas für Hinweise und Berichtigungen sowie Screenshots, an Argo Zero und Axel für Screenshots, sowie ebenso an Ailuros, der unbeabsichtigt unsere "Forschungen" angestoßen hat :-).