AMDs CPU-Architekturen-Strategie (Skybridge, K12, Zen, ...)

[Unicous]

Einige interessante Übersetzung der Konferenz in Japan:



http://www.theregister.co.uk/2015/03/31/amd_opens_kimono_on_chip_futures_a_little_more/

Woher weiß du, dass das überhaupt (richtig) übersetzt wurde? The Register ist nicht bekannt für investigativ recherchierte Artikel und ich bezweifele, dass sie sich die Mühe gemacht haben, das Ganze übersetzen zu lassen, wenn Googlish.com doch so nahe liegt.

Das Ganze macht jedenfalls wenig Sinn.

[Kriton]

SMT bringt dir aber nichts wenn der Konkurrent mit IPC 1.8-2.2 fährt, du braucht bei einer scheiss IPC was besseres, SMT hilft dir nicht weiter.
Da kannste gleich pro Modul 4 Cluster verbauen und hast mehr Durchsatz als SMT.

Der Vergleich scheint mir falsch. Die Frage ist IMHO nicht ob SMT AMD in Schlagweite (oder darüber hinaus) zu Intel bringt, sondern wie die CPU im Vergleich zu einem theoretischen Äquivalent (von AMD) dasteht, das kein SMT hat (ggfs. bei gleicher Transistorenzahl/Fläche/TDP, etc.).

[Coda]

Intel wollte wohl etwas im Micro-Server-Bereich haben. Intel Atom ist eine scheussliche Architektur, IMO. Viele Operationen haben eine ziemlich hohe Latenz. Silvermont hat zum Glück für Intel einiges verbessert.
Ich rede von Silvermont.

[y33H@]

Äh ja ... selbst für HPC iwie unrealistisch - oder einfach nur krankes Teil ;D

16C Zen
32 MB L3
16 GB HBM
4x DDR4
Greenland-GPU
64x PCIe 3.0


51610

http://www.fudzilla.com/news/processors/37494-amd-x86-16-core-zen-apu-detailed

[Skysnake]

Also das sieht nach fake aus. Das DDR4 Quad-Interface ist schon ziemlich heftig, aber noch hinnehmbar, was dann aber meiner Meinung nach einfach unrealistisch ist, sind die 64 PCI-E 3.0 lanes. Sorry, aber das glaube ich bei bestem Willen nicht.


Ansonsten sieht das Ding eigentlich ziemlich gut aus. So wuerde ich mir eine HPC-APU auch vorstellen, wobei ich eher nur 8 CPU-Core erwarten wuerde, die aber eben hoeher takten und eine hoehere IPC haben. Die muessen vor allem extrem gute Sequenzielle Leistung bringen. Fuer alles parallele ist ja die iGPU da.

[FlashBFE]

Also das sieht nach fake aus. Das DDR4 Quad-Interface ist schon ziemlich heftig, aber noch hinnehmbar, was dann aber meiner Meinung nach einfach unrealistisch ist, sind die 64 PCI-E 3.0 lanes. Sorry, aber das glaube ich bei bestem Willen nicht.
Das sind viele, ja, aber ein Serverprozessor braucht auch Interconnects für Multiprozessor-Boards. Bei HyperTransport hat AMD für 8-Prozessor-Systeme jeweils 3 Kanäle benutzt. Wenn zwei Zen-APUs jetzt per PCIe 16x verbunden werden, dann wären in einem 8-APU-System schon 48 Lanes pro APU vergeben.

[Timbaloo]

Also mit gescheiter CPU und fetter GPU auf einem Chip wäre das eigentlich ein Ding von dem ich schon lange träume. Keine hässlichen Steckkarten mehr :)

[Godmode]

Also mit gescheiter CPU und fetter GPU auf einem Chip wäre das eigentlich ein Ding von dem ich schon lange träume. Keine hässlichen Steckkarten mehr :)

Wäre halt toll wenn man eine 200W CPU mit einer 300W GPU stapeln könnte, und dazu noch 64 GB HBM Speicher dazu. Für die Kühlung bräuchte man dann aber wirklich eine neue Lösung. :freak:

[tdon]

Sieht aus wie ein schlecht gemachter Fake.

[S940]

Also das sieht nach fake aus. Das DDR4 Quad-Interface ist schon ziemlich heftig, aber noch hinnehmbar,
Es sieht heftig im Vergleich zu Aktuellem aus, aber wir reden ja auch von 4x4 Cores. Dafür bräuchte man aktuell zwei G34-Sockel, und die hätten dann sogar 8 Speicherkanäle. Rechnet man DDR3 zu DDR4 im Verhältnis 1:2 kommt man dann wieder auf 4 .. ergo ne ganz normale Speicherbandbreite.

was dann aber meiner Meinung nach einfach unrealistisch ist, sind die 64 PCI-E 3.0 lanes. Sorry, aber das glaube ich bei bestem Willen nicht.
Hmm .. naja da steht dass 16 Lanes für Sata-Express herhalten müssen. 8 Lanes sollten für den Grafikoutput herhalten (ist zumindest bei den aktuellen APUs so), blieben noch 40 Lanes übrig. Das würde für zwei vollbelegte x16 Slots reichen, der Rest dann halt für Kleinkram, x1 Slots oder irgendwelche onboard Chips, vermutlich sind 1-2 Lanes auch noch mit dem Ethernet-Interface belegt.

Blieben noch 2 Fragen:
a) Ist der Chip groß genug um die ganzen I/O-Leitungen bereitstellen zu können?
Nachdem das selbst in 14nm ein großer Chip werden dürfte, könnte dafür auch genügend Platz sein.

b) Sind zwei x16 Slots Overkill für so nen Chip, der schon mit ner prächtigen Graka ausgestattet ist? Vermutlich auch nicht, denn statt der 16 Zen Kerne könnte man auch ne reine GPU mit mehr Shader bringen. Und/oder es wäre einfach ein Weg 3 solcher APUs zusammenzuschalten, Kaveri bekam für sowas ja schon den PCIe-Hostmodus verpasst.

Wer weiss .. vielleicht lassen sich die PCI-Lanes auch in nen coherent Hypertransport-4.0-Modus schalten? AMD hatte ~2011 PCIe/HTr-Kombilogik in Arbeit. Dann hätte man quasi ein 3P-Numa-System, wär sicherlich auch nicht verkehrt.

Resume: 64 Lanes schauen in der Tat erstmal nach viel aus, aber es gäbe schon diverse Einsatzmöglichkeiten.
Ansonsten sieht das Ding eigentlich ziemlich gut aus. So wuerde ich mir eine HPC-APU auch vorstellen, wobei ich eher nur 8 CPU-Core erwarten wuerde, die aber eben hoeher takten und eine hoehere IPC haben. Die muessen vor allem extrem gute Sequenzielle Leistung bringen. Fuer alles parallele ist ja die iGPU da.
Naja, ein hoher Takt ist mangels (S)HP-Prozess nicht mehr machbar und das Designziel war Perf/Watt, was das ebenfalls ausschließt. Auch die vermutlich verwendeten High-Density-Libs mögen keinen hohen Takt, von daher musst Du auf ne hohe IPC hoffen. Immerhin sind die Caches schon mal recht gut/groß. Solange der L3 gut angebunden und mit Fullspeed läuft, sollte da schon was gehen. Bei Bulldozer brachte das NB/L3-OC ja auch ne schöne Ausbeute an Mehrleistung.

[robbitop]

So viel sind 64x PCIe 3.0 Lanes nicht. Haswell-E hat 2014 bereits 40x. PCIe 4.0 steht vor der Tür. Insofern...

[fondness]

Für mich sieht die Folie auch nach eine schlecht gemachten Fake aus, ich glaube auch nicht das AMD zum jetzigen Zeitpunkt überhaupt schon solche Infos raus rückt.

Grundsätzlich sollte ein solcher Chip je nach Größe der GPU allerdings druchaus machbar sein, wir sprechen immerhin von 14nm Fertigung, da sind die insgesamt 40MB Cache oder die 64 PCIe-Lanes allemal möglich.

[S940]

Grundsätzlich sollte ein solcher Chip je nach Größe der GPU allerdings druchaus machbar sein, wir sprechen immerhin von 14nm Fertigung, da sind die insgesamt 40MB Cache oder die 64 PCIe-Lanes allemal möglich.Ganz so trivial ist das nicht, die Pins und Pads können nicht mehr kleiner werden, die ändern sich mit kleineren Prozessen also nicht.
D.h. man braucht MUSS bei kleineren Prozessen mehr Kerne & Co verbauen, wenn man die gleiche I/O-Anbindungen unterkriegen will. Da sind 64 PCI-Lanes und Quadchannel dann schon ne Ansage, da es auch noch mehr als aktuell ist.

Aber nachdem man die GPU "problemlos" vergrößern kann ist das im Endeffekt dann nur ne Kühlungs- und Energieverbrauchsfrage, also die ob man die vielen Shader dann auch gekühlt und versorgt bekommt.

[OBrian]

Auf der Folie fehlen zwar die üblichen Kopf- und Fußzeilen, aber man kann annehmen, daß die extra wegretouchiert wurden, zum Schutz der Quelle (daher wohl auch die schlechte Auflösung). Ob Fake oder nicht, kann man nie wissen, wäre ja zu einfach zu machen.

Aber die Daten sehen jedenfalls zwar ambitioniert, aber machbar aus. Man muß ja davon ausgehen, daß es ein großer Interposer wird, auf dem einige HBM-Stacks und mehrere Logik-Dies untergebracht werden. So wird auch eine Gesamt-Diefläche von sagen wir mal über 1000 mm² durchaus händelbar, wenn die Einzeldies nur max. 3-400 oder so haben.

ich glaube auch nicht das AMD zum jetzigen Zeitpunkt überhaupt schon solche Infos raus rücktnaja, wenn es echt ist, wissen wir ja nicht, wie verschwiegen diese Veranstaltung war, auf der diese Folie gezeigt wurde, oder wer Zugriff auf diese Datei hatte (bzw. nur hätte haben sollen).

[OBrian]

Ganz so trivial ist das nicht, die Pins und Pads können nicht mehr kleiner werden, die ändern sich mit kleineren Prozessen also nicht.Dafür ist aber der Interposer zuständig, und der darf ja durchaus einige mm² größer werden, denn dank seiner eher rückschrittlichen Fertigungstechnik (90 nm oder so reicht sicherlich dicke) ist der ja relativ billig.

Also muß im Logik-Die die Verbindung nicht so groß sein, daß sie im Package eingelötet werden kann, es reicht die kleinere Größe eines TSV. Erst vom Interposer zum Package muß es eine Nummer größer sein, aber da gehen ja weniger Verbindungen raus, weil der ganze RAM schon wegfällt.

[Hübie]

Vishera hatte laut Google 8Cores@32nm 320 mm^2 aufs Reißbrett gebracht. Zen soll 14 nm werden. Dann könnten ohne GPU 600 mm^2 bei 16 Kernen und geändertem Moduldesign herauskommen.
Zugegeben kennen ich mich aber nach wie vor nicht mit AMD und deren Prozessen etc aus. Vielleicht kann jemand fundierte Daten liefern :)

[Skysnake]

Für mich sieht die Folie auch nach eine schlecht gemachten Fake aus, ich glaube auch nicht das AMD zum jetzigen Zeitpunkt überhaupt schon solche Infos raus rückt.

Grundsätzlich sollte ein solcher Chip je nach Größe der GPU allerdings druchaus machbar sein, wir sprechen immerhin von 14nm Fertigung, da sind die insgesamt 40MB Cache oder die 64 PCIe-Lanes allemal möglich.
Wir reden aber noch immer von AMD. Das wäre ein viel zu großees Risiko so ein Gewaltding zu bringen. Es überrascht vielleicht viele, aber PCI-E 3.0 zu bringen ist gar nicht sooo einfach! Schon gar nicht mit so extrem vielen Lanes. Selbst Intel hatte mit seinen "gerade" mal 40 Lanes genug Probleme.

Und wie schon gesagt wurde, PCI-E 4.0 steht auch schon vor der Tür. Wenn dann lieber PCI-E 4.0 bringen mit weniger Lanes. Macht mehr Sinn.

[mczak]

Vishera hatte laut Google 8Cores@32nm 320 mm^2 aufs Reißbrett gebracht. Zen soll 14 nm werden. Dann könnten ohne GPU 600 mm^2 bei 16 Kernen und geändertem Moduldesign herauskommen.
Zugegeben kennen ich mich aber nach wie vor nicht mit AMD und deren Prozessen etc aus. Vielleicht kann jemand fundierte Daten liefern :)
Nun, intel packt schon in 22nm (Haswell) sowohl mehr Kerne (18) wie auch mehr L3 (45MB) auf ein einzelnes Die. Gut das benötigt dann auch etwas mehr als 600mm^2. Und das ebenfalls mit quad-channel DDR4 (und etwas weniger PCIE-Lanes).
Von daher also sicher möglich. Scheint mir trotzdem nicht sonderlich realistisch zu sein. Das skaliert sich nicht einfach so hoch (intel hat beim Haswell Xeon ja auch bei allen Chips über 8 Kernen 2 Ring-busse, 2 home agents mit je einem dual-channel ddr4 Speichercontroller). Da müsste man imho zuerst einmal beweisen dass das ganze auch eine ganze Stufe kleiner vernünftig funktioniert bevor man sich an solche Monster wagt.

[S940]

Es überrascht vielleicht viele, aber PCI-E 3.0 zu bringen ist gar nicht sooo einfach! Schon gar nicht mit so extrem vielen Lanes. Selbst Intel hatte mit seinen "gerade" mal 40 Lanes genug Probleme.

Und wie schon gesagt wurde, PCI-E 4.0 steht auch schon vor der Tür. Wenn dann lieber PCI-E 4.0 bringen mit weniger Lanes. Macht mehr Sinn.
Im Serverbereich schon, da braucht man was stabiles, keine Beta-Technik, solltest Du doch wissen :)
PCIe3 mag schwer sein, aber wer weiss welche grauen Haare Dir PCIe4 auf den Kopf zaubern würden, selbst mit weniger Lanes.

[Skysnake]

Naja, PCI-E 4.0 IP kannste schon kaufen bei Cadence. Zumindest steht es bei Ihnen im Portfolio schon drin. Zudem wird man wohl nicht die gleichen Fehler wie bei PCI-E3.0 machen und das mit heiser Nadel stricken.

Bei PCI-E 4.0 gehe ich von einigen Einschränkungen bzgl. Leitungslänge usw aus. Zudem sollten die Hersteller mit 3.0 auch einiges an Erfahrung gesammelt haben, wie man mit nicht so knalle Kanälen umgeht.

[Leonidas]

Was mich eher interessieren würde: Tolle Features für einen Serverchip - und dann eine feste GPU da rein mit extra 16 GB HBM-Speicher .... für was? Sicherlich ist GPGPU im Server-Segment schon eine relevante Sache, aber bei Intel kann man es auch trennen bzw. je nach Bedarf zusammenstellen. AMD will hier aber (scheinbar) eine Server-APU rausbringen. Für welche Anwendungszwecke, die nach so etwas schreien? Und welche der normalen Anwendungszwecke für Server-CPUs lacht sich so etwas an, wo 1/3 des Chips sinnlos rumidelt?

[Wörns]

Eine Server APU macht m.E. nur Sinn, wenn AMD jetzt schon verlässliche Abnehmer im HPC Bereich kennt. Ich denke da an amerikanische Behörden (Atom- , Energie-), die regelmäßig Großrechner mit GPGPU-Unterstützung bestellen. Mal mit AMD, mal Nvidia, zuletzt erst mit Intel.
Aber eher glaube ich gar nicht an die Server-APU.
MfG

[Limit]

Ein solcher Chip als ganzes macht imho keinen so großen Sinn. Die einzelne Teile für sich genommen würden hingegen schon passen. Sollte die Folie kein kompletter Fake sein, würde ich eher vermuten, dass das eine theoretischer Maximalausbau ist. Je nach Anwendungszweck könnte man dann die CPU dann einfach "zurechtschneiden".

Der "normale" Server bekommt die vollen 16 CPU-Kerne mit QC-DDR4 Interface und den viele PCIe-Lanes, die GPU wird aber je nach Bedarf zurechtgestutzt oder komplett entfernt.
Für den HPC-Bereich reduziert man hingegen die Zahl der CPU-Kerne zugunsten der GPU um ein besseres Perf/Watt Verhältnis zu bekommen. Die Variante dürfte vermutlich am nächsten am Maximalausbau dranliegen.
Für Konsolen wäre dann eine Variante mit 4-8 CPU-Kernen und viel weniger PCIe-Lanes interessant. Die GPU dürfte dann je nach Preislage hingegen bis zum Maximum ausgebaut werden, das DDR4-Interface evtl. komplett entfernt werden.
Für den Desktopbereich wird das Speicherinterface und die PCIe-Lanes zusammengestrichen. Bei der Zahl der CPU-/GPU-Kerne müsste man hier allerdings ein weiteres Spektrum anbieten als bei bisherigen APUs.

Es wäre natürlich toll, wenn es so käme, aber das wäre gefühlsmäßig eine Nummer zu groß für AMD, zumindest wenn alles gleich gescheit funktionieren soll.

[OBrian]

Gerade wenn es mehrere Logik-Dies sind, die auf einem Interposer zusammengebaut werden, ist die Customisierung ja noch einfacher. Wer die GPU nciht braucht, kriegt das Paket eben ohne GPU, wer eine größere braucht, kriegt die.

[stav0815]

Vielleicht ist das auch nur die Aufschlüsselung des Zen-Baukastens... so nach dem Motto: Pick 3 of...

[Wörns]

