News Details zu AMDs Seattle-Opteron A1100: Auch 16 Kerne im Plan

Opteron

Redaktion
☆☆☆☆☆☆
Mitglied seit
13.08.2002
Beiträge
23.645
Renomée
2.254
  • SIMAP Race
  • Spinhenge ESL
  • BOINC Pentathlon 2012
In unserer letzten Meldung zu AMDs 64-Bit-ARM-Opterons (Codename “Seattle”) berichteten wir über das in Kürze startende Sampling der Acht-Kern-Version. Merkwürdig fanden wir dabei, dass plötzlich nichts mehr von der 16-Kern-Version kommuniziert wurde, die früher noch recht prominent auf den AMD-Folien prangte:
(…)

» Artikel lesen
 
Zuletzt bearbeitet:
Das liest sich doch richtig gut:
Der SoC stellt zwei 10-Gbit/s-Ethernet-Ports...
Dual-Port 10GbE Steckkarten für PCIe sind häufig von großvolumigen Kühlkörpern bedeckt.

Von 10GbE wird noch immer viel Abwärme erzeugt, wie zu den Anfangstagen von 1GbE ebefalls.
Und AMD packt das mit der TDP eines ganzen SoC, das unter anderem noch 8MB L3-Cache bietet.

Moderne PCIe 3.0 und DDR-4 Unterstüzung sind gleichfalls sehr löblich. Gut gemacht, AMD.

Ergänzung: Der Intel X540-T2 benötigt zum Beispiel 13,4W. Der Vorgänger wurde noch aktiv gekühlt.
 
Das könnte wenn der Preis stimmt für ein NAS interessante werden, die acht Kern Variante dürfte aber reichen ;-)
 
Für die Nutzung von Radeon- oder FirePro-Grafikkarten werde allerdings nicht der proprietäre Catalyst-Treiber verwendet, sondern dessen OpenSource-Gegenstück für ARM portiert. Da „Seattle” auch als „Hierofalcon” für den Embedded-Markt geplant ist, macht dieser Ansatz durchaus Sinn. Immerhin wird die Entwicklung des OpenSource-Treibers maßgeblich von AMDs Embedded-Bereich finanziert. Aktuell steht diese Version des Treibers noch nicht bereit, soll es aber rechtzeitig zum Verkaufsstart. Fraglich ist allerdings, wie weit bis dahin die OpenSource-Unterstützung von OpenCL unter Linux fortgeschritten ist. Hier kommt noch viel Arbeit auf die Entwickler zu.

Bezieht sich das auch auf Win oder nur linux, bei nur Linux dürfte der Aufwand doch minimal sein, da soweit ich das mitbekommen habe die AMD Oss Treiber auch auf dem chinesischen MIPS Systemen mit nur wenig Änderungen laufen sollen. wenn sie den OSS treiber verwenden wollen gehe ich mal davon aus das sie da mit dem release der 16 Core CPU, auch OGL 4.x anpeilen.
Was OpenCl angeht, stellt sich die Frage ob das über das Oss Treiber Team geht oder über das HSA Team, zu opencl mit dem offenen Treiber liest man relativ wenig in letzter Zeit.
 
So und statt 8 ARM-Kerne bitte 8 Mullinskerne dazu noch etwas GPU und fertig ist eine praktische x64-Server APU !
 
Bezieht sich das auch auf Win oder nur linux, bei nur Linux dürfte der Aufwand doch minimal sein, da soweit ich das mitbekommen habe die AMD Oss Treiber auch auf dem chinesischen MIPS Systemen mit nur wenig Änderungen laufen sollen. wenn sie den OSS treiber verwenden wollen gehe ich mal davon aus das sie da mit dem release der 16 Core CPU, auch OGL 4.x anpeilen.
Was OpenCl angeht, stellt sich die Frage ob das über das Oss Treiber Team geht oder über das HSA Team, zu opencl mit dem offenen Treiber liest man relativ wenig in letzter Zeit.

Bisher ist bei den ARM-Servern alles auf Linux als OS ausgelegt. Darauf bezieht sich auch die Aussage zum Treiber.

Der GPU-Treiber wird nichts mit dem HSA-Team zutun haben, denn der Seattle-SoC ist nicht kompatibel zu HSA und eine dedizierte GPU über PCIe geht mit HSA nicht. Auf die OpenCL-Baustelle bezieht sich auch die Aussage mit der vielen noch ausstehenden Arbeit.
 
