News Will AMD künftig ARM-Server herstellen?

Dr@

Grand Admiral Special
Mitglied seit
19.05.2009
Beiträge
12.791
Renomée
4.066
Standort
Baden-Württemberg
  • BOINC Pentathlon 2011
  • BOINC Pentathlon 2012
<div class="newsfloatleft"><a href=""><img src="http://www.planet3dnow.de/photoplog/images/54308/1_AMD-Logo.png" border="0" alt="AMD-Logo"></a></div>Gestern hatten wir bereits über AMDs Ankündigung berichtet, am kommenden Montag eine <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1351159713">Pressekonferenz zur künftigen Ausrichtung des Konzerns abhalten zu wollen</a>. Offenbar hat AMD den amerikanischen Medien eine gesonderte Einladung zugeschickt, in der als Sprecher neben CEO Rory Read und Lisa Su, die Managerin der Global Business Units ist, zusätzlich noch ein "Special Guest" angekündigt wird. Computerworld will jetzt von einem ARM-Sprecher in Erfahrung gebracht haben, dass es sich bei diesem Gast um den ARM-CEO Warren East handelt. Da AMD offenbar auch Pressebriefrings mit Andrew Feldman, dem ehemaligen CEO von SeaMicro und jetzigen Manager der Data Center Server Solutions Group, arrangiert, schlussfolgern die Kollegen, dass AMD wohl im Rahmen der Pressekonferenz SeaMicro-Server basierend auf den kommenden 64-bit-ARM-Kernen ankündigen will. Schließlich wird die Ankündigung solcher ARM-Kerne mit 64-bit-Erweiterung allgemein für die einen Tag nach der Pressekonferenz startende ARM TechCon 2012 erwartet. Ein weiterer Fakt, auf den sich diese Spekulation stützt, ist Feldmans Vortrag auf der letztjährigen ARM Technologie-Konferenz. Dort pries er die SeaMicro-Technologie als ideal zu ARM passend an.

Allerdings war SeaMicro damals noch eigenständig und damit auf der Suche nach einem Investor. <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1330563621">Letztlich kaufte AMD den Spezialisten für Micro-Server</a>. Dadurch wurde AMD über Nacht zu einem Serverhersteller, der ausschließlich Maschinen mit Intel CPUs im Angebot hatte. Mittlerweile bietet AMD aber auch mit dem <a href="http://www.planet3dnow.de/vbulletin/showthread.php?t=407782">SeaMicro SM15000</a> einen Server an, der mit "Piledriver"-Opterons konfiguriert werden kann. Als die Übernahme von SeaMicro verkündet wurde, stellte AMD aber recht schnell klar, nicht als Konkurrent zu den eigenen OEM-Kunden im Server-Markt auftreten zu wollen. Viel mehr sei geplant, die SeaMicro-Technologie auch den Partnern zugänglich zu machen. Angedeutet wurde dabei insbesondere, dass die Funktionalität des SeaMicro ASIC und damit der Chip-Interconnect in künftige Server-Prozessoren integriert werden könnte. Damit ließe sich der Flächenbedarf weiter reduzieren und der Leistungsaufnahme käme die stärkere Integration sicherlich auch zu Gute. Besonders schnell ließe sich dies mit AMDs synthetisierbaren "Bobcat"-CPU-Kernen und dessen Nachfolgern <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1343138045">"Jaguar"</a> realisieren. Diese Linie von x86-CPU-Kernen wurde speziell für die Verwendung in SOCs entwickelte, die zu großen Teilen mit Hilfe von automatischen Tools designt werden können. Für entsprechende Produkte fällt die notwendige Entwicklungszeit deutlich kürzer aus. Zudem ist wesentlich weniger Manpower nötigt. Beides senkt die Entwicklungskosten dramatisch - worauf die Unternehmensführung derzeit ja besonders viel Wert legt. Letztlich gewinnt der kleiner x86-Riese durch die kürzeren Entwicklungszyklen auch an zusätzlicher Flexibilität bei der Wahl der Fab, welche die Chips produzieren soll.<p style="clear:left;">
<center><a href="http://www.planet3dnow.de/photoplog/index.php?n=21774"><img src="http://www.planet3dnow.de/photoplog/images/54308/large/1_Improved-Execution.png" border="1" alt="Improved Execution"></a></center>

