AMD Kaveri: Ausblick auf den Heterogeneous Uniform Memory Access (HUMA)
Mit der nächsten Ausbaustufe der APUs, der Accelerated Processing Units, setzt AMD auf einen gemeinsamen Speicher für die integrierte CPU sowie die GPU - dieses Prinzip nennt sich Heterogeneous Uniform Memory Access (HUMA) und erlaubt unter anderem eine vereinfachte Programmierung der APUs.
Im Desktop-Bereich sind die Trinity-Chips derzeit noch das höchste der APU-Gefühle, im mobilen Segment steht bereits die Richland-Generation Gewehr bei Fuß, welche in den kommenden Wochen ebenfalls Einzug in stationäre Computer halten wird. Beiden Accelerated Processing Units gemein ist die Fähigkeit, dass die integrierte Grafikeinheit per Pointer auf den virtuellen Speicherbereich des Prozessor-Teils zugreifen kann, umgekehrt funktioniert dies allerdings nicht - zumal GPU und CPU über keinen gemeinsamen Speicher verfügen.
Die für Ende 2013 angekündigte Kaveri-APU führt das HSA-Prinzip (Heterogeneous System Architecture) fort und verknüpft Grafikeinheit sowie Prozessor noch enger, ähnlich wie dies Sony für die Playstation 4 implementierte. GPU und CPU verfügen über einen gemeinsamen physikalischen Speicher samt frei verfügbarem logischen (virtuellen) Adressraum, auf welchen die APU zugreifen kann. Der Vorteil hierbei ist, dass der Speicher und alle Caches kohärent bleiben und somit immer die gleichen Daten für beide APU-Rechenwerke zur Verfügung stehen; das Problem der aufwendigen Kohärenz löst AMD mit sogenannten Probe-Filtern. Weiterhin muss der Prozessor nicht erst Informationen in den GPU-Speicher schreiben, dann die Grafikeinheit rechnen lassen und anschließen die bearbeiteten Daten wieder zurück kopieren, sondern die GPU kann per Pointer auf - und das ist neu - jeden beliebigen Bereich im Speicher zugreifen (Pageable Memory statt Page-Locked-Memory) und der CPU liegt das Resultat direkt vor. Leistung sowie Effizienz steigen, obendrein verringert sich der Aufwand für Programmierer. Intel ist übrigens mit Instant Access dort angelangt, wo AMD schon 2011 startete.
Das Ziel von HSA rückt mit dem Hardware-Feature "Heterogeneous Uniform Memory Access" (besser bekannt als Unified Memory Access) also einen großen Schritt näher, denn am Ende sollen GPU und CPU gemeinsam rechnen und je nachdem, welcher APU-Teil sich für bestimmte Aufgaben eignet, diese aufteilen. Zudem soll die Grafikeinheit Berechnungen pausieren können, um sich anderen, gerade erforderlichen Workloads zu widmen (GPU Compute Context Switch) und sie erhält Vorzugsrecht, wodurch die Latenzen sinken. Weitere Informationen zum Thema Heterogeneous System Architecture wird es auf der AMD Developer Summit 2013 (bisher Fusion Developer Summit) geben, welche in diesem Jahr unter dem Motto "APU 13" läuft und Mitte November in San Jose stattfindet.
Möglich, dass die großen Hersteller noch das Layout modifizieren (auch wenn ich nicht glaube, dass sich das lohnt - ARM liefert ja sehr gründliche Arbeit ab), aber den Schaltplan dürften sie wohl 1:1 übernehmen. Eine Eigenwicklung auf Basis einer ARM-Befehlssatzlizenz waren afaik Intels Xscale.
Einen Punkt möchte ich aber noch ansprechen:
? Erzähl mir nicht, dass dir der Unterschied zwischen der Lizenz für eine fertige ARM-Architektur und für eine x86-Befehlssatz nicht klar wäre
Die mögen ihr eigenes Chipdesign machen und den non-Core-Bereich entwickeln, aber die eigentliche Verschaltung und Konzipierung der Kerne (und in den meisten Fällen sicherlich auch deren Layout) kommt von ARM.
Bei ARM ist es halt ziemlich schwierig, weil ARM eben sowohl reine ISA-Lizensen, als auch fertige Designs anbietet. Meist haben Kunden beides, und arbeiten dann auf Grundlage der fertigen Designs ihre eigenen Anpassungen aus.
Klar, man muss dann den Server und Client implementieren, aber eben nur einmalig.
Aber nicht wenn sie schlechter läuft. Niemand wird einen AMD-mobile-Chip für x86 und ARM kaufen, der nicht bereits ein funktionsfähiges ARM und ein funktionsfähiges x86 Gerät hat. AMDs Kombi Chip müsste besser sein, als diese undzwar in dessen jeweiligen Segment. Denn bis sich derartige Hardware etabliert hat, gibt es keine x86 Anwendungen für ultra mobile Geräte und umgekehrt keine ARM Anwendungen für Desktop-PCs.
Stellt sich somit die Frage: Kann AMD jetzt (oder später, dann die entsprechenden Nachfolger als Konkurrenz einsetzen) dank HSA einen Prozessor bauen, der Haswell im Desktop schlägt UND *Was immer Samsung und Apple gerade verbauen* in Smartphones hinter sich lässt? Ich denke nicht. Die wären froh, wenn sie auch nur eins von beiden Zielen zu 2/3teln schaffen würden.
Die mögen ihr eigenes Chipdesign machen und den non-Core-Bereich entwickeln, aber die eigentliche Verschaltung und Konzipierung der Kerne (und in den meisten Fällen sicherlich auch deren Layout) kommt von ARM.
Das heißt nicht, dass sie es gar nicht könnten, aber es geht hier darum, wie AMD wieder nach vorne kommen könnte. Und dazu müssen sie es nicht "okay" machen, sondern "besser als alle Konkurrenten". Vermutlich würde AMD nicht einmal ein ARM-Duell mit Intel gewinnen...
a) Server kauft, um Angry Birds darauf zu spielen
oder
b) servertypische Hardware für ARM programmiert. Letzteres wird wiederum nicht geschehen, solange es keine ARM-CPUs gibt, die besser sind, als Intels Serverlösungen. Und hier beißt sich die Katze in den Schwanz: AMD kann nicht mit schwachen Chips den Markt umkrempeln. Und wenn ARM-Spezialisten dies an Stelle von AMD machen, dann kann AMD gegen die genausowenig anstinken, wie jetzt gegen Intel. Niemand kauf ein System, dass in zwei Sachen schlecht ist - erst recht nicht für den Servereinsatz, wo man die Hardware an einen beschränkten Aufgabenbereich anpassen kann.
...muss kommen.
... Bauchschmerzen....
AMD braucht ...
... einfach machtlos.
Aktuell kan AMD eigentlich nicht wirklich viel mehr machen...
...Es fehlen aktuell einige Launches.
Davon abgesehen nützten einem in den kommenden Jahren auch gute Serverprozessoren wenig, das Geld liegt im Endkundengeschäft.
Dazu kommt halt, das nVidia in de Markt >50% besitzt, wohl eher sogar in GPGPU Bereich >75%.
Was AMD für künftige CPUs angekündigt hat, würde vermutlich schon mit dem Betriebssystemfunktionen mancher Systeme ausgelastet werden, von Anwendungen ganz zu schweigen.
MS unterstützt auch ARM. Wenn die Hardware dafür da ist, wird MS von ganz allein das OS auch für einen mischbetrieb fit machen. Zumal das nicht mal zwingend der Fall sein muss. Es reicht schon, wenn man entsprechend intelligente Compiler hat, die eben für mehrere OS compilieren können. Man braucht halt die richtigen Einstiegspunkte usw.
Ich seh da jetzt dein Problem nicht
Also nochmal zum mitschreiben: ARM und x86 sind einander zu ähnlich. Wie du selbst schreibst kriegt man das meiste, was ARM kann, auch halbwegs mit x86 hin und umgekehrt könnte man das meiste, was x86 kann, mit ARM machen. Es gibt leichte Effizienzunterschiede, aber die sind nicht so groß, dass es sich lohnen würde, ein komplette zweite (Co-)CPU der anderen Architektur zu integrieren und zumindest die Systemsoftware für beide kompatibel zu gestalten. Mittelfristig wird in jedem Markt somit nur eine von beiden Architekturen überleben und alle Konzepte, die auf ihre Verschmelzung setzen, schleppen einfach nur unnötigen Balast mit sich rum.
Das kann man sich erlauben, wenn einen gewissen Vorsprung vor der Konkurrenz hat und auf diesem Wege versucht, zusätzliche Märkte zu erschließen oder neue Technologien einzuführen. AMD hat aber keinen Vorsprung. AMD hat einen mächtigen Rückstand. Wenn die noch Balast draufpacken, mögen die CPUs in irgendwelchen Zukunftsszenarien superduper Vorteile haben, aber im jetzt kauft sie niemand, weil sie im jetzt nicht konkurrenzfähig sind. Und so wird das Zukunftsszenario nie eintreten.
Ich erinnere in diesem Zusammenhang übrigens an die letzte CPU-Architektur, die es dem Compiler überlassen wollte, hochoptimierten Code für höhere Recheneffizienz und bis dato ungeahnte Möglichkeiten zu liefern...
Bislang ist es die Stille nach großen Ankündigungen und sonst nichts.
Mit "Software" meine ich keine Firmware
Compiler sind Firmware?
Denk auch an die Spracherkennungssoftware, ähnlich Siri, die entwickelt wurde.
Gerade die Compiler- und OS-Entwickler sind eine sehr sehr sehr sehr sehr wichtige Schlüsselkomponente. Ohne die kannst du das HSA-Konzept nämlich vergessen. Was aber stimmt ist, das aktuell von genau diesen beiden Fraktionen aber noch die Beiträge fehlen. Es ist aber auch nicht verwunderlich, das erst die Hardware dazu da sein muss, bevor die Software dann den Markt erreicht. Daher NOCH kein Grund zu Panik aber durchaus um besorgt zu sein.
k. Da habe ich mich von der enorm hohen Zahl an Chips mit PowerVR Grafik täuschen lassen.
Das für die anderen HSA-Mitglieder toll wäre, für AMD aber eine Katastrophe. Und iirc geht es darum, warum HSA AMDs Rettung ist.
Klar, man muss dann den Server und Client implementieren, aber eben nur einmalig.
Denk auch mal an die ganzen Spielehersteller. Die müssen ohne HSA alles doppelt entwickeln einmal für arm und einmal für x86. Wenn man mit HSA intelligent dran geht, dann macht man das nur noch einmalig und skaliert eben mit Auflösung, AA, Polycount usw. oder Streamt die Inhalte.
Denk mal nur an so was simples wie AngryBirds. Der Hersteller hätte sich SEHR gefreut, wenn er einfach noch eine Version für x86 dazu bekommen hätte.
Vorallem für AMDs Mobile-Pläne ist das ziemlich gut.
Intel steht vor dem Problem x86 vs den Rest der Welt (ARM).
AMD kann dann im Mobilebereich einfach sagen: Ja wir sind x86, ja ihr könnt all eure Desktop Software bei uns ausführen, weil wir genug Punsh haben, aber ihr könnt auch ALLE! eure Software aus dem Play-Store nutzen.
Gerade bei Konvertebles und Tablets ist das halt schon ein killer Feature.
? Welche bedeutenden Architekturen haben Samsung, Mediatek, Qualcomm, ARM (ausgenommen ARM-Architektur) denn so in den letzten Jahren auf den Markt gebracht?
Du musst ja auch bedenken, dass alle drei nicht einfach nur fertige ARM-Cores lizensieren, sondern ihre eigenen Chips bauen. Nichts anderes macht AMD. Sie haben eine x86 Lizenz und machen ihre eigene Implementierung. Man hört bei AMD halt nur mehr davon, was da tolles eingebaut wird. Bei der ARM Fraktion eher nicht. Da interessiert es einfach keine Sau. Gerade im Bereich der GPUs wurde in den letzten 2-3 Jahren aber gewaltig auf die Tube gedrückt. Wenn man mal bedenkt, dass die iGPUs im Mobilebereich jetzt dann die aller neusten OpenGL Standards unterstützen, und teilweise sogar DoublePercision (WTF
nVidia ist da ein ziemlicher Blender in dem Bereich. Bei ner Diskussion mit Ailuros vor einiger Zeit im 3DCenter ist mir die Kinnlade runter gefallen, als ich erfahren habe, WIE WEIT nVidia beim Featureset hinterherhinkt. Die leben aktuell echt nur von ihrem Desktop-Namen und den wohl sehr niedrigen Preisen.
Gegen Intel sind sie nur im x86 Markt zu klein. Da werden ihnen die anderen nicht helfen können. Wenn die anderen den x86 Markt verkleinern, ist das auch nicht zu AMDs Vorteil.
AMD fährt da schon eine gefährliche aber vielversprechende Idee, indem Sie das Schanier zwischen x86 und ARM darstellen wollen. Gegen die ARM-Fraktion kann sich AMD durchaus behaupten. Sie verstehen durchaus Chips (ARM) zu designen, und haben auch kein ideologisches Problen ARM auch ein zu setzen im Gegensatz zu Intel. Die ketten sich selbst an x86.
Natürlich sind Gegner wie Qualcomm und Samsung im ARM-Segment genau so gefährliche Gegner wie Intel im x86, man hat aber durchaus viel Know-How für GPU und High-Performance Designs. AMD denkt sich wohl, Sie könnten da besser mithalten, als allein mit x86 gegen Intel UND ARM.
Es ist ja nicht so, das ARM nicht in den x86 Markt, vorallem Server, drücken würde, auch wenn es kein HSA geben würde. AMD könnte daran nur nicht partizipieren.
Ich seh da wirklich die Flexibilität von AMDs-Designs als killer Feature an. Bei den Servern können Sie dann mit hoher Performance werben (ok kann Intel auch), aber eben auch damit, das ALLE Software auf ihren Maschinen läuft (das kann dann weder Intel wegen ARM, noch ARM, weil nicht auf High-Performance ausgelegt). Es wäre also etwas die eierlegende Wollmilchsau.
Es ist ein Ritt auf der Rasierklinge, aber man hat eigentlich keine andere Wahl, und wirklich schlechter als ohne diesen Ritt kann es eigentlich auch nicht mehr werden, wenn man sich die aktuelle Situation mal anschaut...
Davon abgesehen ging es nicht um die Marktstärke, sondern um die vorzuweisenden Produkte. AMD arbeitet sehr lange an kombinierten Architekturen und hat bislang so gut wie gar nichts vorzuweisen (vereinheitlichte Speicheransteuerung - das wars im wesentlichen). Und daran werden die Partner erst recht nichts ändern, denn HSA ist kein kooperatives Entwicklungsprogram, sondern nur eine Allianz zur Etablierung gemeinsamer Schnittstellen.
Man scheint sich da wirklich sehr sicher zu sein, die richtigen Implementierungen gefunden zu haben, und das ist wichtig. Man braucht Ideen, wie man etwas gelöst bekommt. Jetzt muss AMD nur noch liefern. Wichtig wäre z.B. in 1 aller aller aller spätestens 2 Jahren auch einen eDRAM minimum onPackage, besser noch auf einem Interposer.
Das brauchen Sie einfach um die Performance der iGPU weiter pushen zu können. Ansonsten werden Sie gegen Intel nicht bestehen können. Aktuell reicht wohl noch der GDDR5 Schachzug aus, aber eDRAM muss kommen. Ich habe da aber keine großen Sorgen bzgl Technologie von Seiten AMD, weil die XBOX720 wird genau das ja haben. Ich befürchte es wird eher am Fertiger liegen, der Ihnen noch das Genick brechen könnte. und genau da habe ich auch wirklich die größten Bauchschmerzen....
AMD braucht einfach gewisse Schlüsseltechnologien die eDRAM on Packge und Interposer in den nächsten Jahren, sonst gehen Sie einfach unter.
Soweit das altbekannte.
Jetzt zur Frage: "Was ändert der Versuch, den größten Sprung seit dem IBM-PC durchzuziehen, an der fehlenden Möglichkeit, große Sprünge zu machen?"
Aktuell kan AMD eigentlich nicht wirklich viel mehr machen, selbst wenn Sie mehr Geld hätten. Ok, Sie könnten sich ihre FABs wieder kaufen, und dann da mal die Peitsche auspacken
Und das machen sie. Bei AMD sehe ich dagegen keine Beschleunigung.
Es kommt dieses Jahr einiges bzgl HSA, APU Opterons usw usw.
Soweit ich das einschätzen kann, sollten da einige große Schritte auf einmal passieren, sobald die APU-Opterons da sind. Die FirePro APUs sind ja schonmal ein guter Schritt gewesen.
Spannend wird halt vor allem, ob man jetzt SMP Systeme mit APUs bauen kann, oder nicht, und was jetzt mit HT für die reinen CPUs wird. Hier muss man wirklich mal endlich den nächsten Schritt tun.
Genauso wie bei gpGPU, wo CUDA ja sofort nach der Einführung von OpenCL weggestorben ist
Dazu kommt halt, das nVidia in de Markt >50% besitzt, wohl eher sogar in GPGPU Bereich >75%.
Im SFF Markt sieht das GANZ! anders aus.
<<10% Marktdurchdringung, und man hat das total veraltete Featureset im Vergleich zur Konkurrenz.
Zudem wird im SFF-Markt viel viel viel! mehr Wert darauf gelegt, das ich in der nächsten Generation der Hardwareliferanten einfach wechseln kann, wenn der scheise baut.
Die Märkte sind also überhapt nicht vergleichbar.
Du bist dir schon darüber im klaren, dass das ein reines Softwareprojekt auf Basis einer externen Emulation ist?
Da wird rein gar nichts nativ ausgeführt, denn in aktuellen AMD CPUs gibt es keine ARM-Kerne. Egal, wie oft du das behauptest.
Und nur dafür. Davon, dass das Ding frei programmierbar/zugänglich ist, wüsste ich nichts. Wäre für ein Sicherheitssystem auch alles andere als gut, wenn es das wäre.
Mit einem kleinen A5 kannst du aber nicht die Software betreiben, die auf einem Desktop/Notebook von Interesse ist. Da ist Quadcore A9 oder A15 gefordert.
Mir wäre nicht bekannt, dass Microsoft Mitglied in der Allianz ist.
Es heißt also korrekterweise "nutzen sie ALL ihre Software auf unseren Geräten, wenn sie ein Nerd sind, ständige reboots in ein anderes Betriebssystem nicht scheuen und damit leben können dass ein Teil ihrer Software mit 5% der Geschwindigkeit läuft, die ihr Smartphone bietet".
Technisch immer noch interessant - aber das waren prä-3dfx-3D-Entschleuniger auch.
Schön. Dir ist aber schon klar, dass ich nicht von Kernen, sondern Architekturen rede? Und den Aufgabentypen, die diesen besonders liegen?
Schau doch mal das BigLittle Konzept an. Das könnte man durchaus auch mit x86 mischen. Das Ergebnis wäre ein Rechner den man eigentlich nicht mehr runter fahren müsste, und der extrem sparsam im Idle, dafür aber noch immer sehr stark unter Last wäre.
Ich seh da jetzt dein Problem nicht
Jup, ein Betriebssystem, dass im laufenden Betrieb auf eine andere Architektur wechseln kann, wäre schon was feines.
So ähnlich wie ein 10 GHz Prozessor mit 10 mW Verbrauch.
Oder ein Fissionsreaktor, der keine Strahlung abgibt und keinen Müll produziert.
Oder ein Solarauto, dass nachts fährt.
Crosscompiles auf jedwede Architektur funktioniert auch.
Ich seh da keine unüberwindbaren Hürden. Mit MS ja durchaus aktuell, weil MS da aktiv werden muss.
Für Linux seh ich aber wirklich absolut kein Problem, Linux derart an zu passen, dass eben beide Architekturen in unterschiedlichen Powerstates genutzt werden. Man muss halt "nur" die Software und vor allem die Compiler fit dafür machen. Vor allem müssen die Hardware und Compilerhersteller Hand in Hand arbeiten, damit der Kontextwechsel auch wirklich sauber passt, und man nicht versehentlich den falschen Code verwendet
So unrealistisch wie du das darstellst ist das bei weitem nicht. Die Grundlagen dafür sind da, man muss es nur zusammenführen.
Genau hier seh ich z.B. auch eine Kernaufgabe für das HSA-Konsortium. Sie müssen entsprechende Schnittstellen für die Compiler/Hardware entwickeln, die genau so etwas reibungslos ermöglichen.
Schön gesagt.
"unterschiedliche Einsatzfelder"
"auf Kernkompetenzen konzentrieren"
Und was will HSA, zumindest der HSA-Partner-AMD-Theorie zu folge? Beide Architekturen gleichberechtigt parallel in einer einheitlichen Umgebung für die gleichen Aufgaben nutzen.
Ich versteh auch wirklich nicht, worauf du hinaus wilslt imt "gleichen Aufgaben" Man nimmt das, was am Besten für eine Aufgabe geeignet ist.
Für ein x86 Programm x86 Cores. Für ARM Programme ARM Cores. Für low Power/idle usw ARM, für Sequenzielle Parts mit viel Rechenbedarf x86. Für Sequenzielle parts, die nur sehr wenig Leistung brauchen (z.B. iGPU steuern usw usw) ARM, für massiv parallele Aufgaben die iGPU.
Das HSA Konzept ist absolut begrüßenswert! Wenn die Hardware das alles vom Programmierer weg nimmt, dann ist das göttlich, und selbst wenn es nur der Compiler übernimmt, ist es noch immer sehr sehr gut.
Es muss halt nur funktionieren
Bisher gibt es aber keine Anzeichen dafür, dass es eben nicht geht. Das Konsortium ist nur etwas ruhig. Jetzt muss sich zeigen, ob das die Stille vor der Veröffentlichung, oder die Stille vor dem großen Knall unter den Partnern ist. We will see.