Was bringt ein Pixelshader 3.0 Chip heute?

31. März 2004 / von Demirug / Seite 1 von 2

  Click here for an english version of this article

Im Gegensatz zu nVidia hat sich ATi bei ihrem neuen Flaggschiff, dem R420 dazu entschlossen, auf eine Pixelshader 3.0 Unterstützung zu verzichten. Die Auswirkungen dieser Entscheidung sind natürlich nur begrenzt vorhersagbar. Da es bis zur offiziellen Vorstellung der beiden Kontrahenten noch etwas dauern wird, wollen wir mittels eines kleinen Gedankenspiels zu den Auswirkungen der technischen (nicht featuremäßigen) Unterschiede zwischen Pixelshader 2.0 und 3.0 die Zeit bis zu den Launches etwas überbrücken.

Wie bei jedem Gedankenspiel kann es am Ende natürlich anders kommen, als man vorher dachte. Daher sollte man auf keinen Fall blind aufgrund solcher technischer Analysen Kaufentscheidungen treffen, diese können bestenfalls als Ergänzung zu mit vorhandener Hardware durchgeführten Tests dienen.

Bei jeder neuen Technik erfolgt in der Regel nach dem Abflauen der Begeisterung, welche Technologiedemos hervorrufen, die Ernüchterung. Dies passiert maßgeblich, weil sich die praktische Erkenntnis einstellt, daß den zum Launch gezeigten Technikdemos noch lange Zeit keine Spiele mit derselben Technik folgen werden. Am Ende bleibt dann von der neuen Karte (fast) nur die höhere Grundleistung zur Nutzung aktueller oder kurze Zeit später erscheinender Titel übrig.

Ausgerüstet mit dieser Erkenntnis aus der Vergangenheit kann man leicht zu dem Schluss kommen, dass es der neuen Pixelshader 3.0 Technologie nicht anders ergehen wird. Der letzte Versuch von ATi, mit Pixelshader 1.4 eine technologische Vorreiterrolle einzunehmen, war nicht unbedingt ein großer Erfolg. So ist die Entscheidung von ATi auch verständlich, beim R420-Chip auf die Pixelshader 3.0 Technologie zu verzichten. Und wenn eine neue Technik erst langfristig zum realen Einsatz kommen wird, ist es auf jeden Fall richtig, nicht unbedacht für jede Neuerung sein Geld auszugeben.

Wie bei jeder neuen Technik ist aber auch die Frage nach den mittel- oder gar kurzfristigen Vorteilen interessant. Bei den Pixelshadern 3.0 ergibt sich hier nun eine etwas ungewohnte Situation: Die Fähigkeit, welche die Hardware zum Erreichen von Pixelshader 3.0 Kompatibilität braucht, kann zur Beschleunigung von Techniken eingesetzt werden, welche zurück bis zu DirectX7 reichen. Hierbei spielt dann natürlich der Treiber eine große Rolle, der diese älteren Techniken (bzw. den Spiel-Code, welcher damit geschrieben wurde) für die optimalen Ausnutzung der neuen Möglichkeiten anpassen muss.

Der Schlüssel zu dieser Beschleunigung ist die Fähigkeit des "dynamischen Verzweigens". Bisher war es immer so, dass für alle Pixel, die zum gleichen Polygon gehören, auch die gleichen Arbeitsschritte ausgeführt wurden. Pixelshader 3.0 Hardware erlaubt es nun aber, dass für jeden Pixel situationsabhängig andere Anweisungen ausgeführt werden können. Dabei kann dann natürlich auch die Anzahl der Schritte pro Pixel unterschiedlich sein. Die berechtigte Frage ist nun natürlich, wie eine solche Fähigkeit die Berechnung von Pixeleffekten beschleunigen soll, welche ohne die Berücksichtigung eben dieser Fähigkeit entwickelt wurden.

Der Grund hierfür ist einfach: Es gab schon früher Situationen, in denen eine solche Fähigkeit nützlich gewesen wäre. Da sie aber nicht zur Verfügung stand, musste man sich mit einem Trick helfen. Man berechnete einfach für alle Möglichkeiten das Ergebnis und wählte dann für jeden Pixel das richtige aus. Erkennt ein Treiber einen solchen (im Spiel-Code liegenden) Trick, kann er die Pixelberechnung so verändern, dass für jeden Pixel nur noch diese Möglichkeit berechnet wird, welche am Ende auch für diesen Pixel gewählt wird. Die Rechentakte, welche zur Berechung der nicht genutzten Alternativen verwendet würden, hätte man dann gespart. Die folgenden Beispiele sollen diese Vorgehensweise verdeutlichen.

  •  Alpha-Test Beschleunigung:

