Kaveri - der Trinity Nachfolger

Du hast den Artikel aber schon vollständig gelesen?

Das war die Schlussfolgerung auf Basis der bisherigen Aussagen und Roadmaps von AMD. Oder warst Du bisher davon ausgegangen, dass "Kaveri" erst 2014 verfügbar wird?
 
Opteron schrieb:
Ne, auch noch Gate-First. Außerdem verwenden sie auch nicht den gemeinsamen 64nm Gate Pitch, wie sonst bei 20nm der Allianz üblich. Mittlerweile wissen wir ja, dass 28 vs 22nm in der Beschreibung eher willkürliche Zahlen sind, da könnte 22nm IBM und 28SHP@GF schon ähnlich sein. Muss mal nach den 28nm GF Bulk-Parametern suchen. Auch wenns nicht die gleichen Werte bei Bulk <> SHP sein müssen, ergeben sich eventuell Anhaltspunkte.[...]
Zum Vergrößern anklicken....
Nach der Theorie würde 28SHP (PDSOI) ja AMDs ursprünglichem 22nm-Prozess entsprechen, der ja parallel mit IBM entwickelt werden sollte, genau wie 130, 90, 45, 32nm davor. Das würde heißen, dass die Halfnode-Prozess-Eskaparden für CPUs von AMD gewissermaßen nur ein kurzfristiger "Fake" war und dass hier die Luft aus der direkten Konfrontation mit Intel herausgenommen würde. 28SHP (22nm-Generation) wäre demnach der direkte Nachfolgeprozess von 32nm und der direkte Konkurrent zu Intels 22nm. Da das sowieso bei allen Herstellern nur Fake-Werte sind liegt diese Annahme sogar nahe. Dann wurde von Read der ursprüngliche 20nm-Prozess (ursprünglich 16nm-Generation) gecancelt und dieser wird vermutlich durch 14XM ersetzt. Passt also auch. AMDs "22nm"-Prozess würde dann sogar nach der 32nm-Verspätung Ende 2013 im Plan liegen (ca. ein halbes Jahr Verzögerung). Anfang 2009 -> 45nm, Herbst 2011 -> 32nm (Plan Anfang 2011), Ende 2013 -> 22nm (alias 28SHP) (Plan Frühjahr 2013), Plan Ende 2015 (wahrscheinlicher Release Anfang 2016) 16nm oder besser gesagt 14XM; das passt alles hervorragend in den Zeitrahmen. Die ursprünglichen 22nm standen also nie in Frage und wurden nie verzögert. Sie heißen heute einfach nur anders aus offensichtlichen Gründen (Intel Nutzung von FinFETs und Ausstieg aus dem Prozessorrennen, man darf nicht vergessen, dass der Prozess von AMD entwickelt und bezahlt wurde). Und da 14XM ein Bulk-Low-Power-Prozess ist brauchts eine komplett neue Architektur nach BD. Das würde im zeitlichen Rahmen zur Neuausrichtung von AMD sehr gut passen. Man kann ja nicht sofort alles umschmeißen, man muss die Produkte noch bringen, die in der Pipeline waren um dann Schritt für Schritt auf die neue Strategie zu wechseln. Man muss sich einfach von den 22, 28, 16, 14 trennen, das sind alles nur dumme Marketingbezeichnungen, schon seit Jahren! Der Klarheit wegen sollte man vielleicht 32nm, 22nm, 16nm, 11nm - Generation sagen, so kann man am besten Vergleiche ziehen.

Ich würde hier sogar noch weiter gehen und die Einzelbereiche von GloFo betrachten. Dresden (also AMD) hat sicherlich die ganze Zeit an den "22nm" alias 28SHP rumentwickelt und der "28nm" HPP, LP (32nm-Generation) usw kommen eigentlich aus Singapur. Die Prozesse haben also fast nichts miteinander zu tun. Erst als diese fertig waren konnte GloFo die Ressourcen wirklich bündeln und entwickelt für alle Fabs 14XM. 20nm SLP ist mMn ein Low-End-Spinoff von 28SHP (20 ist Marketing, ist 22nm Generation mMn), hat also dieselbe Strukturgröße, da man mit den "28nm"-Prozessen von ehemals Chatred massive Probleme hatte - ein Ersatzprozess der 22nm-Generation, damit die Chatred-Werke am Ball bleiben können gewissermaßen und nicht noch mal so ne Katastrophe wie mit der 28nm (32nm - Generation) verursachen. 14XM ist also der erste Prozess, der für alle GloFo-Fabs gilt und der kommt sicherlich aus NY und Dresden und ist ein "16nm" FinFET-Prozess auf Basis der ehemaligen AMD-Technik.
Nicht nur AMD hatte also Umsturkturierungsprobleme, auch GloFo war ja davon betroffen.

