PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Spezialisierte Shader gegenüber einer allgemeinen Shader Architektur


Demirug
2003-05-22, 11:15:53
Warnung: Dies ist mal wieder einer von meinen hochkomplizierten und Threads auf die es nicht viele Beiträge geben wird. Aber mir war eben mal wieder danach.

In modernen Grafikchips herrscht nach wie vor eine starke Spezialisierung vor. Für jeden zu erledigenden Job gibt es eigenen Einheiten. Hier möchte ich nun die Aufmerksamkeit auf die Shader (Vertex und Pixel) sowie die dazugehörigen TMUs (Texture Management Unit) lenken.

Wie viele wahrscheinlich schon wissen werden besteht eine Shadereinheit funktional aus mehrern teilen:
- Registerfeld für veränderbare Werte
- Registerfeld für konstante Werte
- Registerfeld für eingangs Werte
- Registerfeld für ausgangs Werte
- Programmspeicher
- ALU(s) welche die eigentliche Rechenarbeit erledigen

Bei den Pixelshadern kommen dann noch die TMUs für den Zugriff auf bestimmte Speicherbereiche hinzu.

Die ersten Shadereinheiten waren in ihren Möglichkeiten noch sehr beschränkt. Programme konnten nur jeweils einmal komplett vom Anfang bis zum Ende durchlaufen werden. Bei den Pixelshadern gab es die zusätzliche Beschränkung das alle Texturezugriffe vor dem Rechnen mit den ALUs bereits durchgeführt sein mussten. Im Gegenzug dafür hatte die TMUs ebenefalls begrenzte Rechenmöglichkeiten erhalten.

Die erste Erweiterung (Änderung) dieses Konzepts kam dann von ATI mit dem R200. Der R200 hat zwar nach wie vor eine PS-Einheit die es erfordert das zuerst die Texturen ausgelesen werden und dann die Berechnungen durchgeführt werden können. Allerdings kann dieser Vorgang zweimal pro Pass durchgeführt werden und man einen Grossteil der im ersten Durchlauf berechneten werte im zweiten durchlauf weiter benutzten. Als kleiner Wermutstropfen haben die TMUs aber die Rechenfähigkeit eingebüsst und Berechnungen die bisher dort durchgeführt wurden müssen jetzt im ersten Durchlauf von den ALUs übernommen werden.

Der nächste Schritt waren dann die 2.0 und 2.0+ Shader die wir heuten in den R(V)3xx und NV3x Chips finden können. Die technische Implementierung hängt aber gerade bei den 2.0+ Shadern sehr stark von den Optionen ab die nun genau unterstützt werden das ich mir eine genauere Betrachtung jetzt hier erst einmal sparen möchte.

Allgemein kann man sagen das sich die Shader in ihren Möglichkeiten immer mehr einer CPU annähern und sich Pixel und Vertexshader immer ähnlicher werden. Mit den 3.0 Shadern verlieren die Pixelshader auch noch das Privileg als einzige auf den Texturespeicher zugreifen zu dürfen. Denn nun ist es auch den Vertexshadern erlaubt Daten aus den Texturen auszulesen um Effekte wie Displacmentmapping zu realisieren.

Aber kommen wir nun nach dieser Zugegebenehrmassen recht langen Einführung endlich auf das eigentlich Thema. Alle derzeit verfügbaren Grafikchips (die man als normaler Kunden kaufen kann) sind wie gesagt mit stark spezialisierten Einheiten aufgebaut. Wird eine Einheit gerade nicht gebraucht kann sie nur untätig auf neue arbeit warten. Da aber jede Einheit für einen maximalen extrem Fall ausgelegt sein muss nimmt die Effektive Auslastung der einzelnen Einheiten immer weiter ab. Das beste Beispiel sind hierfür die MSAA-Einheiten. Benutzt man nicht die maximale AA-Stufe welche ein Chip beherrscht bleibt ein Teil dieser Einheiten einfach ungenutzt. Aber auch wenn man die maximale AA-Stufe einsetzt sind die Pixelshader meistens kaum in der Lage bei jedem Takt einen neuen Pixel fertig zustellen wodurch die AA-Einheiten auch unter ihren Möglichkeiten bleiben.

