ALU-Auslastung bei R580 vs. R6xx/R7xx - paar Fragen

[Cpl. Dwayne Hicks]

Hi Leute!

Wir kennen ja das Problem dass alle ATi chips ab dem R6xx haben: sie können keine voneinander abhängigen Shader berechnungen parallel ausfürhren.


Hatte der R580 eigentlich auch schon diese Limitierung? Und hat der R580 auch schon eine VLIW Architektur benutzt?

Ich hab ein bisschen nachgelesen... und habe herausgefunden dass der R580 4 dispatch prozessoren hat welche 4 ALU Blöcke mit 12 pixeln aus jeweils 4 threads füttert.. soviel hab ich schonmal verstanden.... behaupte ich jetzt mal :biggrin:. Wie sah das dann mit Interdependenzen aus... hätte der Dispatch Processor trotzdem die voneinander abhängigen shader-Instruktionen an alle vektor prozessoren weiterleiten können?


Leider habe ich nichts genaues gefunden was meine obige Fragen beantwortet:

Wäre dankbar wenn jemand mir weiterhelfen könnte! :smile:

[Nakai]

Ein kleiner Vorteil des R580, er hat kein DX10 und deswegen sind die Pixelshader nur für Pixelarbeiten verfügbar.


mfg Nakai

€: hätte der Dispatch Processor trotzdem die voneinander abhängigen shader-Instruktionen an alle vektor prozessoren weiterleiten können?

Die Anzahl der Threads vom R520 zum R580 hat sich nicht geändert, obwohl die Shader verdreifacht wurden.

[Cpl. Dwayne Hicks]

Ein kleiner Vorteil des R580, er hat kein DX10 und deswegen sind die Pixelshader nur für Pixelarbeiten verfügbar.


mfg Nakai

€:

Die Anzahl der Threads vom R520 zum R580 hat sich nicht geändert, obwohl die Shader verdreifacht wurden.

Hi Nakai

Könnte es nicht trotzdem innerhalb der Pixelshader (im selben Thread) zu Abhängigkeiten kommen? Würde das dann ein Problem für R5xx darstellen?

[Gast]

VLIW gibt's seit R300 - nur leider hat der NV30 VLIW erstmal negativ besetzt, weswegen es für's Marketing gestorben war.

Sowohl R580 als auch R600 haben vier unabhängige Prozessoren intern. Der Rest ist Schönrechnerei.

[Coda]

R5xx war noch viel limitierter, weil er nur eine Op auf allen 4 Komponenten ausführen konnte.

[Gast]

Er konnte häufiger noch das ADD schedulen.

[Spasstiger]

Mal eine Frage zum G80/GT200, wenn wir schon beim Thema ALU-Auslastung sind:
Der G80 hat ja zwei SIMT/SIMD-Shadercores pro Shadercluster, der GT200 sogar drei davon. Kann nun jeder Shadercore unabhängig voneinander eine andere Komponente eines Pixels berechnen?

Und muss man beim R600/RV670 generell von nur vier SIMD-Shadercores (mit je 16 VEC5-ALUs) reden? Der RV770 hat dann wohl acht SIMD-Shadercores (mit je 20 VEC5-ALUs), oder?

[Cpl. Dwayne Hicks]

Hab grad mal nachgeblättert und soweit ich das verstanden habe Ja, aber es wird eine Instruktion über ein Cluster angewendet, aber dafür führt jeder SP diese Instruktion in seinem eigenen Thread aus... deswegen ja SIMD.
Aber wie sind die SPs im G80 eigentlich angeordnet? Als 2 x RGBA pro shadercore oder ändert sich das von Thread zu thread?

Obwohl offizell noch nichts bekannt ist soll der RV770 10 SIMDS mit je 16 x vec4+1 haben...

[deekey777]

Ich glaube, der RV770 hat 4 SIMDs mit 20 "Double-Pumped"-ALUs und 20 Double-Pumped-TMUs.

[Spasstiger]

Hab grad mal nachgeblättert und soweit ich das verstanden habe Ja, aber es wird eine Instruktion über ein Cluster angewendet, aber dafür führt jeder SP diese Instruktion in seinem eigenen Thread aus... deswegen ja SIMD.
Aber wie sind die SPs im G80 eigentlich angeordnet? Als 2 x RGBA pro shadercore oder ändert sich das von Thread zu thread?
Das mit dem Threading hab ich nich nicht ganz verstanden. Pro Shadercluster führen beim GT200 im Fall von reinen Pixeloperationen alle 24 ALUs die gleiche Operation aus, nur halt in drei verschiedenen Threads? Wo liegt dann der genaue Vorteil der Threads, wenn eh alle das Gleiche machen? Oder bringen die Threads bei reinen Pixeloperationen gar keine Vorteile?

[Cpl. Dwayne Hicks]

Jeder SP hat ja seinen eigenen Thread, sonst könnten alle SPs ja garnicht ausgelastet werden, weil ja der G80 bzw. GT200 kein VLIW benutzt. Im Falle von G80 werden 128 Threads auf 8 Shader operationen angwendet.

Also liegt der Vorteil der Threads liegt darin dass es (im Gegensatz zu R6xx) bei Abhängigkeiten im shadercode kaum Probleme mit der ALU Auslastung gibt.... die Parallelisierung wird gewährleistet.

alle Angaben wie immer ohne Gewähr :wink:

EDIT:

Kannst du einigermaßen gut Englisch? Beyond3d und anandtech haben mir geholfen etwas mehr von der Materie zu verstehen:

http://www.beyond3d.com/content/reviews/1/8

http://www.anandtech.com/video/showdoc.aspx?i=2988&p=6

[Coda]

