R1000 Spekulationsthread

[aylano]

Sicher gibts/gabs Probleme.
Denn die 40nm wurden vor mehr als 2 Jahren eingeführt und 40nm hatte schon große (Verspätungs)Probleme.

 

[OBrian]

Tja, das ist nun mal kein Wunschkonzert, da kann man noch so viele Roadmaps malen, aber Chiptechnologie ist absolutes technologisches Neuland. Wenn ich eine Textilfabrik aufbaue, dann weiß man was rauskommt, weil da nichts neues dabei ist, man kann bestenfalls hier und da was an Abläufen optimieren, ansonsten ist das ziemlich planbar. Aber bei Chips weiß man erst, ob was überhaupt funktioniert, wenn es tatsächlich funktioniert. Was diese Fabriken heute neu einführen, gab es noch nie, und was sie in einem halben Jahr machen, sollte theoretisch klappen, aber wurde auch noch nie gemacht. Ich will gar nicht wissen, wie oft die Ingenieure da stehen und sich wundern, was alles so geht; das meiste, was die probieren, geht aber nicht.

Also sind das alles keine Verspätungen und Probleme, sondern einfach der normale, unvorhersehbare Lauf des Fortschritts. Es gibt keine Garantie für alle zwei Jahre eine neue Node, es gibt immer nur den Versuch, zur nächsten zu kommen, bevor der Firma das Geld ausgeht, dann muß man weitersehen.

 

[Stryki]

...bevor der Firma das Geld ausgeht, dann muß man weitersehen.

Das ist der entscheidende Punkt wo ich Intels größte Stärke sehe. Die gigantischen Ausgaben für F&E mal sehen wie sich GF in dieser Hinsicht entwickeln wird immo überzeugen sich mich nicht wirklich.

 

[aylano]

Also sind das alles keine Verspätungen und Probleme, sondern einfach der normale, unvorhersehbare Lauf des Fortschritts.

Aber der Konkurrent fertigt auch schon in kleineren Strukturen und das mit den selben Belichtungs-Tools.

 

[p4z1f1st]

Aber der Konkurrent fertigt auch schon in kleineren Strukturen und das mit den selben Belichtungs-Tools.

[Klugscheiß-Modus]
Wenn, dann mit den GLEICHEN Belichtungs-Tools... sicher nicht mit den SELBEN...
[/Klugscheiß-Modus]

 

[Opteron]

VLIW ist Geschichte:
http://www.planet3dnow.de/vbulletin/showthread.php?t=395675

 

[rasmus]

Das ist ja mal etwas grandios Neues. Das käme dann für die 8000er? Das konnte ich so schnell nicht eruieren.

 

[Opteron]

Das ist ja mal etwas grandios Neues. Das käme dann für die 8000er? Das konnte ich so schnell nicht eruieren.

Habs gerade noch editiert, das sind sogar schon die 7000er, denn Bergmann hat zuvor gemeint, dass die neuen GPU bereits Ende des Jahres erscheinen.
Eventuell machen sie es so wie bei der 6000er Serie. Zuerst einen Mittelklasse VLIW4 Chip als 28nm "Rohrfrei" als 78xx und dann ein dicker "R1000" Chip als HD79xx hinterher.

 

[Lynxeye]

WOW. Der Bummer des heutigen Tages. Ich hätte nicht damit gerechnet, dass AMD diesen Schritt wagt.

Mit dem alten VLIW Design konnte AMD gegenüber NVidia immer bei der Rohleistung glänzen, jetzt begibt man sich in die selbe Arena wie NV. Vielleicht ist es ja doch einfacher und lohnender immer mehr Hardware auf einen Chip zu packen, als sich ständig Gedanken darüber machen zu müssen, wie man den Compiler immer weiter verbessert. Besonders im Hinblick auf OpenCL wären da bestimmt noch einige harte Nüsse zu knacken gewesen, bevor aus der Rohleistung auch in jedem Fall ordentliche Rechenleistung wird.

