News AMDs „Kabini“-Nachfolger „Beema“ gesichtet

[Whoozy]

Naja auf der Roadmap die ich gesehen habe stand auch nichts von HSA für Beema und Mullins. Ich muss aber sagen das die Roadmap schon etwas älter ist. Vorstellen kann ich es mir trotzdem nicht, setzt doch AMD ziemlich stark auf die Vorteile durch HSA und wird auch nicht müde diese zu bewerben. Also warum sollte man nicht nach Kaveri nun auch Beema und Mullins HSA fähig machen ?

 

[Kenneth Coldy]

aber ich erwarte mir von dir ja auch keinen quellen für die angebliche hUMA streichung

Meine Quellen für die angebliche Streichung? Kann es sein das Du da einfach nur was durcheinander bringst? Zur Erinnerung, hier mein erster Beitrag zum Thema:

Kaveri ist die erste und bisher einzige APU mit Unterstützung für hUMA, Beema unterstützt hUMA also, ebenso wie Kabini, "noch nicht" statt "nicht mehr".

Ich habe eben nicht behauptet das hUMA gestrichen worden wäre sondern im Gegenteil diese Falschaussage korrigiert.

DU hast darauf hin geschrieben

Beema/Mullins sollen hUMA unterstützen.

Daraufhin habe ich Dich um einen Beleg für Deine Behauptung gebeten. Nochmal zur Erinnerung: Wer behauptet muss belegen, denn das ist hier kein Religionsunterricht.

Ergänzung (20. April 2014)

Naja auf der Roadmap die ich gesehen habe stand auch nichts von HSA für Beema und Mullins.

Meine Rede. Ich habe schon letzte Woche einigen Aufwand betrieben um heraus zu finden ob es eine entsprechende Folie gegeben hat. Ich habe nichts gefunden.

warum sollte man nicht nach Kaveri nun auch Beema und Mullins HSA fähig machen ?

Vermutung: AMD hat HSA für B&M ebenso wie TrustZone für Kaveri inoffiziell in Aussicht gestellt, den Aufwand dafür aber unterschätzt oder die Entwickler zu früh entlassen. In der Folge wurde der Zeitplan gestreckt und hUMA niemals offiziell für B&M angekündigt. Weil aber Newsseiten gerne und immer wieder mal von anderen Newsseiten abschreiben wurden sowohl TZ für Kaveri als auch hUMA für B&M durch ständiges Wiederholen als zugesicherte Eigenschaft verkündet. voila ... Elvis lebt.

 

[pipip]

Kenneth Coldy
Habe mich hier auch nicht eingemischt, aber ich gehe davon aus, dass sich was HSA angeht im Vergleich zu Kabini nicht anders verhalten wird. Anderseits, ich glaube Kabini hatte noch nicht den ARM Chip oder ? Somit hat AMD bei B&M bereits etwas im Design neben den Pum+ Cores geändert, somit darf man klar die Frage stellen, ist hUMA jetzt auch dabei ?
Vermute eher dass das erst beim Nachfolger der Fall ist. Ich vermute Beema Nachfolger wird sich von Kaveri Nachfolger nicht viel unterscheiden was HSA angeht. Beide werden dann vollständig "verschmolzen" sein. Die Frage ist nur, wird der Nachfolger von Beema dann auch auf AM1 sein, was ja nicht unmöglich wäre, sprechen wir ja seit Kabini von SoC.

Edit
http://www.heise.de/newsticker/meld...parprozessoren-Kabini-und-Temash-2044461.html

Beema und Mullins werden die ersten Chips sein, auf denen AMD einen dedizierten Sicherheitsprozessor auf ARM-Basis integriert. Durch den Cortex-A5-Prozessor realisiert AMD die Sicherheitserweiterung TrustZone

Also das spricht schon mal dafür dass das Design verändert worden ist (neben den Puma+ Cores)

Weiters

AMD erklärte auf Anfrage, dass die kommenden APUs im Unterschied zu Kaveri keinerlei HSA-Funktionen unterstützen werden, also weder hUMA noch hQ.

 

[Mr.Kaijudo]

Soso Kabini und sein Nachfolger können also kein HSA genauso wie die PS4 kein HSA und hUMA kann welche auf der selben Architektur basiert lachhaft.

 

[Krethi & Plethi]

komisch das die das auch NUR heise so erklärt haben, ob da einfach etwas nicht verstanden wurde?
heise ist bezüglich infos zu AMD ja nicht ganz zum ernst nehmen.