Das wäre natürlich ein schönes Baukastensystem.
Allerdings habe ich es bisher so verstanden, dass auf dem Interposer einzig HBM variabel ist. Sonst würde ich auch gleich eine viel fettere GPU dranbasteln wollen, wenn der Chip in das HPC Segment geht.
MfG

[Skysnake]

Was mich eher interessieren würde: Tolle Features für einen Serverchip - und dann eine feste GPU da rein mit extra 16 GB HBM-Speicher .... für was? Sicherlich ist GPGPU im Server-Segment schon eine relevante Sache, aber bei Intel kann man es auch trennen bzw. je nach Bedarf zusammenstellen. AMD will hier aber (scheinbar) eine Server-APU rausbringen. Für welche Anwendungszwecke, die nach so etwas schreien? Und welche der normalen Anwendungszwecke für Server-CPUs lacht sich so etwas an, wo 1/3 des Chips sinnlos rumidelt?
Naja, die Dinger werden komplett HSA kompatibel sein. DAher kann man die iGPU auch als sehr fette SIMD-Unit betrachten meiner Meinung nach.

Damit ist dann an sich auch schon klar, wer an so etwas interesse hat.

[CD-LABS]

Was mich eher interessieren würde: Tolle Features für einen Serverchip - und dann eine feste GPU da rein mit extra 16 GB HBM-Speicher .... für was? Sicherlich ist GPGPU im Server-Segment schon eine relevante Sache, aber bei Intel kann man es auch trennen bzw. je nach Bedarf zusammenstellen. AMD will hier aber (scheinbar) eine Server-APU rausbringen. Für welche Anwendungszwecke, die nach so etwas schreien? Und welche der normalen Anwendungszwecke für Server-CPUs lacht sich so etwas an, wo 1/3 des Chips sinnlos rumidelt?
Nunja, fragt sich halt, wofür der Chip gedacht ist: Gaming? Server? Server- und Gaming?!
Ich tendiere klar zum letzteren; gegen den reinen Server-Einsatz spricht mmn. die "Multimedia Engine", gegen einen reinen Gaming-Einsatz die DoublePrecisionRate!
ECC-Speicher, der Kombi-Speicher und die Masse an PCIe-Lanes seh ich in beiden Segmenten als möglicherweise sinnvoll an. Für High-End-Gaming werden 2017/2018 sicher keine 16 GiB HBM KOMBI-SPEICHER mehr reichen, da muss mehr her und DDR4 ist da sicher nicht die schlechteste Wahl, um kostengünstig die Kapazität in die Höhe zu treiben.
Konzepte wie die vollständige Deaktivierung eines Speicherpools im Idle, ein Cacheing-System und ähnliche schießen mir gerade durch den Kopf...
...und ECC ist seit des Bekanntwerden des Bruteforce-Schadcodeinjektionsprinzips auch für Heimanwender interessant geworden!

Als den großen Faktor wieso Serverbetreiber das Teil Xeon+Xeon Phi vorziehen sollten fällt mir indes nur einer ein: Der Preis! Und genau den könnte AMD massiv drücken, wenn das Teil auch im Gamingbereich eingesetzt werden kann, also die "miesen" Chips in großer Zahl bei den Heimanwendern landen würden.

Insgesamt schwirren mir da aber eh viel zu viele Variablen rum:
Wir haben keine Ahnung, wie sich HBM in der Praxis auf einer APU verhält (Stichwort Leistungsaufnahme im Idle/ Sleep)
Wir haben keine Ahnung, wie AMDs nächste CPU-Generation aufgebaut sein wird, wie groß ein Kern ausfällt, ...
Wir haben keine Ahnung, ob die so stark von AMD gewünschte Multicore-Gaming- und GPGPU-Revolution eintritt! (Bis vor kurzem hätte ich klar mit nein geantwortet, die Ankündigungen zu DX 12 und Vulkan haben die Lage aber ein wenig gewandelt)
Wir haben keine Ahnung, ob AMD mit seiner Semi-Custom-Sparte gelernt hat kostengünstig modulare Designs zu entwerfen!
Und wir haben keine Ahnung, wie gut der 14nm-Prozess werden wird...


...und, das aller Wichtigste: Es ist und bleibt Fudzilla! :rolleyes:

[OBrian]

Wenn AMD HBM auf APUs einsetzen will, werden sie in jedem Fall einen Weg finden müssen, noch weiteren Speicher in Form stinknormaler Steckmodule verbauen zu können. Und zuviel HBM-RAM darf es auch nicht sein, weil das sonst alles zu teuer wird. Es muß auch ganz ohne HBM gehen, es sei denn, AMD führt die biliige Puma+-Linie doch weiter (eigentlich erwarten ja alle, daß Zen beide aktuellen Linien ablöst).

Für High-End-Gaming ist das Teil eh ungeeignet, so ähnlich wie Intels Haswell-E-Plattform, die trotz mehrfach höherer Kosten bei Games auch nicht besser dasteht als ein normaler Haswell. Bei 16 Kernen (was viel zu viel ist, um sie mit Spielen auslasten zu können, noch dazu, wenn sie 32 Threads "abkönnen") muß der Takt zwangsläufig niedriger sein als er sein könnte, wenn man die machbare TDP auf weniger Kerne verteilen muß.

