SIMD bei VLIW (Split aus Trinity) [Archiv]

Archiv verlassen und diese Seite im Standarddesign anzeigen : SIMD bei VLIW (Split aus Trinity)

Skysnake

2011-11-05, 18:04:40

800 / 0,7 / 2 = ~571

576SPs @ VLIW4?

CPU-Taktraten habe ich ähnlich geschätzt:

Oder kann man erwarten, dass die CPU auf 3,8GHz läuft, während die GPUs mit ihren 709MHz rechnet?
edit: Ach bis zu 125W TDP, da sollte wohl beides gleichzeitig möglich sein.

Wenn man mit den APUs in diese Richtung geht, aber bitte doch dann gleich 3 Speicherkanäle...
Wenn bitte gleich ein Quad-Interface. Wenn schon denn schon.

Btw. warum reden die von SIMDs? SIMDs sind es doch erst mit GCN, vorher VLIW4/5

Oder haben die bei der HD 6k/7k auch schon von SIMD fälschlicherweise gesprochen?

AnarchX

2011-11-05, 18:45:32

Skysnake

2011-11-05, 20:32:47

Schon seit R600 wird von SIMDs gesprochen: http://www.computerbase.de/artikel/grafikkarten/2007/test-ati-radeon-hd-2900-xt/3/#abschnitt_technik_im_detail_part_1

Aber was soll an dieser Bezeichnung falsch sein? :|
ganz einfach, weil es VLIW ist und kein SIMD! :freak:

und selbst wenn du ne CU betrachten würdest, wäre das kein SIMD sondern MIMD.

soweit klar oder?

Ravenhearth

2011-11-06, 00:32:59

ganz einfach, weil es VLIW ist und kein SIMD! :freak:

und selbst wenn du ne CU betrachten würdest, wäre das kein SIMD sondern MIMD.

soweit klar oder?

Ich kenn mich zwar nicht besonders aus, dachte aber bisher, dass es tatsächlich Single Instruction Multiple Data wäre.:confused:

Coda

2011-11-06, 01:12:26

Es ist SIMD (Data bezieht sich dabei auf einen "Thread"), wobei jede Instruction VLIW ist. Ihr habt beide recht.

MIMD trifft aber definitiv nicht zu.

Spasstiger

2011-11-06, 01:17:26

Ich kenn mich zwar nicht besonders aus, dachte aber bisher, dass es tatsächlich Single Instruction Multiple Data wäre.:confused:
Eine Compute Unit besteht aus mehreren Vec16-SIMDs, die jeweils unterschiedliche Befehle abarbeiten können. Außerdem kommt noch die Scalar Unit dazu. Alles in allem ist eine CU als eine MIMD-Einheit.

Es ist SIMD (Data bezieht sich dabei auf einen "Thread"), wobei jede Instruction VLIW ist. Ihr habt beide recht.
Werden die mehreren parallelen SIMDs in einer CU per VLIW angesteuert? Aber selbst wenn das so ist, die dedizierte Scalar Unit macht die CUs zu MIMDs.

/EDIT: Wir müssen aufpassen, ob wir von GCN oder Trinity reden. ;)

Skysnake

2011-11-06, 10:02:15

Es ist SIMD (Data bezieht sich dabei auf einen "Thread"), wobei jede Instruction VLIW ist. Ihr habt beide recht.

MIMD trifft aber definitiv nicht zu.

Ne SIMD Uni kann aber kein VLIW verarbeiten. Das sind unterschiedliche Konzepte. nVidia hat echte SIMDs. Da bekommte jede ALU in einem Takt die gleiche! Instruktion ab. Daher ist ein CU bei nVidia ja auch eine SIMD Unit.

Bei der VLIW4/5 Architektur, haste aber eben keine SIMD Units, weil du mit VLIW arbeitest. Die ALUs bekommen nicht alle die gleiche Instruction, sondern eben unterschiedliche, die in einem VLIW codiert sind. Erst wenn man das VLIW als eine gleichartige Instruction ansieht, dann würde das erst zum SIMD. Dann darfst du aber nicht mehr von 4/5 ALUs reden, die ein VLIW ausführen, sondern nur noch von einer ALU, die eben eine Instruction ausführt.