Der Alpha-Test ist ein altes Mittel, um die Ausgabe eines Pixels in den Bildspeicher zu unterdrücken. Erfüllt der Alphawert eines Pixel eine einstellbare Bedingung nicht, wird er verworfen. Benutzt wird diese Technik zum Beispiel zur Darstellung von feinen Strukturen wie Zäunen. Hardware ohne "dynamisches Verzweigen" ist hier immer gezwungen, den Pixel vor dem Test komplett zu berechnen.

Pixelshader 3.0 Hardware könnte nun aber, wenn der endgültige Alphawert vorliegt, den Test vorziehen. Ist das Ergebnis negativ, kann die weitere Berechnung sofort abgebrochen werden, da die Pixelfarbe ja sowieso nicht mehr gebraucht wird. Das ganze ist natürlich nur dann sinnvoll, wenn die Berechnung der Pixelfarbe mehr Takte als die Berechnung des Alphawerts benötigt. Ein Beispiel hierfür wäre die Kombination aus Bumpmapping und Alphatest. Im Falle eines negativen Tests des zuerst eingelesenen Alphawerts könnte das Auslesen und Verrechnen der Bumpmap komplett gespart werden.

  •  Alpha-Blending Beschleunigung:

Das Alpha Blending ist mit dem Alphatest verwandt. Im Gegensatz zum Alphatest gibt es hier aber nicht nur sein oder nicht sein, sondern auch Zwischenstufen. Bei diesen wird der neue Pixelwert mit dem bereits im Bildspeicher vorhandenen verrechnet. Abhängig von der verwendeten Verrechnungsfunktion gibt es auch hier Alphawerte, welche dazu führen, daß der neue Pixelwert keine Bedeutung für das enggültige Bild hat. Für diese Fälle ist die gleiche Optimierung wie beim Alphatest möglich.

Der Alphatest sowie das Alphablending sind sehr alte Techniken, die schon lange vor der Einführung der Shadertechnologie mit DirectX8 möglich waren. Aus diesem Grund können diese Optimierungen selbst bei Spielen, die noch gar keine Shader benutzen, eingesetzt werden.

  •  "Texkill" – Der Pixelkiller

Mit den DirectX8 Shadern wurde auch eine neue Möglichkeit, Pixel zu "töten", ins Leben gerufen. Der Shaderbefehl Texkill erlaubt es, das Schreiben von einzelnen Pixel in den Bildspeicher zu unterdrücken, wenn eine bestimmte Bedingung erfüllt ist. Auch hier wird wie schon beim Alphatest die Berechnung weitergeführt, obwohl schon feststeht, daß der Chip das Ergebnis nicht mehr benötigt.

Hier wäre nun ebenfalls eine gute Möglichkeit, das "dynamische Verzweigen" zum Einsatz zu bringen. Sofern die Bedingung erfüllt ist, können alle Berechnungen, die nach einer Texkill-Anweisung folgen, übersprungen werden. Zusätzlich kann der Treiber noch versuchen, das Shaderprogramm so umzusortieren, dass die Texkill-Anweisung möglichst nahe am Anfang liegt. Der Leistungsgewinn dieser Methode hängt dabei von zwei Faktoren ab:

• 1. Der Anteil der Pixel, die verworfen werden.
• 2. Die Anzahl der Operationen, welche pro Pixel gespart werden.

Das folgenden Diagramm zeigt beispielhaft für einigen Shader das Einsparpotenzial. Auf der vertikalen Achse wurde die relative Geschwindigkeit eingetragen. Dabei entspricht 100 Prozent der Geschwindigkeit einer nicht Pixelshader 3.0 fähigen Hardware. Auf der horizontalen Achse ist der Anteil an Pixeln, die verworfen werden, zu sehen. Für jeden Shader gibt es zwei Zahlenangaben: Die erste gibt die Länge des Shaders an. Die zweite entspricht der Menge von Anweisungen, die mindestens ausgeführt werden muss, bis feststeht, ob der Pixel verworfen werden kann. 08:01 entspricht daher einem Shader mit 8 Anweisungen, welcher nach der ersten Anweisung entscheidet, ob der Pixel gezeichnet wird.

Die Grafik zeigt natürlich nur die Leistungseinsparung (von Pixelshader Rohleistung) für Pixeln an, deren Shaderprogramm eine Texkill-Anweisung enthält. Die Anzahl der davon betroffenen Pixel kann jedoch von Anwendung zu Anwendung stark schwanken. Bei Spielen mit hoher Zahl von "Texkill-Pixel" können sich durch die Möglichkeit des dynamischen Verzweigens bei Pixelshader 3.0 Hardware gute Einsparungspotentiale ergeben.