Nein, wenn es das Teil gibt, dann rein für Großrechneranlagen. Oder es ist für eine Next-Gen-Konsole (die aktuellen Konsolen werden ja nicht so lange durchhalten wie die früheren, und die nächste Generation wird voll abwärtskompatibel werden, 2016 oder '17 wäre also durchaus denkbar für Xbox Two oder Playstation 5).

Aber für einen oberen-Mainstream-bis-High-End-Chip, der für einige hundert Euro in PCs wandern soll, wären 8 Kerne und gar keine GPU sinnvoller. HBM könnte man dann auch weglassen, weil ja nur die GPU so viel Bandbreite braucht, für eine reine CPU reicht sicherlich auch DDR4. Dann kann man das Ganze auch herkömmlich fertigen und nicht aus mehreren Dies mit Interposer.

[L.ED]

Nein es muss eine APU sein auch im normalen Desktop HighEnd und Gaming Maschinen wenn AMD endlich ernst machen möchte (im sinne von Butter bei de Fische), Stichwort HSA/GPGPU! Z.b. ausladende mit dem Spieler interagierende Physik (richtig weiter gehende), nur so möglich!

Ich verstehe vor diesem Hintergrund eigentlich nicht warum nach wie vor die sog. Gamer Fraktion (selbst offenbar im 3DCenter), immer noch nach CPUs schreit die keine BiG Vector Einheit direkt integriert (GPU Part/Kern). Es ist eigentlich völlig entgegen ihrer Interessen, muss schlicht Unwissen drum sein (hier wären die diversen IT Seiten mal gefordert)?!

PS:
Anders gesagt es darf zukünftig im grunde nichts anderes mehr geben als APU artiges, nur so bekommen das HSA Thema mal so langsam in aller breite in fahrt! :wink:

[y33H@]

Höchst unwahrscheinlich IMHO - keine APU für High End Gaming, da entwickelt keiner was für. Außer Intel springt auf den HSA-Zug. Auch unwahrscheinlich (vorerst).

[anddill]

Wenn die aktuellen APUs nicht sogar vom 3 Jahre alten FX aus eigenem Haus Staub fressen würden könnte man sie auch mal ernst nehmen.

[L.ED]

Es ist nen klassisches *Henne ↔ Ei Ding*, deshalb muss AMD schlicht erst mal eine vernünftige HSA Plattform aka Basis liefern! Im Sinne von die ganze Palette durch, angefangen vom einsteiger bis zum sog. HighEnd Segment!

Und bei letzterem hapert es momentan noch ganz gewaltig und die aktuell noch so ausgeprägt existente Aufspaltung (selbst im AMD Lager), ist der Bremsklotz schlechthin! Den muss AMD unbedingt rasieren und dessen bedarf eben minimal zum einstieg dann schon eine 8 Kern APU. Fürs High Performance/semi HighEnd im Jahre 2016 allerdings besser mehr, unter minimal 10 Kernen würde da an stelle von AMD nicht mehr antanzen (besser 12 bis 16)! :wink:

PS: Ja, meine schon Kerne nicht Threads (sei nur noch angefügt weil für viel zu viele dahingehend kein Unterschied zu existieren scheint ^^).

[CD-LABS]

Nein es muss eine APU sein auch im normalen Desktop HighEnd und Gaming Maschinen wenn AMD endlich ernst machen möchte (im sinne von Butter bei de Fische), Stichwort HSA/GPGPU! Z.b. ausladende mit dem Spieler interagierende Physik (richtig weiter gehende), nur so möglich!

Ich verstehe vor diesem Hintergrund eigentlich nicht warum nach wie vor die sog. Gamer Fraktion (selbst offenbar im 3DCenter), immer noch nach CPUs schreit die keine BiG Vector Einheit direkt integriert (GPU Part/Kern). Es ist eigentlich völlig entgegen ihrer Interessen, muss schlicht Unwissen drum sein (hier wären die diversen IT Seiten mal gefordert)?!

PS:
Anders gesagt es darf zukünftig im grunde nichts anderes mehr geben als APU artiges, nur so bekommen das HSA Thema mal so langsam in aller breite in fahrt! :wink:
Weil die momentanigen APUs noch Speicherbandbreitenlimitiert sind, haben viele Gamer die Assoziation APU=zu lahm!
Dass das natürlich nur auf die HEUTIGEN APUs zutrifft, ist selbstverständlich klar, aber halt dennoch nicht jedem bewusst!
Wenn die aktuellen APUs nicht sogar vom 3 Jahre alten FX aus eigenem Haus Staub fressen würden könnte man sie auch mal ernst nehmen.
Es ging AUSDRÜCKLICH nicht um aktuelle APUs. Und selbst dann ist das ein enorm schlechtes Argument...
...ein Xeon E3-1230 v2 schlägt ja schließlich auch einen Broadwell mit Iris Pro! :D :D :D

[Coda]

Höchst unwahrscheinlich IMHO - keine APU für High End Gaming, da entwickelt keiner was für. Außer Intel springt auf den HSA-Zug. Auch unwahrscheinlich (vorerst).
Hä? Machen sie doch schon lang.

[y33H@]

Was macht wer? APU für High End Gaming? Ja, Konsolen wenn man so will. Intel und HSA? Nein, außer du meinst so Zeug wie Pixel Sync.

[Coda]

HSA ist Marketing-BS, die Features sind da.

[L.ED]

Es geht dabei aber nicht darum die dezidierten Grafikkarten zu ersetzen, im Gegenteil die bleiben nach wie vor selbstverständlich erforderlich (es geht um HSA/GPGPU)!

Deshalb würde Zukünftig einfach davon abgehen von GPU Kernen zu Sprechen und es schlicht als Vector Block betiteln. Einfach damit die Leute mal diese Kurve im Kopf bekommen (es Rallen)! Das darüber natürlich auch weiterhin die Anzeige ausgegeben werden kann/könnte (als Art fallback), sei doch dahin gestellt und gerne mitgenommen! :smile:

Und @Coda hat es schon angerissen, HSA ist nur ein Überbegriff den u.a. AMD verwendet, rein Technisch ist auch Intel seit längerem im selben Zug (zumindest zugestiegen). Oder glaubt hier einer es ging und geht bei ihnen darum bessere APU Gaming Performance zu erreichen bei ihren eigenen diesbezüglich Anstrengungen (was zuletzt in u.a. L4 Cache gemündet)!

Was man aber durchaus sagen kann ist das Intel versucht es herauszuzögern um maximal den anderen Pfad noch abzumelken. Bei dem Schwergewicht braucht und kann man von daher nix herein zu interpretieren wenn sie immer noch auch reine CPU Projekte raus hauen. Das ist nichts weiter als Strategie und dahingehend ist viel interessanter was AMD macht, weil jene eben nicht die Ressourcen haben um an der Kante groß noch Spielchen zu treiben. :wink:

PS: U.a. AMD möchte das HSA Zeitalter (den nächsten Schritt aka diese Evolution), von daher würde es mich wirklich wundern wenn sie mit ZEN diesen CUT nicht endlich komplett machen (sprich nur noch APUs)!

[StefanV]

Was macht wer? APU für High End Gaming? Ja, Konsolen wenn man so will. Intel und HSA? Nein, außer du meinst so Zeug wie Pixel Sync.
Nein, aber es gibt da noch was wie DX11 und DX12, OpenCL, was von Intel auch gewöhnlich unterstützt wird. Und OpenCL sogar noch deutlich besser als nVidia. Das geht also durchaus.

Und wenn ichs recht im Hirn habe, dann ist bei 'nem Haswell nur der Display Controller aus, Zugriff auf die Grafikeinheit hast du aber auch damit...

[Leonidas]

Nein es muss eine APU sein auch im normalen Desktop HighEnd und Gaming Maschinen wenn AMD endlich ernst machen möchte (im sinne von Butter bei de Fische), Stichwort HSA/GPGPU! Z.b. ausladende mit dem Spieler interagierende Physik (richtig weiter gehende), nur so möglich!



Wir haben diese Einheiten seit Jahren. Genutzt wurde das nie. Warum also? Bei Skylake kann man sich für den Flächenbedarf der iGPU eine verdoppelte CPU kaufen. Was würde den Spieler wohl glücklicher machen?

[CD-LABS]

Wir haben diese Einheiten seit Jahren. Genutzt wurde das nie. Warum also? Bei Skylake kann man sich für den Flächenbedarf der iGPU eine verdoppelte CPU kaufen. Was würde den Spieler wohl glücklicher machen?
Momentan (dank des Fehlens von Vulkan und DirectX 12) ist ein Kernanzahl >4 fürs Gaming doch nahezu irrelevant...
...wenn man die iGPU wenigstens IRGENDWIE (z.B. zur Reduktion der Leistungsaufnahme) nutzen kann, würd ich auf die iGPU tippen!

Außerdem machst du weiterhin den gleichen gedanklichen Fehler: Die heutigen APUs können gamingtechnisch "nix" (sehr überspitzt dargestellt, schließlich sind die kleineren zum Teil echte Preis-Leistungskracher) aufgrund der Speicherlimitierung!

Und @L.ED: Das mag deine Auffassung sein. Meine ist es nicht!
Die APUs haben doch jetzt schon den Ultra-Low-Cost-Bereich geschluckt. Mach sie was stärker, und sie können auch LowCost und Midrange, vllt. sogar das Performancesegment fressen. Darüber reden wir natürlich weiter über dGPU---und ja, in dem Segment klingen dann auch deine Überlegungen wieder gut!

[Elite_Warrior]

vielleicht macht die dicke APU doch Sinn, denn mit Vulcan\Mantle\DX12 wäre es doch möglich die APU als crossfire mit SFR(oder was auch immer) an einem Bild mit rendern zu lassen. Also für lau mehr performance nimmt man gerne mit.

[anddill]

Die Ideale Aufteilung für einen spieletauglichen PC wäre:
Interne GPU für niedrige Ansprüche oder für Physik/KI/parallelisierbare Aufgaben. -> AMD: Check ... Intel --> Fail
Fette CPU mit 8 Threads (L3, >4GHz etc) --> AMD: Fail ... Intel: Check
Externe Grafikkarte als Pixelknecht --> Check

Irgendwas fehlt immer. Es gibt keine Henne, also kann es auch kein Ei geben.

[y33H@]

Die heutigen APUs können gamingtechnisch "nix" (sehr überspitzt dargestellt, schließlich sind die kleineren zum Teil echte Preis-Leistungskracher) aufgrund der Speicherlimitierung!Selbst mit HBM hat die GPU in einem Kaveri immer noch nur 512 ALUs.

[OBrian]

seit wann hat oder bekommt Kaveri HBM? Kaveri hat "nur" 512 Shader, weil einerseits die Fertigungstechnologie (sprich Diefläche) und andererseits die verfügbare RAM-Bandbreite noch mehr unsinnig macht. Aber wenn es HBM gibt und in sagen wir 14 nm gefertigt wird, dann wird AMD sicherlich auch wesentlich mehr Shader verbauen können, schätzungsweise mehr als das Doppelte.

[fondness]

Das stimmt schon, nur trifft das natürlich genau so auf diskrete GPUs zu, der Abstand dürfte also ca. gleich bleiben. Okay HBM löst das Bandbreitenproblem keine Frage, aber ich denke nicht das AMD deswegen riesen APU-Dies fertigen wird.

[y33H@]

seit wann hat oder bekommt Kaveri HBM?Gemeint war, selbst wenn Kaveri HBM hätte, würde das an der Anzahl der ALUs nichts ändern. Doppelt so viele mit HBM in 14nmFF? Kommt wohl auch auf die Zen-Kerne an.

[Coda]

Die Ideale Aufteilung für einen spieletauglichen PC wäre:
Interne GPU für niedrige Ansprüche oder für Physik/KI/parallelisierbare Aufgaben. -> AMD: Check ... Intel --> Fail
Fette CPU mit 8 Threads (L3, >4GHz etc) --> AMD: Fail ... Intel: Check
Externe Grafikkarte als Pixelknecht --> Check

Irgendwas fehlt immer. Es gibt keine Henne, also kann es auch kein Ei geben.
Ich wiederspreche. Ich will dedizierte GPUs im Prinzip so schnell wie möglich los werden.

Vermutlich verhindert das effektiv nur NVIDIA, weil sie keine x86-Cores bauen dürfen.

[Skysnake]

Ja wäre schon sehr schick, weil man dann eben nicht PCI-E immer als bottleneck beachten müsste.

HSA ist Marketing-BS, die Features sind da.
Intels iGPU kann tasks auf der CPU anstoßen, unterstützt Preemption und die ganze zich Seiten lange Anforderungsliste von HSA1.0?

Wäre mir wirklich neu. Intel geht auch einen ähnlichen Weg, aber die iGPU ist bei weitem noch nicht so stark integriert wie HSA das vorsieht. Bei Intel ist die iGPU meiner Meinung nach noch immer klar eine klassische GPU, die einfach nur stumpf tasks entgegen nimmt und abarbeitet. Mehr nicht.

[Locuza]

Intels iGPU kann tasks auf der CPU anstoßen, unterstützt Preemption und die ganze zich Seiten lange Anforderungsliste von HSA1.0?

Wäre mir wirklich neu. Intel geht auch einen ähnlichen Weg, aber die iGPU ist bei weitem noch nicht so stark integriert wie HSA das vorsieht. Bei Intel ist die iGPU meiner Meinung nach noch immer klar eine klassische GPU, die einfach nur stumpf tasks entgegen nimmt und abarbeitet. Mehr nicht.
Also, die iGPU hängt an einem gemeinsamen Cache-Ring und kann Daten darüber verschicken.
Das ist viel integrierter als bei AMD mit zusätzlichen Verbindungen.
Seit Haswell gibt es auch InstantAccess (Zero-Copy).
Mit Broadwell kommt Intel auf Kaveri Level bzw. darüber.
Cache- Kohärenz, simple Pointer etc.

Die erste HSA 1.0 APU mit GPU-Preemption kommt auch erst in Form von Carrizo.
Wir müssen jetzt nicht so tun, als ob AMD das schon seit 5 Generationen verbaut und Intel noch 10 Jahre zurückliegt.
Dieses Jahr kommt auch Skylake, da müssen wir auch noch abwarten was Intel für Fortschritte gemacht hat.

Langsam werden die iGPUs selber brauchbar.

[Skysnake]

Klar fehlt noch der erste Chip mit vollem HSA-Featureset. Der Punkt ist nur, das entwickelt man nicht mal eben so.

Intel hat zwar die iGPU mit am Ringbus dran, aber gerade die Cohärenz zu gewährleisten ist doch noch etwas mehr als das. Wenn Intel morgen sagen würde, wir machen das, dann seh ich dennoch keine Chips vor 2-3 Jahren von denen.

[Locuza]

Broadwell ist aber schon draußen, der kommt nicht erst in 2 oder 3 Jahren.

Mal ein kurzer Überblick wie sich bei Intel die letzten Jahre das ganze bei Heterogeneous-Compute und der GPU entwickelt hat.

Sandy-Bridge: ("1 APU Gen")
CPU und GPU auf einem die, CPU und GPU teilen sich den last-level-cache und können darüber teilweise Daten austauschen, ohne den Umweg zum Speicher.

Die GPU ist simpel, hat schreckliches AF, DX10.1 war das höchste der Gefühle.

Ivy-Bridge: (2nd Gen)

Alles mehr oder weniger wie bei Sandy-Bridge mit wichtigen Verfeinerungen.
Die GPU bekommt einen eigenen L3-Cache, es geht nicht alles über den LLC.
Das AF wurde gefixed, die GPU steigt im Feature-Level auf DX11.
OpenCL 1.x wird unterstützt.

Haswell: (3rd Gen)

InstantAccess wird angeboten, damit kann die CPU direkt in den Speicherbereich der GPU schreiben, ohne Kopiervorgänge.

Dazu gab es noch PixelSync was ich persönlich mega cool finde und Gott sei Dank Bestandteil von DX12 ist.

Broadwell: (4th Gen)

Ab hier wird Cache-Kohärenz umgesetzt:
http://images.anandtech.com/doci/8814/Compute%20Architecture%20of%20Gen8.png

Support für OpenCL 2.0, shared virtual memory, device-side enqueue, work group operations.

Skylake: (5th Gen)

???

Dank AMDs Finanzlage kann man nicht viel erwarten, aber AMD sollte in Zukunft zusehen, nicht überholt zu werden und irgendwann grundlegend das data-sharing von CPU und GPU umbauen, so wie es bei Intel seit Ewigkeiten implementiert ist.

[CD-LABS]

Ich wiederspreche. Ich will dedizierte GPUs im Prinzip so schnell wie möglich los werden.

Vermutlich verhindert das effektiv nur NVIDIA, weil sie keine x86-Cores bauen dürfen.
Hab ich früher auch gedacht; es spricht aber eigentlich nichts dafür, dass sich da Nvidia irgendwie bisher eingemischt hätte. Nein, bisher resultiert eigentlich alles aus drei Tatsachen:
1. Viel DDR-Speicherbandbreite (also >= 4-Channel) macht Boards unglaublich teuer. Wenig Speicherbandbreite macht High-End-APUs unmöglich.
2. HBM ist noch nicht einsatzfähig, und selbst dann wird es erstmal ziemlich schwierig werden, die für Gaming-Systeme nötige Gesamtspeichermasse ausschließlich mit HBM zu erreichen.
3. DirectX12 und Vulkan sind noch nicht da und damit auch kein flächendeckender Multicoresupport im Gaming; und gerade viele langsame Kerne sind deutlich besser für APUs geeignet als wenige schnelle!

Höchstens auf Punkt III hatte Nvidia Einfluss---und natürlich darauf, dass AMD generell recht wenig Resourcen zur Verfügung haben, weil Nvidia sie nahezu restlos aus dem Midrange-Notebookmarkt gedrängt hat, indem ansonsten die alten APU-Gens hätten brillieren können!

Auf Dauer werden wir aber so oder so das Ende der dGPUs sehen. Denn bald wird sich eine Anbindung von externen Einheiten einfach als zu ineffizient bezüglich der Signallaufwege herausstellen. Ich hoffe nur, dass Nvidia die jetzt gerade gewonnenen Finanzmittel bereits dafür nutzt, auch irgendwie in den APU-Markt zu kommen

[Coda]

Multicore-Support hat nur partiell was mit DX12 und Vulkan zu tun.

[samm]

HSA ist Marketing-BS, die Features sind da.Technisch ziemlich breit und konkret angelegt (http://www.hsafoundation.com/html/HSA_Library.htm), und marketingmässig ziemlich schecht aufgestellt für reinen Marketing-BS ...

[Coda]

So what? Das ist API-Zeugs, die Hardware von Intel hat die Features.

Für Spiele ist das irrelevant, niemand benutzt da diese API. DirectX/OpenGL oder Vulkan. Vielleicht noch CUDA. Aber ganz sicher nicht HSA.

[samm]

Der Zusammenhang mit Spielen war mir da entgangen. Mag sein, dass Intel sogar alles Nötige in der Hardware hätte, aber würden sie dafür sorgen, dass HSAIL --> Hardware für sie funktioniert? Vielleicht, wenn die Sache irgendwann abhebt...

So oder so, bislang hat es zu keinem zusätzlichen Standbein für AMD gereicht, auch wenn sie Grundlagen für Tools und inzwischen auch allgemein einen etwas aktiveren Dev-Support zur Verfügung stellen. Insofern weiss ich nicht, ob sie für die kommenden Cores die Integration noch weiter pushen, als es bei Carrizo der Fall ist.

[Coda]

Meine Herangehensweise ist, dass Spiele im Consumer-Bereich was Highend angeht eigentlich immer der Faktor ist der zählt, deshalb halte ich die API "HSA" für ziemlich irrelevant.

HSA als Konzept ist sehr wichtig und Intel muss sich da nicht verstecken. Sie waren zum Beispiel die ersten die direkte Texture-Uploads ohne Kopie erlaubt haben.

[Kriton]

Wird es denn Deiner Ansicht nach künftig für Spiele relevanter? Ggfs. durch Integration beispielsweise in Vulkan?

[Coda]

Was jetzt genau? Die Konzepte? Ja. Die API? Nein.

[Locuza]

Es gibt wieder FUAD auf dem Tisch. :redface:

http://www.fudzilla.com/news/processors/37564-the-next-generation-opteron-has-32-zen-x86-cores

Neben der angeblichen APU-Variante wird es auch ein reines CPU-Angebot geben, mit eben der doppelten Kernanzahl.
32 Cores, 64 Threads, insgesamt 16 MB L2$ und 64 MB L3$.

Das hier quote ich einfach mal:
A few other notable features for the next generation server parts include a new platform security processor that enables secure boot and crypto coprocessor. The next generation Opteron has eight DDR4 memory channels capable of handling 256GB per channel. The chipset supports PCIe Gen 3 SATA, 4x10GbE Gig Ethernet and Sever controller HUB. Of course, there will be a SMP, dual socket version.

[y33H@]

32C-Zen und ne Fiji VR, aha.

[fondness]

Es ist vollkommen egal was man zu Fiji oder Zen schriebt, jede noch so lollige Meldung bedeutet einen neuen Klickrekord.

[anddill]

Klingt irgendwie nach einer XeonPhi Kopie. Oder irgendwas zwischen "normaler" CPU und ManyCore Architektur. Jedenfalls nichts für den Desktop.

[Thunder99]

4x Zen Di auf einem Trägermaterial? :confused:

[S940]

4x Zen Di auf einem Trägermaterial? :confused:Wär wohl übertrieben, ich schätz eher 2xDies mit je 8 Kernen. Aber wer weiss schon ob überhaupt irgendwas an der Meldung stimmt ;)

[OBrian]

Wenn AMD ein Basis-Die aus sagen wir mal 8 Kernen plus Cache bauen würde, wie sähe dann die kleinstmögliche Version aus, die dann in hochpreisige Spielerechner wandern könnte? Ein 8-Kern-Die, ein HBM-Stack, eine mittelmäßig große GPU (sagen wir 1024 Shader) und ein Die für den ganzen restlichen Kladderadatsch (PCIe, SATA, USB, Netzwerk,...)? Müßte in 100 W reinquetschbar sein (wir reden ja über 14 nm). Sowas gibt es sicherlich, wäre eine gute Fortführung für Mainstream-APUs wie Kaveri.

Nur: Gibt es dann pro Thread mehr Leistung als bei einem 9590? Doch wahrscheinlich nicht, oder? Selbst mit dreimal so guter Effizienz (durch 14nm und angenommen wahnsinnige IPC-Steigerung) bleibt doch nicht genug Spielraum, weil die GPU einen Großteil der TDP blockiert.

Dafür müßte es was geben, wo die GPU auch weggelassen wird. Aber dann baue ich das doch sinnvollerweise in einem Die, ohne HBM (was ja nur für die GPU wirklich interessant ist) und spare mir den ganzen Aufwand mit Interposer. ABER: Dann habe ich einen ganz anderen Die, den ich nur direkt in ein Package löten/kleben kann, nicht mehr als Grundlage für Interposer-Basteleien. Also wäre das ein Extra-Projekt, was ggf. fallengelassen wird.

Also insgesamt sieht das für mich leider so aus, daß es vielleicht was geben wird, was eine Steigerung ggü. Kaveri ist, aber keinen ernsthaften Leistungsschub im Bereich Gaming-PCs ergeben wird. Ich lasse mich natürlich gern vom Gegenteil überraschen.

[Skysnake]

Auch CPUs können von HBM profitieren. Du musst halt nur die "richtigen" Probleme haben. Datenbankanwendungen können da durchaus dankbar sein, oder auch sonstige Sachen, die eben ziemlich random verteilte große! Zugriffsmuster haben.

[y33H@]

AMD wie Intel verkaufen ja hochtaktende Quads mit fetten vier Channels (EDIT Xeon E7-8893 v3 und Opteron 6308), warum also nicht einen mit 16C oder 32C und extremer Bandbreite durch HBM? Klingt zumindest von der Warte her plausibel.

[S940]

Nur: Gibt es dann pro Thread mehr Leistung als bei einem 9590? Doch wahrscheinlich nicht, oder? Selbst mit dreimal so guter Effizienz (durch 14nm und angenommen wahnsinnige IPC-Steigerung) bleibt doch nicht genug Spielraum, weil die GPU einen Großteil der TDP blockiert.
Naja, vergess die Turbo-Modi nicht. 1-2 Kerne wird man schon auf ~4 Ghz jagen können.
Aber in Zeiten von DX12 & Vulkan wird singlethread sowieso immer unwichtiger.

Dafür müßte es was geben, wo die GPU auch weggelassen wird. Aber dann baue ich das doch sinnvollerweise in einem Die, ohne HBM (was ja nur für die GPU wirklich interessant ist) und spare mir den ganzen Aufwand mit Interposer. ABER: Dann habe ich einen ganz anderen Die, den ich nur direkt in ein Package löten/kleben kann, nicht mehr als Grundlage für Interposer-Basteleien. Also wäre das ein Extra-Projekt, was ggf. fallengelassen wird.
Naja, ließe sich auch lösen. TSVs werden nur fürs GPU-Die vorgesehen und beide Dies werden dann klassisch mit Hypertransport wie ein G34-MCM verbunden.

In ner reinen single-die-CPU schaltet man die I/O-Pins von HTr auf PCIe um und stellt damit 2x16 PCIe Slots zur Verfügung. Das Umschalten war schon mal so Anno 2012 geplant. Angeblich solls ja 64 PCIe-Lanes geben ... spräche für die Theorie, denn wenn man da mal ~24-32 Lanes zur Anbindung eines 2. Dies verwendet, blieb immer noch genügend für I/O und 1x PCIe x16 übrig.

Die GPU-Dies müsste man dann nur mit der gleichen Logik ausstatten. Nachdem wg. HBM alle Speicher-Pins wegfallen hätte man auch genügend Platz um ein GPU-Die mit 32 HTr/PCIe-Lanes auszustatten, obwohl man auf normalen Grafikkarten davon nur 16 für PCIe benutzen kann.

Nachteil: In Relation eine etwas schmalbandige Verbindung zw. GPU und CPU, die CPU hätte dann nicht viel von der HBM-Bandbreite, wäre halt ne Art NUMA-System. Aber dafür wär es billig zu haben und platzsparend in einem Gehäuse untergebracht.

Eventuell können die 8MB L3 pro Quadcluster als Indiz für eine Schmalbandanbindung herhalten. Gäbs eine Breitbandanbindung der CPU an HBM, hätt ich mit weniger L3 gerechnet. 8MB sind schon ziemlich viel, das kostet gut Die-Fläche, insbesondere bei 4 Cluster aufwärts.

Noch ein Indiz: Für Server reichen die ~16 GB HBM Speicher hinten und vorne nicht, deswegen gibts ja auch 4 DDR4-Kanäle.

Sicherlich wären 16 GB "L4-Cache" nice to have, aber wenn wichtigere Faktoren dagegen sprechen, dann halt nicht.

Man darf auch nicht vergessen, dass das alles im Moment nur die Opterons (und hoffentlich FX) sind. Auch die Riesen-APU. Eventuell gibts für die Mittelklasse schon noch ein extra Die mit nur einem Quad-Cluster/8Threads, 2 MB L3, integrierter APU und 16 GB HBM komplett ohne Speicherkanäle. Böte sich zumindest für Notebooks an. Skybridge-Sockel-kompatibel bekäme man sowas sicherlich auch noch hin, mit integrierter GPU und RAM wären die meisten Sockelanschlüsse in dem Fall halt nur unbenutzt.

[Unicous]

AMD to launch Godavari APUs at end of May, say Taiwan makers (http://www.digitimes.com/news/a20150427PD200.html)



Ich muss mal einen full quote machen weil es ja bald wieder hinter der wall of digi silence verschwindet.

AMD will launch Godavari series APUs at the end of May to compete with Intel's Broadwell and Skylake platforms, according to Taiwan-based supply chain makers.

AMD said it does not comment on unannounced product or speculation.

AMD will launch 14nm Summit Ridge APUs to be produced by Samsung Electronics and Globalfoundries in 2016, including Bristol Ridge mainstream models, and the Raven Ridge-series in 2017, the sources said.

AMD has placed orders with Taiwan-based ASMedia Technology for USB 3.1 controller ICs to match its chipsets to be launched in September 2015, the sources indicated.

Letzeres finde ich sehr mysteriös. Welcher Chip braucht eine Southbridge um 3.1 zu supporten? Oder gibt es einen "MB-Refresh" für Godavari oder gar Carrizo DT?

[HOT]

Das Ding hat keine Southbrigde. Es gibt nur einen SATA-Hub von ASMedia. Jetzt gibts eben auch nen USB 3.1 Hub zusätzlich.

[Unicous]

Welches Ding?:rolleyes:

[HOT]

Alle ridge-CPUs. Sind doch SoCs. Und für Godaveri baut man nix neues mehr, das bleibt bei Bolton.

[Unicous]

Wer redet denn von Ridge-CPUs? Und woher weißt du auf einmal, dass es SoCs sind? AMD hat dazu nichts verlauten lassen.

Von was für Hubs redest du überhaupt? Meinst du die Controller auf dem MB oder die integrierte IP im chipset?

Wenn du von ersterem sprichst: Was interessiert AMD was die Hersteller auf ihre Boards hauen. Bei zweiterem. Wenn das mit dem chipset stimmt, dann sage doch welcher Chip noch momentan eine Southbride braucht. Die Antwort ist Kaveri bzw. der wahrscheinliche Refresh Godavari. Auch ein Carrizo DT Board könnte man mit einer Southbridge bestücken, wie laut den nicht bestätigten leaks ja wohl auch vorgesehen war.


Ich habe die Frage gestellt, welcher Chip braucht momentan noch eine Southbridge. Meine Antwort Kaveri.

Deine Antwort: Das Ding hat keine Southbridge.:freak:

[fondness]

Hm, vielleicht ist der Chipsatz für Summit Ridge früher fertig und man kann ihn auch schon für Godvari verwenden. Vermutlich wird man am Southbridge-Interface nicht viel ändern. Das AMD neue Chipsatzkomponente nicht mehr selbst entwickelt sondern von ASMedia zukauft ist ja nichts neues.

[HOT]

AMD hat sich da irgendwie exklusiv an ASMedia gebunden, das war mal irgendwo im P3DNow-Forum verlinkt, da AMD selber keine SBs mehr herstellen will. Durch Godaveri ergibt sich jetzt wahrscheinlich die seltsame Situation, dass man noch seinen Bolton hat, aber trotzdem ASMedia verbauen muss könnt ich mir vorstellen. Ursprünglich geplant war es ja anscheinend, dass Carrizo auch im Desktop erscheinen sollte, dann hätte ASMedia die zusätzlichen I/O-Controller dafür gestellt. Ich weiss nicht wie das abläuft, aber ich schätze dass das irgendwie mit einem Exkusivkram zusammenhängt. Die Boardhersteller werden einfach von AMD das Komplettpaket bekommen: Chipsatz+ASMedia USB3.1-Controller.
Und ja, ich hab zu flüchtig gelesen. Ist aber auch egal, die Ridge-CPUs kommen jedenfalls ziemlich sicher mit ASMedia I/O-Zeug.
War nicht schon Bolton an sich mit ASMedia-SATA-Controllern ausgestattet? Alle Chipsätze davor setzten ja auf Promise und davor auf SiliconImage-Technik. AMD hat ja keine eigene SATA-Technik.

[Unicous]

Das kam nicht von p3Dnow (afaik) sondern auch von digitimes.

Und ASMedia ist übrigens fabless, wüsste nicht, wie und wo die Chips herstellen sollen.

AMD hat einfach die IP eingekauft. Es hat nämlich sonst immer ewig gebraucht, bis sie endlich I/O wie SATA und USB in den Chipsatz eingebracht haben, das gleiche Spiel gibt es ja bei Intel. Sie kaufen die IP ein, bringen sie in den Chipsatz ein und lassen es bei GF fertigen. So sehe ich das. Könnt ihr natürlich gerne dagegen argumentieren, dass AMD die Southbridge komplett "fremd" fertigen lässt, IMO ist das nicht 100% plausibel. Man darf nämlich digitimes nicht immer beim Wort nehmen, die haben immer ein paar scoops aber nur die Hälfte davon stimmt dann.

Bei AMD ist soviel Fremd-IP in den Chips, da macht das bißchen USB Zeugs auch nicht den Kohl fett.

Ich male mir das so aus: AMD schickt an ASMedia die Blaupausen für ihren Chip, ASMedia fügt die neue IP hinzu macht die erste Validierung blabla und am Ende landet es bei AMD.

Lange wird das eh nicht mehr laufen. Die Ära der Southbridge geht langsam zu Ende.

[HOT]

Das hat mich doch gar nicht interessiert, ich weiss selber, dass ASMedia fertigen lässt. Es ist doch vollkommen egal, wer was wo fertigt, ob ASMedia das fertigen lässt und dann an AMD weitergibt, oder AMD selbst fertigen lässt mit IP, es sieht aber dieses Mal eben eher nach ersterem aus und man spart sich einfach die komplette Maske für die SB. Und GloFo fertigt keine SBs für AMD AFAIK, die kommen alle von TSMC oder UMC (jedenfalls früher mal). Es gibt eben auch keine neue SB mehr, sondern nur noch Standardcontroller von ASMedia, die über AMD laufen, und auf die AMD auch keine eigenen Aufkleber klebt. Trotzdem kommen diese Chips offenbar exklusiv von AMD, deshalb ist das nicht Sache des Mobo-Herstellers. Der bekommt Bolton und den ASMedia USB-Controller eben von AMD und kann weitere andere USB-Controller draufklatschen wenn er mag.

[y33H@]

Apropos P3D: http://www.planet3dnow.de/vbulletin/attachment.php?attachmentid=32376&d=1430143447

insider2015
Cadet
Registriert seit 27.04.2015
Beiträge 1

[fondness]

Kann man natürlich auch leicht faken, aber 6. Mai ist ja nicht mehr lange hin.

[Locuza]

Würde zu fast allen Gerüchten passen.
3 Execution-Pipes, SMT drauf und ein eher klassischer AMD Core.
Getrennte Integer/FP-Domain, exklusiver L2$ per Core.
Wenn man Glück hat, lassen sich die 2 FP-Pipes verschalten für eine AVX512 Operation.

[Nakai]

Würde zu fast allen Gerüchten passen.
3 Execution-Pipes, SMT drauf und ein eher klassischer AMD Core.
Getrennte Integer/FP-Domain, exklusiver L2$ per Core.
Wenn man Glück hat, lassen sich die 2 FP-Pipes verschalten für eine AVX512 Operation.

Mhh, das ist interessant.

Excavator sollte wie Steamroller zwei Decoder mit je 4 MacroOps haben. Ergo 8 MacroOps Decoding pro Modul. Zen sollte bei dieser Execution-Breite irgendetwas zwischen 4 und 8 MacroOps raushauen können.

Ansonsten sind es 6 Integer-Pipes(3 ALU; 3 AGU) und 3 Float-Pipes und es ist sehr wahrscheinlich, dass AMD AVX512-Ops ermöglicht.

Das Design hat dedizierte Scheduler für FP und INT, welche jedoch doch unified sind.

[Duplex]

Remember, it's just a sneak peek. We won't get tangible information yet... just one number: a Zen core is below 10 sqmm
http://www.planet3dnow.de/vbulletin/threads/421433-AMD-Zen-14nm-8-Kerne-95W-TDP-DDR4?p=5004085&viewfull=1#post5004085

[Duplex]

Ein aufgebohrter K10 ohne Schwachstellen?

3 ALUs + 3 AGUs
1x 512 Bit FPU oder 2x 256Bit FPU
Uop Cache wie Sandy Bridge ?
AVX3 ?
2 Fach SMT
Fullspeed Cache ?

[robbitop]

Man wird ganz sicher keinen K8/10 aufbohren. Da gab es zu viele Engpässe. Das Ding ist vermutlich "designed from scratch". Die Anzahl der Einheiten sagt eigentlich erstmal wenig aus.

10 sqmm@14nm klingt jetzt nicht so verkehrt. Jaguar@28 nm war 3,1 sqmm pro Core und Steamroller@28 nm 9,6 sqmm. Die neuen HD Labs bringen ~35 %. Ohne HD Libs wäre ein Zen Core also 13.5 sqmm groß. @28 nm wäre ein Zencore also grob 26 sqmm groß. Also deutlich mehr Transistoren. Das bietet viel Raum für IPC Steigerung. Wenn man noch die Differenz von CMT -> SMT abrechnet steigt die Differenz weiter.

Quelle für Jaguar/Steamrollergröße:
http://www.itproportal.com/2014/01/21/why-amd-should-take-note-of-intels-playbook-and-ditch-steamroller/

[Duplex]

Komplett neu glaub ich nicht, der Pentium3 wurde auch aufgebohrt.
Wenn Zen 64KB L1D Cache hat, dann hat der noch mehr Ähnlichkeiten mit K10.

[Coda]

Sie werden mit Sicherheit Teile von Jaguar/Bulldozer wiederverwenden. Es gibt keinen Grund alles neu zu machen.

K10 hat keine physical register file und der Scheduler ist ziemlich unflexibel. Glaube ich nicht.

[Timbaloo]

Hmmm, ich tu mich schwer die "unter 10mm^2" einzuordnen. Ein Broadwell Kern dürfte ja nicht soviel größer sein, und bis Zen kommt sollte GloFo/Samsung ja ähnlich kompakt sein.

[Nakai]

Ich wäre damit noch ganz zurückhaltend. Das Schaubild ist ziemlich abstrahiert und daher schon etwas "wertlos".
Wir wissen nicht, wie die I-Pipes organisiert sind, wieviele AGU, ALUs, Branches, etc. Welche Art von ALUs, AGUs(LD/ST), etc...

K10/8 hatte 3 Int-Scheduler für ALU/AGU-Pärchen(jeweils 2 Ports) und einen fetten FP-Scheduler mit 3 Ports. Dieses Prinzip hat auch Bobcat/Jaguar/Puma(2 I-Scheduler; 1 FP-Scheduler). Ich gehe hierbei eher von einem globalen Int-Scheduler, welcher 6 Ports bedienen kann. Bulldozer hatte auch schon einen globalen Int-Scheduler für nur 4 Ports, welche noch Abhängigkeiten hatten(einfacher).

Das Schaubild ist auch sehr, seeeehr einfach gehalten...da kann man wirklich nicht viel rauslesen. Wieso hat man hierbei 4 Pfeile von Decoder zu Schedulern gelegt? Damit es gleich zu Excavator ist? Excavator hatte 2 Decoder a 4 MacroOPs, sollte das heißen, dass Zen 8 MacroOPs kann(gleiche Anzahl an Pfeile ;D:freak:).

Abwarten und Hopfen-Tee schlürfen...

[fondness]

Man wird ganz sicher keinen K8/10 aufbohren. Da gab es zu viele Engpässe. Das Ding ist vermutlich "designed from scratch". Die Anzahl der Einheiten sagt eigentlich erstmal wenig aus.

10 sqmm@14nm klingt jetzt nicht so verkehrt. Jaguar@28 nm war 3,1 sqmm pro Core und Steamroller@28 nm 9,6 sqmm. Die neuen HD Labs bringen ~35 %. Ohne HD Libs wäre ein Zen Core also 13.5 sqmm groß. @28 nm wäre ein Zencore also grob 26 sqmm groß. Also deutlich mehr Transistoren. Das bietet viel Raum für IPC Steigerung. Wenn man noch die Differenz von CMT -> SMT abrechnet steigt die Differenz weiter.

Quelle für Jaguar/Steamrollergröße:
http://www.itproportal.com/2014/01/21/why-amd-should-take-note-of-intels-playbook-and-ditch-steamroller/

Man könnte auch einfach sagen, dass die Aussagen ein Zen-Core wird kleiner als 10sqmm alles andere als mutig ist. Wäre er größer als 10sqmm müsste Zen entweder eine Bombe werden oder AMD hätte ein Problem. Selbst ein Broadwell liegt inkl. L2-Cache deutlich unter 10 sqmm.

[robbitop]

Man könnte auch einfach sagen, dass die Aussagen ein Zen-Core wird kleiner als 10sqmm alles andere als mutig ist. Wäre er größer als 10sqmm müsste Zen entweder eine Bombe werden oder AMD hätte ein Problem.
Naja wenn man es genau nimmt ja. <10 sqmm kann alles heißen. Aber wenn die Aussage sinnvoll gewählt ist - meint sie knapp unter 10 sqmm. Sonst könnte man auch 8 oder 9 sqmm sagen.

Knappe 10 sqmm würden jedenfalls eine Menge Platz für IPC Steigerungen lassen.

[Coda]

10 mm² in 14nm ist riesig, Broadwell hat nur 7 iirc.

[Kriton]

Edit: Hier stand Mist.

[robbitop]

Da Intel deutlich schlauer ist als AMD, braucht Intel eben weniger. ;D (kleiner Scherz - aber man hat doch deutlich mehr R&D und kann sicherlich effizienter designen)
Intels 14 nm sollte etwas dichter packen als Samsungs/GFs "14 nm" Prozess aus bekannten Gründen. Andererseits nutzt AMD HDLibs - Intel AFAIK handgelayoutet.

Inkl. iGPU (jeweils)?
Es geht einzig um die Größe eines einzelnen (CPU)Cores - nicht des gesamten Dies.

[Ravenhearth]

[...]
Just because I said <10 sqmm for Zen doesn't mean it's exactly 10. It's smaller.

So viel dazu.

[robbitop]

Naja die Frage ist, wieviel kleiner. So eine Aussage impliziert eigentlich, dass man nur knapp drunter ist. Und zwar 9,5...10 sqmm. Ansonsten müsste man sagen > 9 sqmm.

Oder derjenige hält sich sinnlos vage. Aber dann braucht man auch gar nichts sagen.

[Botcruscher]

10 mm² in 14nm ist riesig, Broadwell hat nur 7 iirc.
Es sind ja unter 10...

[Pirx]

Andererseits hatte Intel doch afair gar nicht immer soo eine hohe "Packdichte".

[HOT]

Vielleicht sollte man Zen lieber mit Skylake-Kernen vergleichen anstatt mit Broadwell-Kernen. Erst recht, wenn er so gigantische FP-Power bietet, wie auf der noch zu verifizierenden Folie abgebildet. Mit 2 256Bit FMACs hätte das Ding die doppelte Power eines Broadwell-Kerns.

Intels Packdichte war nie hoch, weil die Prozesse bisher immer recht "groß" waren im Vergleich zur Konkurrenz. Das hat sich mit 14nm geändert. Jetzt ist man sehr dicht zusammen, was Packdichte angeht bei Samsung(GloFo; LPP), Intel und TSMC (FF+).

[Locuza]

Das Design hat dedizierte Scheduler für FP und INT, welche jedoch doch unified sind.
Wie meinst du unified?
Bei Intel hängt ja alles an der unified reservation station.
AMD hat doch seit Ewigkeiten Integer-Ports von FP-Ports getrennt und das Schaubild ist grob, aber für mich sieht das weiterhin so aus.

Mit 2 256Bit FMACs hätte das Ding die doppelte Power eines Broadwell-Kerns.

Seit Haswell hat doch Intel selber zwei 256-Bit FMA Pipes.

[Agent117]

Intels 14 nm sollte etwas dichter packen als Samsungs/GFs "14 nm" Prozess aus bekannten Gründen. Andererseits nutzt AMD HDLibs - Intel AFAIK handgelayoutet.


Ist das mit den HD-Libs sicher? Ich weiß dass sie die jetzt erstmals bei Carrizo einsetzen - auch ein Grund für die gesteigerte Perf/W im Mobile Sektor.
Aber im Destop Segment kann das bei höheren Taktraten auch sehr ineffizient werden.
Wenn ja müsste Zen ja wirklich seinen Namen treu bleiben und unter 3Ghz bleiben.
Aber in der Ruhe liegt diegen Kraft und Perf/W:wink:

[Nakai]

Wie meinst du unified?
Bei Intel hängt ja alles an der unified reservation station.
AMD hat doch seit Ewigkeiten Integer-Ports von FP-Ports getrennt und das Schaubild ist grob, aber für mich sieht das weiterhin so aus.


Guck dir mal K7/8/10 an.
http://de.wikipedia.org/wiki/AMD_K8

Hierbei gibt es noch eine Hierarchie-Ebene vor den ALUs/AGUs. Pro ALU-AGU-Paar, also pro AGU und ALU-Port, ist noch ein 8-Entry Scheduler verbaut. Bei Bulldozer fällt dieser Teil weg und hat hierbei einen unified Scheduler für alle INT-Ports.

Jaguar/Bobcat besitzen pro 2 ALUs und pro 2 AGUs einen eigenen Scheduler, wie K7/8/10.
http://www.3dcenter.org/dateien/abbildungen/AMD-Jaguar-Presentation-Slide09.jpg

Bulldozer hat zwar immer noch ALU/AGU-Paare, aber diese werden gleich von einem unified Scheduler angesprochen.
http://de.wikipedia.org/wiki/AMD_Bulldozer
Außerdem gibt es bei Bulldozer noch Abhängigkeiten. Loads können gleichzeitig mit INT-Ops ausgeführt werden. Bei Stores wird der zugehörige ALU-Port gelockt.

Ich zitiere:
http://www.agner.org/optimize/microarchitecture.pdf

The execution pipes EX0 and EX1 are used for most integer and general purpose instructions. Memory read instructions use AGLU0 and AGLU1. Memory write instructions use both AGLU0/1 and EX0/1 simultaneously. AGLU0 and 1 can also handle simple register-to-register moves with 32-bit and 64-bit general purpose registers, except on early versions of Bulldozer. AGLU0 and 1 can not handle register move instructions with 8-bit or 16-bit registers or an immediate operand.
LEA instructions are executed as ALU operations in EX0 and EX1. Simple LEA instructions take one clock cycle. If shifting or more than one addition is involved then it takes two clocks. If the operand size or address size is 16 bits then it takes an extra clock.
Integer multiplication of operands up to 32 bits takes 4 clock cycles with a throughput or one multiplication per 2 clocks. Integer division is not pipelined.

[robbitop]

Andererseits hatte Intel doch afair gar nicht immer soo eine hohe "Packdichte".
Das ist seit 14 nm drastisch besser geworden. Die liegt nun ein Stückchen vor Samsungs/GF. Andererseits spart AMD durch HD Libs bis zu 35 % Fläche (büßt dafür aber taktbarkeit ein).

Ist das mit den HD-Libs sicher? Ich weiß dass sie die jetzt erstmals bei Carrizo einsetzen - auch ein Grund für die gesteigerte Perf/W im Mobile Sektor.
Aber im Destop Segment kann das bei höheren Taktraten auch sehr ineffizient werden.
Wenn ja müsste Zen ja wirklich seinen Namen treu bleiben und unter 3Ghz bleiben.
Aber in der Ruhe liegt diegen Kraft und Perf/W:wink:

Sowas entwickelt man nicht für einmalige Nutzung. AMD wird zukünftig IMO nicht mehr versuchen an die extrem hohen Taktraten zu kommen. HD Libs heißt ja nicht, dass > 3 GHz nicht möglich sind. Man braucht ein sehr gut skalierbares und sparsames Design. Idealerweise zwischen 5 und 100 W. Mit Fokus auf den unteren Bereich. Im Prinzip ziemlich ähnlich zu Core.
4,x GHz fällt dann eben raus.

[Locuza]

@ Nakai

Ai, so ist es natürlich klar.
Ich war verwirrt. :D

[Duplex]

Vielleicht kommen die "HD Libs" nur bei den APUs zum Einsatz, damit man im Mobilen Markt punkten kann.
Im Desktop & Server Markt muss das nicht so sein, hier ist max. Performance entscheident.

[robbitop]

Vielleicht kommen die "HD Libs" nur bei den APUs zum Einsatz, damit man im Mobilen Markt punkten kann.
Im Desktop & Server Markt muss das nicht so sein, hier ist max. Performance entscheident.
Klar - AMD hat die Manpower 2x Layouts für die Cores zu machen...

Selbst im Serverbereich sind Taktraten jetzt nicht all zu hoch. Einzig im Desktop Enthusiastbereich wäre das nötig. Eine Nische in einem Markt der schrumpft (Desktop). Ich glaube nicht dran.

[Duplex]

Klar - AMD hat die Manpower 2x Layouts für die Cores zu machen...
Bei Piledriver gab es auch 2x Layouts, die Kerne bei der Trinity APU & Piledriver 4M/8C waren unterschiedlich. Das wurde mal bei P3DNow untersucht und bestätigt.

Selbst im Serverbereich sind Taktraten jetzt nicht all zu hoch. Einzig im Desktop Enthusiastbereich wäre das nötig. Eine Nische in einem Markt der schrumpft (Desktop). Ich glaube nicht dran.
Der Server Markt ist sehr wichtig für AMD, man muss wieder was starkes zeigen, die DIEs für Server & Desktop sind meistens gleich bei AMD.

[robbitop]

Bei Piledriver gab es auch 2x Layouts, die Kerne bei der Trinity APU & Piledriver 4M/8C waren unterschiedlich. Das wurde mal bei P3DNow untersucht und bestätigt.
Soweit ich weiß war Vishera kein Piledriver (obwohl AMD sie so benannt hatte) sondern gefixte Bulldozerkerne. So ein Zwischending.

Das ist aber auch was anderes. Das eine ist eine stetige Weiterentwicklung eines Kerns - das andere ein komplett anderes (handgemachtes! aufwändiges) Layout.


Der Server Markt ist sehr wichtig für AMD, man muss wieder was starkes zeigen, die DIEs für Server & Desktop sind meistens gleich bei AMD.
Schau doch mal in die Prospekte von Dell und HP. Wie hoch sind die CPUs in den Dingern getaktet? Die Opterons und Xeons sind viel viel konservativer getaktet als die FX und i7. Gerade im Server Bereich gibt es gar kein Problem hinsichtlich Taktrate. Da zählt perf/W deutlich mehr.
3,x GHz würden da schon reichen. Mit ordentlicher IPC und ordentlicher Verlustleistung.

[Duplex]

Da sind aber auch viel mehr Kerne auf einem DIE, jedenfalls bei Intel.
AMD verwendet 2 DIEs per MCM Package.
Logisch das die Taktraten geringer als bei den Desktop Modellen ausfallen.

[HOT]

Ich frage mich, was FinFETs auf Änderungen wie HD-Libs und GPU-Transistoren beim Carrizo für einen Einfluss haben können. Mit der veränderten Transistorgeometrie bei FinFETs verändert sich da doch sowieso verdammt viel oder nicht?

Zen (nach Folie) kommt mir vor wie ein komplett neu umgesetztes K7-Konzept mit heutigen Technologien.

[Duplex]

Zen (nach Folie) kommt mir vor wie ein komplett neu umgesetztes K7-Konzept mit heutigen Technologien.
Exakt!

[robbitop]

Du kannst dir auch die S1050 Xeons anschauen. Die sind alle niedriger getaktet als die S1050 i7.

Im Serverbereich zählt vor allem Perf/W. Dann lieber ein bisschen niedriger takten und mehr Kerne. Ich kann mir gut vorstellen, dass eine Servervariante mit 16 Zen Kernen (vieleicht auch 2x Dies mit je 8 Kernen) kommt.


Zen (nach Folie) kommt mir vor wie ein komplett neu umgesetztes K7-Konzept mit heutigen Technologien.
Das siehst du an diesem groben (evtl gefälschten) Diagramm? Viel wahrscheinlicher ist es, dass man das beste aus der Katzen und Baggerfamilie genommen hat.

Warum sollten die HDLibs Probleme mit FinFets machen? HDLibs sind Alltag im GPU Bereich. Und GPUs sind schon lange für FinFet Prozesse eingeplant. AMD wird das nicht für 1x APU Generation entwickelt haben.

[OBrian]

ja sicher, Server ist wichtig. Aber im Server ist Performance pro Dollar wichtig, und Dollar heißt neben Anschaffungskosten auch Rackfläche, Strom- und Kühlkosten usw. D.h. effiziente Chips sind da König. Also muß bzw. darf man sich nicht so extremst bis an dem Anschlag hochtakten. Ist praktisch die gleiche Anforderung wie im Mobile-Bereich.

Desktop ist nicht so kritisch, da kann man die Chips verwursten, die für den Takt etwas mehr Saft brauchen, und der High-End-Desktop ist stückzahlen- und umsatzmäßig nicht so groß, dafür entwickelt man nichts ganz anderes, sondern versucht aus dem Vorhandenen möglichst viel rauszuquetschen, durch Selektion. Das sollte reichen.

Ich mein, wenn beim Desktop-Topmodell wie bei Kaveri (hat ja auch schon den taktbegrenzenden Fertigungsprozeß) ca. 4 GHz drin sind, dann sollte das bei realistisch anzunehmender drastischer IPC-Steigerung völlig ausreichen, um wieder vorne mitspielen zu können.

[HOT]

Soweit ich weiß war Vishera kein Piledriver (obwohl AMD sie so benannt hatte) sondern gefixte Bulldozerkerne. So ein Zwischending.

Das ist aber auch was anderes. Das eine ist eine stetige Weiterentwicklung eines Kerns - das andere ein komplett anderes (handgemachtes! aufwändiges) Layout.

[...]
Das ist wohl nicht ganz korrekt. Vishera ist ein Orochi mit PD-Elementen. Ein Hybride, den man mit heißer Nadel gestrickt hatte. War ein erstaunlich gutes Projekt für den Einsatz, wenn man das revuepassieren lässt.
Aber auch PD und SR waren nicht identisch sondern es war offenbar ein evolutionärer Prozess geplant. Erst Ur-BD, dann APU-Upgrade, dann Komodo mit PD+-Kernen, eben Serverworkloadoptimiert, dann SR-Konzept-APU(Kaveri) usw, also BD (02h) -> PD(10h) -> PD+(20h) -> SR (30h) -> SR+ (40h) usw.

02h, 20h und 40h hat man eben zu 03h eingedampft und das ganze Projekt Vishera genannt.


Nochmal zuden Prozessgrößen: Du erinnserst dich doch an die Vergleichstabelle der 14nm-Prozesse von Samsung, Intel und TSMC. Dort wurde der Intel-Prozess Intel-marketingwirksam verglichen, aber nur mit Samsung 14nm LPE, nicht jedoch mit LPP und TSMCs 16nm FF, aber nicht FF+. In Wirklichkeit werden die CPU-tauglichen Prozesse mAn. sehr gleichwertig sein von der Packdichte her.

[Duplex]

Du kannst dir auch die S1050 Xeons anschauen. Die sind alle niedriger getaktet als die S1050 i7.

Im Serverbereich zählt vor allem Perf/W. Dann lieber ein bisschen niedriger takten und mehr Kerne. Ich kann mir gut vorstellen, dass eine Servervariante mit 16 Zen Kernen (vieleicht auch 2x Dies mit je 8 Kernen) kommt.


Mehr Kerne bringen dir auch im Server Markt nicht viel wenn weniger Kerne genauso schnell seien können.
Was meinst du warum AMDs Interlagos nicht besser als Magny Cours abgeschnitten hat, obwohl Interlagos (BD) 4 Kerne mehr als MC hatte, war Magny Cours (K10) wegen der besseren IPC öfter schneller.
Anandtech hatte mal einen schönen Artikel wo das analysiert wurde.

[Ravenhearth]

Irgendwie traue ich dem Braten nicht ganz. Macht es denn Sinn, dass AMD solch eine doch recht technische Folie auf dem Financial Analyst Day (!) präsentiert? Oder wollen die nur zeigen "Hey, dieser Kern links kommt dieses Jahr, und der rechts schon nächstes!"?

[robbitop]

Mehr Kerne bringen dir auch im Server Markt nicht viel wenn weniger Kerne genauso schnell seien können.
Was meinst du warum AMDs Interlagos nicht besser als Magny Cours abgeschnitten hat, obwohl Interlagos (BD) 4 Kerne mehr hatte war Magny Cours (K10) wegen der besseren IPC öfter schneller.
Kerne bringen häufig verdammt viel. Niemand sagt, dass man mit geringer IPC antanzt oder mit geringem Takt. Nur eben gewisse Einschnitte.

Selbst die einfachsten Standardserver in 0815 Firmen profitieren enorm von vielen Kernen. Weil eben mehrere virtuelle Maschinen auf einem Server laufen, mit vielen aktiven Diensten die sich um die Kerne kloppen.


Nochmal zuden Prozessgrößen: Du erinnserst dich doch an die Vergleichstabelle der 14nm-Prozesse von Samsung, Intel und TSMC. Dort wurde der Intel-Prozess Intel-marketingwirksam verglichen, aber nur mit Samsung 14nm LPE, nicht jedoch mit LPP und TSMCs 16nm FF, aber nicht FF+. In Wirklichkeit werden die CPU-tauglichen Prozesse mAn. sehr gleichwertig sein von der Packdichte her.
IIRC hatte Intel aber auch noch einen dichteren 14 nm Prozess oder? Ich nehme an, dass die dichteren Prozesse Nachteile haben. Sonst gäbe es sie wohl nicht. (16 FF mal ausgenommen - der ist ja praktisch tot - FF+ ersetzt diesen)

Irgendwie traue ich dem Braten nicht ganz. Macht es denn Sinn, dass AMD solch eine doch recht technische Folie auf dem Financial Analyst Day (!) präsentiert? Oder wollen die nur zeigen "Hey, dieser Kern links kommt dieses Jahr, und der rechts schon nächstes!"?
Die Wahrscheinlichkeit ist nicht gering, dass die Folien gefakt sind.

[Duplex]

Kerne bringen häufig verdammt viel. Niemand sagt, dass man mit geringer IPC antanzt oder mit geringem Takt. Nur eben gewisse Einschnitte.

Selbst die einfachsten Standardserver in 0815 Firmen profitieren enorm von vielen Kernen. Weil eben mehrere virtuelle Maschinen auf einem Server laufen, mit vielen aktiven Diensten die sich um die Kerne kloppen.
Das war eben bei Bulldozer nicht der fall, obwohl mehr Threads als K10!
Zu K10 Zeiten war der Marktanteil noch höher als mit Bulldozer.

[Ravenhearth]

Die Wahrscheinlichkeit ist nicht gering, dass die Folien gefakt sind.

Trotzdem machen alle ne News (http://wccftech.com/amd-zen-cpu-core-block/) draus. ;D Naja, immerhin mal positive Meldungen zu AMD.

[robbitop]

Das war eben bei Bulldozer nicht der fall, obwohl mehr Threads als K10!
Zu K10 Zeiten war der Marktanteil noch höher als mit Bulldozer.
Auch Xenons kannst du skalieren. Für die gleiche TDP wie einem 8C BD konnte man auch 2x 4C Xenons oder 1x 8C Sandy-E oder sogar die EP Versionen nehmen. In jedem Fall war das Endergebnis dann schlechter für AMD.

BD hat einfach zu viel Strom gesoffen und hatte viel viel zu wenig IPC. Perf/W war einfach für die Tonne.

Wenn du jetzt aber einen konkurrenzfähigen Kern hast (IPC und Power) ist das was anderes. Wie gesagt: im Serverbereich brauchst du nicht die allerhöchsten Taktraten. Ein kurzer Blick in AMDs und Intels Opteron/Xenon Portfolio sollte das klar machen.

Trotzdem machen alle ne News (http://wccftech.com/amd-zen-cpu-core-block/) draus. ;D Naja, immerhin mal positive Meldungen zu AMD.
Irgendwo muss das Geld ja herkommen. Clickbaits. :D

[HOT]

Hm ich könnt mir vorstellen, dass weniger Packdichte eher für Billigprozesse (wie LPE) nützlich sind. Das ist nur ne Theorie, aber ich bleibe dabei. Vielleicht hat ja jemand Daten, die belegen, wie es zwischen Samsung 14nm LPP und Intels 14nm wirklich aussieht. Wär mal interessant.

Server-CPUs müssen maximal viele Threads haben und auf dem Takt/W Sweetspot laufen. BD war da nie konkurrenzfähig, weil dem auch die Rohleistung fehlte ggü. Sandy AFAIK.

Und AMD hat schon öfter Architekturfolien bei Analysts-Days präsentiert AFAIK. Wenn man so einen Tag macht, dann hat man auch was vorzuweisen, davon bin ich überzeugt. Das Teil kann natürlich trotzdem ein Fake sein.
Mir kommt der Gedanke aber sehr sympatisch rüber, dass man das so bauen könnte ;). Das muss ich zugeben.

[Timbaloo]

Irgendwie traue ich dem Braten nicht ganz. Macht es denn Sinn, dass AMD solch eine doch recht technische Folie auf dem Financial Analyst Day (!) präsentiert? Oder wollen die nur zeigen "Hey, dieser Kern links kommt dieses Jahr, und der rechts schon nächstes!"?
Auch einem Investor sollte klargeworden sein, dass AMDs schlechte Zahlen ein klitzekleinesbißchen mit nicht-konkurrenzfähigen Produkten korrelieren. Demnach würde ich mir als Investor eigentlich genau einen Anhaltspunkt wünschen wie man da in Zukunft gedenkt zu verbessern. Gerade da man in der letzten Zeit im Bereich R&D eher gekürzt hat, sollte man als Investor kritisch hinterfragen ob man sich da nicht kaputtspart.

[OBrian]

So irre technisch ist die Folie ja nicht, daß man das nicht den Analysten vorlegen könnte, die sich ja einreden, was davon zu verstehen. Was komplizierteres, wo man auch was sinnvolles ablesen könnte, gibt es ja nicht. Auf den Folien davor und dahinter könnte ja in Textform noch was interessantes stehen. Aber wir werden wohl noch die Woche warten müssen.

[Skysnake]

Ich frage mich, was FinFETs auf Änderungen wie HD-Libs und GPU-Transistoren beim Carrizo für einen Einfluss haben können. Mit der veränderten Transistorgeometrie bei FinFETs verändert sich da doch sowieso verdammt viel oder nicht?

Es ändern sich hauptsächlich die Design Rules. Also z.B. das alle Transistoren gleich lang sein müssen in einem gewissen Umfeld, das man immer Dummy-Transistoren braucht usw usw.

"HD-Libs" sind wohl Eigenentwicklungen von Standardzellen Libs. Das läuft am Ende wohl auf Verletzungen von Design-Rules hinaus in manchen Bereichen, und/oder bessere Router für die Interconnects.

Es steckt wohl ziemlich viel Arbeit für die Validierung drin, dass die Libs auch wirklich so funktionieren wie gewünscht. Die FABs sind da ja eher etwas konservativ in der Auslegung, damit die Chips auch sicher funktionieren die unter Einhaltung der DesignRules designt wurden.

[robbitop]

Nichts was ATI und NV seit Jahren eh schon mit ihren GPUs machen.

[Nakai]

Ist der L2-Cache in den <10mm² schon eingerechnet?

Wie soll Zen erscheinen? Ohne GPU-Part?

AMD könnte einen Octacore-Zen mit irgendwas zwischen 150~200mm² bringen.

Also wenn Zen so aussehen sollte sieht es tatsächlich eine K10-Reloaded sehr ähnlich. Mit allen Verbesserungen seit Bulldozer und Co. wäre schon einiges drin. Bei INT-Workloads wären theoretisch maximal 50% mehr IPC drin. Bei FP-Teil sogar 100%. Mich würde es nicht wundern, wenn Jim Keller erstmal :facepalm: bei AMD und Bulldozer gemacht hat, als er angekommen ist.

€: Ahja AMDs Packdichte mit 28nm+HD-Libs ist schon beachtlich, wenn man Intel mit ihrem 14nm-Prozess vergleicht.

€2: Steamroller/Excavator wäre schon noch ein Stück schneller mit L3-Cache und schnellerem Interconnect.

[OBrian]

Ich nehme an, daß es als Hauptprodukt etwas wie Carizzo geben wird, nur eben mit den neuen Kernen. Möglicherweise auch zwei solche SoCs, einen eher wie Kabini für das untere Marktsegment, mit 2 Kernen (dank SMT dann 4 Threads), kleiner GPU und 1-Kanal-RAM, und einen größeren mit 8 Kernen, größerer GPU und besserer RAM-Anbindung. Und dann ggf. noch dieses Server-Monster mit 16 Kernen und HBM. Außerdem gibt es bestimmt noch einen Refresh für die Konsolen, wo Zen ebenfalls drin landet.
Mich würde es nicht wundern, wenn Jim Keller erstmal bei AMD und Bulldozer gemacht hat, als er angekommen ist.vielleicht hat er das schon gemacht, als er von BD gehört hat, und hat sich wieder beworben, so nach dem Motto "ich machs auch umsonst, laßt mich nur diese Scheiße reparieren, ihr Idioten" *lol*

[S940]

Vielleicht kommen die "HD Libs" nur bei den APUs zum Einsatz, damit man im Mobilen Markt punkten kann.
Im Desktop & Server Markt muss das nicht so sein, hier ist max. Performance entscheident.Im Serverbereich zählt allein Perf/Watt und sonst nichts.
Kleiner Nebeneffekt der HD-Libs ist unter anderem ein etwas kleinerer Stromverbrauch, außerdem kann man sich für die eingesparte Fläche tiefere Puffer, größere Caches und Registerfiles gönnen .. wenn AMD das nicht nützen würde, gehörten sie geteert und gefedert, da gibts keine Diskussion.:freak:

[Skysnake]

Nichts was ATI und NV seit Jahren eh schon mit ihren GPUs machen.
Im Prinzip ja, FinFet kommen aber auch immer mit Multi-Patterning daher, und du darfst die Transistoren auch nur noch in eine Richtung ausrichten, musst also für die horizontale und vertikale Chip-Kante die I/O-IP zweimal designen, dazu hunderte/tausende neue DesignRules usw usf.

Ich konnte mal nen Layout von nem FinFet Inverter für ne Standardzellen-Lib sehen, und allein das wirklich! simple Ding explodiert dir bzgl Aufwand/Komplexität. Und nein, mehr kann ich da nicht mehr ins Detail gehen.

[y33H@]

Und AMD hat schon öfter Architekturfolien bei Analysts-Days präsentiert AFAIK.Ja, auf dem FAD 2010 u.a. Bulldozer:

http://phx.corporate-ir.net/External.File?item=UGFyZW50SUQ9Njk3NTl8Q2hpbGRJRD0tMXxUeXBlPTM=&t=1

[robbitop]

Im Prinzip ja, FinFet kommen aber auch immer mit Multi-Patterning daher, und du darfst die Transistoren auch nur noch in eine Richtung ausrichten, musst also für die horizontale und vertikale Chip-Kante die I/O-IP zweimal designen, dazu hunderte/tausende neue DesignRules usw usf.

Ich konnte mal nen Layout von nem FinFet Inverter für ne Standardzellen-Lib sehen, und allein das wirklich! simple Ding explodiert dir bzgl Aufwand/Komplexität. Und nein, mehr kann ich da nicht mehr ins Detail gehen.
Wie gesagt: wird schon gehen. NV und AMD haben die FinFet Designs für deutlich größere ASICs mit Sicherheit schon fertig. Da sitzen halt ein paar hundert Mann dran, die das seit vielen Jahren kennen. Ich würde das jetzt nicht überbewerten.

[Skysnake]

FinFet und halt DoublePatterning ist nicht wirklich vergleichbar mit dem was man bisher gemacht hat, wobei Sie natürlich mit Double-Patterning ohne FinFet schon Erfahrung sammeln konnten. Einfach ist das Zeug aber nicht, vor allem, wenn man wirklich die DRC-Rules verletzten will bewusst. Das zu verifizieren ist nicht einfach. Da steckt schon verdammt viel Arbeit drin.

[robbitop]

Ja mag sein. Aber wie gesagt müssen auch NV und AMD nächstes Jahr FinFET GPUs mit viel mehr Transistoren liefern. Wenn die Designs jetzt noch nicht abgeschlossen wären, würde mich es wundern.
Scheint also machbar zu sein. Intel hat es ja auch hinbekommen. Keiner sagt, dass sowas nicht aufwändig ist. Aber offenbar ist es machbar.

[Skysnake]

Ich würde nicht davon ausgehen, dass die Standard-Libs schon fertig sind. Da wird wohl so lange dran optimiert, bis das GPU-Design an sich fertig ist. Man kann da ja wirklich ernsthaft sparen.

Zumal man eben auch nicht nur einen Inverter baut, sondern 2,4,8 oder gar 10 unterschiedliche. Je nachdem wie feingranular man das machen will bzgl. Last die einer treiben muss.

Das ist ja das "lustige" an analogen Designs, bzw auch digitalen mit >GHz. Man ist eigentlich nie fertig.

[robbitop]

Willst du damit sagen, dass GP100/R4xx hangelayoutet ist?

[Skysnake]

Definiere "Handgelayoutet"

Das ist ein verdammt weites Feld.

Selbst in einem reinen Digitaldesign hast du von jedem AND, NOR usw usf mehrere Versionen. Also ein AND2 AND3 ANDx. Dazu kann noch ein AND2_strong, AND2_weak usw usf. Das sind halt PCells. Also Standardzellen, die parametrisiert sind. Meines Wissens nach läuft das über SKILL skripte. Also du setzt dich hin, und erstellst ein skript, welches die Standardzelle zeichnet mit den entsprechenden Parametern, wobei du natürlich die Designrules einhalten musst.

Je nachdem, wie die Designrules sind, bzw. wie stark du noch otimieren kannst, sind eben die Skripte mehr oder weniger aufwendig. Man hat da ja immer eine gewisse Symmetrie drin, daher lohnen sich die parametrisierten Skripte auch. Man muss allerdings auch sicherstellen, dass ALLE! Permutationen an designten Standardzellen aneinander passen! Man muss ja sicher sein, dass das Placement und Routing vom Tool ja auch sicher funktioniert.

Der digital Designer sieht davon erstmal nichts, so lange er nicht beeinflusst, wie das Tool den HDL Code interpretiert. Klassisches Beispiel ist hier z.B. Differenzielle Logik. Das kannste als Single-Ended mit nem inverter bauen, was dann halt nicht wirklich dem entspricht was der Designer wollte, aber vom HDL Code ist es das Gleiche. Da musste halt das Tool die entsprechenden Zellen in die Hand drücken, die wirklich differenziell sind und nicht single ended.

Ob das also "hangelayoutete" Designs sind, ist immer eine Frage des Betrachtungswinkels. An sich sind es große Mixed-Signal designs. Also sowohl Digital als auch Analog. Der ganze I/O Kram, Clockgenerierung usw sind an sich Analogblöcke, die werden ziemlich sicher auch komplett von Hand gebaut.

Die SRAMs usw sind wohl teilweise aus hangelayouteten Standardzellen (SRAM) und teils komplett per Hand gebaut (Sensamp zum Auslesen z.B.). Und die Digitallogik ist halt irgend ein RTL code, den man auf die STandardzellen-Libs mapt. Da werden die wohl auch etwas dran drehen, und schauen was man noch rausholen kann, wobei Sie eventuell sich auch "nur" auf das intelligente Placement&Routing beschränken bei den neuen Prozessen. Der Validierungsaufwand ist schon sehr sehr hoch. Gerade Double-Patterning ist da ECHT! ein Graus.

Wieviel Sie da aber an welcher Stelle drehen, können dir nur AMD und nVidia sagen. Ich habe allerdings schon gehört, dass die ihre "eigenen" STandardzellen-Libs verwenden, also zumindest für so Sachen wie SRAM. Genaues wirst du da aber nie erfahren. Das machen auch eh nur ganz ganz wenige Firmen.

[Sunrise]

Willst du damit sagen, dass GP100/R4xx hangelayoutet ist?
Bei solchen Monster-GPUs ist es heutzutage erstens kaum noch sinnvoll und auch fast nicht mehr möglich, hier groß "mit der Hand" zu optimieren. Du musst dich größtenteils auf die am Markt zur Verfügung stehenden Libraries, Tools etc. verlassen. Es werden wenn überhaupt nur noch minimalste Änderungen durchgeführt, um hier keine Verzögerungen zu provozieren.

Diverse Blöcke (normalerweise wird die Arbeit in Blöcke aufgeteilt, diese werden dann nach Bedarf nur noch nach Anforderung multipliziert, bzw. wenn analog dann eben einmalig komplett) bedürfen aber u.a. unterschiedlicher herangehensweise, je nachdem, was du erreichen willst.

Das sagt zumindest Rys, der bei IMGtec für die GPU-Entwicklung zuständig ist und das ist auch nachvollziehbar.

Was mir da zum Vergleich gerade einfällt, das macht es "greifbarer":

Stell dir mal sehr viele kleine Dominosteine vor, die du per Hand in die richtige Position bringen musst, damit sie alle nach einem bestimmten Ablauf umfallen. Die Anforderung und das Ziel ist also klar, du möchtest das alle Bausteine sich gegenseitig unterstützen können (alle müssen kontrolliert umfallen) um das Ziel (auch der letzte Dominostein muss umfallen) zu erreichen.

Jetzt ist die entscheidende Frage (das beschreibt jetzt handoptimiert):

Traust du dich da überhaupt noch, dort per Hand noch ranzugehen und zu riskieren, das du wegen ein paar Feinheiten (z.B. minimalem Flächenvorteil -> mehr Dominosteine) riskierst, dass plötzlich irgendwo ein Fehler ist (ein Stein fällt nicht mehr um) oder ist es dir wichtiger, die Risiken möglichst zu minimieren und dich auf verifizierte Dominoabstände und Anordnungen (design rules) zu verlassen?

Wir reden hier ja nicht nur von 3-4 x-fach replizierten Blöcken (eher bei GPUs, bzw. bei CPUs die xCores und die xCaches), sondern von mittlerweile an die 10 Milliarden bei nicht mehr vorstellbaren Strukturgrößen.

Das wird immer schwieriger werden, da überhaupt noch mit der Hand ranzugehen, wenn man mal von speziellen ASICs (SoCs, Analogteilen) etc. absieht. Es ging dir ja um GPUs.

Auch Intel wird nicht alles handoptimieren, das macht einfach keinen Sinn.

[robbitop]

Ich wollte mit meiner Frage implizieren, dass Skysnakes Bedenken etwas zu übervorsichtig sind. Natürlich werden die nicht handgelayoutet.

[Skysnake]

@Sunrise:

Daher optimiert man ja auch die Standardzellen Libary;)

Wenn du 1% bei ner SRAM-Zelle sparen kannst an Verlustleistung oder Fläche, dann ist das schon ganz schick, einfach weil die Dinger Millionenfach verbaut werden.

Die Frage ist halt immer, wieviel Aufwand will man betreiben. Die Standardzellen-Libs von den FABs sind ja schon ganz schön umfangreich, decken aber dennoch nicht alles ab. Deswegen lässt sich da auch wunderbar drüber streiten, ob das handoptimierte Chips sind.

Wenn man nur danach geht, ob das Placement und Routing von nem Tool oder von Mensch gemacht wird, dann nein für den Digitalteil. Wenn man aber auch angepasste Standardzellen als Handgelayoutet definiert. Dann ja.

Die Diskussion ist daher müßig, denn reines Handlayout findest du nirgends mehr. Macht meiner Meinung nach auch nicht wirklich Sinn. Die Tools haben da den besseren Überblick bei Digitalschaltungen. Man kann aber eben durchaus die Standardzellen optimieren von Hand, und das macht meiner Meinung nach auch durchaus Sinn, wenn man ein Konzern wie AMD, Intel oder nVidia ist. Deren Chips sind verdammt groß und Sie bauen verdammt viele davon.

[Nakai]

AMDs größtes Problem bei Bulldozer und Co. waren eher die Off-Chip Sachen, wie Cache-System, Interconnect, Interconnect-Takt, etc...

Zen sollte da deutliche Verbesserungen bringen.
Es wird kein Shared-L2-Cache mehr geben, ergo der einzige Shared-Cache ist der L3-Cache. Wenn der Interconnect deutlich überarbeitet wird, dann sollten schon einige interessante Sachen möglich sein. Bulldozer und Co. war stark durch das ganze Off-Chip Zeug limitiert.

Zu den Int-Pipes kann man derzeit nichts sagen. Wir wissen auch nicht die maximale Bandbreite für die AGU, ebenso wenig, wieviele MULs und DIVs verbaut sind. Wird SMT unterstützt sollten gewisse Funktionalitäten doppelt da sein.

Bei AMD sieht man in den ganzen Block Diagrammen nicht, wo die Branch-Unit ist. Welche Funktionseinheiten machen LEA, Shift, MUL, DIV, wäre eine interessante Frage. Hat man 2 AGUs oder doch 3? Intel hat 4 AGUs bei Haswell verbaut.

Naja so far...

[Unicous]

Hmmm...


wir werden weiter gefüttert

51762

http://www.planet3dnow.de/vbulletin/threads/421433-AMD-Zen-14nm-8-Kerne-95W-TDP-DDR4?p=5004276&viewfull=1#post5004276

[Hübie]

Hm. Da steht wie in dem anderen slide nur Blah. Das kann man sogar erraten :rolleyes:

[Ravenhearth]

Genau das richtige Futter für Analysten, wie? :freak:

[y33H@]

"Based Quad Core Unit" klebt mir zu eng am Strich und ist zudem ein Pixel nach unten versetzt :ulol:

EDIT
Wenn das übrigens die Slides wären, die am 6ten Mai online gehen, stünde da IMHO nichts von NDA. Müsste also Vorab-Briefing sein und dann verstehe ich nicht, warum der FAD erwähnt wird.

Schauen wir mal ...

[Hübie]

X-D
Dear analysts,

we blah core blah interconnect blah *insertrandombuzzword*.
Please let us know how much money you will give us.

regards and fuck off,

AMD Marketing at it's best

[dildo4u]

Schade dachte 4Core's gibt nur noch als APU.Ist ja wie bei Intel Mainstream vermutlich in 2020 noch 4 Core's. :rolleyes: Wozu das ganze Gehype um die besser Multicorenutzung unter DX12 und Mantle wenn die neuen bezahlbaren CPU's gar nicht so breit sind.

[Ravenhearth]

Höh? Das ist doch nur ein "Modul", bestehend aus vier Kernen. Wird doch nirgendwo gesagt, dass das auch so in reinen CPUs zum Einsatz kommt. Da könnten das gut mehr sein.

[Timbaloo]

512KB L2 ist neu, oder?

[Unicous]

Hm. Da steht wie in dem anderen slide nur Blah. Das kann man sogar erraten :rolleyes:

Seit wann gehen die Marketing Slides von AMD oder anderen Firmen irgendwie in die Tiefe.

Also von daher könnte ich jetzt nicht sagen ob das Fake ist oder nicht.


@Timbaloo

512KB pro Kern, also 2MB pro (Compute ;)) Unit.


Das Ding wäre damit modular aufgebaut. Man könnte eine, zwei, drei oder vier "Units" in einen Die einbringen. Das mit dem Interconnect finde ich interessant. Crashtest hatte ja schon gesagt, es wäre HT 3.0..

[Ravenhearth]

Der Aufbau erinnert mich schon recht deutlich an Jaguar.

[fondness]

Schade dachte 4Core's gibt nur noch als APU.Ist ja wie bei Intel Mainstream vermutlich in 2020 noch 4 Core's. :rolleyes: Wozu das ganze Gehype um die besser Multicorenutzung unter DX12 und Mantle wenn die neuen bezahlbaren CPU's gar nicht so breit sind.

Der PS4 oder Xbox 360 SoC hat auch bereits zwei "Quad-Core-Units" verbaut. Scheint ein ähnliche Aufbau wie bei Jaguar zu sein.

Im übrigen steht auf dem Slide bereits das mehrere solche Module kombiniert werden könne. Man könnte also 4/8/12/16, etc. Kern Cpus damit bauen. Allerdings orientiert sich auch dieser Slide sehr stark an den herum geisternden Gerüchte und könnte genau so gut fake sein.

[Unicous]

@Ravenhearth

Frag mal Duplex, der findet bestimmt einen Vergleich zu K 8/10.:freak:

[Ravenhearth]

Ha! Quadcore! Genau wie K10!

[Coda]

Sieht sehr nach einem modernen Design aus ohne Experimente. Gut. Jetzt muss nur noch die Execution stimmen und es könnte was werden.

Der Aufbau erinnert mich schon recht deutlich an Jaguar.
Das Problem ist, dass eigentlich jeder moderne Out-of-Order-Kern ziemlich gleich aussieht. Bulldozer war immer der komische Ausreißer.

[Ravenhearth]

Ich meinte eigentlich nicht den Kern an sich, sondern die Organisation von 4 Kernen und shared cache in einer größeren Einheit.

[fondness]

Ich meinte eigentlich nicht den Kern an sich, sondern die Organisation von 4 Kernen und shared cache in einer größeren Einheit.

Das hat ja AMD schon länger, auch Bulldozer ist ja faktisch in Modulen mit 2 Kerne/Threads und shared L2-Cache designet. Bei Jaguar ging man dann auf jeweils 4 Kerne pro Modul.

[Coda]

Ich meinte eigentlich nicht den Kern an sich, sondern die Organisation von 4 Kernen und shared cache in einer größeren Einheit.
Macht Intel ja auch nicht groß anders. Außer das sie bei den größeren Cores einen Ring-Bus durch die Caches ziehen.

[Skysnake]

hmm seh ich das richtig, dass die Daten der FP Units nicht! über den L1D Cache gehen?

Das FP Geraffel geht doch normal auch über den L1D oder nicht? Habe dazu auf die Schnelle nicht wirklich was gefunden. Bei BD gehts wohl drüber, bei Itanium nicht. Zu SB habe ich jetzt nichts gefunden.

Ich frage mich allerdings echt, was das mit dem Interconnect sein soll, und dem Zusammenschalten. :confused:

Sind da eventuell die FP Units gemeint? Das wäre dann schon ganz nett ;D

[Hübie]

Sogar zwei Ringe bei den großen CPUs. Sozusagen zwei Module.

[Ravenhearth]

hmm seh ich das richtig, dass die Daten der FP Units nicht! über den L1D Cache gehen?

Das FP Geraffel geht doch normal auch über den L1D oder nicht? Habe dazu auf die Schnelle nicht wirklich was gefunden. Bei BD gehts wohl drüber, bei Itanium nicht. Zu SB habe ich jetzt nichts gefunden.

Bei der Excavator-Folie war aber auch kein L1D für die FPU eingezeichnet, genauso bei den anderen Bulldozer-Folien von AMD. Vielleicht ist die Grafik einfach ungenau.


Ich frage mich allerdings echt, was das mit dem Interconnect sein soll, und dem Zusammenschalten. :confused:

Sind da eventuell die FP Units gemeint? Das wäre dann schon ganz nett ;D

Vielleicht auch nur mehrere Quad-Core-Einheiten zusammen...

[fondness]

Am interessantesten an dem Slide finde ich übrigens das mit dem "fully inclusive Cache Design". Das wäre das erste mal das AMD sowas bei einer CPU mit mehr als zwei Cache-Ebenen implementiert. Alle anderen AMD-Server-CPUs haben ein exklusives Cache-Design, Jaguar war der erste mit inklusiven-Design, hatte allerdings auch nur 2 Cache-Ebenen. Dadurch braucht man natürlich auch einen relativ kleinen L2- und einen relativ großen und hoffentlich schnellen L3-Cache.

[StefanV]

Hm. Da steht wie in dem anderen slide nur Blah. Das kann man sogar erraten :rolleyes:
fully inclusive cache design for high performance, low latency

Wäre für mich nicht nur Blah :P

[Skysnake]

Am interessantesten an dem Slide finde ich übrigens das mit dem "fully inclusive Cache Design". Das wäre das erste mal das AMD sowas bei einer CPU mit mehr als zwei Cache-Ebenen implementiert. Alle anderen AMD-Server-CPUs haben ein exklusives Cache-Design, Jaguar war der erste mit inklusiven-Design, hatte allerdings auch nur 2 Cache-Ebenen. Dadurch braucht man natürlich auch einen relativ kleinen L2- und einen relativ großen und hoffentlich schnellen L3-Cache.
Ja das ist interessant, aber mit den inklusive Caches ist das halt immer so eine Sache.

Wenn man unglückliche Assoziativitäten hat, und zwei an sich unabhängige Cachelines in zwei Cores hat, die aber eben im L2 auf die gleiche Cacheline mappen, dann trasht man sich schön immer L1 und L2. Zumindest, wenn ich es jetzt gerade richtig im Kopf zusammenbringe :freak:

[Hübie]

fully inclusive cache design for high performance, low latency

Wäre für mich nicht nur Blah :P

Ist doch nur bei AMD was neues...

[w0mbat]

Mit 8MB L3 dürfte inclusiver Cache kein Problem sein. Haben wir schon Infos zur L1 & L2 Größe?

Macht ja nur wirklich Sinn, wenn andere Corse häufig nachschauen wollen, was denn so im Cache liegt, oder? Damit man nicht auf alle Cache-Stufen zugreifen muss.

[Unicous]

Na beim L2 sind es laut der Folie 512KB pro Core, also 2MB pro "Unit".

Den L1 würde ich im gleichen Ballpark wie Carrizo ansiedeln, also 128 KB(96/32).

[w0mbat]

Ah stimmt, danke.

[Locuza]

Mit 8MB L3 dürfte inclusiver Cache kein Problem sein.
Das Ratio ist aber nicht so aggressiv wie bei Intel.

Intel i7: L2$ : L3$ = 1:8
i5: L2$ 1 MB vs. L3$ 6 MB.
(Die Server-Angebote habe ich jetzt nicht im Kopf)

Bei Zen 1:4.
Da sind >2MB vom Cache gleich weg, bei Intel effektiv nur etwas mehr als 1MB.

Natürlich ist man allgemein gespannt, wie sich Zen's Cache-Architektur durch die Bank schlagen wird.

[Coda]

Ist doch nur bei AMD was neues...
Hat Bulldozer wirklich exklusive Caches? Ich dachte das wäre nur bei Bobcat mal der Fall gewesen.

[robbitop]

Gut wäre es vor allem, wenn L1/L2 nun endlich mal schnell werden (Latenz/Bandbreite). Darunter litten alle AMD CPU Designs. Hitrate ist aber sicher auch ein sehr wichtiger Faktor.

L3 dann idealerweise @Fullspeed.

[HOT]

L3 ist teilweise inclusive, alles andere ist exclusive.

[Skysnake]

Hat Bulldozer wirklich exklusive Caches? Ich dachte das wäre nur bei Bobcat mal der Fall gewesen.
Ja, L2 soll shared exklusiv sein. (http://www.cpu-world.com/CPUs/Bulldozer/AMD-FX-Series%20FX-8150.html)

Ist halt immer so ne Sache mit exklusiv oder nicht. Snoop traffic vs. Cacheline trashing. Muss man schauen, was bei rum kommt.

[y33H@]

Ich hatte L2 als inklusive im Kopf mit Write-Through für den L1D und der L3 arbeitet exklusive (iwie logisch bei 8M L2 und 8M L3).

EDIT
51767 51768

[Ravenhearth]

L3 dann idealerweise @Fullspeed.

Intel ist bei Haswell aus Gründen des Stromverbrauchs ja wieder davon weg gegangen. Da hat der L3 einen eigenen Takt (neben CPU und Uncore/GPU), läuft aber nicht mit voller CPU-Geschwindigkeit.

[robbitop]

Intel ist bei Haswell aus Gründen des Stromverbrauchs ja wieder davon weg gegangen. Da hat der L3 einen eigenen Takt (neben CPU und Uncore/GPU), läuft aber nicht mit voller CPU-Geschwindigkeit.
Er hat einen eigenen Taktgeber läuft aber auf vollem Takt AFAIK. Bei Haswell-e oder EP war IIRC mal die Rede davon.

[y33H@]

Bei Haswell läuft der L3 unter (CPU-)Last mit Fullspeed, er hat nur eine eigene Takt-Domäne.

EDIT
Vorteil aus Effizienz-Sicht ist, dass der L3 zB auch anspringen kann wenn die GPU was will, die Kerne aber weiter schlafen können. Die L3-Latenz leidet glaub ein bisschen.

[Ravenhearth]

Achso, okay :) Das mit der Latenz hatte ich in Erinnerung, nur beim Takt war ich mir nicht sicher.

[S940]

Gut wäre es vor allem, wenn L1/L2 nun endlich mal schnell werden (Latenz/Bandbreite).
Ergäbe sich zwangsläufig, wenn man 256bit AVX2 inkl. FMA in einem Rutsch ausführen will ...

Spannend wirds in Sachen L1-Größe ... 32 oder 64kB für Daten? Bleiben 96kB für Instruktionen?

[y33H@]

64 + 128 wäre schön ;D

[Hübie]

Der läuft mit vollem Takt bzw. höherem Takt als der Kern.

Bulldozer is ein Fall für sich. Da wird afaik wild gemixt und wehe du hast nix im L3.. Ich bin aber ehrlich gesagt mit AMD nicht sehr vertraut, da die zwar interessante Ansätze haben und (offenbar in der Designphase) massiv auf Parallelisierung setzten, dies jedoch in real world scenario kaum von Belang war / ist. Irgendwo sah ich mal ein Szenario wo ein Bulldozer einen Nehalem gnadenlos die Hosen runterzog aber in welchem Projekt weiß ich nicht mehr. War glaub ich 2011.

[Coda]

Gut wäre es vor allem, wenn L1/L2 nun endlich mal schnell werden (Latenz/Bandbreite). Darunter litten alle AMD CPU Designs. Hitrate ist aber sicher auch ein sehr wichtiger Faktor.

L3 dann idealerweise @Fullspeed.
Bei Cache sind die unbeachtetend Performance-Faktoren auch die Assoziativität und Ersetzungsstrategie. Letztere ist komplett undokumentiert.

Soll heißen ein 32KiB 8-way-cache würde viel besser funktionieren als ein 64KiB direct mapped cache.

[Hübie]

Ich hatte dazu mal einen sehr guten Artikel gelesen. Wenn mir die passenden Google Schlagwörter einfielen würde ich das verlinken. Bulldozer hat (afaik) noch einen Buffer zwischen L1/L2. Der frisst wohl ebenfalls Latenz.

Edit: Gerade mal auf cpu-world.com geschaut:
http://www.abload.de/thumb/27rlw.jpg (http://www.abload.de/image.php?img=27rlw.jpg)

Es handelt sich um einen FX-8370 (Verpiledriver)

[Unicous]

http://www.realworldtech.com/includes/images/articles/bulldozer-6.png?71da3d
http://www.realworldtech.com/bulldozer/8/


Edit: Hab mich vertan, siehe unten

[Locuza]

Ich hatte dazu mal einen sehr guten Artikel gelesen. Wenn mir die passenden Google Schlagwörter einfielen würde ich das verlinken. Bulldozer hat (afaik) noch einen Buffer zwischen L1/L2. Der frisst wohl ebenfalls Latenz.

Der Write Coalescing Cache:
http://ht4u.net/reviews/2011/amd_bulldozer_fx_prozessoren/index10.php

Oder ausführlicher in Englisch von Kanter damals:
http://www.realworldtech.com/bulldozer/8/

[Hübie]

Aaah der von realworldtech war es. Danke, man! =)