Aber wie sind die SPs im G80 eigentlich angeordnet? Als 2 x RGBA pro shadercore oder ändert sich das von Thread zu thread?
G80 rechnet seriell. Es werden somit pro Shadercore 8 Programme parallel bearbeitet. Das ist kein Marketing.

Bei R600 ist es so, dass ein Programm durch die Vec5-ALU muss, d.h. die Auslastung kann <5 sein, was bei G80 nur passiert wenn man Bubbles in der Pipeline hat.

Obwohl offizell noch nichts bekannt ist soll der RV770 10 SIMDS mit je 16 x vec4+1 haben...
1-1-1-1-1 wobei eine ALU davon "fett" ist, d.h. auch die Spezialfunktionen bearbeiten kann.

[ShadowXX]

Aber wie sind die SPs im G80 eigentlich angeordnet? Als 2 x RGBA pro shadercore oder ändert sich das von Thread zu thread?

Soweit ich das mitbekommen habe ist der große Unterschied das nV seine Cores Vertikal (quasi seriell) "füttert" während ATI es noch "konventionell" Horizontal macht.

Der Scheduler und das Füttern der Cores ist zumindest bei nV auch ziemlich komplex.

Obwohl offizell noch nichts bekannt ist soll der RV770 10 SIMDS mit je 16 x vec4+1 haben...
Das ist Vermutung eins und die von Deekey ist vermutung zwei.

Ich tendiere zu eins, da irgendwo die fast 1 Milliarde Transistoren ja geblieben sein müssen.

P.S.
ich sehe Coda hat es schon in professionell erklärt.

[Gast]

Ich glaube, der RV770 hat 4 SIMDs mit 20 "Double-Pumped"-ALUs und 20 Double-Pumped-TMUs.
Weil Arun es glaubt? Die Fotos vom CHip sagen was anderes, AMD auch.

[Coda]

Was sagt AMD denn?

[AnarchX]

Was sagt AMD denn?
Das:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6601402&postcount=1072

[Coda]

Da sieht man aber nicht in wieviele Cores es wirklich aufgeteilt wird was die Threads angeht.

[robbitop]

Ich glaube, der RV770 hat 4 SIMDs mit 20 "Double-Pumped"-ALUs und 20 Double-Pumped-TMUs.
Wie kommst du darauf? (ehrlich gemeinte Frage) In der ATI-Folie im Diagramm sieht es aus, als hätte der RV770 10x R600-SIMD-Cluster. (inkl 10x Quad R600 TMUs)

edit: wenn du es glaubst, weil Arun es glaubt, glaubst du es nicht, sondern Arun. ;)
Und auch Arun ist nicht allwissend.

[deekey777]

Weil Arun es glaubt? Die Fotos vom CHip sagen was anderes, AMD auch.
Wie kommst du darauf? (ehrlich gemeinte Frage) In der ATI-Folie im Diagramm sieht es aus, als hätte der RV770 10x R600-SIMD-Cluster. (inkl 10x Quad R600 TMUs)

edit: wenn du es glaubst, weil Arun es glaubt, glaubst du es nicht, sondern Arun. ;)
Und auch Arun ist nicht allwissend.
Jein.
Wer die Diskussion um den RV770 mitverfolgt hat, dem ist vielleicht aufgefallen, dass ich meine Probleme mit "Okto-TMUs" habe. Diese habe ich zu "parallel arbeitenden" TMUs umgelabelt, die die Zusammengehörigkeit von TMU-Quad A und dem ALU-Quad A nicht aufheben. Arun dagegen ging einen Schritt weiter und schrieb was von "Double-Pumped-ALUs".

[robbitop]

Also ATIs Diagramm sagt eben etwas anderes. Ich kann mir kaum vorstellen, dass sie die Tatsachen dermaßen falsch darstellen.
Zumal es bisher noch keine TMUs gab, die auch wirklich 2x bi Samples rausgehauen haben pro Takt. Bisher nur 2xAF oder Tri in einem Takt.
RV770 kann nachweislich 40 bi samples pro Takt raushauen.

[del_4901]

Wir kennen ja das Problem dass alle ATi chips ab dem R6xx haben: sie können keine voneinander abhängigen Shader berechnungen parallel ausfürhren.

19 Antworten und es ist noch niemanden aufgefallen, das das so gar nicht gehen kann.

[deekey777]

Also ATIs Diagramm sagt eben etwas anderes. Ich kann mir kaum vorstellen, dass sie die Tatsachen dermaßen falsch darstellen.
Zumal es bisher noch keine TMUs gab, die auch wirklich 2x bi Samples rausgehauen haben pro Takt. Bisher nur 2xAF oder Tri in einem Takt.
RV770 kann nachweislich 40 bi samples pro Takt raushauen.
Ich bin sicher, dass deine Zehennägen jetzt aufrollen, aber meine "parallelen TMUs" arbeiten so: Es sind zwei eigenständige Quad-TMUs, die zwar an einem Thread arbeiten, aber an unterschiedlichen Pixel-Quads (desselben ALU-Quads). Ein ALU-Quad verarbeitet zunächst vier Pixel, dann die nächsten und dann wieder die nächsten. Das ALU-Quad A bearbeitet also Pixel-Quad 1, dann 2, 3 und 4. Die parallelen TMUs A1 und A2 schwitzen dann nebeneinander an Pixel-Quad 1 (TMU A1) und Pixel-Quad 2 (TMU A2).

Ergibt das einen Sinn?

Zum Thema: http://ati.amd.com/developer/SDK/AMD_SDK_Samples_May2007/Documentations/ATI_Radeon_HD_2000_programming_guide.pdf Eigentlich ab Seite eins (insbesondere ab Seite vier).

[Gast]

Kann nun jeder Shadercore unabhängig voneinander eine andere Komponente eines Pixels berechnen?