Und das Beste daran ist, dass Intel nicht kontern kann. Dies würde bei der Strategie der letzten Jahre eine Kapitulation in Sachen x86 bedeuten. Intel hat zwar immer wieder Mal kurze Eskapaden mit anderen Architekturen gehabt, aber immer nur in Nischen. Darunter mit den XScale SoCs für PDAs sogar welche mit ARM Kernen. AMD kann es sich dagegen erlauben x86 zu "verraten". Sie haben es schließlich nicht erfunden und sind nicht derart darauf versteift. Wenn sich das ganze als erfolgreich erweist, dehnt AMD diese Taktik womöglich weiter aus und lizenziert noch viel mehr IP von externen Quellen. Das würde eine immense Risikoverlagerung bedeuten, wenn man sich nur noch auf die Bündelung verschiedener (Funktions-)Blöcke verlegt und verdient trotzdem richtig gut damit. Dann könnte man regelrecht eine Rosinenpickerei betreiben und nur noch das selbst entwickeln, wobei man sich von der Konkurrenz absetzen kann. Wie man damit wirtschaftlich erfolgreich sein kann macht Qualcomm eindrucksvoll vor. Die Frage ist nur, ob AMD dafür nicht schon zuviel Ingeneure den Rücken gekehrt haben. Zu diesem Konzept würde jedenfalls passen, dass AMD seit der Gründung von GlobalFoundries fabless ist.
 
Ich glaub nicht, dass die Server-ARMs von AMD großartigen Erfolg haben werden. Außerhalb bei Rechenzentren wie die von Facebook und Google, wo es nicht auf die Rechenleistung, sondern eher auf die I/O-Leistung und niedrigen Stromverbrauch ankommt bringen diese Schmalspur-Kerne es doch nicht.
 
Potentiell können sie überall dort zum Einsatz kommen, wo man bisher auf Bobcat, Jaguar oder die Atom-Äquivalente gesetzt hat, wenn die Softwareseite nicht dagegen spricht. Spätestens seitdem es Android gibt, ist eine Menge quelloffener Linux-Software auf die ARM Architektur portiert worden. Davon profitieren dann letztendlich viele Serverbetreiber, die über einen Wechsel auf ARM-Microserver nachdenken. Aller Anfang ist schwer. Ich sehe ein Scheitern der neuen Opteron der A-Serie jedenfalls nicht vorprogrammiert. Ganz im Gegenteil. Es ist vorrangig eine Preisfrage. Das wird der entscheidene Dreh- und Angelpunkt sein. Neben den Lizenzkosten für die AMR Kerne machen bestimmt die 8MB L3-Cache das SoC recht teuer. Selbst wenn aufgrund der Kosten die Nachfrage gering bleibt, wird dies bestimmt nicht der letzte Anlauf von AMD gewesen sind. Beim nächsten Mal wird eben entsprechend tiefer gestapelt. Hauptsache AMD kann sich damit ein weiteres Standbein aufbauen und dadurch flexibler auf diesem gewinnträchtigen Markt reagieren.
 
Zuletzt bearbeitet:
Nochmal zu OpenCL, HSA, AMD und Linux, ein Zitat von John Bridgman (AMD):
Actually there's a lot of Linux HSA work going on now, it's just being going through the "nothing seems to be happening" phase as well but that won't last much longer.
da das OpenCl- und das HSA-Thema eng mitenander verbunden sind, vermurte ich, dass dies etwas mit dem ARM-Engagement zu tun hat. Ebenso die neuerdings schnelle Entwicklung des OpenGL-Teils im freien OpenGL-Treiber. Aber ich weiß zu wenig über die gegenseitige Nähe programmierbarer Shader in OpenGL, OpenCL und HSA. Es fällt jedoch sehr auf, wie stark AMD sich jüngst in diesem bereich engagiert, bis vor Kurzem war da immernoch Intel erster - das hat sich jüngst umgekehrt.
 
Das liest sich doch richtig gut:
Dual-Port 10GbE Steckkarten für PCIe sind häufig von großvolumigen Kühlkörpern bedeckt.

Von 10GbE wird noch immer viel Abwärme erzeugt, wie zu den Anfangstagen von 1GbE ebefalls.
Und AMD packt das mit der TDP eines ganzen SoC, das unter anderem noch 8MB L3-Cache bietet.

Moderne PCIe 3.0 und DDR-4 Unterstüzung sind gleichfalls sehr löblich. Gut gemacht, AMD.

Ergänzung: Der Intel X540-T2 benötigt zum Beispiel 13,4W. Der Vorgänger wurde noch aktiv gekühlt.

Nicht dass Du Dich zu früh freust, den PHY stellt AMD auf der CPU sicher nicht, dh. das was den Kühlkörper braucht muss sicher vom Mobo kommen.
 
Nicht dass Du Dich zu früh freust, den PHY stellt AMD auf der CPU sicher nicht...
Das hatte ich mir vohin schon überlegt, aber dann die i82599 und X540 Ethernet Controller verglichen. Der neuere X540 Controller hat die PHYs für Cooper (RJ-45) bereits integriert, während der ältere i82599 dafür separate PHYs benötigt. Zugegeben, der i82599 ist schon etwas betagt, aber bei den PCIe Steckkarten mit diesem Controller sitzt sowohl auf den PHYs als auch auf dem Ethernet Controller große Kühlkörper. Wahrscheinlich fällt der Großteil des Stromverbrauchs tatsächlich bei den PHYs ab. Insofern ist dein Einwand mehr als nur berechtigt. Einige Watt kommen jedoch mit Sicherheit auch beim Controller selbst zusammen. Wenn ich mir die Kühlkörper so anschaue, die üblicherweise auf dem i82599 sitzen, dürften das mindestens 5 Watt sein.
 