@Coda: sind die L1-Cachedimensionen (instruction / data) im BD Design denn ausreichend für übliche Codeschnipsel moderner engines? Habe da absolut kein Gefühl für bzw keinerlei Größenordnungen welche bekannt wären. Interessiert mich einfach mal. Vor allem wie weit das moderne compiler abdecken wäre auch mal interessant. Viele sagen AMD hätte grundsätzlich Nachteile da die meisten compiler auf Intels Architektur optimieren. Ist das so?

[Coda]

Nein, Compiler optimieren nicht auf Intels Architektur.

Edit: Solange sie nicht von Intel stammen.

[Hübie]

Woher stammt dann dieses Ammenmärchen? :| Doch nicht immer noch von einem uralten Test der einem Programm eine Intel-CPU vorgaukelte obwohl AMD drin war?
Also angenommen ich stelle diese These auf. Wie würdest du die entkräften?

ps: Das habe ich tatsächlich gestern erst auf planet3dnow gelesen...

[Ravenhearth]

AMD-Fanboys :D

[Unicous]

AMD-Fanboys :D

For realz?:confused:

http://www.agner.org/optimize/blog/read.php?i=49#49

http://www.dtu.dk/english/Service/Phonebook/Person?id=78696&tab=2&qt=dtupublicationquery