Dann und nur dann kannst du eigentlich das als SIMD wieder bezeichnen. Es gibt ja nicht ohne Grund die Unterscheidung zwischen SIMD und VLIW.....

Aber gut, wenn AMD mal wieder auf Definitionen kackt, dann seis drum. Bei BD interessiert Sie die Definition eines Cores ja auch nicht....:udown:

EDIT:
Und ja, in die neue XBox wird wohl ne APU wandern.

Da seh ich dann btw. ziemliches Potenzial auf uns zukommen, da die Optimierungen der XBox dann auch den APU-Usern im Desktop wohl zugute kommen würden. Sprich mit ner APU hat man ne XBox @home :ugly:

Coda

2011-11-06, 10:53:44

Ne SIMD Uni kann aber kein VLIW verarbeiten. Das sind unterschiedliche Konzepte.
AMD bezeichnet das so, und doch kann sie. Weil die "Single Instruction" dabei eben auf VLIW-Instruction bezieht.

Es sind 16 Einheiten die gleichzeitig in vier Takten 64 Thread bearbeiten, wobei immer die gleiche VLIW-Instruction für jeden Thread ausgeführt werden.

NVIDIA bezeichnet das gleiche Prinzip oft als SIMT, wobei da tatsächlich nur skalare Instructions zum Einsatz kommen.

Skysnake

2011-11-06, 22:06:21

AMD bezeichnet das so, und doch kann sie. Weil die "Single Instruction" dabei eben auf VLIW-Instruction bezieht.

Es sind 16 Einheiten die gleichzeitig in vier Takten 64 Thread bearbeiten, wobei immer die gleiche VLIW-Instruction für jeden Thread ausgeführt werden.

NVIDIA bezeichnet das gleiche Prinzip oft als SIMT, wobei da tatsächlich nur skalare Instructions zum Einsatz kommen.
coda, SIMT ist auch richtig, wenn man es genau nimmt, da du ja unterschiedliche Programmabläufe haben kannst.

SIMD und VLIW schließen sich aber konzeptionell aus. Schlag jedes x beliebige Buch zu Prozessorarchitekturen auf, dann kannste das nachlesen. Bei nvidia kannste aber dennoch noch von SIMD sprechen, da es an und für sich eben SIMD-Units mit einer Maskierungsfunktion und dem sequenziell getrennten abläufen der Threads. SIMT ist aber natürlich 100% richtig, aber eben schon im größeren Zusammenhang gesehen mit Frontend etc.

Gipsel

2011-11-06, 23:30:39

coda, SIMT ist auch richtig, wenn man es genau nimmt, da du ja unterschiedliche Programmabläufe haben kannst.Nein, kann man nicht wirklich. Mehr als Lane Masking geht nicht. Alles, was unter die Bezeichnung "irreducible control flow" fällt, geht prinzipiell nicht. Das sind wirklich nur einzelne Elemente eines Vektors, die (wie bei SIMD üblich) in lockstep ausgeführt werden. Es gibt genau einen Intruction pointer für alle Elemente in einem Vektor (Wavefront/Warp) zusammen. Das sind ganz einfach keine Threads.
SIMD und VLIW schließen sich aber konzeptionell aus.Nein. Coda hat das schon richtig geschrieben. AMDs bisherige GPUs nutzen (genau we die von nv) SIMD-Einheiten. Der einzige Unteschied ist, was das "I" genau für eine Instruktion ist. Bei AMD ist es eine VLIW-Instruktion, bei nvidia ein "normale", die nur eine Operation enkodiert.
Schlag jedes x beliebige Buch zu Prozessorarchitekturen auf, dann kannste das nachlesen.Wenn das stimmen sollte, war der jeweilige Author ein Idiot (ja, das ist vollkommen ernst gemeint). VLIW ist eine Alternative zu (dynamischen) multiple issue von Befehlen. Historisch gesehen ist die Idee zwar als (billigere) Alternative zu superskalaren Rechner (was multi-issue fähige skalare sind) entstanden. Aber das Prinzip ist vollkommen orthogonal zur Frage Skalarrechner oder SIMD/Vektorrechner. Genauso wie es single-issue und multi-issue-fähige Vektorrechner gibt, gibt es auch VLIW-Vektorrechner. Und auf AMDs GPUs bezogen sind das eben S-VLIW-MD-Rechner.
Bei nvidia kannste aber dennoch noch von SIMD sprechen, da es an und für sich eben SIMD-Units mit einer Maskierungsfunktion und dem sequenziell getrennten abläufen der Threads. SIMT ist aber natürlich 100% richtig, aber eben schon im größeren Zusammenhang gesehen mit Frontend etc.
Der einzige Zusammenhang, wo man "SIMT" vielleicht irgendwie gelten lassen könnte, sind die work groups (AMD/OpenCL, bei nv thread block genannt), die aus mehreren (Hardware-)Threads (d.h. also Wavefronts bzw. Warps) bestehen. Wobei der Begriff "SIMT" an sich meiner Meinung eigentlich schon totaler Schwachsinn ist.