jede einzelne ALU rechnet nicht eine einzelne komponenten, es rechnet jede ALU an ihrem eigenen pixel. das ganze hintereinander bis alle komponenten durch sind.

ein core mit 8 ALUs rechnen jeden takt an 8 pixeln, für RGBA werden 4 takte gebraucht.

jeder core kann dabei prinzipiell eine andere instruktion ausführen, auch innerhalb eines clusters, die ALUs eines cores führen allerdings in einem takt immer die selbe operation aus.

[Cpl. Dwayne Hicks]

19 Antworten und es ist noch niemanden aufgefallen, das das so gar nicht gehen kann.

OK OK... :rolleyes:
Was ich meinte ist dass bei Abhängigkeiten nicht alle SPs pro ALU/thread gleichzeitig ausgelastet werden können.

Besser so? :smile:

@ Gast:

Ich glaube nicht dass beide cores eine andere Instruktion ausführen kann, da es ja SIMD Cluster sind.

[robbitop]

Klar kann R600 das. Aber in dem Falle nur horizontal. Vertikal kann er nur effizienter rechnen, sofern es keine Abhängigkeiten gibt. Die R600 ALUs können horizontal rechnen (also wie ihre Vorgänger ALUs) und müssen dort aber mit dem üblichen Verschnitt rechnen oder die 4 von 5 Kanälen können vertikel rechnen, wie G80. Aber nur an einem Programm. (nicht wie G80) Und dann darf es keine Inderdependezen geben. Eigentlich sind es ja laut Schema 16 ALUs also 64 Kanäle die die gleiche Instruktion ausführen pro Takt. Wenn sie horizontal rechnen muss halt alles stimmen. Deswegen und wegen der VLIW-Architektur hängt halt viel vom Compiler ab.
G80 mit deinen ALUs, pro Kanal mit unterschiedlichen Programmen rechnen können und seiner superskalaren Architektur, die das dynamische Verteilen der Parallelität selbst übernimmt, ist oftmals deutlich robuster.
Es klingt aber bitterer als es ist. Der GPU-Programmcode ist von Haus aus recht parallel. Und NVs Methode ist halt recht teuer.

Ich bin sicher, dass deine Zehennägen jetzt aufrollen, aber meine "parallelen TMUs" arbeiten so: Es sind zwei eigenständige Quad-TMUs, die zwar an einem Thread arbeiten, aber an unterschiedlichen Pixel-Quads (desselben ALU-Quads). Ein ALU-Quad verarbeitet zunächst vier Pixel, dann die nächsten und dann wieder die nächsten. Das ALU-Quad A bearbeitet also Pixel-Quad 1, dann 2, 3 und 4. Die parallelen TMUs A1 und A2 schwitzen dann nebeneinander an Pixel-Quad 1 (TMU A1) und Pixel-Quad 2 (TMU A2).

Ergibt das einen Sinn?

Zum Thema: http://ati.amd.com/developer/SDK/AMD_SDK_Samples_May2007/Documentations/ATI_Radeon_HD_2000_programming_guide.pdf Eigentlich ab Seite eins (insbesondere ab Seite vier).
Kannst du das mal bitte grafisch darstellen? Was genau hällt dich eigentlich an dieser Theorie? Eine, die von der Folie abweicht und die dazu auch noch die Granularität herunterzieht? Das kann man weder in Spielen noch für GPGPU gebrauchen.
Das Dokument kenne ich und es gibt in etwa das wieder, was ich oben beschrieben habe.

[Cpl. Dwayne Hicks]

Ich verstehe die ganze Horizontal/Vertikal Geschichte nicht ganz. Und was genau meinst du mit dem "üblichen verschnitt rechnen"

(Mit Abhängigkeiten meinte ich übrigens Interdependenzen)

[robbitop]

Ich verstehe die ganze Horizontal/Vertikal Geschichte nicht ganz. Und was genau meinst du mit dem "üblichen verschnitt rechnen"
Am besten mal ins 2900XT Review reinschauen.

(Mit Abhängigkeiten meinte ich übrigens Interdependenzen)
Das eine ist nur ein Fremdwort für das andere. ;)

[MadManniMan]

Genau die selbe Frage wollte ich auch gerade stellen ... also nochmal das Review wälzen *ächz*

[Coda]

19 Antworten und es ist noch niemanden aufgefallen, das das so gar nicht gehen kann.
Hm? Hast du das "keine" überlesen?

[reunion]

Hm? Hast du das "keine" überlesen?

Wie will man voneinander abhängige Berechnungen parallel ausführen? Man ist ja auf das Ergebnis der ersten Berechnung angewiesen. Oder übersehe ich etwas?

[Coda]

"sie können keine voneinander abhängigen Shader berechnungen parallel ausfürhren."

Steht doch da? Oder bin ich jetzt dumm geworden?

[reunion]

"sie können keine voneinander abhängigen Shader berechnungen parallel ausfürhren."

Steht doch da? Oder bin ich jetzt dumm geworden?

Achso, ja so gesehen stimmt es schon, nur hat dieses "Problem" dann wohl jede GPU und nicht nur AMD.

[robbitop]

Deswegen rechnen G80/90/200 GPUs ja auch verschiedene Programme parallel aber jedes Programm für sich seriell. R600 kann pro SIMD immer nur ein Programm rechnen.

[Coda]

Achso, ja so gesehen stimmt es schon, nur hat dieses "Problem" dann wohl jede GPU und nicht nur AMD.
Das Problem hat z.B. G80 von vornherein nicht weil er keine Vektoroperationen verwendet die nicht ausgelastet sein könnten.

[del_4901]

Hm? Hast du das "keine" überlesen?
nein