Eine Unbekannte ist da noch zu erwähnen: 28 FDSOI. Das ist ein Lizenzprozess der 32nm-Generation von STM, der bei GloFo getestet wurde. Die erste Produktionsvariante ist mMn GloFos eigenentwickelte "16nm"-Variante davon (14FDSOI). STM hat mMn die eigene Variante der 22nm-Generation (20FDSOI) gecancelt. Man hat den als Joker in der Hinterhand, falls die FinFETs zu lange verzögern. Das wird auch Cross-License sein, GloFo kann FDSOI nutzen und STM GloFos FinFETs.
 
Zuletzt bearbeitet:
Kann man das mal in den Fertigungs-Thread verschieben?
Die Themen sind kaum noch voneinander zu unterscheiden :(
 
Nein, nein, und nein. Für den Kaveri-Nachfolger "Carizo" gibt es noch weniger über den Codenamen hinausreichende konkrete Anhaltspunkte (AMD-Roadmaps, -Folien, etc.) als aktuell für den Kabini-Nachfolger "Beema". Das soll aber niemanden daran hindern, entsprechende Threads zu eröffnen, u.a. fehlen noch Spekulationsthreads für Excavator und Monkey Islands (oder wie sie die nächste GPU-Generation diesmal getauft haben :) )
 
Monkey Islands wäre genial als Codename. *lol*
 
In Charlie's Artikel zum Hawai Launch handelt ein Abschnitt über die gemeinsame GPU-Lösung von Kaveri/Berlin, der Volcanic Islands Grafikkarten und (in abgewandelter Form) der Konsolen-APUs :
Meanwhile AMD is doing the sane thing and keeping one architectural development path. Hawaii is the next step and it will go in to devices top to bottom, APUs included starting with Kaveri in Q4 or early Q1. Please note that unlike what some are saying, there are no delays to Kaveri, the roadmap hasn’t slipped at all since earlier this year when SemiAccurate last looked. To make things even easier for AMD they have synergies with all three game consoles so 100% of next generation game engine development is AMD architecture focused.
Zum Vergrößern anklicken....

Das wäre dann "GCN2.0", bislang aber ohne Hinweise darauf, welche Verbesserungen mit dieser GPU µ-arch eingeführt werden.
 
Hardware.fr fast nochmal die "Kaveri kann GDDR5M speku. " & alten gddr5m Fakten zusammen.

Der Artikel fasst es im Gegensatz zu der Hier geposteten News alle Angaben welche sich zu GDDR5M finden lassen zusammen, und warum sie denken Kaveri könnte den Verwenden.

Ich denke eine Kaveri & GDDR5M Diskussion ohne neue Informationen macht kein Sinn
 
Seh ich auch so, dass es techn. ginge wissen wir, aber die Frage ist, obs AMD auch wirklich macht.
 
Es ist doch davon auszugehen, dass AMD in Zukunft nur noch APUs baut und das erscheint mir auch durchaus sinnvoll, aber dann habe ich doch ein paar Fragen.
Wenn die APUs auch die FX ersetzen sollen, dann wird AMD doch gar nicht drumherum kommen 4 Modul-APUs zu bauen und wenn sie auf den L3 verzichten, dann würde GDDR5 noch mehr Sinn machen.

Nun hat man zwar schon was von den GDDR5-Gerüchten zu Kaveri gelesen, aber noch nie etwas über einen 4-Moduler.
Spätestens mit dem Kaveri-Nachfolger müssen aber doch DEUTLICH grössere APUs kommen, mindestens was den CPU-Bereich betrifft, wie soll man denn sonst den FX und noch mehr die Bulldozer basierten Server-CPUs ersetzen?

HSA optimierte Software wird sicher mehr und mehr kommen, aber ein großer Teil der Standard-Software wird weiterhin reines x86 bleiben und gerade bei Servern und virtualisierungen nützt mir HSA recht wenig oder sehe ich da was falsch?

Ausserdem habe ich eine Sache zu HSA noch nicht so richtig verstanden.
HSA zieht seinen Vorteil daraus, dass CPU und GPU-Teil, später ja noch ARM dazu den selben Speicher benutzen und die selben Daten verwenden können.
Programmiert werden soll das ganze nun in c++ oder in OpenCL.