Skysnake

2011-11-07, 09:29:56

Naja, du hast schon nen Controllflow und damit unterschiedliche Instructioncounter. Ansonsten könntest du innerhalb einer Workgroupe ja keine if(..) realisieren. Da kann ja ein Element für eine ALU den einen Weg nehmen, und das nächste Element den anderen. Wird halt sequenzialisiert. Daher "wissen/sehen" die ALUs nichts davon, das man unterschiedliche Programmpfade hat, die abgelaufen werden.

SIMT passt daher schon, nur sind die ALUs nur als SIMD ausgelegt. Deswegen muss man ja sequenzialisieren in so einem Fall.

Und Gipsel, einigen wir uns drauf, ich schau mal das ich Zeit finde zum Bücher wälzen und mach dann mal ein kleines Quote zu dem Punkt.

Coda

2011-11-07, 09:40:53

Es gibt keine unterschiedlichen Instruction-Counter. Branching wird über Maskierung erreicht.

Skysnake

2011-11-07, 10:01:49

Wie genau die Sache umgesetzt wird, spielt da ja auch keine Rolle. Du hast halt etwas, das sich wie ein Thread verhält für den User der Hardware.

Coda

2011-11-07, 10:19:41

Es verhält sich eben nicht immer wie ein Thread. Und nicht nur was Performance angeht.

Gipsel

2011-11-07, 10:23:38

Wie genau die Sache umgesetzt wird, spielt da ja auch keine Rolle. Du hast halt etwas, das sich wie ein Thread verhält für den User der Hardware.
Doch, das spielt eine Rolle, da Du eben wie erwähnt nicht alles machen kannst, was sonst möglich wäre. Innerhalb eines Vektors (Warp/Wavefront) kannst Du z.B. keine zwei Zweige (if else) aufmachen, die sich an irgendeiner Stelle darin synchronisieren, also die Elemente, die den if-Zweig nehmen, können z.B. nicht auf die im else-Zweig warten. Dazu müssen sie in zwei echt verschiedenen Threads sitzen, was bei GPUs heißt, es müssen verschiedene Wavefronts/Warps sein. Dies sind also die Hardware-Threads, und nur diese haben auch einen eigenen Instruction Pointer.

Und weil sich alle "Threads" so verhalten wie die Elemente eines Vektors, ist die Bezeichnung "Thread" schlicht Unsinn. OpenCL bezeichnet die nicht umsonst nur als "work item". Threads arbeiten immer einen ganzen Vektor ab (also die Wavefronts/Warps) und nur diese können wirklich andere Pfade bei der Ausführung nehmen. OpenCL abstrahiert diese Hardware-Threads (und auch die Vektorlänge). Dort kann man halt nur mit den workgroups arbeiten, was je nach zugrunde liegender Hardware eine Zusammenfassung einer unterschiedlichen Menge an Threads oder auch über eine Schleife implementiert werden kann.