kabini kann eigentlich auch "HSA", hUMA ist keine zwingende voraussetzung dafür!
die GPU unterstützt OpenCL, also wird "HSA" unterstützt.

"HSA" ist nur eine nette marketingabkürzung für einige dinge und nicht mit hUMA gleich zu setzen!

 

[pipip]

Mr.Kajudo
Die PS4 APU ist weder ein Kabini noch ein Beema, sie hat lediglich zwei Module mit Jaguar Cores. Somit kann die PS4 APU den benötigten (h)UMA haben. Aber im Endeffekt ist es auf einer Konsole sowieso egal, kann man HSA Operationen dank hardwarenahe-Programmierung der Architektur und dem gemeinsamen und großen Arbeitsspeicher sowieso realisieren. Theoretisch kann so was sogar die WiiU, hat sowohl CPU als auch GPU Zugriff auf den eDRAM, auch wenn Nintendo selbst von gpgpu spricht.
hUMA ist eher für den Desktop interessant um Programme HSA fähig zu machen und Programmierer das Leben besonders für den Desktop zu erleichtern.

K&P
Das interessante an HSA ist der erste Buchstabe, denn die Idee ist eine Aufgabe so zu verteilen dass die Aufgabe optimal auf die Ausführungseinheiten verteilt werden und somit nicht die Hauptlast auf der CPU liegt selbst wenn die GPU im Szenario schneller wäre. GPGPU betrachte ich als Teil von HSA, eventuell Vorstufe oder Mittel. Durch gpgpu ist HSA erst interessant geworden.
Somit ist die CPU nicht mehr der Mittelpunkt sondern auch GPU und SIMD stehen im Mittelpunkt und ermöglicht eine effizientere Auf gaben Lösung. Soweit die Theorie, soweit ich es verstanden habe. Das Marketing nannte es Fusion, HSA ist schon ein korrekter Name. hUMA ist im Endeffekt die Gleichstellung CPU und GPU vor dem Arbeitsspeicher, eine Form von Emanzipation und Programmierer können damit arbeiten und müssen den Code nicht erst selbst in die Richtung anpassen. Da man auf der PS4 jeden Register, Speicherzelle etc wie beim Assambler ansprechen können sollte, wieso soll HSA Operation dann nicht möglich sein. Konsolen werben ja mit gpgpu, at least Sony und Nintendo. Das beworbene gpgpu wird sicherlich HSA-charakter haben und zum Beispiel bei modernen Spiele KI oder Physik, Wetter etc würde die potente GPU und nicht die CPU machen müssen.

Kurzdassung: Die Konsolen APUs sind wie Smartphone-Chips AMP (asymmetric processing ) und deshalb spricht man auch beim CPU Part von Modulen. Im Endeffekt kommt es auf die Programmierung an ob die jeweiligen Prozessoren wie eine HSA APU handeln.

hUMA, HSAIL, HMMU, Queuing, context switching, ect, das alles ist dafür da, damit der Programmierer wie gewohnt in Hochsprachen programmieren kann und sich nicht darum kümmern muss, wie die Hardware des Computer aussieht. Bei der Konsole selbst ist die Hardware immer gleich.

 

[Kenneth Coldy]

@pipip: bitte bleib beim Thema. Vermutete Eigenschaften und Programmiermodelle einer Konsole Deiner Wahl solltest Du in einem passenderen Thread diskutieren.

 

[pipip]

Kenneth Coldy
Ich hab nur auf die Kritik oben reagiert, dass erstens PS4 APU nicht gleich ein Kabini oder Beema ist nur weil die PS4 APU zwei Module des AMP jaguar-cores beinhaltet und das, falls HSA Hardwareseitig nicht vollständig ausgeführt ist, HSA-Features in Konsolen durch die Programmierung durchaus möglich sein sollten, weil wir hier im Gegenteil zum PC die selbe Hardware haben.
Sonst habe ich erwähnt was die HSA Foundation unter eine APU versteht und Kabini oder Beema falls sie hUMA, Heterogeneous Queuing nicht beinhalten, keine höheren HSA-APUs wären (Context Switching glaube ich hat Kaveri auch schon, obwohl das erst im Nachfolger sein sollte, aber hier bin ich nicht ganz sicher), außer der Programmier nützt die passende Software, die AMD bereits freigegeben hat.
Doch eben diese Fähigkeiten würde es erlauben, einfach auf Beema HSA Applikation laufen zu bringen, ohne das der Programmierer viele Fragen an die Hardware benötigt. Die Konsolen waren hier wieder eine gute Gegenüberstellung zum Desktop PC, wieso eine Umsetzung von HSA auch im Hardware-Level besonders bei Desktop PC Sinn ergibt.