Lassen wir aber die AA-Einheiten mal aussen vor und betrachten nur die Vertext und Pixelshader. Moderne Chips bieten eine sehr hohe Vertexleistung die aber meist gar nicht genutzt wird weil die Pixelshader nicht mit der Arbeit hinterherkommen. Nun wissen wir aber das es bei den 3.0 Shadern zwischen dem Pixel und Vertex Bereich kaum unterschiede gibt.

Diesen Umstand sollte man nun meiner Meinung nach ausnutzten und statt getrennter Pixel und Vertexshader nur noch allgemeine Shader verbauen. In Abhängigkeit des Workloads könnte diese dann dynamisch dem Pixel oder dem Vertexprocessing zugeordent werden.

Der Vorteil wäre eine bessere Ausnutzung der Ressourcen allerdings würde man dafür aber auch zusätzliche Transistoren zur Steuerung des ganzen benötigen.

Exxtreme
2003-05-22, 12:41:00
Naja, die Frage ist jetzt ob solche "Universal-Shader" die gleiche Geschwindigkeit erreichen können wie spezialisiertere Shader. Meist ist es nämlich so, daß je flexibler, desto langsamer.

zeckensack
2003-05-22, 12:47:46
Ich kann mich mit 'frei verschiebbaren' Einheiten irgendwie nicht so recht anfreunden ;)

Erstmal, wenn das Argument ist, daß die Vertexeinheit der Fragmenteinheit davonrennt, dann muß man halt mehr Vertex Shader benutzen :D
Ansonsten müsste man behaupten, die HW-Entwickler bauen zu große/zu viele Vertex-Einheiten ein, was durchaus stimmen könnte. Wozu zB der 4fache VS auf dem R300 gut sein soll, ist mir immer noch nicht ganz klar. Sowas zielt wohl eher auf SpecViewperf/UGS ab, als auf den Spiele-Markt (woran die Spieleentwickler zum Teil mitschuldig sein könnten, weil sie diese Ressourcen eben nicht konsequent genug nutzen).

Rein architektonisch betrachtet sehe ich auch keinen guten Ansatzpunkt, Recheneinheiten zwischen VS und PS frei einzuteilen. Diese beiden Blöcke sind ja recht stark voneinander abgegrenzt, und liegen vor allem räumlich auseinander. Wenn eine ALU im 'pixel block' frei ist, wie kriegt man dann Vertex-Daten schnell da hin, und ebenso schnell wieder zurück, ohne daß das ganze langsamer als eine Recheneinheit 'direkt vor Ort' ist?

Man kann einen Pool von Recheneinheiten natürlich zwischen die beiden Teile setzen, sodaß von beiden Blöcken aus ein gleich langer Weg zu überbrücken ist. Dann straft man beide logischen Blöcke gleichermaßen ab, nur mit dem Vorteil daß der worst case nicht ganz so schlimm ausfällt.

Nächster: Kontroll-Logik. Ich gehe mal davon aus, daß auch Flow Control nichts daran ändern wird, daß im Pixel Shader alle parallelen Einheiten das gleiche machen (FC löst man IMO am saubersten mit predication). Sie führen alle gleichzeitig die selbe Instruktion aus dem selben Programm aus, sodaß man nur eine einzige Steuerungslogik braucht. So ähnlich wie der Trident XP, nur eben nicht langsam :D

Diese Chance verspielt man, wenn Einheiten Instruktionen aus verschiedenen Programmen ausführen (eben der Fall Vertex Shader&Pixel Shader).


Kurzum: ich halte das was du dir vorstellst zwar für grundsätzlich machbar, aber ich befürchte die Komplexität würde so weit ansteigen, daß es den möglichen Nutzen wieder auffressen würde (und zur Kompensation gleich weniger Einheiten verbaut würden).

Demirug
2003-05-22, 13:13:47
Originally posted by Exxtreme
Naja, die Frage ist jetzt ob solche "Universal-Shader" die gleiche Geschwindigkeit erreichen können wie spezialisiertere Shader. Meist ist es nämlich so, daß je flexibler, desto langsamer.

Das macht keine Unterschied. Die Flexibilität innerhalb eines Shaders wird ja nicht verändert. Das einzige was sich ändern würde ist die Eingangs und Ausgangslogik des Shaders.

Demirug
2003-05-22, 13:36:53
Originally posted by zeckensack
Ich kann mich mit 'frei verschiebbaren' Einheiten irgendwie nicht so recht anfreunden ;)