Kann gut sein SPINA
 
So und statt 8 ARM-Kerne bitte 8 Mullinskerne dazu noch etwas GPU und fertig ist eine praktische x64-Server APU !

Das Ding gib es sogar schon:-) Hat sogar 32MB L3.

http://www.hardwareluxx.de/index.ph...-gibt-details-zum-soc-der-xbox-one-preis.html

---------- Beitrag hinzugefügt um 20:24 ---------- Vorheriger Beitrag um 20:14 ----------

Neben den Lizenzkosten für die AMR Kerne machen bestimmt die 8MB L3-Cache das SoC recht teuer.

Die 8MB sind ca. 20mm² Chipfläche 50% Zelleffizenz angenommen und die ARM Lizenzen werden bei der Entwicklung gespart.
 
naja, das ist ja was anderes, Crashtest meinte wohl einen 16-Kerner aus halbe-halbe ARM und x86, aber ohne GPU.

Aber für einen Server wäre wohl beides nicht so unbedingt sinnvoll. Gemischt ARM und x86 ist unnötig, weil der Kunde sich vorher überlegt, ob er mit ARM oder x86 besser fährt, und dann rein auf das setzt, was er braucht/will. Und die Konsolenchips aus XBox One oder PS4 im Server einzusetzen, macht nur Sinn, wenn da auch die GPUs wirklich ausgenutzt werden; aber dann fehlen den Konsolenchips immer noch servertypische unverzichtbare Details, die für die Konsolen aus Kostengründen weggelassen wurden, wie ECC, breite Netzwerkanbindung und einiges andere. Seattle wird bestimmt recht erfolgreich in seiner Nische sein, weil eben konsequent auf einen Einsatzzweck hin optimiert, keine Kompromisse enthalten, die für eine Eignung zu mehreren Anwendungen üblicherweise notwendig sind (wie z.B. Kabini für Server nicht so toll ist, weil zuviel Consumerkram enthalten ist und Serverkram fehlt).

Aber AMD hat ja gesagt, sie wollen in Zukunft mehr maßgeschneiderte Chips bauen, also wird es wohl auch viel mehr Varianten geben, mehr unterschiedliche Zusammenstellungen der bekannten IP-Blöcke mit ggf. noch ein paar dazugekauften.
 
Wenn die Infrastruktur schon 16 Kerne kann, ist es sicherlich auch möglich, einen Prozessor mit einer ähnlichen Infrastruktur und Excavator-Kernen zu bauen.
 
Ich wär mit folgenden Dingen zufrieden:

8 Kern Mullins-sparsame Server-Soc-APU
8 Modul XV Highend-Server-CPU (mit 3 coh. HT-Links + 24 PCIe 3.0 Lanes)
 
Ich glaub nicht, dass die Server-ARMs von AMD großartigen Erfolg haben werden. Außerhalb bei Rechenzentren wie die von Facebook und Google, wo es nicht auf die Rechenleistung, sondern eher auf die I/O-Leistung und niedrigen Stromverbrauch ankommt bringen diese Schmalspur-Kerne es doch nicht.
Täusche dich da mal nicht. Klar kann ein A-57 nicht mit den grossen x86 Kernen mithalten. Der ist aber auch bei weitem nicht so schwachbrüstig wie ein In-Order Atom. Ich würde gerne mal einen Vergleich zwischen einem solchen 16-Kern ARM und dem 10-Kern + SMT Ivy Bridge bei vergleichbaren Taktraten sehen.


@topic

Interessant, dass das Cache Layout ähnlich wie Bulldozer ist. Wobei laut ARM auch bis zu 2 MB L2 für bis zu 4 Kerne gehen sollen. Also vergleichbar mit der Jaguar CU. Vielleicht hat AMD das Design so flexibel gestaltet, dass man x86 und ARM Kerne recht einfach austauschen und so den Marktbedürfnissen anpassen kann. Wäre auf jeden Fall eine interessante Option. Eventuell sogar für Bulldozer Kerne. Diese lohnen sich mMn aber erst, wenn man ein Modul auf 4 Threads aufbohrt. Davor dürften ARM und Jaguar/Puma klare Vorteile bezüglich Flächeneffizienz haben.
 
Weil der Chef von Dell mal meinte, dass er nicht mal AMD CPUs verbauen würde, wenn AMD zu jeder CPU 20 $ dazu legt!
das war aber keine persönliche Abneigung (wäre auch höchst unprofessionell), sondern einfach basierend auf der Tatsache, daß Intel noch mehr als diese 20$ bezahlt (wenn man die Paketpreise für mehrere Chips zusammenrechnet).
 
Man könnte das aber auch verwirrende Taktik nennen. AMD wird vermutlich schon lange Pläne abseits von x86 haben. Nur solange die Zeit dafür nicht reif ist, wird man das natürlich nicht an die grosse Glocke hängen.
 
Zurück
Oben Unten