Damit ist fraglich, ob AMD wirklich die ARM-Kerne für einen Server-Chip benötigt, wenn doch bereits eine funktionierende 64-bit-Kernarchitektur vorhanden ist, die ebenfalls auf eine möglichst geringe Leistungsaufnahme und Flächenbedarf hin optimiert wurde. Während der Telefonkonkonferenz zu den Geschäftszahlen des dritten Quartals 2012 hat CEO Rory Read jedenfalls bestätigt, dass die "Kabini"-APU mit "Jaguar"-Kernen voll im Zeitplan läge. Ist daraus nicht viel mehr zu schlussfolgern, dass AMD am Montag die Verwendung dieser Technologie in Servern - insbesondere in den Micro-Servern von SeaMicro - verkünden wird?

<center><a href="http://www.planet3dnow.de/photoplog/index.php?n=19234"><img src="http://www.planet3dnow.de/photoplog/images/49616/large/2_AMD_Opteron_3000_EMEA_Press_Briefing_March_2012-16.png" border="1" alt="AMD Opteron 3200"></a></center>

Interessanterweise hatte AMD bereits auf dem AFDS 2012 bestätigt, dass ein ARM-Kern in genau diese "Kabini"-APU und nachfolgenden APU-Designs integriert sei. Allerdings ging es dabei bisher lediglich um die <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1339667038">Realisierung der TrustZone-Technologie</a>. Der ARM-CEO Warren East wird sicherlich nicht ohne wichtigen Grund auf der Veranstaltung am Montag zu Gast sein. Weshalb durchaus mit der Ausweitung der Partnerschaft zwischen AMD und ARM zu rechnen ist, die ja beide auch <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1339584790">Gründungsmitglieder der HSA Foundation</a> sind. Denkbar wären beispielsweise APUs, die x86- und ARM-Kerne gleichberechtigt vereinen, sodass bei geringer Auslastung lediglich der ARM-Kern aktiviert ist, während die x86-Kerne per Power-Gating von der Spannungsversorgung vollständig getrennt sind. Einen ähnlichen Ansatz verfolgt bereits NVIDIA, die beim Tegra 3 neben vier "großen" ARM Cortex-A9 zusätzlich einen viel kleineren sogenannten "Ninja Core" verbaut haben. Dieser zusätzliche Kern ist unsichtbar für das Betriebssystem und übernimmt bei geringer Rechenlast und im Standby das Zepter, sodass zum Beispiel die Verbindung zu Netzen gehalten werden kann. Connected Standby ließe sich für AMD auf diese Weise sicherlich gut für künftige Tablet-Chips realisieren. Die Heterogeneous System Architecture (HSA) bietet hierzu sicherlich die richtige Grundlage.

<center><a href="http://www.planet3dnow.de/photoplog/index.php?n=20690"><img src="http://www.planet3dnow.de/photoplog/images/9775/large/1_3rd_party.png" border="1" alt="Trustzone"></a></center>

Dies sind aber alles nur Spekulationen. Was das Management um CEO Rory Read und der "Special Guest" am kommenden Montag wirklich zu verkünden haben, bleibt abzuwarten. Es wird jedenfalls spannend.

<b>Quelle:</b> <a href="http://www.computerworld.com/s/article/9232916/AMD_likely_to_announce_ARM_based_server_on_Monday" target="b">Computerworld</a>

<b>Links zum Thema:</b>
<ul><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1351159713">AMD kündigt Pressekonferenz zur neuen Strategie an</a></li><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1350904050">Neuausrichtung bei AMD: Gut oder schlecht? Diskussion im P3D-Team</a></li><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1349779370">AMD stellt Tablet-Plattform "Hondo" mit Z-60 APU vor</a></li><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1339667038">AMD vertieft Zusammenarbeit mit ARM und übernimmt 2013 deren TPM-Lösung Trustzone für die Kabini-APU und für alle zukünftigen Designs ab 2014</a></li><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1339699724">AFDS 2012: AMD aktualisiert und erweitert Roadmaps für 2012 und 2013</a></li><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1330563621">AMD kauft Seamicro für 334 Millionen US-Dollar</a></li></ul></p>
 