Tja, damit wird VLIW wohl für immer ein Ausrutscher in der Geschichte bleiben. AMD ist scheinbar mit der vom R600 geerbten Architektur genauso an der Umsetzung eines funktionieren Compilers für VLIW gescheitert wie Intel damals beim Itanium.

 

[Opteron]

Tja, damit wird VLIW wohl für immer ein Ausrutscher in der Geschichte bleiben. AMD ist scheinbar mit der vom R600 geerbten Architektur genauso an der Umsetzung eines funktionieren Compilers für VLIW gescheitert wie Intel damals beim Itanium.

In der Zwischenzeit bis jetzt, fand ich es ganz gut.
Aber jetzt ist wohl der Punkt gekommen, in dem der Compiler zu komplex geworden wäre. Es werden ja immer mehr Shader verbaut, das Problem wurde damit womöglich immer schlimmer.

 

[OBrian]

Wahrscheinlich ließ sich die VLIW-Architektur auch nicht so wirklich im Fusion-Konzept verwursten. Das lebt schließlich davon, daß der Programmierer einfach beliebigen Code schreibt und nicht wissen muß, in welchem Teil der APU der ausgeführt wird, gut laufen soll er aber. Ist wohl alles einfacher, wenn die GPU im Aufbau näher an eine CPU heranrückt.

 

[aylano]

Irgendwie hört sich das so an, als ob das die erste echte AMD-GPU wäre bzw erste AMD-GPU, wo AMDs-CPU-Architektur-Know-How dann von Grund auf bzw. Anfang an bzw. Konzeptional einfließt.

Eines ist mir auch noch eingefallen.
Erste R600-Chips gabs schon im Herbst 2006.

Also, müssten die R600-Entwickler schon Mitte 2006 mit der R600-Architektur fertig sein.
Ob dieses Team dann ein dem obengenannten neuen Architektur begannen? (5 Jahre?) Oder jenes, was mit R770 dann so Anfang 2008 fertig war. (3,5 Jahre?)

Irgendiwe hört es sich so an, als ob AMD diese SIMD viel leichter in eine FPU unter einer FPU-Sheduler neben FMAC anhängen kann als VILW, was dann quais Fusion in Vollendung wäre.

 

[FredD]

Tja, damit wird VLIW wohl für immer ein Ausrutscher in der Geschichte bleiben. AMD ist scheinbar mit der vom R600 geerbten Architektur genauso an der Umsetzung eines funktionieren Compilers für VLIW gescheitert wie Intel damals beim Itanium.

Fragt sich dann aber, wozu die aufwändige Weiterentwicklung zu VLIW-4, wenn diese lediglich ein kurzes Zwischenstadium darstellen sollte. War Cayman ein Ausrutscher, ein groß gewordenes Experiment? Oder sind die non-VLIW Pläne eher lang- als mittelfristig einzuordnen, Stichwort "heterogeneous computing"?

 

[Opteron]

Fragt sich dann aber, wozu die aufwändige Weiterentwicklung zu VLIW-4, wenn diese lediglich ein kurzes Zwischenstadium darstellen sollte. War Cayman ein Ausrutscher, ein groß gewordenes Experiment? Oder sind die non-VLIW Pläne eher lang- als mittelfristig einzuordnen, Stichwort "heterogeneous computing"?

Siehe News Meldungsfolie:

Da zählen sie links die Nachteile von VLIW auf:
Komplex, kompliziert, schwierig zu handhaben... klingt nicht besonders gut.

VLIW4 ging schon in die Richtung Vereinfachung, aber hats am Ende dann wohl doch nicht gepackt.

 

[gruffi]

Mit dem alten VLIW Design konnte AMD gegenüber NVidia immer bei der Rohleistung glänzen, jetzt begibt man sich in die selbe Arena wie NV.