Skysnake

2011-11-07, 10:44:39

Gipsel

2011-11-07, 13:42:54

Ähm... Das sollte eigentlich gehen. Jetzt nicht direkt, aber in einem zweiten Schritt. Du musst halt den Fall abdecken, dann zuerst der Else Zweig ausgeführt wird und dann erst der IF Zweig. Aber möglich sollte das sein, wenn ich nicht gerade etwas fatales vergessen habe. Man muss halt beide Möglichkeiten kodieren, und dazwischen eine Fence packen, dann sollte das funktionieren, ist aber sehr sehr sehr eklig.Das würde nur gehen, wenn man sowas wie die mal "rumorierte" dynamic warp formation hätte. Sprich, bei einem Branch werden zwei neue Threads (Warps/Wavefronts) aufgemacht, die die beiden Teilzweige für die jeweiligen work items abarbeiten (die Zuordnung der work items zu den Warps/wavefronts wird also on-the-fly geändert/umsortiert).
Ansonsten ist es prinzipiell unmöglich, daß mitten im if-Zweig auf den else-Zweig gewartet wird, weil der eben nicht gleichzeitig zum if-Zweig abgearbeitet werden kann (umgekehrt genauso). Taucht also im if-Zweig eine Barriere auf, warten dort alle Elemente des Warps/der Wavefront. Die Elemente, die den Zweig nicht genommen haben (also maskiert sind) können nicht weiterlaufen und erreichen somit auch nie den else-Zweig. Sowas nennt man eine deadlock-Situation, die sich hier prinzipiell nicht vermeiden läßt, weil die work-items halt nur Elemente eines Vektors sind und keine Threads.
Sodele, jetzt aber mal einen kurzen Abstecher zu SIMD vs. VLIW:

Brinkschulte Ungerer "Mikrocontroller und Mokroprozessoren" Springer 2002
S. 262 6.5 "Die VLIW-Technik"

Den wichtigen Teil habe ich mal fett markiert.
Der aber nichts darüber sagt, daß es keine Kombination von VLIW und SIMD geben kann. ;)
Jetzt klar, warum SIMD!=VLIW? Es ist einfach nicht das Selbe, wie ich schon die ganze Zeit gesagt habe.
Das Gleiche ist es ja auch nicht, es schließt sich gegenseitig nur nicht aus, man kann es also kombinieren.
Und die HD5k/6k etc. sind einfach VLIW Architekturen und KEINE! SIMD Architekturen. Entweder oder, aber nicht beides.Na klar sind sie beides. Eine einzelne VLIW-Instruktion besteht aus (bis zu) 5 Operationen, die im SIMD-Prinzip auf Vektoren mit 64 Elementen (eine Wavefront) angewendet wird.
Wie schon gesagt, genauso wie es bei skalaren Rechnerarchitekturen single-issue und multiple issue (dann meist superskalar genannt) sowie auch den VLIW-Ansatz gibt, kann man auch bei Vektorarchitekuren (wie den GPUs) single-issue, multi-issue oder VLIW Varianten bauen. Was ist denn daran unklar?
GCN soll wirklich SIMD werden, und dann können wir auch von SIMD sprechen, aber dann eben nicht mehr von VLIW.
GCN wird genauso SIMD nutzen, wie dies die heutigen AMD-GPUs und auch nVidias GPUs tun, sogar die Vektorlänge bleibt gleich. GCN erweitert das allerdings um echte skalare Operationen, bisherige GPUs haben praktisch einen reinen SIMD/Vektor-Instruktionssatz (Controlflow ist das einzig skalare). Damit nähert man sich in einem ganz high-level Bild ein wenig Larrabees Ausführungsmodell (oder allgemein dem von CPUs mit SIMD/Vektorerweiterung) an, ein skalarer (x86er-)Kern kombiniert mit einer breiten Vektoreinheit. Bei GCN ist es eben eine (Integer-) Skalareinheit kombiniert mit 4 Vektoreinheiten, und alles noch deutlich heftiger multithreaded.