Das mit dem ARM-Ninja-Core für ein x86-SoC ist ziemlich problematisch. Dank gänzlich unterschiedlichem Instruktionssatz dürfte ein einfacher Wechsel da nicht möglich sein. ARM selbst hat ja extra für big.LITTLE die A7-Kerne mit gleichem Instruktionssatz zu den A15ern.
Ich denke eher man wird wohl mit ARM kooperieren, um HighPerformance-GPGPU-Technik auf den SoCs unterzubringen. Die Malis mögen zwar gut sein, aber für ordentlichen Bums braucht es schon eine hochgezüchtete Technik inklusive Software-Unterstützung und da wären doch GCNs gepaart mit ARM-Kernen optimal. Und möglicherweise bringt AMD dann KnowHow für ARMv8-Cores mit ein. Schließlich sind die quasi DIE Firma für 64bit.

Unabhängig davon:
Wovon ich träume wäre ein Kabini (also ein Quad Jaguar) mit einer dicken GPU-Einheit (so 640 GCN Kerne oder sogar mehr) und 4 Gig Stacked RAM. Und das dann neben einem Einsatz in Notebooks auch als Rechenbeschleuniger für PCI-Express verkauft.
 
HSA soll aber doch genau diese Barriere zwischen unterschiedlichen ISAs durchbrechen. Für völlig unmöglich halte ich es daher nicht.

Ich kann nach wie vor keinen richtigen Sinn darin erkennen, warum AMD einer unter vielen ARM-SOC-Herstellern/Entwicklern werden sollte. 64-Bit-Fähigkeit ändert daran nichts.

ARM + dicke GPU gibt es schon von NVIDIA in großen Stückzahlen.
ach ja und die Chips von Apple sind da ja auch nicht gerade knapp GPU-Power bestückt.

ARM + x86 + dicke GPU wäre neu und innovativ. Alle drei Kernarchitekturen haben Vor- und Nachteile. Für mobile Anwendungen wäre dies doch eine nahezu ideale Kombination.
 
Dr@ schrieb:
ARM + dicke GPU gibt es schon von NVIDIA in großen Stückzahlen.
Dick ist die nun beim Tegra3 nicht gerade, oder meinst du die CARMA-Kits? Vor allem ist der Tegra ja noch nicht GPGPU-fähig.
Im Prinzip könnte AMD jetzt schon sowas machen, was AMD mit Project Denver (so das denn wirklich jemals kommt) vorhat, nämlich eine APU mit Schwerpunkt auf die GPU zu bauen. Eigentlich hauptsächlich eine GPU mit angeflanschtem CPU-Teil. Momentan ist das ja immer recht ausgewogen. Siehe Ontario mit kleiner CPU und kleiner 80 Shader-GPU, Trinity mit 4 CPU-Kernen und mittlerer GPU. Und was ich gerne hätte wäre quasi ein Ontario aber mit einer dickeren GPU-Einheit als bei Trinity....naja wie gesagt, nur so ein Wunschtraum.

Ich bin mir bei HSA immer noch nicht so sicher. Erstmal muss sich das doch auf Programmebene etablieren und erst zu einem deutlich späteren Zeitpunkt kann ich das auf Betriebssystem-Ebene machen, oder?
 
Zuletzt bearbeitet:
Dicke GPU ist natürlich immer relativ. Ich bezog mich auf den Tegra 3. Klein finde ich dessen GPU jedenfalls nicht und künftige Modell werden da sicherlich noch weiter zulegen. Dürfte für NVIDIA ein Kernelement zur Differenzierung sein.

Wie, was, wo und wann umgesetzt werden muss oder kann, weiß ich nicht. Ich spekuliere lediglich, wie es Computerworld auch macht. Was der Aktuelle Stand bei HSA ist und ob da schon Projekte mit MS laufen, weiß ich nicht.

<center><a href="http://www.planet3dnow.de/photoplog/index.php?n=22006"><img src="http://www.planet3dnow.de/photoplog/images/54308/large/1_HSA-Solution-Stack.png" border="1" alt="HSA-Solution-Stack"></a></center>
 
HSA soll aber doch genau diese Barriere zwischen unterschiedlichen ISAs durchbrechen.

Wie kommst Du denn darauf? Ich sehe bei HSA nur eine vereinheitlichte Schnittstelle für GPU und andere Pheripherie und einen gemeinsamen Adressraum.

"diese Barriere zwischen unterschiedlichen ISAs durchbrechen" ist Aufgabe von Hochsprachen wie Java. Die haben aber m.E. bei weitem zuviel Overhead um auf den untersten Ebenen des Betriebssystems nennenswerte Aufgaben durchzuführen.
 
ARM + x86 + dicke GPU wäre neu und innovativ. Alle drei Kernarchitekturen haben Vor- und Nachteile. Für mobile Anwendungen wäre dies doch eine nahezu ideale Kombination.