Nicht ganz. Der theoretische Durchsatz pro Compute Unit (vorher SIMD Engine) ist ja der gleiche, 128 FLOPs (32-bit). Nur der Aufbau ist nun anders gestrickt. Das ganze ähnelt mehr Larrabee (512-bit SIMD Pipeline), nur ohne den Hinkefuss x86 und hervorgegangen aus einer richtigen GPU-Architektur anstatt aus P54C Kernen.

Fragt sich dann aber, wozu die aufwändige Weiterentwicklung zu VLIW-4, wenn diese lediglich ein kurzes Zwischenstadium darstellen sollte.

Ich denke, dass es vielmehr eine wichtige Vorstufe für die Non-VLIW Architektur war.




Es sollte klar sein, dass die neue Architektur flexibler agieren kann und einiges vereinfacht. Die Frage, die ich mir stelle, welche Nachteile bringt der Verzicht von VLIW. Weniger FLOPS pro mm²?

 

[Opteron]

Weniger FLOPS pro mm²?

Gute Frage, wenn man annimmt, dass die VLIW Effizienz wg des noch komplexeren Compilers noch weiter gesunken wäre, dann nichtmal das.

 

[Lynxeye]

Nicht ganz. Der theoretische Durchsatz pro Compute Unit (vorher SIMD Engine) ist ja der gleiche, 128 FLOPs (32-bit). Nur der Aufbau ist nun anders gestrickt. Das ganze ähnelt mehr Larrabee (512-bit SIMD Pipeline), nur ohne den Hinkefuss x86 und hervorgegangen aus einer richtigen GPU-Architektur anstatt aus P54C Kernen.

Auf die Compute Unit gesehen ist das vollkommen richtig, nur wenn ich skalare Einheiten habe, werden diese automatisch komplexer als VLIW Einheiten mit dem selben Durchsatz. In Endeffekt bedeutet dies, das ich weniger dieser Einheiten auf dem Chip unterbringe. Also genau das was NVidia macht: weniger Einheiten mit entsprechend weniger Rohleistung, dafür aber einfach ansteuerbar und deshalb bei den meisten Realworld Anwendungen am Ende schneller.

Es sollte klar sein, dass die neue Architektur flexibler agieren kann und einiges vereinfacht. Die Frage, die ich mir stelle, welche Nachteile bringt der Verzicht von VLIW. Weniger FLOPS pro mm²?

Meiner Meinung nach weniger Roh-FLOPS pro mm². Was hinten für den Anwender raus kommt ist eine andere Frage.

 

[rasmus]

Also VLIW5 war ja nach seinem Reifeprozeß durchaus sehr erfolgreich. Gescheiterte Umsetzung sieht doch eher anders aus. Nur weil AMD seine CPU Architektur seit Beginn aufgewärmt hat, heißt das ja nicht zwangsläufig, daß man das bei der GPU auch so machen muss. VLIW5/4 war sehr erfolgreich zuletzt, jetzt kann frei nach Law of the Woodscrews dann der AMD Thermi folgen. Ich gehe aber davon aus, daß AMD-F/Thermi seine nukleare Power weniger in der Hitzeabstrahlung als in der GPU Power konzentriert, denn im Gegensatz zur CPU Abteilung waren sie bei den GPUs in letzter Zeit ja eher auf die Füße gefallen als auf den Kopf.

Edit: @7000er schon... das wäre ja der Kracher! Ich hatte angenommen, 6900 gehen mit ein paar Polituren in die 28nm Prod. - Dafür waren sie doch mal gedacht.

 

[Lepus]

Hm, mit dem weniger Flops pro mm² kann ich mich nur anfreunden, wenn wir uns auf die gleiche Strukturbreite einigen. Nun steht aber ein Wechsel zu 28nm an, was wohl auch dieser Baustelle entgegenwirkt. Lassen mer uns mal überraschen. Vllt habens ja gschafft, statt runtertakten einfach nur so viele SIMDs zu aktivieren, wie man brauch, um die momentane Leistung im Idle bereitzustellen. Macht bei mir weniger Leckströme oder bin ich da aufm Irrweg? Beim Llano habens doch auch so ähnlich

 