Erstmal, wenn das Argument ist, daß die Vertexeinheit der Fragmenteinheit davonrennt, dann muß man halt mehr Vertex Shader benutzen :D
Ansonsten müsste man behaupten, die HW-Entwickler bauen zu große/zu viele Vertex-Einheiten ein, was durchaus stimmen könnte. Wozu zB der 4fache VS auf dem R300 gut sein soll, ist mir immer noch nicht ganz klar. Sowas zielt wohl eher auf SpecViewperf/UGS ab, als auf den Spiele-Markt (woran die Spieleentwickler zum Teil mitschuldig sein könnten, weil sie diese Ressourcen eben nicht konsequent genug nutzen).

Das Argument ist das die Shader oft einseitig benutzt werden und sich dadurch gegenseitig blockieren. Es gibt Situaionen in denen die VS am Limit sind und dann aber auch wieder Situationen in denen PS die Bremse darstellen. Im Moment spielt bei den PS die Bandbreite noch gerne das Limit aber je mehr man rechnet und je weniger man sampelt des unabhängier wird man von der Bandbreite.

Rein architektonisch betrachtet sehe ich auch keinen guten Ansatzpunkt, Recheneinheiten zwischen VS und PS frei einzuteilen. Diese beiden Blöcke sind ja recht stark voneinander abgegrenzt, und liegen vor allem räumlich auseinander. Wenn eine ALU im 'pixel block' frei ist, wie kriegt man dann Vertex-Daten schnell da hin, und ebenso schnell wieder zurück, ohne daß das ganze langsamer als eine Recheneinheit 'direkt vor Ort' ist?

Man kann einen Pool von Recheneinheiten natürlich zwischen die beiden Teile setzen, sodaß von beiden Blöcken aus ein gleich langer Weg zu überbrücken ist. Dann straft man beide logischen Blöcke gleichermaßen ab, nur mit dem Vorteil daß der worst case nicht ganz so schlimm ausfällt.

Nicht die Recheneinheiten sondern den kompletten Shader mit allem drum und dran. Dadurch ändert man nur die Eingangs und Ausgangslogik etwas.

Nächster: Kontroll-Logik. Ich gehe mal davon aus, daß auch Flow Control nichts daran ändern wird, daß im Pixel Shader alle parallelen Einheiten das gleiche machen (FC löst man IMO am saubersten mit predication). Sie führen alle gleichzeitig die selbe Instruktion aus dem selben Programm aus, sodaß man nur eine einzige Steuerungslogik braucht. So ähnlich wie der Trident XP, nur eben nicht langsam :D

Diese Chance verspielt man, wenn Einheiten Instruktionen aus verschiedenen Programmen ausführen (eben der Fall Vertex Shader&Pixel Shader).

predication ist gut für wenige Anweisungen sobald die Zweige grösser werden ist es besser mit echten Sprüngen zu arbeiten und pixelkill wird wahrscheinlich auch eine grössere Bedeutung bekommen. Ich sehe aber ehrlich gesagt kein so grosses Problem den Programmspeicher entsprechend auszulegen das er mehrer Shader mit Instruktionen versorgt. Letzen Endes braucht man nur einen Speicher mit genügend Readports

Kurzum: ich halte das was du dir vorstellst zwar für grundsätzlich machbar, aber ich befürchte die Komplexität würde so weit ansteigen, daß es den möglichen Nutzen wieder auffressen würde (und zur Kompensation gleich weniger Einheiten verbaut würden).

Denn nutzen könnte ich dir ausrechnen allerdings müsste mir da NVIDIA mal den Serverraum dafür ausleihen. Der Punkt ist das es immer komplizierter wird die Pipeline auszugleichen (nicht umsonst ist das eines der neuen Lieblingsthemen des Devsupports). Der Entwickler kann zwar diesen Ausgleich versuchen aber er muss letzte Endes scheitern weil gerade Dinge wie EarlyZ und Hir-Z massiven Einfluss auf die Lastverteilung haben. Wenn die Hardware also die Gefahr des Ungleichgewichts bei den Shadern gleich ausschliesst ist da schon mal ein Problem weniger.

Gil-galad
2003-06-09, 18:46:16
@ Demirug