Skysnake

2011-11-07, 20:07:22

Gipsel, ich würde eine Kombination mit VLIW aber nicht als SIMD bezeichnen, sondern als MIMD. Einfach deswegen, weil man mehrere Instruktionen hat. Ein VLIW ist für mich keine einzelne Instruktion.

Und ich finde nicht das sich GCN den CPUs annähert, oder besser gesagt, ja schon irgendwie, aber mir liegt der Vektorrechner viel viel näher bei der Betrachtung als ne CPU.

Bei den Vektorrechnern gibt es ja auch diese Unterteilung zwischen kleiner Skalar-Unit und großer Vektorunit etc.

@WArps bla blub.
Sollte eigentlich schon gehen. Mach nen If-Else Zweig, der ausgeführt wird, dann ne Barrier, dann führ es umgekehrt aus, und mach halt ne Kontrollogig mit nem nochmaligen if-else etc. um sicher zu stellen, das du nicht bereits im ersten Abschnitt das Ergebnis berechnet hast, und dann halt wieder ne Barrier. Sollte mit den Barriers eigentlich schon möglich sein. Du berechnest einfach etwas, und entscheidest erst nach der ersten Barrier, ob das Ergebnis richtig ist, oder nicht. Kannst ja ne shared Variable nehmen, die die im Else Zweig dann kopieren sollen, womit du den zeitlichen Ablauf checken kannst. Performante ist aber was anderes, sollte aber eigentlich funktionieren. Zumindest seh ich jetzt einfach keinen Grund warum es nicht gehen sollte, was aber natürlich nicht heißen muss, das es nicht doch ein Problem geben kann, warum es dann doch nicht geht. Ich seh dieses Problem nur nicht.

Naja, soll ja auch Syncs über alle Workgroups geben, hab ich sogar mal versucht ein zu setzen, hat aber nicht das gewünschte gemacht. Kann also wie gesagt sein, dass da irgendwas ganz tricky ist und deswegen nicht geht.

Gipsel

2011-11-07, 21:35:57

Gipsel, ich würde eine Kombination mit VLIW aber nicht als SIMD bezeichnen, sondern als MIMD. Einfach deswegen, weil man mehrere Instruktionen hat.Flynn ist nicht das Ende aller Bezeichnungen. Ein wenig genauer kann man es (und muß es auch!) ja schon machen. Ansonsten kannst Du genauso argumentieren, daß superskalare Prozessoren genau wie skalare VLIW-CPUs auch schon MIMD wären (letztendlich wäre fast alles MIMD), was es ja zum einen nicht wirklich trifft, und zum anderen vollkommen an der Intention des Herrn Flynn bei der Einteilung vorbei geht. Das ist einfach nicht spezifisch genug.

Das häufig weggelassene Detail bei Flynns Taxonomie ist nämlich das Wörtchen "stream". Es ging ihm eigentlich um die Anzahl der simultan abgearbeiteten Instruktionsströme bzw. Datenströme. Und auch VLIW-Architekturen haben erstmal nur einen Instruktionsstrom, es ist auf jeden Fall SI** (genau wie superskalare CPUs). ;)

Die Originaldefinition für MIMD (aus: Michael J Flynn, IEEE Transactions on Computers. Vol. c-21, No.9, September 1972) lautet übrigens, es gäbe mindestens 2 Möglichkeiten:
"1. True Multiprocessors: Many independent SI [single instruction stream] processors share storage at some level for cooperative execution of a multitask program
2. Shared Resource Multiprocessor: Skeleton processors are arranged to share system resource.",
also trifft es je nach Strenge der Auslegung erst auf Multithreading, Multicores oder gar erst Multi-Prozessor-Setups zu.