[Coda]

Was kann dann "so gar nicht gehen"?

[del_4901]

Was kann dann "so gar nicht gehen"?
das "Problem"

[Coda]

Ich kapier's nicht. Bitte erklär's mir was du meinst.

[robbitop]

@Alphatier

verzichte in Zukunft auf diese sinnfreien Einzeiler. Entweder es wird erläutert oder man klemmt sich das "nein". Damit hilfst du keinem und müllst nebenher noch das Forum zu. Danke.

[Gast]

@ Gast:

Ich glaube nicht dass beide cores eine andere Instruktion ausführen kann, da es ja SIMD Cluster sind.

es sind pro cluster 2 (bzw. beim G200 3) SIMD-cluster, die jeweils einen eigenen befehl ausführen können. (beim G200 kann prinzipiell auch noch jede 64bit-ALU einen eigenen befehl ausführen)

soweit ich weiß ist das allerdings nur über CUDA möglich, da pixelthreads immer 32 pixel groß sind.

[robbitop]

es sind pro cluster 2 (bzw. beim G200 3) SIMD-cluster, die jeweils einen eigenen befehl ausführen können. (beim G200 kann prinzipiell auch noch jede 64bit-ALU einen eigenen befehl ausführen)

soweit ich weiß ist das allerdings nur über CUDA möglich, da pixelthreads immer 32 pixel groß sind.
Ein ganzer Cluster führt pro Takt nur eine Instruktion simultan aus. (beim G80 also 16 Kanäle, beim GT200 24)
Allerdings mit verschiedenen Programmen. Somit ist es schon skalar. Jeder skalare Kanal kann sein eigenes Programm ausführen. Aber es ist halt immer nur eine Instruktion pro Cluster.

[Gast]

@Alphatier

verzichte in Zukunft auf diese sinnfreien Einzeiler. Entweder es wird erläutert oder man klemmt sich das "nein". Damit hilfst du keinem und müllst nebenher noch das Forum zu. Danke.


Es würde reichen, Posting #21 nochmals zu lesen, um "das Problem" zu sehen.

Und ich gebe Alphatier recht. Die parallele Berechnung voneinander abhängiger Shader kann kein Grafikchip durchführen, egal wie er aufgebaut ist.

[Cpl. Dwayne Hicks]

es sind pro cluster 2 (bzw. beim G200 3) SIMD-cluster, die jeweils einen eigenen befehl ausführen können. (beim G200 kann prinzipiell auch noch jede 64bit-ALU einen eigenen befehl ausführen)

soweit ich weiß ist das allerdings nur über CUDA möglich, da pixelthreads immer 32 pixel groß sind.

Quote vom beyond3d artikel:

Inwardly, each 16 SP cluster is further organised in two pairs of 8 (let's call that 8x2) and the scheduler will effectively run the same instruction on each half cluster across a number of cycles, depending on thread type.

So wie ich das da verstehe bekommen beide 8er blöcke in jedem Cluster den gleichen Befehl zugeteilt.

Aber warum wird der Cluster dann überhaupt in 2 Blöcke aufgeteilt wenn auf beide Cluster Hälften eh die gleiche Instruktion gefahren wird? Hat das was mit der Thread Granularität z tun?


http://www.beyond3d.com/content/reviews/1/8

Ich hab auch nie behauptet dass G80 voneinander abhängige Shader parallel berechnen kann... Ich hab lediglich gesagt dass beim R600 in einem solchen Fall Teile der ALUs brach liegen... oder ist das jetzt auch wieder falsch? :D Aber ist ja auch egal jetzt...

[robbitop]

Es würde reichen, Posting #21 nochmals zu lesen, um "das Problem" zu sehen.

Und ich gebe Alphatier recht. Die parallele Berechnung voneinander abhängiger Shader kann kein Grafikchip durchführen, egal wie er aufgebaut ist.
Das hat doch auch keiner behauptet. :|

[del_4901]

Ich hab auch nie behauptet dass G80 voneinander abhängige Shader parallel berechnen kann... Ich hab lediglich gesagt dass beim R600 in einem solchen Fall Teile der ALUs brach liegen... oder ist das jetzt auch wieder falsch? :D Aber ist ja auch egal jetzt...
Warum hast du nicht einfach geschrieben, dass der R600 keine gleichen Befehle die unabhaenig voneinader sind, in seinen SIMD Einheiten zusammenfassen kann? Ich hab extra versucht micht nicht so technisch auzudruecken.

Und ich denke das ist nichtmal ein Problem mit der Hardware sondern einfach nur ein Compiler der das nicht beherscht.
Das hat doch auch keiner behauptet. :|
Doch, ihr habt euch wieder Sachen dazugedacht, die so nicht dastehen. Ich nehm euch das nicht uebel, ich hab das gleiche Problem, ich wollte nur darauf hinweisen. Es war vllt. etwas zu zynisch fuer einen gut gemeinten Hinweis, dafuer werde ich mich jetzt mal entschuldigen.

[Coda]

Okay nochmal für alle was ich gemeint habe:

G80 kann zwar auch keine abhängigen Befehle gleichzeitig ausführen aber es ist nie ein Problem weil er die Programme skalar abarbeitet. D.h. die Auslastung der ALUs ist immer 100% solange keine anderen Pipeline-Stalls auftreten (Texture-Cache-Miss o.ä.)

Der R600-VLIW kann nur ausgelastet werden wenn in einem Programm Parallelität vorhanden ist. Die G80 VLIWs rechnen deshalb einfach auf n Datensätzen rum und zwar ganz ohne Parallelität.

[del_4901]

Okay nochmal für alle was ich gemeint habe:

G80 kann zwar auch keine abhängigen Befehle gleichzeitig ausführen aber es ist nie ein Problem weil er die Programme skalar abarbeitet. D.h. die Auslastung der ALUs ist immer 100% solange keine anderen Pipeline-Stalls auftreten (Texture-Cache-Miss o.ä.)

Der R600-VLIW kann nur ausgelastet werden wenn in einem Programm Parallelität vorhanden ist. Die G80 VLIWs rechnen deshalb einfach auf n Datensätzen rum und zwar ganz ohne Parallelität.

Mit anderen (einfachen) Worten G80 kann z.B n(bis zu 16) Pixel-/Vertexprogramme in einer SIMD Einheit rechnen wenn gleiche Befehle/Befehlsketten in den Programmen vorhanden sind. (Das ist z.B. bei nebeneinanderliegenden Pixeln/Vertices sehr haeufig der Fall, deswegen sagt Coda die Auslastung liegt bei 100%)

R600 kann nur Befehle/Befehlsketten in einer SIMD Einheit rechnen, die in einem Programm vorkommen und unabhaenig sind.


Ich wollte das nur nochmal auftroedeln, nicht das es bei den vielen Fachbegriffen zu Missverstaendnissen kommt.

[Gast]

Mit anderen (einfachen) Worten G80 kann z.B n(bis zu 16) Pixel-/Vertexprogramme in einer SIMD Einheit rechnen wenn gleiche Befehle/Befehlsketten in den Programmen vorhanden sind. (Das ist z.B. bei nebeneinanderliegenden Pixeln/Vertices sehr haeufig der Fall, deswegen sagt Coda die Auslastung liegt bei 100%)
Kann er das wirklich? Oder kann er einfach nur 16 Datensätze für ein Shaderprogramm gleichzeitig bearbeiten?
Kann mir kaum vorstellen, dass der zusätzliche Schedulingaufwand sich rechnen soll.

[robbitop]

Ja das kann er. Und das kostet ja auch ordentlich Transistoren. Dafür ist die Auslastung aber auch eine ganz andere. Damit die Transistorkosten den Mehraufwand nicht auffressen, hat man durch viel Handarbeit dann den Takt nach oben gejagt.

[del_4901]

Kann er das wirklich? Oder kann er einfach nur 16 Datensätze für ein Shaderprogramm gleichzeitig bearbeiten?
Kann mir kaum vorstellen, dass der zusätzliche Schedulingaufwand sich rechnen soll.
Ich nehme schon an das er das kann, die Programme werden einfach anders gepackt, dann muss man sich auch keine Sorgen um das scheudling machen. Bevor man natürlich wieder Pixel draus macht muss man das ganze wieder auspacken. Ziehmlich viele Unterlagen von Nvidia deuten darauf hin, in z.B Cuda verhält sich der VLIW zumindestens nach außen so. Wie das innendrin genau aussieht kann dir nur Nvidia sagen.
Ja das kann er. Und das kostet ja auch ordentlich Transistoren. Dafür ist die Auslastung aber auch eine ganz andere. Damit die Transistorkosten den Mehraufwand nicht auffressen, hat man durch viel Handarbeit dann den Takt nach oben gejagt.
Ich glaube nicht das, das soviel Transistoren kostet, das ein und auspacken ist ja wohl firlefanz. Alles Andere wird wohl ein Compiler erledigen, da steckt natürlich viel know-how drin.

[Coda]

Ich ging bisher immer davon aus, dass alle ALUs die gleiche Op rechnen bei G80 und sich das VLIW nur darauf bezieht, dass MAD und MUL/Special Function/Interpolator gemeinsam angesteuert werden.

[Cpl. Dwayne Hicks]

Aber pro Op gibts doch im G80 16 threads... und demnach können dann auch 16 Programme bearbeitet werden oder?

[Coda]

Ja die Frage ist halt ob alle 16 ALUs auch die gleiche Op = Gleiches Programm ausführen.

Ich würde sagen ja, weil man sonst nämlich auch pro ALU ne eigene Branchlogik braucht etc. Dann wäre auch die Branchgranularität viel besser.

[del_4901]

Ich ging bisher immer davon aus, dass alle ALUs die gleiche Op rechnen bei G80 und sich das VLIW nur darauf bezieht, dass MAD und MUL/Special Function/Interpolator gemeinsam angesteuert werden.
Mit gleicher ALU meinst du doch ein 16xSIMD Cluster? Dann gebe ich dir für den ersten Teil recht.

VLIW bedeutet eigentlich nur, das der Compiler die Drecksarbeit machen darf, damit ist jetzt nicht der ShaderCompiler gemeint, reden wir hier lieber vom "Treiber".
Also nochmal auf deutsch: Ein VLIW lässt die Befehle vom Compiler auf die Ausführungseinheiten verteilen.

Ja die Frage ist halt ob alle 16 ALUs auch die gleiche Op = Gleiches Programm ausführen.

Ne gleiche Op muss nicht aus dem gleichem Shaderprogramm stammen. Es stammt aber aus dem gleichem Programm, was der VLIW-Pre-Compiler (Treiber) geschaffen hat. Letzters kann bunt gemischt sein.

Ich würde sagen ja, weil man sonst nämlich auch pro ALU ne eigene Branchlogik braucht etc. Dann wäre auch die Branchgranularität viel besser.
Wenn du das nochmal so formulierst, das ich das verstehe, kann ich das vllt. sogar beantworten.

[Coda]

Ich kapier's grad auch nicht mehr was du meinst. Wir reden wohl aneinander vorbei.

Ich geh davon aus dass ein 16er SIMD immer das gleiche Programm auf allen 16 ALUs ausführt und von oben kommen dann halt Daten von 16 Pixeln oder 16 Vertices rein. Falls ein Datensatz dann einen Branch nimmt und die andere nicht, dann laufen die Ops dieses Branches trotzdem auf allen 16 ALUs und werden halt auf den restlichen 15 entsprechend maskiert.

Das läuft dann 4 Takte und dann kommt wieder der nächste Thread dran mit anderen 16 Pixeln oder 16 Vertices.

Ich glaube nicht dass da irgendwie verschiedene Programme gleichzeitig aktiv sind in einem 16er SIMD. Das VLIW bezieht sich imho nur darauf, dass es eigentlich zwei SIMDs sind (ein normales und ein Interpolator/Special Function). So "very large" ist das Instruction Word also wohl gar nicht.

[del_4901]

Ich kapier's grad auch nicht mehr was du meinst. Wir reden wohl aneinander vorbei.

Ich geh davon aus dass ein 16er SIMD immer das gleiche Programm auf allen 16 ALUs ausführt und von oben kommen dann halt Daten von 16 Pixeln oder 16 Vertices rein. Falls ein Datensatz dann einen Branch nimmt und die andere nicht, dann laufen die Ops dieses Branches trotzdem auf allen 16 ALUs und werden halt auf den restlichen 15 entsprechend maskiert.

Das läuft dann 4 Takte und dann kommt wieder der nächste Thread dran mit anderen 16 Pixeln oder 16 Vertices.

Ich glaube nicht dass da irgendwie verschiedene Programme gleichzeitig aktiv sind in einem 16er SIMD.
Ja das ist bei Branches natürlich ein Problem (ich stand warscheinlich grad aufm Schlauch), weil die der Compiler nicht vorhersehen kann, müssen die weggeschmissen werden. Das gleiche Problem hat übrigens auch ein Itanium. Dafür brauchen beide keine Steuerlogik und können dafür auch mehr Recheneinheiten auf dem Die unterbringen.

[Coda]

Itanium funktioniert nunmal aber ganz anderes als ein G80 wenn ich nicht falsch liege. Itanium ist ja eher wie R600.

[del_4901]

Itanium funktioniert nunmal aber ganz anderes als ein G80 wenn ich nicht falsch liege. Itanium ist ja eher wie R600.

Die haben alle 3 keine eigene Steuerlogik, und lassen dafür einen Compiler schuften -> VLIW
Wie der die Daten hohlt, ob SIMD, MIMD Einheiten vorhanden sind ist dabei erstmal egal. Wichtig ist nur das der Chip selber nicht zu entscheiden hat welche Reihenfolge und Parallelität die Instuktionen haben dürfen.

[Gast]

Ein ganzer Cluster führt pro Takt nur eine Instruktion simultan aus. (beim G80 also 16 Kanäle, beim GT200 24)
Allerdings mit verschiedenen Programmen. Somit ist es schon skalar. Jeder skalare Kanal kann sein eigenes Programm ausführen. Aber es ist halt immer nur eine Instruktion pro Cluster.
Die skalaren Einheiten führen keine eigene Instruktion aus. Stell es dir einfach als SIMD16 vor. Es wird ein und die selbe Instruktion für 16 Dateneinheiten durchgeführt, genau wie bei SSE, Altivec usw.
NVs marketing nennt das dann Threads, weil sie auch gleich 16Pixel gleichzeitig verarbeiten, von der Hardware ist das bis auf eine etwas bessere Shuffleeinheit am input und output kein Unterschied, entsprechend sind es auch keine Threads und keine Instruktion pro Scalareinheit.

[Coda]

NVIDIA meint mit Threads eigentlich etwas anderes und das sind auch wirklich Threads. Ein Thread läuft auf G80 immer 4 Takte lang auf einer ALU, dann kommt wieder ein anderer.

Das hilft um Latenzen zu verstecken.

[robbitop]

Die skalaren Einheiten führen keine eigene Instruktion aus. Stell es dir einfach als SIMD16 vor. Es wird ein und die selbe Instruktion für 16 Dateneinheiten durchgeführt, genau wie bei SSE, Altivec usw.
NVs marketing nennt das dann Threads, weil sie auch gleich 16Pixel gleichzeitig verarbeiten, von der Hardware ist das bis auf eine etwas bessere Shuffleeinheit am input und output kein Unterschied, entsprechend sind es auch keine Threads und keine Instruktion pro Scalareinheit.
Nichts anderes habe ich gesagt. Ein und die selbe Instruktion pro Cluster. Aber pro Kanal je ein anderes Programm bzw einen Pixel. Ich habe das schon verstanden, keine Angst. ;) Das Problem in dem Thread ist, dass die Nomenklatur dazu führt, dass alle Leute aneinander vorbeireden.