http://www.tomshardware.com/news/amd-opencl-driver-hsa,26194.html
Die nächsten Schritte um HSA durchzusetzen, ist neben der Hardware die Software so anzupassen, dass es für den Programmierer keinen Unterschied macht, ob er für eine CPU oder HSA APU programmieren und dazu wird der Finalizer HSAIL den Code für die APU anpassen.

To recap, Java already has limited support for HSA through Aparapi, an API for expressing parallelized workloads. The company expects the subsequent release of Java 8 to arrive in the middle of 2014 with support for Lambda language expressions and parallel acceleration (thanks to the Sumatra project, which sets out to let Java applications leverage GPUs and APUs) through the HSAIL intermediate language, culminating in native Java Virtual Machine (JVM) support via Java 9 in 2015. OpenCL 2.0 is expected to be the primary path for most apps on both Windows and Linux platforms, though, and AMD plans to deliver this functionality to selected developers in Q3 of this year, with optional features enabled in Q4 that should leverage even more HSA-specific optimizations and functionality.

Somit ist es, gegen der Behauptung von Krethi & Plethi, HSA sicherlich kein Marketing. Sondern es gibt verschiedene Abstufungen von HSA. Intel könnte ihre CPUs mit IGP auch als HSA vermarkten, wenn sie die passende Schnittstellen, Sprachen ect anbieten, so wie C++ AMP. Nur ist AMD (und HSA Foundation) durch die Hardwareumsetzung und die daraus verbundene einfache Programmierung einfach weiter als die Konkurrenz.

Im Endeffekt ist die Idee einer HSA APU, einen AMP, das kann jeder Smartphone SoC sein oder eben ein Desktop, Notebook Prozessor, so optimal wie möglich auszulasten um dadurch effizienter Anwendungen zu lösen ohne dass ein Part ständig alles koordinieren muss.

Somit, Beema bleibt eine APU, wird aber, wenn sie nicht auf dem Standard von Kaveri ist weiß ich nicht ob sie die meisten HSA-kompatiblen Programme so effizient ausführen kann wie es eben Kaveri kann.
Doch spricht AMD bei Kabini bereits von HSA Features und das wird mit GCN zu tun haben.

 

[Krethi & Plethi]

doch, HSA ist eben nur ein marketingausdruck für viele verschiedene sachen in der APU.
wenn eine APU kein hUMA unterstützt ist es falsch zu behaupten das sie nicht HSA kompatibel ist.

richland wird halt von HSA-programmen nicht so sehr unterstützen weil hUMA und hQ fehlen, aber die GPU wird die programme trotzdem beschleunigen.

wenn jetzt auf einer roadmap bei beema plötzlich HSA eingetragen werden würde, bedeutet das nicht gleichzeitig das hUMA dabei ist.
ausser sie schreiben Full-HSA oder ähnliches, aner nur HSA setzt halt hUMA nicht zwingend voraus, es ist nur ein sammelgebriff.

 

[pipip]

Krethi & Plethi
Ich finde dass Sammelbegriff der richtige Ausdruck für HSA wäre. Aber wie du es beschreibst, bei beema wird sicherlich HSA-Features stehen, so wie beim Vorgänger.

 

[Krethi & Plethi]

beema ohne HSA inkl, hUMA wäre mehr als lächerlich.

bei kabini gibt es das noch nicht weil es da halt nicht fertig war, der SoC der PS4 ist eine etwas weitere entwicklung, beema muß da logischerweise aufschließen.
wegen hUMA kabini zu verschieben war halt nicht nötig, so wichtig ist das aktuell auch wieder nicht.

unterstützt die PS4 eigentlich auch hQ?

 

[pipip]

Krethi & Plethi
Naja, wir müssen einfach Geduld haben ^^ Allein wegen dem Security ARM Prozessor wurde im Vergleich zu Kabini etwas verändert. Wir werden sehen ob es ein UMA oder hUMA sien wird.

 

[Krethi & Plethi]

man weis auch noch nicht in welchem prozess beema überhaupt gefertigt wird.
28nm kwürde auch noch fdSOI bei GF einschließen, ist ja ein standardprozess und angeblich soll Bulk einfach auf fdSOI portiert werden können.