Als Software-Entwickler will ich ja nun Software schreiben, die auf einer möglichst breiten Hardwaebasis läuft, um einen entsprechenden Markt zu haben.
Muss ich denn nun Rücksicht darauf nehmen ob das eine HSA-APU, ein reine CPU + GPU-Steckkarte oder eine OpenCL-kompatible CPU ist oder erledigt die Library bzw der Compiler selbst?

Wie groß ist der Kopieranteil bei einer Anweisung die auf der GPU ausgeführt werden soll?
Sind Handelsübliche CPUs + GPU-Steckkarten bei den üblichen Workloads immer noch schneller, oder bringt HSA so viel, dass es, wenn sich OpenCL oder ähnliches durchsetzt, nicht mehr lohnt einfach eine moderne GPU-Steckkarte einzubauen?
 
Zuletzt bearbeitet:
GDDR5 geht nur bis zu einer bestimmten Menge (4-8GB bei 128Bit oder 8-16GB bei 256Bit Speicheranbindung). Zudem gibts zwar wohl einen S0-DIMM-Standard, aber der ist vergleichsweise lahm, bedeutet, GDDR5 müsste verlötet werden um effizient zu sein. Das geht durchaus im Mobilbereich, also in Notebooks oder Fernsehern beispielsweise aber für Server-APUs ist das so oder so keine Option. Eine Server-APU müsste auf DDR4 setzen. Das tut man mit XV (Excavator) wohl auch dann.
Die LLC (Last level Cache) Diskussion ist auch in einem anderen Thread entbrannt, ich könnte mir das nur so vorstellen, dass der LLC dann Stacked verbaut wird, da das Die für CPU + LLC + GPU wohl doch einfach nicht groß genug ist und unwirtschaftlich wird, zumal man davon ausgehen muss, dass man 28SHP wohl auch ne ganze Weile nutzen wird.
Das SR-Server-Die, also der große Kaveri ohne GPU gewissermaßen, ist wohl mit der Streichung von Komodo und Terramar komplett gestorben, da auch seine Plattform gestorben ist. Stattdessen hält man sich mit Warschau, einem erneuten Orochi-Aufgruss, über Wasser, bis XV soweit ist. Der kann dann ja auch in zwei APU-Variationen kommen, aber mit einer neuen CPU kann man denke ich nicht mehr rechnen.
 
Zuletzt bearbeitet:
wosch666 schrieb:
Programmiert werden soll das ganze nun in c++ oder in OpenCL.

Als Software-Entwickler will ich ja nun Software schreiben, die auf einer möglichst breiten Hardwaebasis läuft, um einen entsprechenden Markt zu haben.
Muss ich denn nun Rücksicht darauf nehmen ob das eine HSA-APU, ein reine CPU + GPU-Steckkarte oder eine OpenCL-kompatible CPU ist oder erledigt die Library bzw der Compiler selbst?

Wie groß ist der Kopieranteil bei einer Anweisung die auf der GPU ausgeführt werden soll?
Sind Handelsübliche CPUs + GPU-Steckkarten bei den üblichen Workloads immer noch schneller, oder bringt HSA so viel, dass es, wenn sich OpenCL oder ähnliches durchsetzt, nicht mehr lohnt einfach eine moderne GPU-Steckkarte einzubauen?
Zum Vergrößern anklicken....
Die Library sucht die im System installierten HSA Devices. So wie man aktuell einen Videodecoder/encoder für Videowiedergabe/bearbeitung auswählen kann, wird man entsprechende HSA Devices auswählen können.

Beim Kopieranteil lohnen sich aktuell z.B. nur Arrays mit mehr als 1000 Einträgen von der GPU verarbeiten zu lassen.
Bei kleineren Arrays würde das kopieren länger dauern als die Berechnung auf der CPU.
Mit Kaveri treten aber keine Kopierverluste mehr auf, da sollten sich auch schon kleine Arrays vorteilhaft über die interne GPU verarbeiten lassen.
Schau mal hier rein: http://developer.amd.com/tools-and-sdks/heterogeneous-computing/amd-accelerated-parallel-processing-app-sdk/bolt-c-template-library/
Bei großen Aufgaben, wo der Kopieranteil vernachlässigt werden kann, werden auch zukünftig dedizierte GPUs schneller sein.
Hängt halt vom Anwendungsfall ab, so wie aktuell noch manche Programme auf einem schnellem 2 Kerner schneller laufen als auf einem langsamer getackteten 8 Kerner bzw. es sich bei manchen Programmen lohnt Hyperthreading auszuschalten.
 