Mag sein aber das das ein OS innerhalb eines vernünftigen Zeitraum unterstützt geht wohl gegen 0, ausser der OS Hersteller heisst Apple ( Apple diktiert dem Kunden die HW), bei Windows ist die Vielfalt zu gross, sieht man schon bei BD das man da kein vernünftige Teillast hinbekommt wenn man einem Foren user hier glauben darf. Hw und Os muss dazu Zeitgleich optimiert aufeinander auf dem Markt kommen, und das bekommt AMD zusammen mit MS nicht gebacken.
 
Nur in der Form wie wie aktuell benutzt werden. GCJ zum Beispiel konnte Java-Quellcode in nativen Maschinencode übersetzen - indem er Java als eine Art Untersprache zu C++ behandelt hat.
Das Ganze scheiterte nur daran dass zum damaligen Zeitpunkt die gesamte Plattform noch Closed war und Apache Harmony als Backend herhalten musste das nunmal deutlich weniger komplett war als ein JRE.
HSA hat mit der HSA Runtime schon in gewisser Weise Ansätze vom Befehlssatz zu abstrahieren, nur so wäre es ja möglich dass man ein und das selbe HSA-Programm auf einer Geforce, einer Radeon oder eime CELL laufen lassen kann.
Wobei das noch nicht impliziert wie man den HSA-Code erzeugt.
Wie Projekte alla Rootbeer zeigen, kann man sogar java-Code auf einer GPU laufen lassen (mit Einschränkungen natürlich)
Dennoch ist es noch ein weiter Weg bis HSA überhaupt mal CUDA ablöst, von einem kompletten HSA-Betriebssystem (das immernoch einen plattform-Bootstrap bräuchte das die HSA-Runtime lädt) mal ganz zu schweigen.
Sowas ist langwierig. Microsoft baut garantiert nicht die x Gigabytes Windows-Quellcode "mal eben" auf HSA um, nur weil irgend ein Konsortium behauptet das wäre ganz toll und super.

Allerdings könnte man durchaus einen ARM benutzen um zum Beispiel Dinge wie Connected Standby zu realisieren und einige Hintergrundarbeit, während der "große" x86er erst dann angeworfen wird, wenn der Benutzer irgend eine App startet. - Möglichkeiten gibt es da einige.
Theoretisch kann auch der ARM der "master" - Prozessor sein, auf dem das OS läuft (z.B. android) welcher eine APU dann mit daten Befüttert & anspricht, genau so wie es CPUs heute mit GPUs machen, nur dass die APU eben auch serielle Aufgaben bewältigen kann. Dazu böte openCL womöglich heute schon die Technologie, wenn denn irgendwer ein Gerät so konstruieren will.
Alles in Allem - AMD als "einer mehr" unter den ARM-SoC-Fertigern muss nun wirklich nicht sein, allerdings kann die Kooperation beiden Firmen helfen. Was die "AMD macht alles falsch" - Unkenrufer immer wieder vergessen ist nämlich dass durchaus eine Menge KnowHow in dem Laden steckt. Schon alleine in Sachen GPUs.
 
Wie kommst Du denn darauf? Ich sehe bei HSA nur eine vereinheitlichte Schnittstelle für GPU und andere Pheripherie und einen gemeinsamen Adressraum.
HSA will aber viel mehr sein. Programme, die für HSA geschrieben wurden, sollen auf allen Prozessoren/Geräten (Notebooks, Smartphones, Supercomputer, Tablets usw. ) ausgeführt werden können, die zur HSA-kompatibel sind. Das ist völlig unabhängig von der ISA des jeweiligen Rechenkerns.

Was spräche denn dagegen, Windows RT auf solch einer APU laufen zu lassen - also auf dem ARM-Kern. Besonders rechenintensive Programme nutzen dann die x86-Kerne, die GPU oder irgendeine andere Spezialeinheit über die HSA-Schnittstelle.
 
In dem Segment in dem Seamicro tätig ist zählt doch nur eines: Möglichst viele Cores mit möglichst geringem Stromverbrauch zusammen zu schalten.
Insofern macht der Einsatz von ARM Cores Sinn.
 
@Dr@
Danke für das Bild, das kannte ich noch nicht. Mir fehlt da der Pfeil von OpenCL/HSA zur CPU, das ist ja jetzt schon möglich.... schon komisch, dass sie die CPUs so von HSA abkapseln.