Den Disclaimer müssen sie seit einiger Zeit auf ihrer Website zeigen...in zig Sprachen.

https://software.intel.com/sites/default/files/m/7/f/f/German.gif
https://software.intel.com/en-us/articles/optimization-notice#opt-en

[Coda]

Woher stammt dann dieses Ammenmärchen? :|
Wenn man den Intel-Compiler benutzt wäre das tatsächlich der Fall. Macht nur niemand.

Jedes Spiel oder Programm das ich jemals auf Windows gesehen hat ist mit dem Microsoft-Compilier übersetzt. Linux/Mac GCC/Clang.

Einzige Ausnahme die ich kenne ist Cinebench oder wie das heißt.

[Ravenhearth]

Und was hat es mit der Info (http://www.planet3dnow.de/vbulletin/threads/421433-AMD-Zen-14nm-8-Kerne-95W-TDP-DDR4?p=5003844&viewfull=1#post5003844) auf sich, dass die Intel memory controller die 100- bis 1.500-fache Anzahl an Speicherfehlern/Pagefaults (im Vergleich mit AMD) verursachen würden?

[Coda]

Ein Page-Fault passiert wenn eine virtuelle Speicher-Seite nicht physikalisch zugewiesen ist, das hat nichts mit Speicherfehlern zu tun.

Die Frage ergibt so keinen Sinn.

[Ravenhearth]

So wird diese "Info (http://www.planet3dnow.de/vbulletin/threads/421433-AMD-Zen-14nm-8-Kerne-95W-TDP-DDR4?p=5003844&viewfull=1#post5003844)" aber verbreitet.

[Coda]

Was weiß ich was der da redet, kohärenten Sinn ergibt es nicht.

Er könnte meinen, dass Intel-Speichercontroller irgendwie mehr Bitflips erzeugen. Falls er das meint, dann würde das als absurdes Gerücht einordnen. Wahrscheinlich hatte er einen PC mit defekten DIMMs und meint das hätte was mit der CPU zu tun.

[Unicous]

Ich würde Crashtest nicht als absurden Spinner abstempeln, aber die Aussage ist schon sehr vage. Außerdem redet er auch von DDR2, vllt. redet er von älteren Serversystemen.

[Coda]

Ich würde ihn als absurden Spinner abstempeln. Und jetzt?

Speicherfehler resultieren in so gut wie allen Fällen sofort in Crashes. Das hätte NIIIIIIIIIIIIEEEEEEEMAAAAAAAAND bemerkt. Is klar.

[Unicous]

:rolleyes:

[Duplex]

:rolleyes:

[tdon]

Ja das ist unglaubwürdig von einem AMD Fanboy, der seine Agenda betreibt. Ist doch von P3d nichts Neues. Oder generell von Fanboyseiten. So entstehen Gerüchte.

[Unicous]

Agenda? Was für eine Agenda?

Sind hier nur Ankläger und Scharfrichter in einer Person unterwegs?


Das nimmt hier schon wieder Züge an.:facepalm:

[Pentium M]

Ja das ist unglaubwürdig von einem AMD Fanboy, der seine Agenda betreibt. Ist doch von P3d nichts Neues. Oder generell von Fanboyseiten. So entstehen Gerüchte.

Per Anhalter durch die Galaxie. Haben sie dich nicht mitgenommen.Tut mir leid.:cool:

[Hübie]

Hier H.M.S. Niveau: Wir sinken :rolleyes:

http://abload.de/img/hmsniveau8yqcf.jpg (http://abload.de/image.php?img=hmsniveau8yqcf.jpg)

Wenn ein pagefault auftritt ist das idR auf schlampige Programmierung (bzw. auch Windows MMU) oder DRAM-Defekt zurückzuführen.

Edit: Ich rede von pagefaults in stetig steigender Masse - nur dass das klar ist.

[Pentium M]

Hier H.M.S. Niveau: Wir sinken :rolleyes:

http://abload.de/img/hmsniveau8yqcf.jpg (http://abload.de/image.php?img=hmsniveau8yqcf.jpg)

Wenn ein pagefault auftritt ist das idR auf schlampige Programmierung (bzw. auch Windows MM) oder DRAM-Defekt zurückzuführen.

Gloria _wir sehr wir leuchten

[Skysnake]

Woher stammt dann dieses Ammenmärchen? :| Doch nicht immer noch von einem uralten Test der einem Programm eine Intel-CPU vorgaukelte obwohl AMD drin war?
Also angenommen ich stelle diese These auf. Wie würdest du die entkräften?

ps: Das habe ich tatsächlich gestern erst auf planet3dnow gelesen...
Ist ja nicht so, das niemand den Intel-Compiler einsetzt ;)

