Archiv verlassen und diese Seite im Standarddesign anzeigen : Registerfile-Größe bei CineFX
"What limitations exist in this extension?
RESOLVED: Very few. Programs can not exceed a maximum program length (which is no less than 1024 instructions), and can use no more than 32-64 temporary registers."
Ich denk mal, 32-64 gilt je nach dem, ob man FP16 oder FP32 nimmt.
32 Temp-Register hört sich für mich erst mal recht viel an. Wieso zum Teufel dann die Probleme in Direct3D? Oder gilt auch für OpenGL, dass man besser nicht mehr als 4-8 Temps nutzen sollte, wenn die Performance hoch bleiben soll?
Wenn das der Fall ist, kann es sein, dass in CineFX Rampage-Ideen drin sind? Also beliebig tiefe Dependend Reads, aber nur wenige Temps bis zum nächsten Befehl speicherbar?
Demirug
2003-12-09, 12:55:35
Es sind 32 FP32 Register wobei man in jedes FP32 Register auch auch zwei FP16 Werte Speichern kann. Doppelte Nutzung des gleichen Speichers. Im Prinzip müsste es sogar möglich sein den gleichen Speicher erst für einen FP32 Wert und später im gleichen Shader für 2 FP16 Werte zu nutzen. Das habe ich allerdings nicht ausprobiert.
Das Temp-Problem gibt es natürlich auch bei OpenGL.
Im weitesten Sinn ist das ganze dem Rampage ähnlich die unterschiede sind aber denoch gross genug das ich da keinen direkten Bezug sehe. Die Ähnlichkeit zum NV2X ist höher.
Original geschrieben von Demirug
Das Temp-Problem gibt es natürlich auch bei OpenGL. Was genau ist das für ein Problem? 32 Register sind für Temps doch sehr viel.
Demirug
2003-12-09, 13:30:35
Original geschrieben von aths
Was genau ist das für ein Problem? 32 Register sind für Temps doch sehr viel.
Das Problem ist das wenn man viele Temps pro Pixel nutzt das ganze sehr langsam wird.
32 Regs * 4 Pipes =128 Regs. Wenn das Programm nur 1 Temp-Reg benutzt und danach in den dependent read loop geht (mindestens 160 Takte), dann sind die Temps nach 32 Takten aufgebraucht und der PS dreht 128 Takte lang die Daumen umeinander. Mit etwas Glück (und gutem Compiler) werden die Temps nicht sofort mit dem dependent read verrechnet. Da also die nachfolgenden Befehle unabhängig sind, kann der PS trotzdem noch (etwas) weiterrechnen.
Richtig schwierig wird's, wenn das Dreieck klein ist und es nicht mehr möglich ist, einfach mit den nächsten Quad-Pixeln desselben Dreiecks fortzufahren. Neue Dreiecke oder state changes verlangen zusätzlichen Speicher (für Interpolatoren-Resultate usw.) und komplexere Scheduling-Steuerlogik.
Demirug
2003-12-09, 14:07:43
Original geschrieben von Gast
32 Regs * 4 Pipes =128 Regs. Wenn das Programm nur 1 Temp-Reg benutzt und danach in den dependent read loop geht (mindestens 160 Takte), dann sind die Temps nach 32 Takten aufgebraucht und der PS dreht 128 Takte lang die Daumen umeinander. Mit etwas Glück (und gutem Compiler) werden die Temps nicht sofort mit dem dependent read verrechnet. Da also die nachfolgenden Befehle unabhängig sind, kann der PS trotzdem noch (etwas) weiterrechnen.
Richtig schwierig wird's, wenn das Dreieck klein ist und es nicht mehr möglich ist, einfach mit den nächsten Quad-Pixeln desselben Dreiecks fortzufahren. Neue Dreiecke oder state changes verlangen zusätzlichen Speicher (für Interpolatoren-Resultate usw.) und komplexere Scheduling-Steuerlogik.
Bei nur einem 1 Temp Register und lauter Dependent Reads rauschen die Quads nur so durch die Pipeline.
Die Tatsache das man beim NV3X aber voll auf unlimitierte Dependent Reads gesetzt hat ist allerdings einer der Hauptgründe das man soviel Registerspeicher braucht und daher auch zuwenig davon hat. Für jede Stufe der Pipeline muss für jedes benutzt TempRegister Speicher zur Verfügung stehen. Bei mehr als 200 Stufen kommt da eine Menge zusammen. Reicht der Speicher nicht bleiben Stufen unbesetzt.
Kleine Dreiecke sind durchaus ein Problem. Die FXen sind auf etwa 32 Pixel pro Dreieck ausgelegt. Die Pipeline darf dazu Pixel aus bis zu 32 Dreicken gleichzeitig enthalten.
Interpolations-Resultate werden übrigens nicht gespeichert sondern bei Bedarf mit der Ebenengleichung der entsprechende Vertexwerte direkt berechnet.
Wenn ich es richtig gelesen habe, dann werden Texture-Befehle bei NV im PS behandelt. Das obige Beispiel ist also nicht ganz so dramatisch und trifft mehr auf ATI zu, obwohl bei ATI wiederum das texture fifo und die Anzahl der regs (zumindest mir) unbekannt sind.
Bin mir noch nicht im Klaren darüber, ob die 4x2 Architektur (also 2 TMUs) von Vorteil ist oder einfach vom Vorgänger übernommen wurde.
Original geschrieben von Demirug
Bei nur einem 1 Temp Register und lauter Dependent Reads rauschen die Quads nur so durch die Pipeline.
Wie das? Der Chip muss dann intern wesentlich mehr Speicher haben. Wie soll es sonst gehen?
Die Tatsache das man beim NV3X aber voll auf unlimitierte Dependent Reads gesetzt hat ist allerdings einer der Hauptgründe das man soviel Registerspeicher braucht und daher auch zuwenig davon hat. Für jede Stufe der Pipeline muss für jedes benutzt TempRegister Speicher zur Verfügung stehen. Bei mehr als 200 Stufen kommt da eine Menge zusammen. Reicht der Speicher nicht bleiben Stufen unbesetzt.
ATI ist auf 4 dependent reads begrenzt. Kein Spiel sollte mehr verwenden, also sollten dieselben Speicheranforderungen gelten?
Interpolations-Resultate werden übrigens nicht gespeichert sondern bei Bedarf mit der Ebenengleichung der entsprechende Vertexwerte direkt berechnet.
Wenn nicht die Resultate gespeichert werden, dann eben die Koeffizienten. Wie soll es ohne irgendeine Form von Speicherung gehen? Die Dreiecke sind nun mal im Chip. Ausserdem gibt's ja noch weitere Parameter.
Demirug
2003-12-09, 14:31:51
Original geschrieben von Gast
Wenn ich es richtig gelesen habe, dann werden Texture-Befehle bei NV im PS behandelt. Das obige Beispiel ist also nicht ganz so dramatisch und trifft mehr auf ATI zu, obwohl bei ATI wiederum das texture fifo und die Anzahl der regs (zumindest mir) unbekannt sind.
Ja, Texturebefehle werden vom ShaderCore bearbeitet. Bei ATI ist dafür aber auch der Pixelprozessor zuständig aber das läuft etwas anders ab.
Bin mir noch nicht im Klaren darüber, ob die 4x2 Architektur (also 2 TMUs) von Vorteil ist oder einfach vom Vorgänger übernommen wurde.
Es wurde übernommen. Einen kleinen Vorteil hat es allerdings schon. Da der Shadercore ja alle Befehle bearbeiten kann ergibt sich das man mit den einzelnen Recheneinheiten die man für eine Vector4 Operation braucht auch 2 Textureoperationen ausführen kann.
Demirug
2003-12-09, 14:36:11
Original geschrieben von Gast
Wie das? Der Chip muss dann intern wesentlich mehr Speicher haben. Wie soll es sonst gehen?
Warum sollte er mehr Speicher haben. Das Registerfile wird dynamisch verwaltet. Jeder Pixelquad nimmt sich davon soviel wie er braucht. Wenn nicht mehr übrig ist darf auch kein Pixelquad mehr in die Pipeline.
ATI ist auf 4 dependent reads begrenzt. Kein Spiel sollte mehr verwenden, also sollten dieselben Speicheranforderungen gelten?
Die Anzahl der möglichen dependent reads hat nichts mit den Speicheranforderungen zu tun.
Wenn nicht die Resultate gespeichert werden, dann eben die Koeffizienten. Wie soll es ohne irgendeine Form von Speicherung gehen? Die Dreiecke sind nun mal im Chip. Ausserdem gibt's ja noch weitere Parameter.
Natürlich werden die Koeffizienten gespeichert. Dafür benötigt man aber viel weniger Platz als für die Interpolierte Werte benötigt würde.
Original geschrieben von Demirug
Warum sollte er mehr Speicher haben. Das Registerfile wird dynamisch verwaltet. Jeder Pixelquad nimmt sich davon soviel wie er braucht. Wenn nicht mehr übrig ist darf auch kein Pixelquad mehr in die Pipeline.
Ein Missverständnis? Es ging mir um das konstruierte Beispiel. Es ist entweder korrekt oder falsch. Deine Antwort deutet auf korrekt hin, ansonsten bitte richtigstellen.
Die Anzahl der möglichen dependent reads hat nichts mit den Speicheranforderungen zu tun.
Warum sollte NV dann diesbezüglich Probleme mit den Temp-Regs haben? (Verliere den roten Faden.)
Demirug
2003-12-09, 15:23:33
Original geschrieben von Gast
Ein Missverständnis? Es ging mir um das konstruierte Beispiel. Es ist entweder korrekt oder falsch. Deine Antwort deutet auf korrekt hin, ansonsten bitte richtigstellen.
Bei einem 1 Temp Register und dann sofort Dependent Reads läuft die Pipeline mit maximaler Geschwindigkeit.
Der Grad mit dem die Pipeline gefüllt werden kann berechnet sich aus.
(Speicherzellen / (2*Aufrunden((FP32 Temps pro Pixel)/2))) / Anzahl der Stages
Problematisch ist das die Anzahl der Speicherzellen und Stages nicht genau bekannt ist. Beim NV35 sollen es 256 Zellen sein (muss ich aber nochmal nachschauen) und über 200 Stages.
Warum sollte NV dann diesbezüglich Probleme mit den Temp-Regs haben? (Verliere den roten Faden.)
Das ist ein Folgeproblem. Unlimitierte dependent Reads ohne zusätzliche Wartetakte bei einer langen Pipeline erfodert ein sehr grosses Registerfile. Zu gross für das Transitorenlimit.
Original geschrieben von Demirug
Bei einem 1 Temp Register und dann sofort Dependent Reads läuft die Pipeline mit maximaler Geschwindigkeit.
Der Grad mit dem die Pipeline gefüllt werden kann berechnet sich aus.
(Speicherzellen / (2*Aufrunden((FP32 Temps pro Pixel)/2))) / Anzahl der Stages
Problematisch ist das die Anzahl der Speicherzellen und Stages nicht genau bekannt ist. Beim NV35 sollen es 256 Zellen sein (muss ich aber nochmal nachschauen) und über 200 Stages.
Habe mir nochmal den ganzen Thread durchgelesen und festgestellt, dass wir leider perfekt aneinander vorbeireden. Jeder hat seine eigenen Prioritäten im Hinterkopf (welcher Sachverhalt ist wichtig darzustellen), wodurch sich scheinbare Widersprüche ergeben. In diesem Posting argumentierst du z.B. mit den Latenzen des PS (Anzahl der Stages), während ich mit den Latenzen des Texture-Zugriffs (160 Stages) argumentiere.
Das ist ein Folgeproblem. Unlimitierte dependent Reads ohne zusätzliche Wartetakte bei einer langen Pipeline erfodert ein sehr grosses Registerfile. Zu gross für das Transitorenlimit.
Wie gesagt, wir lesen/schreiben zu schnell ohne zu merken, worauf der andere wirklich hinaus will. Mir gings hierbei darum, dass *unlimited* dependent reads (DR) nicht *an sich* mehr Speicher kostest. Anders gesagt: Eine unlimited DR Architektur (NV), bei der aber nur 4 DR vom Programm genutzt werden, brauchen nicht mehr Speicher als eine *limited* (4) DP Architektur (ATI) desselben Programms. Mag vielleicht trivial (oder gar falsch sein), aber mehr wollte ich nicht sagen.
Demirug
2003-12-09, 16:51:10
Original geschrieben von Gast
Habe mir nochmal den ganzen Thread durchgelesen und festgestellt, dass wir leider perfekt aneinander vorbeireden. Jeder hat seine eigenen Prioritäten im Hinterkopf (welcher Sachverhalt ist wichtig darzustellen), wodurch sich scheinbare Widersprüche ergeben. In diesem Posting argumentierst du z.B. mit den Latenzen des PS (Anzahl der Stages), während ich mit den Latenzen des Texture-Zugriffs (160 Stages) argumentiere.
So sehr haben wir IMHO gar nicht aneinander vorbei geredet.
Die Textur-Zugrffs Latenz (Laut nv beim NV35 > 176 Stages) ist ja ein Teil der gesamten PS-Pipeline (> 200 Stages). Auch wenn gar nicht aus einer Texture gelesen wird müssen die Quads da durch.
Wie gesagt, wir lesen/schreiben zu schnell ohne zu merken, worauf der andere wirklich hinaus will. Mir gings hierbei darum, dass *unlimited* dependent reads (DR) nicht *an sich* mehr Speicher kostest. Anders gesagt: Eine unlimited DR Architektur (NV), bei der aber nur 4 DR vom Programm genutzt werden, brauchen nicht mehr Speicher als eine *limited* (4) DP Architektur (ATI) desselben Programms. Mag vielleicht trivial (oder gar falsch sein), aber mehr wollte ich nicht sagen.
Ja, das stimmt schon. Allerdings führten eben noch ein paar andere Forderungen die nVidia an den Pixelprozessor stellte das ihr Pixelprozessor mehr Registerspeicher braucht als ATI. Und eine dieser Anforderungen ist eben das bei dependent reads keine zusätzliche Latenz entstehen darf.
PS: Kleine Korrektur. Es sind nicht 256 Speicherzellen sondern 256*2 beim NV35. Ursprünglich waren aber scheinbar schon für den NV30 einmal 512*2 Zellen geplannt.
Original geschrieben von Demirug
So sehr haben wir IMHO gar nicht aneinander vorbei geredet.
Die Textur-Zugrffs Latenz (Laut nv beim NV35 > 176 Stages) ist ja ein Teil der gesamten PS-Pipeline (> 200 Stages). Auch wenn gar nicht aus einer Texture gelesen wird müssen die Quads da durch.
Ich würde das zwar trennen, aber meinetwegen.
Ja, das stimmt schon. Allerdings führten eben noch ein paar andere Forderungen die nVidia an den Pixelprozessor stellte das ihr Pixelprozessor mehr Registerspeicher braucht als ATI. Und eine dieser Anforderungen ist eben das bei dependent reads keine zusätzliche Latenz entstehen darf.
Was meinst du mit "keine zusätzliche Latenz entstehen"? Latenzen sind unvermeidbar, man kann/sollte nur verhindern, dass eine Einheit (PS) untätig ist. Das Problem trifft also ebenso auf ATI zu. Wenn NV aus noch nicht genannten Gründen weiteren Speicherplatz braucht (mehr als ATI), dann wozu? Anders gefragt, warum gibt es das Temp-Reg Problem, dass ATI angeblich nicht hat? Der NV35 hat ca. 15 Mio. Transistoren mehr als 9800PRO.
PS: Kleine Korrektur. Es sind nicht 256 Speicherzellen sondern 256*2 beim NV35. Ursprünglich waren aber scheinbar schon für den NV30 einmal 512*2 Zellen geplannt.
Interessant wie freizügig NV Developer mit Internas versorgt. Oder stammt das aus dem Patent? Mir war diese Information jedenfalls nicht bekannt. Und was genau sind "Speicherzellen"? Ein englischer Begriff würde mir auch genügen.
Allgemein: Ich habe mir die Frage gestellt, was VS und PS voneinander unterscheidet bzw. warum der PS bei allen IHV mehr oder weniger ein Problemkind ist und offensichtlich wesentlich komplizierter und aufwendiger ist. Meine Antwort: 1. PS muss Pixel- *und* Dreiecksdaten unterscheiden/verwalten/speichern. 2. Dependent texture read und die damit verbundenen massiven Latenzen. Mit DXnext und dem Textur-Zugriff auch vom VS aus wird eine GPU sicherlich nicht einfacher oder kleiner...
P.S.
Ich verabschiede mich mit diesem Posting aus diesem Thread.
Demirug
2003-12-09, 19:42:21
Original geschrieben von Gast
Ich würde das zwar trennen, aber meinetwegen.
Kann man bei den moderen Chips >= PS 1.4 leider nicht mehr. Beim Rampage (obwohl nur PS 1.0) hätte man es auch nicht trennen dürfen. Der Textur-Latenz FIFO ist dort immer ein fester bestandteil der Pixelpipeline.
Was meinst du mit "keine zusätzliche Latenz entstehen"? Latenzen sind unvermeidbar, man kann/sollte nur verhindern, dass eine Einheit (PS) untätig ist.
In diesem Sinn war es auch gemeint.
Das Problem trifft also ebenso auf ATI zu. Wenn NV aus noch nicht genannten Gründen weiteren Speicherplatz braucht (mehr als ATI), dann wozu? Anders gefragt, warum gibt es das Temp-Reg Problem, dass ATI angeblich nicht hat? Der NV35 hat ca. 15 Mio. Transistoren mehr als 9800PRO.
Ich habe hier einigen Personen schon versprochen zu den Smartshadern einen ähnlichen Artikel wie für CineFX zu schreiben. Die Frage bezüglich der unterschiede zwischen den Registerfiles ist dabei ein wichtiger Teil. Leider kann ich bei ATI nicht auf ähnlich gutes Material wie bei nVidia zugreifen.
Interessant wie freizügig NV Developer mit Internas versorgt. Oder stammt das aus dem Patent? Mir war diese Information jedenfalls nicht bekannt. Und was genau sind "Speicherzellen"? Ein englischer Begriff würde mir auch genügen.
Eine Speicherzelle entspricht einem Register welches für jeden Pixel eines Pixelquad jeweils einen FP32 Vector4 Wert aufnehmen kann. Also 4*4*32 Bit = 512 Bit oder 64 Byte
Allgemein: Ich habe mir die Frage gestellt, was VS und PS voneinander unterscheidet bzw. warum der PS bei allen IHV mehr oder weniger ein Problemkind ist und offensichtlich wesentlich komplizierter und aufwendiger ist. Meine Antwort: 1. PS muss Pixel- *und* Dreiecksdaten unterscheiden/verwalten/speichern. 2. Dependent texture read und die damit verbundenen massiven Latenzen. Mit DXnext und dem Textur-Zugriff auch vom VS aus wird eine GPU sicherlich nicht einfacher oder kleiner...
Texturen in den Vertexshader gibt es schon ab VS 3.0. Und ja das macht die VS auch komplizierter. Um genau zu sein ist das die einzige Sache die nVidia bei den NV3X Chips zur VS 3.0 kompatibilität fehlt.
Die Textur-Latenz ist nicht erst bei Dependent Reads ein Problem aber diese machen es noch schlimmer.
Bei DX-Next erwarte ich das man langsam Anfängt für Vertex und Pixelshader gemeinsame Einheiten zu benutzen.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.