offtopic:
OpenCL in der ARM-Welt: ArndaleBoard
Ein Samsung Exynos 5 (2x Cortex A15 plus Mali T-604). Voll OpenCL-kompatibel und mit allen modernen Schnittstellen.

@Ramius
Ich würde irgendwie noch Effizienz in deiner Gleichung mit unterbringen.
 
HSA hat mit der HSA Runtime schon in gewisser Weise Ansätze vom Befehlssatz zu abstrahieren, nur so wäre es ja möglich dass man ein und das selbe HSA-Programm auf einer Geforce, einer Radeon oder eime CELL laufen lassen kann.

Das "nur so" stimmt ganz sicher nicht. Siehe Apples Binaries die auf 68k|PowerPC|x86. Das waren FatBinaries mit völlig unterschiedlichen Codepfaden die abhängig vom OS angesprungen wurden und genau so läßt sich selbstverständlich auch ein HSA Programm konstruieren (nebenbei - woher stammt die Aussage über dessen Eigenschaften?) das auf unterschiedlicher Hardware läuft.
.
EDIT :
.

HSA will aber viel mehr sein. Programme, die für HSA geschrieben wurden, sollen auf allen Prozessoren/Geräten (Notebooks, Smartphones, Supercomputer, Tablets usw. ) ausgeführt werden können, die zur HSA-kompatibel sind.

Soweit, so klar.

Das ist völlig unabhängig von der ISA des jeweiligen Rechenkerns.

Aber woher kommt das?
 
Aber woher kommt das?
Sämtliche HSA Programme werden in die Zwischensprache HSAIL übersetzt. Erst der hardwarespezifische HSA Finalizer bildet die Befehle dann auf die jeweilige ISA ab. Die Programmierung von Anwendungen erfolgt völlig unabhängig von diesem letzten finalen Schritt bei der Programmausführung.

Damit sind die Programme unabhängig vom Hersteller der Chips und auch von deren Generation.
 
Was spräche denn dagegen, Windows RT auf solch einer APU laufen zu lassen

Ebensowenig wie dagegen sprach WindowsNT auf Alpha und OS/2 auf PowerPC zu portieren.
Es wäre derart proprietär das MS sich m.E. keinen Gewinn davon versprechen würde.

Dazu kommt noch die Sinnfrage. Einen ARM-Kommunikationsprozessor in der Netzwerkkarte würde ausreichen um CS zu realisieren, ein Bobcat-Kern der kein ganzes Windows stemmen muß kann noch um einiges Energieffizienter zu Werke gehen als bisher. Der 5.te Prozessor im Tegra wird wenn ich mich recht entsinne nicht nur einfach mit anderem Aufbau sondern mit anderen Transistoren gefertigt. ARM als alleine seeligmachendes Konzept wäre zwar ein für die Schlipsies typisches Luftschloß, würde aber m.E. keines der Probleme wirklich lösen.
 
Eine spekulative Variante wäre, dass AMD ST-Micro sein verlustbringendes Sorgenkind ST-Ericsson abnimmt, wobei ST-M noch eine Milliarde drauflegen muss. AMD hätte erst einmal einen ARM SOC, auf den es aufbauen könnte und der mit derzeit ähnlicher Fertigungstechnologie hergestellt wird. AMD entwickelt den weiter zu 64bittigen fdSOI SeaMicro Serverchips, wofür sich die fdSOI Technologie ohnehin viel eher eignet als für Mobilgeräte, wo das Prinzip Hurry-up-and-idle bestens funktioniert.
MfG und sorry für die dreiste Spekulation
 
Erst 1000 Leute in der Entwicklung entlassen und dann die Produkte noch komplizierter machen, das wird nicht funktionieren.
 
Schätze die wollen, in Zusammenarbeit mit ARM, trusted module für die Hose bekannt geben. Selbige geht dann nur bei der Freundin oder im Gewerbe auf.
 
attachment.php


Dann wird es wohl doch die ARM-Server-Geschichte. :]


Edit:

ARM-Kerne & SeaMicro-Interconnect

AMD typisch ist der Stream natürlich überlastet ...
 
Wer hat nur das #AMDARM entworfen?
Daraus kann ganz schnell #AMD ARM werden.*engel*
Wollen wir mal nicht hoffen das es dank ARM dann wirklich AMD ARM wird.
 
Zurück
Oben Unten