Radeon X800 und die Texturen: Wieviel Optimierung verträgt der Mensch?
2/4Der intelligente Algorithmus
Während man über PR-Statements geteilter Meinung sein kann, so steht doch eines ziemlich fest: sie sind zumeist so formuliert, dass konkrete Aussagen Mangelware sind. So mussten wir auch in diesem Falle feststellen, dass ATi sich mit der abschließenden Bemerkung gekonnt absicherte, die dem (den Optimierungen zugrunde liegenden) Algorithmus bescheinigte, weitgehend fehlerfrei zu arbeiten, aber man sich über Fehlerberichte, wo der Algorithmus dennoch versage, freuen würde und diese dann umgehend beheben wolle.
Unter genau diese Prämisse möchten wir das nun folgende verstanden wissen, nämlich, dass einerseits Marketing- und PR-Aussagen niemals eine objektive Wahrheit widerspiegeln, sondern sich per Definition immer Hintertürchen offenlassen und andererseits, dass ATi explizit einräumt, dass die verwendete Analysemethode noch Fehler enthalten kann.
Nun, wie es aussieht, haben wir ein paar dieser Fehler gefunden - doch der Reihe nach.
ATi behauptet, ihre intelligente Optimierung würde nur angewandt bei typischen Fällen, in denen Mipmaps durch den Boxfilter erstellt würden. Dieser Filter ist derjenige, der aufgrund seiner guten optischen Ergebnisse bei vergleichsweise geringem Aufwand typischerweise für das automatische Erzeugen von MipMaps benutzt wird und praktischerweise auch in der Texture-Load-Funktion von DirectX der Default-Filter ist. Dieser Filter verkleinert die Basistextur zum Mip-Level 1 dadurch, dass er jeweils ein Quadrat von 2x2 Pixeln der Ausgangstextur oder Mip0 mit jeweils 25% Gewichtung zu einem Pixel der Mip1 zusammenrechnet, aus dieser dann vier Pixel zu einem Pixel der Mip2 usw.
Auf der anderen Seite würde der Filter nicht angewandt, wenn der Algorithmus atypische Situationen erkennt, bei denen starke Differenzen zwischen den einzelnen Mip-Levels zu erwarten wären. Dies soll natürlich Artefakte und optische Auffälligkeiten, die durch optimierte, trilineare Filterung entstehen, verhindern.
Ein eindeutiger Fall - der Farbunterschied, wenn man bei schwarz und weiß denn von Farben sprechen will, zwischen Ausgangstextur und erstem Mip-Level ist zu groß. Hier muss richtige, trilineare Filterung mit acht Textursamples pro Pixel her. Dasselbe passiert auch mit grün oder blau eingefärbtem Bereich.
Interessant wird es jedoch, wenn wir zur gleichen schwarzen Ausgangstextur wahlweise folgende erste Mip-Stufen hinzugesellen.
Obwohl optisch zwischen dem rechten Mip-Level aus dieser Reihe und dem mittleren Mip-Level 1 aus der mittleren Bildreihe (der mit den 32 reinweißen Zeilen) kein Unterschied auszumachen sein dürfte, entscheidet hier der Algorithmus in den Catalyst-Treibern, dass hier offenbar keine Notwendigkeit mehr besteht, trilinear zu filtern und wendet knallhart die mittlerweile bekannte Optimierung an.
Unsere Tests haben gezeigt, dass der Treiber offenbar eine relativ einfache Prüfsumme über die Mip-Level erstellt und erst 32 Zeilen (bis mindestens Mip-Level 5) mit einem Kontrastwert von 255 auf einem der Farbkanäle Rot, Grün oder Blau ausreichen, um den Übergang als würdig einzustufen, in den Genuss der maximal möglichen, trilinearen Texturfilterung zu kommen.
Die Gesamtsummen der nötigen Kontrastdifferenzen, die auf mindestens einem der Farbkanäle erreicht werden muss, haben wir in folgender Tabelle, die nur für explizit schwarze Basistexturen getestet ist, zusammengefasst.
| Mip-Stufe | Bit-Differenz der Summenwerte be- nachbarter MipMaps |
|---|---|
| Basistextur | 16711680 |
| Mip-Level 1 | 4177920 |
| Mip-Level 2 | 2088960 |
| Mip-Level 3 | 1044480 |
| Mip-Level 4 | 522240 |
| Mip-Level 5 | 261120 |
| Mip-Level 6 | 130560 |
| Mip-Level 7 | 65280 |
| Mip-Level 8 | 32640 |
| Mip-Level 9 | 16320 |
(Die Kontrastwerte können beliebig auf den gesamten Mip-Level verteilt sein)
Bereits ab Mip-Level 5, bei dem die Kontrastschwelle genau den maximal möglichen Wert umfasst, also beispielsweise einen Schwarz-Weiß-Kontrast kann keine Änderung des Texturinhaltes von einer MipMap zu nächsten mehr dafür sorgen, dass der Algorithmus nicht die Filterung optimiert.
Im Extremfall würde der Algorithmus also die beiden folgenden Bilder als nicht unterschiedlich genug ansehen, um auf volle, trilineare Filterung im Rahmen der Möglichkeiten des Chips zu schalten.
Das rechte Bild sieht natürlich rein weiß aus, ist aber mit einem minimal andersfarbigen Pixel mit einem RGB-Wert von 254-254-254 angereichert, der sich leicht zum Beispiel mit dem Füllwerkzeug von Windows-Paint finden lässt.
Auch folgende Textur samt ihrer MipMaps, die nicht mit dem DirectX-Standardverfahren und 2x2-Box-Filter erzeugt wurden, müssen laut dem aktuellen Stand der Erkennungsroutine nicht maximal gefiltert werden, die damit ATis offiziellem Statement „It [Der Algorithmus, Anm. d. Verfassers] only applies this optimization to the typical case - specifically, where the mipmaps are generated using box filtering. Atypical situations, where each mipmap could differ significantly from the previous level, receive no optimizations.“ gleich in zweifacher Hinsicht widerspricht.
Keine Anwendung findet der Algorithmus, wenn man Texturen nach dem ersten Rendern noch einmal verändert oder auch nur mittels einem Lock/Unlock den Anschein erweckt. Hier geht die Optimierungsroutine übervorsichtig vor, denn nachträgliche Veränderungen an Texturen versucht man aus Performancegründen eigentlich weitestgehend zu vermeiden und für sich ständig ändernde Texturen gibt es noch spezielle dynamische Texturen, die laut ATi sowieso mit der maximal möglichen Trilinearität gefiltert werden.
Uns sind zum Beispiel die beiden AF-Tester von Demirug und XMas bekannt, die ihre Texturen nach dem Rendern noch einmal verändern und zwar nur, um sie einzufärben...