Ein VLIW ist für mich keine einzelne Instruktion.Für andere schon. Letzendlich ist es Semantik und auch irrelevant, weil es so oder so nur einen einzelnen Instruktionsstrom darstellt. ;)
Und ich finde nicht das sich GCN den CPUs annähert, oder besser gesagt, ja schon irgendwie, aber mir liegt der Vektorrechner viel viel näher bei der Betrachtung als ne CPU.Na, in die Richtung gehen die CPUs mit ihren (immer breiteren und umfänglicheren) Vektorerweiterungen aber auch irgendwie. ;)
Sollte eigentlich schon gehen. Mach nen If-Else Zweig, der ausgeführt wird, dann ne Barrier, dann führ es umgekehrt aus, und mach halt ne Kontrollogig mit nem nochmaligen if-else etc. um sicher zu stellen, das du nicht bereits im ersten Abschnitt das Ergebnis berechnet hast, und dann halt wieder ne Barrier. Sollte mit den Barriers eigentlich schon möglich sein. Du berechnest einfach etwas, und entscheidest erst nach der ersten Barrier, ob das Ergebnis richtig ist, oder nicht. Kannst ja ne shared Variable nehmen, die die im Else Zweig dann kopieren sollen, womit du den zeitlichen Ablauf checken kannst. Performante ist aber was anderes, sollte aber eigentlich funktionieren. Zumindest seh ich jetzt einfach keinen Grund warum es nicht gehen sollte, was aber natürlich nicht heißen muss, das es nicht doch ein Problem geben kann, warum es dann doch nicht geht. Ich seh dieses Problem nur nicht.Das Problem ist ganz einfach, daß wenn in einem Zweig eine Barriere stehen würde, der ganze Thread (Wavefront/Warp) nicht mehr weiterläuft. Du kannst also gar nicht beide Zweige nacheinander in umgekehrter Reihenfolge mit entsprechendem Lane Masking durchlaufen. Das Ding hält bei der ersten Barriere an und es ist Ende Gelände.
In den realen Implementationen wird das so aufgelöst, daß Du in einer Wavefront gar nicht explizit zwei Zweige gegeneinander synchronisieren kannst. Es gibt praktisch zwei Barrieren und damit auch zwei Synchronisationspunkte: einen für alle Elemente im if-Zweig (für die das nicht gültig ist, sind dort maskiert), und einen zweiten für den else-Zweig. Aber das ein Element im if-Zweig wartet, bis ein anderes Element der gleichen Wavefront im else-Zweig angekommen ist, geht definitiv nicht.

Die einzige "Ausnahme" (es ist keine) ergibt sich, wenn eine Workgroup z.B. aus 2 Hardware-Threads (Warps/Wavefronts) besteht, und in einem Thread alle Elemente den if-Zweig nehmen und im anderen Thread alle Elemente den else-Zweig (dann geht das nämlich über "echten" Kontrollfluß und nicht über Lane-Masking mit doppeltem Durchlauf). Dann und nur dann könnte man im Prinzip den if-Zweig eines Threads mit dem else-Zweig eines anderen Threads synchronisieren. Wobei ich nochmals betone, daß Thread hier wieder eine komplette Wavefront/Warp bedeutet.

edit:
Dein Vorschlag läuft übrigens in letzter Konsequenz darauf hinaus, eine Software-Simulation zu schreiben die das Scheduling für die Ausführung von z.B. 64 Threads auf einem Single-Thread-Prozessor nachbildet. Das kann man mit der gleichen Berechtigung die unabhängige Ausführung von 64 Threads nennen, als wenn man sagt, daß eine x86-CPU zu beliebigen Befehlssätzen kompatibel ist, da man ja einen entsprechenden Emulator programmieren könnte.

Skysnake

2011-11-07, 21:49:21