Zumindest im wissenschaftlichen Bereich ist er durchaus häufiger vertreten, wenn du Intel-Installationen betreibst. Holt halt nochmal etwas mehr raus, als der GCC, wobei es lustig ist, dass der GCC zumindest bei XeonPhi als ich es getestet habe, teils schnelleren Code produziert hat ;D

Ansonsten:
Compiler können auf unterschiedliche Architekturen optimieren. Das musst du aber von Hand aktivieren. Beim GCC gibt es da auch keine Bevorzugung eines Herstellers, beim Intel-Compiler sah/sieht es halt anders aus.

[Coda]

Ist ja nicht so, das niemand den Intel-Compiler einsetzt ;)
Nicht bei Zeug das wirklich gemessen wird von den gängigen Seiten. Spezialanwendungen sind irrelevant dafür.

Wenn ein pagefault auftritt ist das idR auf schlampige Programmierung (bzw. auch Windows MMU) oder DRAM-Defekt zurückzuführen.

Edit: Ich rede von pagefaults in stetig steigender Masse - nur dass das klar ist.
Ich wiederhole mich, ein Pagefault ist ein völlig normaler Vorgang und hat weder etwas mit schlampiger Programmierung noch mit DRAM-Defekten zu tun. Das passiert schlicht wenn der physikalische RAM ausgeht und das OS auslagern muss.