Bei der Big-Server-Die Diskussion muss man bedenken das mit Cray der vermutlich wichtigste Kunde zu Intel übergelaufen ist.
Zumindest lassen die ganzen Folien vermuten das da nicht mehr viel kommt in naher Zukunft und ich bin pessimistisch ob sich das jemals wieder ändern wird.
Für AMD verständlich aus meiner Sicht aber natürlich Schade für die meisten hier im Forum.
 
Wie bei den Automotoren. Nachdem 4 Zylinder und >100PS zur Massenware geworden ist wird die Luft für 6 oder 8 Zylinder reichlich dünn.
Formel 1 und Dragster sind faszinierend, aber eben nichts für den Massenmarkt.
 
Stryki schrieb:
Bei der Big-Server-Die Diskussion muss man bedenken das mit Cray der vermutlich wichtigste Kunde zu Intel übergelaufen ist.
Zumindest lassen die ganzen Folien vermuten das da nicht mehr viel kommt in naher Zukunft
Zum Vergrößern anklicken....
Übergelaufen sind sie nicht, aber nach AMDs Seamicrokauf hat Intel quasi als Retourkutsche Crays Interconnect samt Entwicklerteam gekauft. da kommt also ganz sicher nichts mehr ...
Zwar ist der Interconnect im Moment PCIe-basierend, also für alle offen, aber bald kommen Intels 22nm Chips, da hat AMD noch weniger Chancen als jetzt schon.
 
Da waren aber gewisse Disharmonien bezüglich der Bulldozer Verschiebungen auch vorher schon bekannt geworden. In dem Fall würde ich AMD auch einen Teil "Eigenschuld" zusprechen und nicht auf den "Intel hat sie rausgekauft" Zug aufspringen.
Klar die haben die Möglichkeit genutzt diesen Markt weiter an sich zu binden.
 
Stryki schrieb:
Da waren aber gewisse Disharmonien bezüglich der Bulldozer Verschiebungen auch vorher schon bekannt geworden. In dem Fall würde ich AMD auch einen Teil "Eigenschuld" zusprechen und nicht auf den "Intel hat sie rausgekauft" Zug aufspringen.
Klar die haben die Möglichkeit genutzt diesen Markt weiter an sich zu binden.
Zum Vergrößern anklicken....
Naja, was der Grund für die Zustimmung des Verkaufs an Intel war ist aber mal nicht wichtig. Ja, AMD war spät dran mit BD und Cray ziemlich sauer, aber Intel hats gekauft. Obs nun ein besonders guter Preis war, oder ob Cray froh war die Kostenstelle weg zu haben ... kA.
Intel hat aber mal die Devise ausgegeben, dass sie AMD alles nachmachen werden und überall bekämpfen wollen, deswegen gabs damals auch das unsägliche Skulltrail 2P Board als Gegenentwurf zu AMDs komischen 4x4 FX-Plattform. Das hätten sie sich eigentlich sparen können. AMD hatte das nur gemacht, da sie keine Quadcores hatten, Intel hatte die aber, trotzdem haben sies nachgemacht ... ziemlicher Irrsinn. Intel will AMD einfach nirgendwo unbekämpft lassen.

Von daher gehe ich davon aus, dass die Initiative von Intel ausging. Die haben gesehen, dass sich AMD bei nem Interconnect einer Serverfirma einkauft, ergo mussten die Intel Leute auch so nen schönen Sandkuchen haben, also haben sie sich Crays Interconnect gekauft.
 
Charlie berichtet über eine Reihe neuer FM2+ Boards. Hat zwar nur peripher mit Kaveri zu tun, zeigt aber immerhin das Vertrauen der Board-Partner in die APUs/Plattform.
 

Ähnliche Themen

FredD
Beema - der Kabini Nachfolger
24 25 26
Antworten
638
Aufrufe
141K
derDruide
derDruide
Nero24
News Architektur-Infos zu Kaveri und Steamroller geleakt
Antworten
12
Aufrufe
6K
y33H@
y33H@
Dr@
Bericht: x264 mit OpenCL-Beschleunigung
Antworten
0
Aufrufe
44K
Dr@
Dr@
Zurück
Oben Unten