Für andere schon. Letzendlich ist es Semantik und auch irrelevant, weil es so oder so nur einen einzelnen Instruktionsstrom darstellt. ;)
Na, in die Richtung gehen die CPUs mit ihren (immer breiteren und umfänglicheren) Vektorerweiterungen aber auch irgendwie. ;)
Das Problem ist ganz einfach, daß wenn in einem Zweig eine Barriere stehen würde, der ganze Thread (Wavefront/Warp) nicht mehr weiterläuft. Du kannst also gar nicht beide Zweige nacheinander in umgekehrter Reihenfolge mit entsprechendem Lane Masking durchlaufen. Das Ding hält bei der ersten Barriere an und es ist Ende Gelände.
In den realen Implementationen wird das so aufgelöst, daß Du in einer Wavefront gar nicht explizit zwei Zweige gegeneinander synchronisieren kannst. Es gibt praktisch zwei Barrieren und damit auch zwei Synchronisationspunkte: einen für alle Elemente im if-Zweig (für die das nicht gültig ist, sind dort maskiert), und einen zweiten für den else-Zweig. Aber das ein Element im if-Zweig wartet, bis ein anderes Element der gleichen Wavefront im else-Zweig angekommen ist, geht definitiv nicht.

Was anderes habe ich auch NIE behauptet :ugly: Ich glaub wir reden aneinander vorbei ;D

Die einzige "Ausnahme" (es ist keine) ergibt sich, wenn eine Workgroup z.B. aus 2 Hardware-Threads (Warps/Wavefronts) besteht, und in einem Thread alle Elemente den if-Zweig nehmen und im anderen Thread alle Elemente den else-Zweig (dann geht das nämlich über "echten" Kontrollfluß und nicht über Lane-Masking mit doppeltem Durchlauf). Dann und nur dann könnte man im Prinzip den if-Zweig eines Threads mit dem else-Zweig eines anderen Threads synchronisieren. Wobei ich nochmals betone, daß Thread hier wieder eine komplette Wavefront/Warp bedeutet.

Das ist ja eh logisch aber nicht gemeint. Ging schon darum, das man so etwas dadurch implementieren kann, das man halt die Threads nacheinander alles doppelt durchlaufen lässt, um zu gewährleisten, dass die Reihenfolge eingehalten wird.
Wie gesagt effektiv ist etwas anderes....

Ja, wenn Du Workgroups der Größe 1 festlegst und dann die Workgroups global synchronisierst, geht es, aber dann hast Du natürlich auch für jedes Work Item einen eigenen Hardware-Thread. ;)
[/quote]
Na, da gibt es inzwischen so ne Strange CUDA Funktion, die das ermöglichen soll. Sie funktioniert nur eben nicht :ugly:
Oder sagen wirs mal so. Bei mir hat Sie nicht das gemacht, was Sie tun sollte....:rolleyes:
Musst mal ins CUDA4 (glaub ich wars) Manual schauen, da ist die Funktion aufgeführt.

Gipsel

2011-11-07, 21:59:53

Was anderes habe ich auch NIE behauptet :ugly: Ich glaub wir reden aneinander vorbei ;DIch rede davon, daß ein echter Thread in einem if-Zweig auf einen anderen Thread warten kann, bis dieser im else-Zweig angekommen ist. Die Elemente eines Vektors bei GPUs können das nicht, weil es eben keine Threads sind. Es sind alle gleichzeitig im if-Zweig und genauso sind alle gleichzeitig im else-Zweig, sie können nicht wirklich divergieren, es gibt eben nur einen einzigen Instruction Pointer für alle Elemente zusammen.

Skysnake

2011-11-07, 23:56:27

naja, du kannst aber eben sowohl den if als auch den else Zweig betreten innerhalb einer Wavefront, mit beliebiger Verteilung. Klar, die Sache wird Serialisiert, aber das wars auch. Dennoch kann man von Threads sprechen, da die Programmteile der beiden Zweige einen unterschiedlichen Programmablauf nehmen.

Wie willste sonst die Fähigkeit dazu nennen?

Nur ein Prozess kanns nicht sein. Das ist klar.

So wenn es nicht MultiThread ist, kanns nur noch ein einzelner Thread sein. Das würde aber bedeuten, das es gar keine Verzweigung bei Branches geben kann. Der Thread läuft ja entweder so rum oder anders rum.

Bzw. jaja, wenn mans GANZ genau nimmt, würde man einfach mit Maskierung einer SIMD-Unit argumentieren, die dann dementsprechend eben immer alle Möglichkeiten der Verzweigungen abprüft und dann auch ausführt, sobald ein Argument diese Bedingung erfüllt.