[gruffi]

Auf die Compute Unit gesehen ist das vollkommen richtig, nur wenn ich skalare Einheiten habe, werden diese automatisch komplexer als VLIW Einheiten mit dem selben Durchsatz.

Mag sein. Da steht aber explizit, dass es Vektor-ALUs sind, 16 wide SIMD. Eben das, was Intel auch mit Larrabee vorhatte. Das schaut mir nicht nach den skalaren CUDA Kernen von nVidia aus.

 

[Lynxeye]

Mag sein. Da steht aber explizit, dass es Vektor-ALUs sind, 16 wide SIMD. Eben das, was Intel auch mit Larrabee vorhatte. Das schaut mir nicht nach den skalaren CUDA Kernen von nVidia aus.

Und wieder hast du Recht. Allerdings stellt sich mir dann wirklich die Frage, was sich AMD dabei gedacht. Das wäre eine Rolle rückwärts in die Shadertechnologie der GeForce7 / Radeon X1800, wobei natürlich das Umland der Shader, wie der Scheduler seit dieser Zeit viel dazu gelernt haben.

Naja, ich glaube darüber muss ich erst mal schlafen, bevor ich mir ein klares Bild machen kann, was dies genau für die Programmierbarkeit bedeutet. AMD legt damit eindeutig den Fokus auf Vektormaschinen, also weg von immer freierer Programmierbarkeit der Shaderkerne, hin zu den starren Durchsatzmonstern, welche die Idee von der Verwendung der GPU für allgemeine Berechnungen erst aufkeimen ließen.

 

[gruffi]

Interessant ist auch, dass es neben den 4 Vektor ALUs einer Compute Unit auch eine skalare Integer Unit gibt. Für was die gut ist?

 

[Lynxeye]

Wahrscheinlich eine Special-Function-Unit, in welche man alle Befehle reinsteckt, die man zwar braucht, welche aber nicht häufig vorkommen (wie etwa RCP, RSQ). Damit hat man bei diesen Befehlen zwar nur noch 1/4 des Durchsatzes, meist brauch man die Ergebnisse dieser SF aber sowieso nur skalar.

An der Stelle wäre schön zu wissen, ob gleichzeitig ein Skalar- und Vektorbefehl ausgeführt werden kann. Nach dem Blockbildchen zu urteilen, wäre dies möglich und würde die Architektur doch wieder mehr von anderen bisher gekannten abheben.

Für mich ist damit zum ersten mal seit Langem eine GPU Architektur wieder wirklich interessant, nachdem uns Jahrelang der selbe Einheitsbrei von wieder aufgegossenen VLIW- oder Skalarrechenwerken präsentiert wurde.

 

[Complicated]

Interessant ist auch, dass es neben den 4 Vektor ALUs einer Compute Unit auch eine skalare Integer Unit gibt. Für was die gut ist?

Ich denke dass dies auch für die Kompatibilität von Software von belang ist, welche für APUs entwickelt werden soll. Könnte mir vorstellen dass dies auch der Grund ist für den Wechsel weg von VLIW - das ganze schneller in die Programmierstuben zu transportieren und weniger kompliziert zu machen. Wer weiss wie die GPU mit Nvidia optimierten Spielen umgeht

 

[gruffi]

Wahrscheinlich eine Special-Function-Unit, in welche man alle Befehle reinsteckt, die man zwar braucht, welche aber nicht häufig vorkommen (wie etwa RCP, RSQ).

Integer? Sollte diese SFU dann nicht auch Gleitkomma sein?

Für mich ist damit zum ersten mal seit Langem eine GPU Architektur wieder wirklich interessant, nachdem uns Jahrelang der selbe Einheitsbrei von wieder aufgegossenen VLIW- oder Skalarrechenwerken präsentiert wurde.

Jup, das war echt ein Hammer. Damit hätte ich nicht gerechnet. Schon gar nicht bei Southern Islands.