[Gast]

Quote vom beyond3d artikel:

Inwardly, each 16 SP cluster is further organised in two pairs of 8 (let's call that 8x2) and the scheduler will effectively run the same instruction on each half cluster across a number of cycles, depending on thread type.

So wie ich das da verstehe bekommen beide 8er blöcke in jedem Cluster den gleichen Befehl zugeteilt.

Aber warum wird der Cluster dann überhaupt in 2 Blöcke aufgeteilt wenn auf beide Cluster Hälften eh die gleiche Instruktion gefahren wird? Hat das was mit der Thread Granularität z tun?


steht doch genau so da, "the scheduler will effectively run the same instruction on each half cluster"

jede cluster-hälfte führt also in 1 takt die selbe instruktion aus (bzw. beim G200 jedes drittel). da steht nichts davon, dass die andere clusterhälfte nicht parallel eine andere instruktion ausführen kann.

noch eindeutiger wird es hier beschrieben:
http://www.beyond3d.com/content/reviews/51/3

Each SP in each SM runs the same instruction per clock as the others, but each SM in a cluster can run its own instruction. Therefore in any given cycle, SMs in a cluster are potentially executing a different instruction in a shader program in SIMD fashion.

als SM werden bei beyond3d die 8er-SIMDs bezeichnet, wovon es beim G80 2 und beim G200 3 pro cluster gibt.

[Gast]

NVIDIA meint mit Threads eigentlich etwas anderes und das sind auch wirklich Threads. Ein Thread läuft auf G80 immer 4 Takte lang auf einer ALU, dann kommt wieder ein anderer.

Das hilft um Latenzen zu verstecken.Ihre paper, sagen dass sie z.b. beim g80 128stream prozessoren haben von denen jeder einen thread abarbeiten kann und so ihre GigaThread technologie entsteht.
Dabei sind es nur 8 SIMD16 Prozessoren. Und das Threadwechseln alle 4 takte ist eher ne art Hyperthreading mit 4Threads.

[del_4901]

Puh, Ihr habt da Beide irgendwie nicht ganz falsch. Wie soll man das blos erklärn? Ich hab übrigens selber nochmal nachschlagen müssen ... vorhin kahm übrigends Frage wieviele Threads ... es sind 512 (G92) ... und das hängt auch nicht von dem Aufbau der Recheneinheiten ab, sondern nur vom Speicherausbau eben Dieser.

Ein SMID Cluster nimmt sich aus diesem "Threadpool" oder auch Threadblock 32 "Threads" (... ich glaub das hieß früher mal Warp) und bearbeitet diese, dabei ist die volle Parallelität nur garantiert wenn alle Rechenoperationen gleichen Typs sind. (ob das nun 4 Takte dauert ist erstmal egal, Warscheinlich meinen die damit eh nur fetch/decode/exec/writeback, sprich pipelining) Der Threadpool, wird wenn man das nicht selber macht (z.B CUDA) vom VLIW-Compiler(Treiber) angelegt. Ob das nun Pixel oder Vertices sind ist dabei auch erstmal egal, das kann der Treiber entscheiden wie er lustig ist. Damit das ganze funktioniert braucht man natürlich ein intelligentes Scatter und Gather auf dem Chip (Die Shuffleeinheit vom Gast). Ob man das als Threads bezeichnen kann, naja. Also das sind wirkliche mini-Threads, nur ein paar Befehle lang ... keinesfalls zu vergleichen mit dem was man aus der CPU-Programmierung kennt.

[Gast]

Nichts anderes habe ich gesagt. Ein und die selbe Instruktion pro Cluster. Aber pro Kanal je ein anderes Programm bzw einen Pixel. Ich habe das schon verstanden, keine Angst. ;)
dann sorry, shit happens.

