Demirug
2003-08-25, 17:50:59
Ich weiss das ich euch mal wieder mit alten Dingen auf die nerven gehen die kein mensch mehr interesieren. Aber da ich heute ansonsten nur stinklangweilige arbeiten zu erledigen hatte (typisch montag) müsst ihr da jetzt durch. (oder auch nicht man kann ja noch schnell abhauen)
Mir geht hier jetzt nicht um primär die Performance. Darüber wurde ja schon viel geschrieben. Es ist viel eher ein Vergleich der Hardwareimplementierungen. Aufbauen auf Informationen aus unterschiedlichen mehr oder minder öffentlichen Quellen.
Ein DX8 Pixelshader unterscheidet primär zwischen Textur und Arithemetik Operationen und so besteht ein Shaderprogramm auch immer aus Blöcken dieser beiden Anweisungstypen. Bei den PS <= 1.3 gibt es einen Textur und einen Arithmetikblock. Die 1.4 Shader erlauben jeweils 2 Blöcke von jedem Type. Die DX Pixelshader stelle nun ja nur ein virtuelles Model dar. Die echte Hardware mag nun stark davon abweichen und tut dies auch durchaus.
NV2X:
nVidia benutzt für die Texturoperationen und die Arithmetikanweisungen zwei getrennte Einheiten im Chip.
Die Textureoperationen werden von den "Texture-Shader" genannten Einheiten durchgeführt. Dabei handelt es sich um eine FPU mit einem relative begrenzten festen Befehlsvorrat. Diese FPU kann pro Takt bis zu zwei Texturesamples pro Pixel in Auftrag geben. Als Eingangsregister stehen die vom Vertexshader gelieferten texturekoordinaten zur Verfügung. Als Ausgang stehen dieser Einheit 4 RGBA Register zur Verfügung. Gefüllt werden diese 4 Register durch ein entsprechendes Programm welches die FPU im Loopmodus solange durchläuft bis alle Register mit den gewünschten Daten gefüllt sind. Aufgrund des Loops ist es möglich die aus einer Texture gewonnen Daten auch wieder als Grundlage für eine weitere Berechung zu benutzen. Damit dies auch ohne Probleme möglich ist konvertiert die FPU bei Bedarf die im Integerformat von der TMU gelieferten Daten in das Fliesspunktformt der FPU.
Die Arithmetikanweisungen werden nun in den schon in den NV1X Chips zum Einsatz gekommen Registercombiner ausgeführt. Wie in den NV1X Chips stehen davon weiterhin 2 pro Pixel zur Verfügung. Die Neuerung ist das es nun auch hier die möglichkeit gibt diese 2 Einheiten bis zu 4 mal pro Pixel zu durchlaufen. Dadurch ist der Chip in der Lage die geforderten 8 Arithmetikanweisungen auszuführen. Die Regcombiner sind für die Ausführung von DX8 Pixelshaderanweisungen etwas überdimensioniert da sie mehr Berechnungen pro Einheit durchführen können als es für eine DX8 Pixelshader ALU erforderlich ist.
R2XX:
ATI schlug nun mit der R2XX Chipfamilie einen gänzlich anderen Weg ein. Für alle Berechnungen steht nur eine ALU-Typ zur Verfügung. Eine Textureeinheit gibt es aber denoch. Diese verfügt nun über 6 Ausgangsregister sowie 6 Eingangsregister. Als Operationen kann diese Einheit aber lediglich den Inhalt eines Eingangsregisters in ein Ausgangsregister umkopieren oder ein Texturesample in Auftrag geben. Bei diesen Samples kann das Ergebniss in ein beliebiges Ausgangsregister geschrieben werden und ein beliebiges Eingangsregister als Quelle für die Texturekoordinaten benutzt werden. Diese Einheit wird nun auch im Loop betrieben bis alle Ausgangsregister mit Werten gefüllt sind. Innerhalb dieser Einheit ist es nun aber nicht möglich das Ergebniss eines Texturesamples direkt als Koordinaten für ein weiteres Sample zu benutzen. Um nun aber denoch Effekte zu ermöglichen die solche dependent Reads erfordern kann die Textureinheit zweimal durchlaufen werden. Beim erstenmal werden die Eingangsregister mit den interpolierten Texturekoordinaten aus den Verticen gefüllt beim Zweiten durchlauf sind die Zwischenspeicherregister der ALU die Quelle. Da die Eingangsregister aber nur 3 Elemente pro Register haben gehen die Alphawerte der Zwischenspeicherregister verloren da diese ein viertes element benötigen.
Der Arithmetikteil der R2XX Chips verfügt nun über die besagte ALU. Bevor das bis zu 8 Anweisungen umfassende Programm gestartet wird werden die 6 Ausgangsregister der Textureeinheit in die Zwischenspeicherregister umkopiert. Das Programm wird dann im Loopmodus abgearbeitet. Da auch diese Einheit zweimal durchlaufen werden kann gibt es natürlich auch zwei Programme. Nach dem ersten Durchlauf werden die Zwischenspeicher wie schon gesagt wieder in die Eingangsregister der Textureeinheit umkopiert. Ist der zweite Durchlauf eines Pixels beendet wird der werte aus dem ersten Zwischenspeicherregister in der Pipeline weitergegeben um dann im Framebuffer gespeichert zu werden.
Da die ALUs der R2XX Chips im Gegensatz zu den Reg-Combinern der NV2X Chips auch mit Texturekorrdinaten rechnen ist es ATI hoch anzurechnen das man sich nicht mit 9 Bit pro Kanal zufrieden gab da sonst die TMUs dorch mit sehr ungenauen Texturekoordinaten versorgt worden wäre. Als nedbeneffekt stehen die zusätzlichen Bits dann auch noch für Overbrightlight Effekte zur Verfügung.
Der Verzicht auf spezielle Einheiten für das Berechnen von per Pixel-Texturekoordinaten zwingt ATI aber auch dazu das bei der Verwendung von PS <= 1.3 die entsprechen Operationen bei Bedarf von der ALU übernommen werden müssen. Glücklicherweise erfordern die einfachen Texturoperationen welche primär benutzt werden keine solchen zusätzlichen Berechnungen.
Parhelia:
Hier kann man leider nicht viel schreiben da es ausser dem Pipelinedigramm nichts öffentlich zugängliches gibt. Dieses Diagramm lässt nun vermuten das es wie beim NV2X getrennte Einheiten für Textur und Arithmetik befehele gibt. Wobei es sich wohl um 4 Textur und 5 Arithmetik Einheiten pro Pixel handelt.
P10/P9:
Sorry aber das ist mir jetzt zu aufwendig. Das machen wir ein anderesmal wenn ich wieder mal das Bedürfnis habe euch zu quälen.
sonstige DX8 Chips:
Da bei allen anderen Chips welche DX8 fähige Shaderhardware haben überhaupt keine Detailinformationen zu bekommen sind muss diese Kapitel ungeschrieben bleiben.
Rampage:
OK ich weiss das es den Chip nie zu kaufen gibt aber da ich die Informationen hier rumliegen haben und es inzwischen wohl auch keine Rolle mehr spielt das da überall "Confidential" steht schreibe ich auch noch ein paar Worte dazu.
Rampage benutzt wie auch ATI nur eine universal ALU die sowohl Textureoperationen wie auch Arithemetikoperationen übernimmt. Ausnahme sind die einfachen Textureoperationen welche die TMU auch aleine erledigt. Eine Rampage Pipeline ist nun so aufgebaut das nach der TMU direkt die ALU folgt und das Berechnungsergebniss wieder in die TMU eingespeist oder für spätere Verwendung zwischengespeichert werden kann. So hat jeder Pixel 4 Runden durch diese Pipeline zur verfügung. Um nun aber mit nur 4 Runden denoch auf die bis zu 8 Arithemetikanweisungen zu kommen ist die ALU in zwei Teile geteilt. TCU (Texture Combine Unit) und CCU (Color Combine Unit) können dabei nahezu alle Arithemetikanweisungen ausführen. Beim Dot3 Produkt müssen sie aber kapitulieren. Dafür gibt es aber zwischen diesen beiden Einheiten noch eine Csum Einheit welche das notwendige summieren von R, G und B übernimmt. Bei mehr als 4 Dot3 Anweisungen pro Shader bekommt Rampage daher Probleme. Wie bei ATI sind aufgrund der Berechnug von Texturkoordinaten ein grössere zahlenraum erforderlich. 3dfx wollte hier mit 13 Bit antreten.
Schlusswort:
Genau wie viele Wege nach Rom führen gibt es auch viele Wege eine DX8 Pixelshaderhardware zu bauen. Jede Lösung hat dabei Vor und Nachteile. Unter dem gemeinsamen Mantel der DX-Spec wirken sich diese im wesentlichen unter dem Leistungsgesichtspunkt aus. Die unterschiedliche felexibilität kann meist nur durch entsprechende Extensions unter OpenGL ausgedrückt werden.
Durchaus interesant mag noch die Tatsache sein das sich die Blockweise Struktur von DX-Shaderanweisungen sich auf alle Chips gut übertragen lässt. Nur der Rampage hätte da eine grosse Ausnahme dargestellt den dieser hätte es von der Architektur bevorzugt wenn einer Textureanweisung immer zwei Arithemetikanweisungen (aber höchsten eine DOT3) folgen. Da wäre wohl ein etwas aufwendigerer Treiber notwendig geworden.
So ich habe euch aber jetzt genügend generft.
PS: Ich sollte aufhören nachdem ich no-Brain Arbeiten erledigen musste hier ellenlange Texte zu schreiben.
Mir geht hier jetzt nicht um primär die Performance. Darüber wurde ja schon viel geschrieben. Es ist viel eher ein Vergleich der Hardwareimplementierungen. Aufbauen auf Informationen aus unterschiedlichen mehr oder minder öffentlichen Quellen.
Ein DX8 Pixelshader unterscheidet primär zwischen Textur und Arithemetik Operationen und so besteht ein Shaderprogramm auch immer aus Blöcken dieser beiden Anweisungstypen. Bei den PS <= 1.3 gibt es einen Textur und einen Arithmetikblock. Die 1.4 Shader erlauben jeweils 2 Blöcke von jedem Type. Die DX Pixelshader stelle nun ja nur ein virtuelles Model dar. Die echte Hardware mag nun stark davon abweichen und tut dies auch durchaus.
NV2X:
nVidia benutzt für die Texturoperationen und die Arithmetikanweisungen zwei getrennte Einheiten im Chip.
Die Textureoperationen werden von den "Texture-Shader" genannten Einheiten durchgeführt. Dabei handelt es sich um eine FPU mit einem relative begrenzten festen Befehlsvorrat. Diese FPU kann pro Takt bis zu zwei Texturesamples pro Pixel in Auftrag geben. Als Eingangsregister stehen die vom Vertexshader gelieferten texturekoordinaten zur Verfügung. Als Ausgang stehen dieser Einheit 4 RGBA Register zur Verfügung. Gefüllt werden diese 4 Register durch ein entsprechendes Programm welches die FPU im Loopmodus solange durchläuft bis alle Register mit den gewünschten Daten gefüllt sind. Aufgrund des Loops ist es möglich die aus einer Texture gewonnen Daten auch wieder als Grundlage für eine weitere Berechung zu benutzen. Damit dies auch ohne Probleme möglich ist konvertiert die FPU bei Bedarf die im Integerformat von der TMU gelieferten Daten in das Fliesspunktformt der FPU.
Die Arithmetikanweisungen werden nun in den schon in den NV1X Chips zum Einsatz gekommen Registercombiner ausgeführt. Wie in den NV1X Chips stehen davon weiterhin 2 pro Pixel zur Verfügung. Die Neuerung ist das es nun auch hier die möglichkeit gibt diese 2 Einheiten bis zu 4 mal pro Pixel zu durchlaufen. Dadurch ist der Chip in der Lage die geforderten 8 Arithmetikanweisungen auszuführen. Die Regcombiner sind für die Ausführung von DX8 Pixelshaderanweisungen etwas überdimensioniert da sie mehr Berechnungen pro Einheit durchführen können als es für eine DX8 Pixelshader ALU erforderlich ist.
R2XX:
ATI schlug nun mit der R2XX Chipfamilie einen gänzlich anderen Weg ein. Für alle Berechnungen steht nur eine ALU-Typ zur Verfügung. Eine Textureeinheit gibt es aber denoch. Diese verfügt nun über 6 Ausgangsregister sowie 6 Eingangsregister. Als Operationen kann diese Einheit aber lediglich den Inhalt eines Eingangsregisters in ein Ausgangsregister umkopieren oder ein Texturesample in Auftrag geben. Bei diesen Samples kann das Ergebniss in ein beliebiges Ausgangsregister geschrieben werden und ein beliebiges Eingangsregister als Quelle für die Texturekoordinaten benutzt werden. Diese Einheit wird nun auch im Loop betrieben bis alle Ausgangsregister mit Werten gefüllt sind. Innerhalb dieser Einheit ist es nun aber nicht möglich das Ergebniss eines Texturesamples direkt als Koordinaten für ein weiteres Sample zu benutzen. Um nun aber denoch Effekte zu ermöglichen die solche dependent Reads erfordern kann die Textureinheit zweimal durchlaufen werden. Beim erstenmal werden die Eingangsregister mit den interpolierten Texturekoordinaten aus den Verticen gefüllt beim Zweiten durchlauf sind die Zwischenspeicherregister der ALU die Quelle. Da die Eingangsregister aber nur 3 Elemente pro Register haben gehen die Alphawerte der Zwischenspeicherregister verloren da diese ein viertes element benötigen.
Der Arithmetikteil der R2XX Chips verfügt nun über die besagte ALU. Bevor das bis zu 8 Anweisungen umfassende Programm gestartet wird werden die 6 Ausgangsregister der Textureeinheit in die Zwischenspeicherregister umkopiert. Das Programm wird dann im Loopmodus abgearbeitet. Da auch diese Einheit zweimal durchlaufen werden kann gibt es natürlich auch zwei Programme. Nach dem ersten Durchlauf werden die Zwischenspeicher wie schon gesagt wieder in die Eingangsregister der Textureeinheit umkopiert. Ist der zweite Durchlauf eines Pixels beendet wird der werte aus dem ersten Zwischenspeicherregister in der Pipeline weitergegeben um dann im Framebuffer gespeichert zu werden.
Da die ALUs der R2XX Chips im Gegensatz zu den Reg-Combinern der NV2X Chips auch mit Texturekorrdinaten rechnen ist es ATI hoch anzurechnen das man sich nicht mit 9 Bit pro Kanal zufrieden gab da sonst die TMUs dorch mit sehr ungenauen Texturekoordinaten versorgt worden wäre. Als nedbeneffekt stehen die zusätzlichen Bits dann auch noch für Overbrightlight Effekte zur Verfügung.
Der Verzicht auf spezielle Einheiten für das Berechnen von per Pixel-Texturekoordinaten zwingt ATI aber auch dazu das bei der Verwendung von PS <= 1.3 die entsprechen Operationen bei Bedarf von der ALU übernommen werden müssen. Glücklicherweise erfordern die einfachen Texturoperationen welche primär benutzt werden keine solchen zusätzlichen Berechnungen.
Parhelia:
Hier kann man leider nicht viel schreiben da es ausser dem Pipelinedigramm nichts öffentlich zugängliches gibt. Dieses Diagramm lässt nun vermuten das es wie beim NV2X getrennte Einheiten für Textur und Arithmetik befehele gibt. Wobei es sich wohl um 4 Textur und 5 Arithmetik Einheiten pro Pixel handelt.
P10/P9:
Sorry aber das ist mir jetzt zu aufwendig. Das machen wir ein anderesmal wenn ich wieder mal das Bedürfnis habe euch zu quälen.
sonstige DX8 Chips:
Da bei allen anderen Chips welche DX8 fähige Shaderhardware haben überhaupt keine Detailinformationen zu bekommen sind muss diese Kapitel ungeschrieben bleiben.
Rampage:
OK ich weiss das es den Chip nie zu kaufen gibt aber da ich die Informationen hier rumliegen haben und es inzwischen wohl auch keine Rolle mehr spielt das da überall "Confidential" steht schreibe ich auch noch ein paar Worte dazu.
Rampage benutzt wie auch ATI nur eine universal ALU die sowohl Textureoperationen wie auch Arithemetikoperationen übernimmt. Ausnahme sind die einfachen Textureoperationen welche die TMU auch aleine erledigt. Eine Rampage Pipeline ist nun so aufgebaut das nach der TMU direkt die ALU folgt und das Berechnungsergebniss wieder in die TMU eingespeist oder für spätere Verwendung zwischengespeichert werden kann. So hat jeder Pixel 4 Runden durch diese Pipeline zur verfügung. Um nun aber mit nur 4 Runden denoch auf die bis zu 8 Arithemetikanweisungen zu kommen ist die ALU in zwei Teile geteilt. TCU (Texture Combine Unit) und CCU (Color Combine Unit) können dabei nahezu alle Arithemetikanweisungen ausführen. Beim Dot3 Produkt müssen sie aber kapitulieren. Dafür gibt es aber zwischen diesen beiden Einheiten noch eine Csum Einheit welche das notwendige summieren von R, G und B übernimmt. Bei mehr als 4 Dot3 Anweisungen pro Shader bekommt Rampage daher Probleme. Wie bei ATI sind aufgrund der Berechnug von Texturkoordinaten ein grössere zahlenraum erforderlich. 3dfx wollte hier mit 13 Bit antreten.
Schlusswort:
Genau wie viele Wege nach Rom führen gibt es auch viele Wege eine DX8 Pixelshaderhardware zu bauen. Jede Lösung hat dabei Vor und Nachteile. Unter dem gemeinsamen Mantel der DX-Spec wirken sich diese im wesentlichen unter dem Leistungsgesichtspunkt aus. Die unterschiedliche felexibilität kann meist nur durch entsprechende Extensions unter OpenGL ausgedrückt werden.
Durchaus interesant mag noch die Tatsache sein das sich die Blockweise Struktur von DX-Shaderanweisungen sich auf alle Chips gut übertragen lässt. Nur der Rampage hätte da eine grosse Ausnahme dargestellt den dieser hätte es von der Architektur bevorzugt wenn einer Textureanweisung immer zwei Arithemetikanweisungen (aber höchsten eine DOT3) folgen. Da wäre wohl ein etwas aufwendigerer Treiber notwendig geworden.
So ich habe euch aber jetzt genügend generft.
PS: Ich sollte aufhören nachdem ich no-Brain Arbeiten erledigen musste hier ellenlange Texte zu schreiben.