[Skysnake]

Naja, SPECView wars glaube ich, der es eingesetzt hatte, und das war schon scheise für AMD. Intel hatte dafür ja auch auf die Finger bekommen.

Btw. Kann ich mir unter Windows eigentlich so einfach anschauen, mit was das Zeug compiliert wurde?

[Locuza]

Complicated hat die Sache aufgeklärt, von der Crashtest nicht ganz korrekt gesprochen hat.
Es ging um Bitflips bei benachbarten Speicherbänken und Adressen:
http://users.ece.cmu.edu/~yoonguk/papers/kim-isca14.pdf
http://www.planet3dnow.de/vbulletin/attachment.php?attachmentid=32397&d=1430292618

[Coda]

Ach die Geschichte. Das ist Forschung, solche Zugriffsmuster finden sich in der Praxis nirgends. Vor allem steht da nirgends, dass sie den gleichen Aufwand auf Intel und AMD betrieben haben diese Fehler zu provozieren, das ist höchst Architekturspezifisch.

[Skysnake]

Und hängt an sich meines Verständnisses nach auch eher am RAM als am Controller. So lange man eben die RAMs mit den gleichen Spannungen betreibt.

Die RAM-Zellen werden meines Wissens nach ja nicht direkt ausgelesen. Da sitzen ja ein paar Verstärker zwischen RAM-Zelle und Controller.

[S940]

Ach die Geschichte. Das ist Forschung, solche Zugriffsmuster finden sich in der Praxis nirgends. Vor allem steht da nirgends, dass sie den gleichen Aufwand auf Intel und AMD betrieben haben diese Fehler zu provozieren, das ist höchst Architekturspezifisch.
Na klar ist das architekturspezifisch .. die eine Architektur erzeugt Fehler, die andre um Faktor >100 weniger. Genau darum gehts doch :freak:

Oder willst Du etwas kompliziert ausdrücken, dass der verwendete Code nur zufällig schlecht auf Intel liefe und sich auch anfälliger Code für AMDs Piledriver finden ließe?
Und hängt an sich meines Verständnisses nach auch eher am RAM als am Controller.
Naja, sie werden bei dem Test ja wohl den gleichen RAM-Riegel verwendet haben, ansonsten wärs ja wohl witzlos ...

[Gipsel]