Das Problem in dem Thread ist, dass die Nomenklatur dazu führt, dass alle Leute aneinander vorbeireden.wenigstens kann man klugscheissen und die haelfte stimmt einem zu :P

[Gast]

Nichts anderes habe ich gesagt. Ein und die selbe Instruktion pro Cluster. Aber pro Kanal je ein anderes Programm bzw einen Pixel.


hängt jetzt davon ab was wir unter cluster verstehen.

es ist die selbe instruktion pro takt für jedes 8-way-SIMD.

die 2 (bzw. 3) 8er-SIMDs arbeiten gemeinsam als MIMD, können also prinzipiell auch unterschiedliche instruktionen ausführen.

mit CUDA funktioniert das auch, beim pixelshading bin ich mir da nicht sicher, die granularität wird da soweit ich weiß vom setup bestimmt, was immer blöcke zu je 32 pixel rausschmeißt.


Das Problem in dem Thread ist, dass die Nomenklatur dazu führt, dass alle Leute aneinander vorbeireden.

stimmt, ich weiß noch immer nicht was du als cluster bezeichnest, und damit ob du richtig liegst ;)

[robbitop]

Ich meinte schon Cluster, der mehrere SMs beinhaltet. Aber mir war neu, dass jeder "SM" eine eigene Instruktion ausführen kann. Gibt's außer Rys noch eine Quelle (NV Dokument) die das belegen kann?

[del_4901]

Ich meinte schon Cluster, der mehrere SMs beinhaltet. Aber mir war neu, dass jeder "SM" eine eigene Instruktion ausführen kann. Gibt's außer Rys noch eine Quelle (NV Dokument) die das belegen kann?
Du kannst ja hier mal schauen: http://developer.download.nvidia.com/compute/cuda/2.0-Beta2/docs/Programming_Guide_2.0beta2.pdf

[robbitop]

@Gast

falls du im Forum häufiger bist, würde ich dich bitten, dich zu registrieren. Wir brauchen dringenst solch erfahrene User im Forum! Bitte mehr davon. :up:

[Gast]

Ein SMID Cluster nimmt sich aus diesem "Threadpool" oder auch Threadblock 32 Rechenoperationen raus (... ich glaub das hieß früher mal Warps) und bearbeitet diese (ob das nun 4 Takte dauert ist erstmal egal, Warscheinlich meinen die damit eh nur fetch/decode/exec/writeback, sprich pipelining) Der Threadpool, wird wenn man das nicht selber macht (z.B CUDA) vom VLIW-Compiler(Treiber) angelegt. Ob das nun Pixel oder Vertices sind ist dabei auch erstmal egal, das kann der Treiber entscheiden wie er lustig ist. Damit das ganze funktioniert braucht man natürlich ein intelligentes Scatter und Gather auf dem Chip (Die Shuffleeinheit vom Gast). Ob man das als Threads bezeichnen kann, naja. Also das sind wirkliche mini-Threads, nur ein paar Befehle lang ... keinesfalls zu vergleichen mit dem was man aus der CPU-Programmierung kennt.
So langsam geht mir ein Licht auf. Danke. :)