Du sagst ja das die Pixelshader nicht mit der Arbeit nachkommen (1. Post von Dir). Wäre es dann nicht einfacher "einfach" ein paar mehr Pixelshader in den Chip zu packen, damit die Arbeit schneller geht (Arbeitsaufteilung [wie bei Dual-Prozessor-Systemen] oder so) ?

Ich hab vor kurzem neue Spekulationen zum NV40 gelesen. Wozu braucht man 16 Vertex-Shader wenn die 8 Pixelshader (zumindest sagt die Quelle das es 16 Vertex- und 8 Pixelshader sind) nicht mit der Arbeit hinterher kommen ?

Falls ich was falsches sage/meine dann verzeiht mir, bin noch Einsteiger auf dem Gebiet ;)

Demirug
2003-06-09, 18:59:26
AiS|Gil-galad, ja in vielen fällen blockieren die Pixelshader die Vertexshader aber es gibt auch immer wieder situationen in denen die Pixelshader keine Arbeit haben weil sich die Verteshader gerade mit verticen vergnügen die im Trisetup alle weggeworfen werden weil die HSR einheiten entdecken das sie nicht gebraucht werden.

Aus diesem Grund versucht man ja derzeit immer eine möglichst ausgeglichenes Verhältniss zwichen VS und PS zu finden. Aber letzende Endes hat man nur sehr selten ein ausgeglichendes Verhältniss. Deswegen ja auch Idee die Shader immer für den Job zu benutzen welcher gerade erledigt werrden muss. Naütlich würde dann wieder was anderes zum flaschenhals werden der aber etwas breiter sein sollte.

Die Spekulation zum NV40 vergessen wir mal ganz schnell die ist mit sehr hoher Wahrscheinlichkeit so falsch.

Quasar
2003-06-09, 19:11:13
Original geschrieben von Demirug
Die Spekulation zum NV40 vergessen wir mal ganz schnell die ist mit sehr hoher Wahrscheinlichkeit so falsch.

Diese schon, aber ganz ohne Bezug zum nV40 kann ich mir deinen Thread nun auch nicht vorstellen. Es gibt ja bereits offizielle Aussagen von nV, dass man in dieser Richtung die Zukunft sieht (sehen muss?).

Ich stelle mir das Ganze allerdings ein wenig praktikabler vor als zeckensack, vielleicht, weil ich technisch gesehen bei weitem nicht so tief in der Materie drinstecke.
Allerdings wäre der Aufwand, um auch nur vergleichbare Geschwindigkeit bei sog. Legacy-Apps zu erhalten, sicherlich enorm.

Der Hersteller müsste den Mut aufbringen, in älteren Games (prä-DX9) nur genausoschnell oder gar langsamer zu sein, als das Vorgängermodell und auch die Konkurrenz oder eben zu einem wahnsinnig aufwendigen Chipdesign greifen, wenn quasi jeder Funktionsblock "alles" können soll.

Demirug
2003-06-09, 19:35:54
Quasar, ich bezog mich auf die speziellen Zahlen die dort genant wurden das man mögliche Designveränderungen natürlich immer mit Spekulationen über zukünftige Chips verknüpfen muss ist klar. Ausser man beschränkt sich auf rein theoretische Betrachtungen.

Demirug
2003-06-09, 19:39:07
Original geschrieben von Quasar
Ich stelle mir das Ganze allerdings ein wenig praktikabler vor als zeckensack, vielleicht, weil ich technisch gesehen bei weitem nicht so tief in der Materie drinstecke.
Allerdings wäre der Aufwand, um auch nur vergleichbare Geschwindigkeit bei sog. Legacy-Apps zu erhalten, sicherlich enorm.

Der Hersteller müsste den Mut aufbringen, in älteren Games (prä-DX9) nur genausoschnell oder gar langsamer zu sein, als das Vorgängermodell und auch die Konkurrenz oder eben zu einem wahnsinnig aufwendigen Chipdesign greifen, wenn quasi jeder Funktionsblock "alles" können soll.

Mit den Legacy-Apps sehe ich gar keine grossen Probleme. Auch diese würde ja davon profitieren wenn man die Shaderleistung dynamich umverteilen kann. Das Problem ist ja heute schon akkut.

Quasar
2003-06-09, 22:54:54
Ich dachte eher daran, dass es wohl recht viel Leistung erfordert, wenn man keine dedizierten Funktionseinheiten wie Filterkernel mehr hat, sondern dies auch über frei programmierbare Einheiten erledigen will...