doppelte effizienz bei gleichem verbrauch wird bei weiterhin Bulk nicht so leicht erreichbar sein, soviel besser wird der prozess bei GF nicht sein.
gerade eine so kleine Die wäre ideal um einen prozess zu testen, wenn er etwas taugt könnten sie vielleicht auch carizzo so fertigen lassen.

 

[pipip]

Krethi & Plethi
Erzählst genau den richtigen von fd-SoI.

https://www.computerbase.de/forum/t...-beema-gesichtet.1339726/page-5#post-15586712

Gut dass du die Fertigung ansprichst. Interessant ist eigentlich zu wissen ob der Prozessor überhaupt bei TSMC oder GF gefertigt wird.
Carrizo, Kaveri's Nachfolger soll ja einen anderen 28 nm Prozess als Kaveri verwenden. Wer sagt mir dass Kabini's Nachfolger Beema nicht den gleichen bekommt und als Versuchskaninchen fungiert ?
Fragen über Fragen die wir nicht beantworten können

Ich habe aber absichtlich fd-SoI nicht erwähnt auch wenn dieser Standard ca 90% der Geräte der normalen Bulk Fertigung nützten könnte und fd-SoI bereits erfolgreich bei ARM Prozessoren angewendet wurde, am Ende ist es nur eine Vermutung.
Aber seitdem Samsung und GF zusammen einen 14nm FinFet Prozess entwickeln, warte ich mal auf weitere News ab.

 

[Krethi & Plethi]

AMD kann ja theoretisch beema mal in fdSOI fertigen, das würde Carizzo ja nicht betreffen, ist ja eine ander maske.
kommt halt drauf an ob die ganzen aussagen bezüglich der einfachen portierung von Bulk auch der wahrheit entsprechen.

http://www.planet3dnow.de/vbulletin...alFoundries-?p=4899392&viewfull=1#post4899392

fdSOI soll ja mehr für energiesparende chips geeignet sein, also ideal für so niedrig getaktete puma-kerne.
im bereich von 4Ghz soll der prozess nichts bringen, dafür wäre vielleicht der von samsung dann wiederum besser.

AMD könnte aber ruhig sagen in welchem prozess man die beemas fertigt, die geheimhaltung bringt ihnen ja eigentlich nichts.

intel verwendet ja für haswell und baytrail ja immerhin auch nicht den selben prozess, AMD sollte auch wenn amn 2 unterschiedliche produkte hat bei jedem den optimalen verfügbaren prozess nutzen!

wird sicher auch eine kostenfrage, 14nm FinFET/Samsung ist sicher um einiges teurer als fdSOI 28/20nm.

wenn Gf in zukunft die GPUs in Bulk fertigen kann würden man die abnahmemenge wohl auch ohne den großen CPUs zusammen bekommen.
somit wäre es auch egal wenn GF für 14nm zu blöd ist, dann kann AMD ohne strafe zahlen zu müßen alle großen APUs auch direkt bei samsung bestellen:}

 

[10hmbAir13]

Wenn also Beema bei 15W sagen wir 20% fixer ist, als Kabini (25W TDP aber 15W real) dann haste bezogen auf die TDP deine 2x Perf / W schon erreicht, allerdings nur auf einer Marketingfolie

die performance-Unterschiede wird man subjektive kaum groß unterscheiden können. Wer Leistung benötigt, nimmt sicher keinen Beema oder Kabini.
Für soho wird es gerade Wurst sein, ob Beema oder Kabini. Was billiger ist, wird gekauft...(der Preis regelt)

 

[Daedal]

wenn Gf in zukunft die GPUs in Bulk fertigen kann würden man die abnahmemenge wohl auch ohne den großen CPUs zusammen bekommen.
somit wäre es auch egal wenn GF für 14nm zu blöd ist, dann kann AMD ohne strafe zahlen zu müßen alle großen APUs auch direkt bei samsung bestellen:}

Ich glaube nicht, dass es was,mit zu blöd zu tun hat. Wenn Samsung Reserve Kapazitäten haben möchte und hier Entwicklungskosten gespart werden und man selber noch Reserven bilden kann weil man eventuell für größere Stückzahlen Samsung in der Hinterhand hat. Dann wäre man als CEO ja dämlich auf einen eigen Prozess zu bestehen.

20 nm scheinen sehr problematisch zu sein und 14XM von GF sollte auf 20nm basieren und ist ja tatsächlich ein 20/14nm Mix. Wahrscheinlich hätte man die Probleme eine weitere Generation mitgeschleppt. So gewinnen alle...