Das würde auch bedeuten, dass Branches keinen Einfluss auf die Performance haben, solange genug passende Rechenoperationen anstehen?

Irgendwie hatte ich den Scheduler für wesentlich simpler gehalten. :up:

[del_4901]

Das würde auch bedeuten, dass Branches keinen Einfluss auf die Performance haben, solange genug passende Rechenoperationen anstehen?

Ne leider nicht. So wie ich das verstanden habe läuft ein Warp auf einem Befehlsfolge bzw. Kontrollfluß. Wenn jetzt ein if/else Konstukt in diesem Kontrollfluß vorkommt. Wird nur einer dieser beiden ausgeführt, der Andere wird rescheudled. Das dumme ist jetzt aber das in einem Warp unterschiedliche Kontrollflüsse vorkommen können. (Das konnte der VLIW Compiler nicht wissen) Tja was macht macht man da, man füllt diese "Threads" entweder einfach mit nops (Itanium) auf. oder rechnet die zwar zuende und verwirft die Ergebnisse(G80). Das kann einen gehörigen Verschnitt zur Folge haben, den ich als Performance-Einbuße wahrnehmen kann.

Ich hätte oben nochmal deutlicher machen sollen, das nur ein Instruktions-Typ Pro Warp zeitgleich ausgeführt werden darf.

[Gast]

Das würde auch bedeuten, dass Branches keinen Einfluss auf die Performance haben, solange genug passende Rechenoperationen anstehen?


glaub ich nicht, allerdings widerspricht sich da irgendwie der CUDA-programming-guide selbst, mal 2 zitate von seite 22:

Individual threads composing a SIMT warp start together at
the same program address but are otherwise free to branch and execute
independently.


A warp executes
one common instruction at a time, so full efficiency is realized when all 32 threads
of a warp agree on their execution path. If threads of a warp diverge via a datadependent
conditional branch, the warp serially executes each branch path taken,
disabling threads that are not on that path, and when all paths complete, the threads
converge back to the same execution path. Branch divergence occurs only within a
warp; different warps execute independently regardless of whether they are
executing common or disjointed code paths

[Cpl. Dwayne Hicks]

steht doch genau so da, "the scheduler will effectively run the same instruction on each half cluster"

jede cluster-hälfte führt also in 1 takt die selbe instruktion aus (bzw. beim G200 jedes drittel). da steht nichts davon, dass die andere clusterhälfte nicht parallel eine andere instruktion ausführen kann.

noch eindeutiger wird es hier beschrieben:
http://www.beyond3d.com/content/reviews/51/3



als SM werden bei beyond3d die 8er-SIMDs bezeichnet, wovon es beim G80 2 und beim G200 3 pro cluster gibt.

Sorry aber ich checks nicht...

Wenn jede Cluster Hälfte die gleiche instruktion ausführt, wie kann denn auf einmal jede Hälfte parallel eine andere Instruktion ausführen? Irgendwie ist das doch ein Wiederspruch.
Sogesehen erhält jeder Cluster ja dann doch 2 Instruktionen... aber dann ist es ja kein "Single Instruction Multiple Data" mehr?

Oder werden 2 Instruktionen (vom VLIW Treiber) in einer "Über Instruction" zusammengefasst und dann, nachdem sie am Cluster Scheduler "angekommen" sind, auf die beiden Cluster Hälften aufgeteilt?

Nicht dass ich dir nicht glaube, du hast offensichtlich mehr Ahnung als ich, aber wiegesagt ich verstehe es im moment nicht. :smile:

[del_4901]

Sorry aber ich checks nicht...

Wenn jede Cluster Hälfte die gleiche instruktion ausführt, wie kann denn auf einmal jede Hälfte parallel eine andere Instruktion ausführen? Irgendwie ist das doch ein Wiederspruch.
Sogesehen erhält jeder Cluster ja dann doch 2 Instruktionen... aber dann ist es ja kein "Single Instruction Multiple Data" mehr?

Oder werden 2 Instruktionen (vom VLIW Treiber) in einer "Über Instruction" zusammengefasst und dann, nachdem sie am Cluster Scheduler "angekommen" sind, auf die beiden Cluster Hälften aufgeteilt?

Nicht dass ich dir nicht glaube, du hast offensichtlich mehr Ahnung als ich, aber wiegesagt ich verstehe es im moment nicht. :smile:
Ich denke mal er hat sich da nur vertippt da steht eindeutig das da zu einem Zeitpunkt immer nur eine Instuktion drin ist. Die Hälften rechnen nur auf unterschiedlichen Daten.

[Gast]

Wenn jede Cluster Hälfte die gleiche instruktion ausführt, wie kann denn auf einmal jede Hälfte parallel eine andere Instruktion ausführen? Irgendwie ist das doch ein Wiederspruch.


die formulierung ist nur etwas unglücklich, lies den G200-artikel, da ist sie eindeutig.

hier steht: "the scheduler will effectively run the same instruction on each half cluster".

auf deutsch: der scheduler lässt auf jeder clusterhälfte die selbe instruktion laufen. da steht nirgends, dass auf beiden clusterhälften die selbe instruktion läuft.


Sogesehen erhält jeder Cluster ja dann doch 2 Instruktionen... aber dann ist es ja kein "Single Instruction Multiple Data" mehr?

G80+ besteht aus einer reihe von 8-way-SIMDs, es gibt keine 16-way-SIMDs oder gar 24-way-SIMDs.


Nicht dass ich dir nicht glaube, du hast offensichtlich mehr Ahnung als ich, aber wiegesagt ich verstehe es im moment nicht. :smile:

nicht wirklich, ich schreib auch nur ab und beziehe den großteil meines wissens von den beyond3d-artikeln ;)