Und hängt an sich meines Verständnisses nach auch eher am RAM als am Controller. So lange man eben die RAMs mit den gleichen Spannungen betreibt.

Die RAM-Zellen werden meines Wissens nach ja nicht direkt ausgelesen. Da sitzen ja ein paar Verstärker zwischen RAM-Zelle und Controller.
Es hängt auch an der Geschwindigkeit der CPU bzw. des Controllers (z.B. wie lange eine Cache-Flush benötigt; etwas, das man ja sonst eher selten macht, also nicht wirklich repräsentativ). Damit der Ansatz klappt, muß man ja möglichst viele Requests an die gleiche Zeile einer Bank des DRAM-Arrays in kurzer Zeit raushauen. Wer schneller ist, produziert also mit dem gleichen Speicher mehr Fehler. ;)

[Coda]

Oder willst Du etwas kompliziert ausdrücken, dass der verwendete Code nur zufällig schlecht auf Intel liefe und sich auch anfälliger Code für AMDs Piledriver finden ließe?
Nicht zufällig schlecht. Bewusst schlecht. Das ist ja was sie provizieren wollten. Was da gemacht wird passiert in echtem Code nicht. Nie.

[Skysnake]

Klar, aber ich hoffe doch, das man da am theoretischen Maximum operiert.

An sich gibt es ja nicht viele Vorgehensweisen. Entweder man verwendet Atomics oder eben volatile und mach immer! ein CLFlush hinterher, damit man sofort den Cache invalidiert.

Ich kann mir aber an sich nicht vorstellen, das man da den RAM-Controller nicht ausgelastet bekommt.

[Coda]

Whatever, ich diskutier den Scheiß nicht mehr. Das hat sowas von keine theoretische Relevanz.

[Skysnake]

Für Hacker nicht unbedingt. Für normale Programme/Nutzer aber ja. Und selbst wenn, dann muss man halt schlicht sagen: Tja, that's life.

Wenn man nicht mit Single-Bit Flips klar kommt, die eh immer! passieren können, dann muss man sich halt ECC zulegen. Damit gibt es das Problem auch nicht mehr.

[S940]

Nicht zufällig schlecht. Bewusst schlecht. Das ist ja was sie provizieren wollten. Was da gemacht wird passiert in echtem Code nicht. Nie.Ok, mag sein, dass das ganze künstlich konstruiert ist und in der Realität nicht vorkommt .. aber in Endeffekt hats dann doch ne ähnliche Relevanz wie der FDIV-Bug des Pentiums annodazumal ;) Deswegen kann man sich die Frage stellen, wieso es bei AMD deutlich weniger besser ausfällt und bei Intel mehr. Ist ja der gleiche Code, also ist die Frage - konstruiert hin oder her - legitim.

Die Studie wurde teilweise von Intel gesponsort, also wird man kaum AMD-Lastigkeit unterstellen können.

@Gipsel:
Könnte dann die Lösung sein, bei AMD läuft der Speicherkontroller ja mit langsameren "NB-Takt". Schade das keine Sockel 1156-CPUs getestet wurden, die hatten sowas ja auch noch.

Wenn man nicht mit Single-Bit Flips klar kommt, die eh immer! passieren können, dann muss man sich halt ECC zulegen. Damit gibt es das Problem auch nicht mehr.
So siehts aus ... wollen wir deshalb mal hoffen, dass es wieder nen einigermaßen günstigen AMD Zen FX mit ECC im Desktopbereich geben wird.

[Kriton]

Nicht zufällig schlecht. Bewusst schlecht. Das ist ja was sie provizieren wollten. Was da gemacht wird passiert in echtem Code nicht. Nie.

Gab es dazu nicht vor kurzem eine Meldung dies als Angriffsvektor zu nutzen?

[Unicous]

Es geht um besagte Studie und das bereits bekannte "Row Hammering".

Er beruht auf einer wohlbekannten Anfälligkeit von DDR3-Speicher, wenn man allzu häufig auf eine Zeile zugreift oder zwischen zwei Zeilen innerhalb einer Bank wechselt. Das sogenannte Row Hammering kann benachbarte Zeilen derart stören, dass hier Bits kippen. Diese Anfälligkeit ist der Industrie schon seit Jahren bekannt – Intel hat mehrere Patente, die das Problem angehen, etwa das US-Patent US20140006703 A1, eingereicht im Juni 2012. Da werden Zugriffe innerhalb eines Zeitfensters auf dieselbe Zeile mitgezählt. Sind es mehr als ein vorgegebener Schwellenwert, zum Beispiel 550 000 innerhalb der üblichen Refresh-Zeit von 64 ms, dann wird ein zusätzlicher Refresh für die gefährdete Nachbar-Zeile („victim row“) eingeschoben.

Die breitere Öffentlichkeit wurde von der Zeilenhammergefahr aber erst im Sommer vorigen Jahres auf dem Internationalen Symposium für Computer-Architektur (ISCA) informiert. Wissenschaftler der Carnegie Mellon University sowie ein Intel-Entwickler hatten sich die Mühe gemacht, sowohl mit speziell designten FPGAs als auch auf realen Systemen mit Intel- und AMD-Prozessoren und mit völlig harmlosem User-Code zu „hämmern“. Lustigerweise, wenn man bedenkt, dass ein Intel-Mitarbeiter dabei war, beklagten sich die Autoren darüber, dass nur AMD das Mapping der Bits auf die Speicherzeilen sorgsam dokumentiert hat, bei den Intel-Prozessoren waren sie jedoch auf Reengineering angewiesen. Etwas unglücklich für Intel dürfte auch gewesen sein, dass die Systeme mit Intel-Prozessoren (Sandy/Ivy Bridge und Haswell) bei den Experimenten weit häufiger Bit-Flips erlitten als solche mit AMDs Piledriver, immerhin so um Faktoren 200 bis 1000.

Die Autoren präsentierten auch eine Idee, wie man das Problem allein im DRAM mit einem zufälligen Refresh der Nachbarzeile (PARA) beim Öffnen oder Schließen einer Zeile in den Griff kriegen kann. Das kostet nur marginal zusätzliche Zeit und verlangsamt nach ihren Simulationen etwa SPEC CPU2006 nur um 0,2 Prozent. Bei DDR4-Systemen soll das „1 Row Disturb“-Problem, wie es in der Szene heißt, aber schon beseitigt sein.

http://www.heise.de/ct/ausgabe/2015-8-Prozessorgefluester-Von-Zeilen-Spalten-und-Kreisen-2577489.html

[Locuza]

Roadmap-Time ;)

http://www.planet3dnow.de/vbulletin/attachment.php?attachmentid=32408&d=1430310568

http://www.planet3dnow.de/vbulletin/attachment.php?attachmentid=32407&d=1430310566

[robbitop]

Wenn das stimmt, macht das Mut. Ist ja alles dabei von 5 W bis zum High End Desktop. Und K12 übernimmt dann ULP.

[Skysnake]

hm... HSA1.0 support erst ab 2016 in fast allen Produkten das ist etwas enttäuschend, aber immerhin bekommt es auch der ARM-Zweig.

AM3(+) ist dann wohl auch tot. Ich frage mich allerdings, warum die reine CPU den gleichen Sockel bekommt, also FM3, bzw. warum kommt überhaupt noch eine reine CPU...

[Ravenhearth]

Wobei K12 in "Styx" nur mit 2 Kernen und (vermute ich mal) recht niedrigen Taktfrequenzen antritt. Die IPC könnte aber vergleichbar zu Zen sein.

[y33H@]

Wo ist Nolan abgeblieben?

[Ravenhearth]

War Nolan nicht Carrizo-L? Sollte neuen Gerüchten (!) zufolge nämlich in 28nm statt 20nm kommen.

[fondness]

Max 8 CPU-Cores im High-End Desktop, das wiederspricht schon mal klar den unglaubwürdigen Fudzilla-Slides. Ist aber okay wenn die Dinger SMT und eine ordentliche IPC können, Intel hat auch nicht mehr. Mich wundert es allerdings das man hier nicht versucht durch mehr Cores einen Vorteil zu verschaffen.

[robbitop]

8 Cores ist mehr als genug, wenn die "Core artig" sind.

[Ravenhearth]

Max 8 CPU-Cores im High-End Desktop, das wiederspricht schon mal klar den unglaubwürdigen Fudzilla-Slides. Ist aber okay wenn die Dinger SMT und eine ordentliche IPC können, Intel hat auch nicht mehr. Mich wundert es allerdings das man hier nicht versucht durch mehr Cores einen Vorteil zu verschaffen.

Das Fudzilla-Teil mit 16 Cores und GPU sah eher nach HPC aus, weniger nach Mainstream-PC.

Und außerdem hat AMD mehr Cores: Skylake hat 4+SMT, Zen hat 8+SMT.

[fondness]

War Nolan nicht Carrizo-L? Sollte neuen Gerüchten (!) zufolge nämlich in 28nm statt 20nm kommen.

Zumindest Mullins fehlt auf der Roadmap, kann mir nicht vorstellen das man den <10W x86 Bereich einstellt.

[Ravenhearth]

Zumindest Mullins fehlt auf der Roadmap, kann mir nicht vorstellen das man den <10W x86 Bereich einstellt.

Sonderlich viel verkauft hat man Mullins anscheinend nicht. Es gibt bei uns kein einziges Tablet damit zu kaufen und das einzige Notebook ist das HP Stream 14. Außerdem kommt 2016 dann Basilisk (x86) mit 5W minimum.

[Masmiseim]

Ich frage mich allerdings, warum die reine CPU den gleichen Sockel bekommt, also FM3
Dann sparen sie sich den Entwicklungsaufwand für einen zweiten Sockel. Der Grafikteil auf den Mainboards ist dann einfach ungenutzt. macht Sinn bei beschränktem Budget.

, bzw. warum kommt überhaupt noch eine reine CPU...
bei den aktuellen APUs (egal ob Intel oder AMD) belegt der GPU Teil den größten Teil des Chips. Wenn man den ohnehin nicht benötigt (Spiel PC) oder mehr Rechenleistung braucht (Workstation) ist es besser den Platz für zusätzliche CPU Cores zu nutzen.

[fondness]

Das Fudzilla-Teil mit 16 Cores und GPU sah eher nach HPC aus, weniger nach Mainstream-PC.

Und außerdem hat AMD mehr Cores: Skylake hat 4+SMT, Zen hat 8+SMT.

AMD wird keine reine Server-Chip designen, das lohnt sich nicht. Server landet sicher auch im High-End-Desktop.

[Ravenhearth]

AMD wird keine reine Server-Chip designen, das lohnt sich nicht. Server landet sicher auch im High-End-Desktop.

Auch sowas? (Wenn das echt ist)

http://cdn.wccftech.com/wp-content/uploads/2015/03/006l.jpg


HPC APU mit vlt >200W?

[fondness]

Dann sparen sie sich den Entwicklungsaufwand für einen zweiten Sockel. Der Grafikteil auf den Mainboards ist dann einfach ungenutzt. macht Sinn bei beschränktem Budget.


Da geht es nicht um den Entwicklungsaufwand, es bedeutet zusätzlichen Entwicklungsaufwand wenn ich zwei unterschiedliche Chip-Designen in das gleiche Pinout anpassen muss. Da geht es darum eine einheitliche Plattform für den Kunden zu kreieren, des bedeutet mehr Auswahl bei Mainboards und mehr Flexibilität für den Kunden. Wenn man nur einen geringen Marktanteil hat nicht unwichtig. Zwei Plattformen kann AMD den Mainboardherstellern wohl nur noch schwer verkaufen. Aktuell hat man ja mit AM1, AM2 und AM3 ja sogar 3.

Auch sowas? (Wenn das echt ist)

http://cdn.wccftech.com/wp-content/uploads/2015/03/006l.jpg


HPC APU mit vlt >200W?

Warum nicht? Für Mainstream-Spiele-PCSs sicher eine praktikable Lösung und wenn HSA mal verwendet wird unschlagbar.

[Unicous]

I want to believe. Everything is awe... 14nm in 2016.
btw. wo ist der x86 in 20nm. Gibbet wohl nich mehr, wie vermutet.


Das mit den Codenamen ist aber schon ein wenig krazy. Basilisk ("Drache") schwirrt ja jetzt schon seit Ewigkeiten umher, Godavari (Fluss) ist ja eigentlich auch recycled, Styx ein mythologischer Fluss. Dann die Ridges...

Ist natürlich plausiblel wenn man weiß, dass es verschiedene Designteams gibt, aber eine einheitliche Benennung wie mit Rennstrecken, Raubkatzen gäbe es dann nicht mehr.


@Ravenhearth Warum niedrige Taktraten?

Zwei muskulöse ARMe mit ordentlichen Taktraten können es mit "normalen" ARMen aufnehmen siehe Apple. Und wo war Jim Keller bevor er wieder zu AMD gestoßen ist? Bei Apple als Leiter der platform architecture group.:freak:

[Masmiseim]

es bedeutet zusätzlichen Entwicklungsaufwand wenn ich zwei unterschiedliche Chip-Designen in das gleiche Pinout anpassen muss.
Wer sagt das es zwei (mehrere) Chipsätze geben wird?

[Ravenhearth]

@Ravenhearth Warum niedrige Taktraten?

Zwei muskulöse ARMe mit ordentlichen Taktraten können es mit "normalen" ARMen aufnehmen siehe Apple. Und wo war Jim Keller bevor er wieder zu AMD gestoßen ist? Bei Apple als Leiter der platform architecture group.:freak:

Nur hat Cyclone halt keine hohen Taktraten. <1.5GHz sind imho "niedrig".

[Unicous]

Es geht um die Sockel.

Und natürlich wird es auch einen Server-Sockel geben, fondness erzählt Quatsch. Zumal man u.U. MCM weiternutzen wird um zwei 8 Cores (+SMT?) zu einem 16 Core zu verbinden.


@Ravenhearth

Cyclone wird aber auch noch in 20nm hergestellt. Dass ein breiter ARM keine Taktrekorde bricht dürfte klar sein, aber zusammen mit 14nm FinFET brauch man sich bis zu einer gewissen Schwelle keine Sorge machen. Siehe Intel. Die bekommen ja auch erst ab einem bestimmten Punkt Probleme bei Taktung und TDP.

[fondness]

Nur weill du mich nicht richtig interpretierst erzähle ich noch lange keinen Quatsch, natürlich wird es einen eigenen Server-Sockel geben. Es ging mir um Den Consumer-Bereich.

[Unicous]

Sorry, dann habe ich es falsch verstanden. Dachte du meinst FM3 wird auch als Server-Sockel genutzt.

[Skysnake]

Max 8 CPU-Cores im High-End Desktop, das wiederspricht schon mal klar den unglaubwürdigen Fudzilla-Slides. Ist aber okay wenn die Dinger SMT und eine ordentliche IPC können, Intel hat auch nicht mehr. Mich wundert es allerdings das man hier nicht versucht durch mehr Cores einen Vorteil zu verschaffen.
Wobei man sich schon fragt, warum man so was bringen sollte. Die Cores sollen ja nicht wahnsinnig groß sein. Also wird die CPU auch nicht sooo groß.

Ist durch FM3 ja auch bzgl Leistungsaufnahme begrenzt. Ich gehe mal nicht davon aus, dass das ein 140w Sockel ist.

8 Cores ist mehr als genug, wenn die "Core artig" sind.
Naja. Für den Wettstreit mit den kleinen Intel-CPUs vielleicht, aber nicht für E und EX. Da sieht man kein Land mehr.

FM3 wird ja sicher kein HT (what ever) bekommen. Also kein Multi-Sockel usw.

Da muss also klar noch ein weiterer Sockel her. Da hätte man sich meiner! Meinung nach den reinen CPU DIE auch gleich sparen können, und für die Enthusiasten eben die SErver-Sockel öffnen. Würde ich als sinnvoller ansehen.

[robbitop]

Naja. Für den Wettstreit mit den kleinen Intel-CPUs vielleicht, aber nicht für E und EX. Da sieht man kein Land mehr.


Dafür gibts dann MCM.

[Skysnake]

Und wie bindest du damit TB an RAM an ohne neuen Sockel?

[robbitop]

MCM benötigt einen eigenen Sockel. Siehe G34 etc.

Das hier waren consumer roadmaps.

[Sunrise]

Und außerdem hat AMD mehr Cores: Skylake hat 4+SMT, Zen hat 8+SMT.
Intel hat auch 8+SMT, auch für den Desktop.

[Unicous]

@Fudzilla Slide.

Warum widerspricht das dem slide? Der sagt lediglich up to 16 cores(32 Threads) und das Markt-Segment wird gar nicht genannt. Das wäre dann z.B. mit einem MCM-Package möglich.
Nicht das ich den slide verteidigen möchte, aber da ist mE erst einmal nicht widersprüchlich.

Was Fuad daraus macht ist eine ganze andere Sache.

Oder Nick Farrell

First Zen Chips will be Quad Core

:facepalm:

According to Techpowerup Zen scale up will stop at four cores sharing 8 MB of L3 cache and a set of four cores makes up what AMD calls a "quad-core unit." This is not a module, the cores share no hardware components with each other, besides the L3 cache.

[fondness]

Realistisch betrachtet muss man wohl sagen, dass es sich für AMD nicht lohnen wird eine 16 oder 32 Core CPU zu designen, auch wenn es technisch kein Problem wäre. Dazu sind die Stückzahlen vermutlich zu klein.

[y33H@]

Vor allem weil "Zen" kein Chip ist, sondern ne Architektur ...

[Unicous]

@fondness

Ersetze Cores durch Threads und gib einfach nichts auf Fuadzillas Ausführungen und Interpretationen.

[Ravenhearth]

Intel hat auch 8+SMT, auch für den Desktop.

Aber nicht in einem Mainstream-Sockel wie 1150 oder FM3.