Das ist ja auch Quasi das, was die Hardware macht, nur ist die Analogie zu nem SIMT eben sehr schön, da man die Sache eben sehr schön als einzelne Threads mit individuellem Instructioncounter sehen. Der Programmierer sieht ja Quasi nicht, dass die beiden Zweige sequenziell ausgeführt werden. Für Ihn sieht das schon so aus, als ob es einzelne Threads wären.

Ach lassen wir doch einfach die Diskussion, man kann irgendwie immer in die eine oder andere Richtung argumentieren, wenn ich mir das so anschaue.

Ich finde es aber dennoch noch immer Strange, das AMD bei VLIW von SIMD-Units spricht. Das passt bei mir einfach nicht zusammen :D

Gipsel

2011-11-08, 01:16:20

Bzw. jaja, wenn mans GANZ genau nimmt, würde man einfach mit Maskierung einer SIMD-Unit argumentieren, die dann dementsprechend eben immer alle Möglichkeiten der Verzweigungen abprüft und dann auch ausführt, sobald ein Argument diese Bedingung erfüllt.

Das ist ja auch Quasi das, was die Hardware machtGanz genau.
nur ist die Analogie zu nem SIMT eben sehr schön, da man die Sache eben sehr schön als einzelne Threads mit individuellem Instructioncounter sehen.Den es aber genau nicht gibt.
Der Programmierer sieht ja Quasi nicht, dass die beiden Zweige sequenziell ausgeführt werden.
Doch, er sieht es, wenn er versucht, das oben beschriebene Beispiel zu implementieren (allgemein bei "irreducible control flow").
Für Ihn sieht das schon so aus, als ob es einzelne Threads wären.Threads, die nicht individuell ausgeführt werden sondern einen gemeinsamen Instruction Pointer haben und sich somit nicht an unterschiedlichen Stellen synchronisieren lassen? Dann sind es keine Threads und für den Programmierer sieht es im allgemeinen Fall auch nicht danach aus. Es ist SIMD mit Lane Masking, fertig ist die Soße.
Ich finde es aber dennoch noch immer Strange, das AMD bei VLIW von SIMD-Units spricht. Das passt bei mir einfach nicht zusammen :DWas paßt da nicht zusammen? Ich habe das doch haarklein auseinander gedröselt. :confused:

Single VLIW Instruction (Stream), Multiple Data (Streams)
(und zusätzlich noch zweifaches barrel processing)

Skysnake

2011-11-08, 14:09:42

Na es passt nicht zusammen, weil SIMD für mich eben impliziert, das es eine uniforme Ausführung auf n Rechenwerken mit n Datensätzen ist.

Bei VLIW wird halt die Gleichartigkeit bzgl. der Instruction verletzt. SIMD wird daher der Sache eben nicht gerecht. Daher ist für mich einfach VLIW VLIW und SIMD SIMD. Zwei unterschiedliche Konzepte, die aber sehr viele Gemeinsamkeiten haben.

Darauf können wir uns doch sicherlich einigen oder?

Und zu SIMT. Die aktuellen GPU-Architekturen werden halt öfters als SIMT bezeichnet.

Coda

2011-11-08, 14:15:25

Was ist denn dann mit einem MADD? Das sind auch zwei Instruktionen.

Ich sehe wirklich nicht ein warum du VLIW unbedingt als mehrere Instruktionen definieren willst. Für die Logik ist es effektiv nur eine sehr komplexe.

Daher ist für mich einfach VLIW VLIW und SIMD SIMD. Zwei unterschiedliche Konzepte, die aber sehr viele Gemeinsamkeiten haben.
Du hast anscheinend immer noch nicht begriffen, dass wir hier über zwei Ebenen reden.

Die eine Ebene ist die ALU, die andere ist eine ganze SIMD-Einheit der GPU. Auf ALU-Ebene könnte man auch SIMD verwenden, da verwendet man halt inzwischen aber VLIW oder einzelne Instructions.

"Yo dawg, I heard you like SIMD, so I've put a SIMD into your SIMD, so can compute while you compute"