AMD/ATI - Kaveri: 28nm, 2-4 Steamroller Kerne, GCN GPU - Ende 2013 [Archiv] - Seite 2

PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : AMD/ATI - Kaveri: 28nm, 2-4 Steamroller Kerne, GCN GPU - Ende 2013

Seiten : 1 [2] 3 4

AnarchX

2013-05-25, 12:57:10

Steamroller Kern Dieshot?
http://forum.beyond3d.com/showthread.php?t=63622

S940

2013-05-25, 13:33:46

Steamroller Kern Dieshot?
http://forum.beyond3d.com/showthread.php?t=63622
Weiss nicht, ich seh da nichts von der verdoppelten Sprungvorhersage. Das müsste oben links im Eck sein. Sieht alles so aus wie gehabt. Die 256bit FPU würde ich jetzt auch noch nicht erwarten ... Ich sage also mal vorsichtig: fake.
Edit: Wenn ich das richtig sehe, hat der "Künstler" den L1D auch verdoppelt, dafür hat er dann aber Flächen in der Modul-Mitte, an der "Spiegelachse" der beiden INT-Cluster gelöscht.

Skysnake

2013-05-25, 13:52:04

SavageX

2013-05-25, 13:58:44

Also ich glaub eher nicht, dass das ein Steamroller ist. Für mich sieht das mehr nach APU aus. Um genau zu sein nach einem Big-Little-Konzept :confused:

Hier mal die Einteilung, wie ich Sie vornehmen würde:

PS:
Nach "künsterlischen" Betätigung sieht das für mich eher nicht aus.

Tut mir leid, dieser Einteilung kann ich mich nicht anschließen. Ich zeichne gerade auf, wie ich es für möglich halte.

Skysnake

2013-05-25, 14:05:02

Dann mach mal ;)

Für mich sieht das auf jeden Fall nicht nach einer reinen CPU aus.

Je länger ich mir das anschaue, desto weniger glaube ich sogar, dass das überhaupt eine CPU ist.

Zumindest kommt mir kein einziger Teil wirklich bekannt vor, außer der Teil, den ich mit "L2/L3 Cache" gekennzeichnet habe.

Das sieht aus wie der von nem Jaguar.

SavageX

2013-05-25, 14:13:34

So, hier mein Wurf:

http://s15.postimg.org/x90z05dqf/steamroller.jpg (http://postimg.org/image/x90z05dqf/)

edit: Zum Vergleich die Struktur bei Bulldozer: http://logout.hu/dl/upc/2011-02/13063_amd-bulldozer-core-module.jpg

Über die Breite der FPU mache ich lieber keine Aussagen, sieht aber breiter aus.

edit2: Oh, und der unmarkierte Bereich in der linken oberen Ecke ist dann mit guter Wahrscheinlichkeit Fetch und Branch Prediction.

S940

2013-05-25, 14:15:09

Also ich glaub eher nicht, dass das ein Steamroller ist. Für mich sieht das mehr nach APU aus. Um genau zu sein nach einem Big-Little-Konzept :confused:
Hej neeee, da bist Du total auf dem Holzweg, vergleich doch mal mit nem aktuellen BD-Kern, da siehst Du, dass der Mittelteil fast identisch ist, das unten sind keine "Little Kerne", das ist nur die FPU, in dem eventuellen Fake schlicht kopiert und verdoppelt (wiewohl das beim K8 ->K10 FPU128 Upgrade die gleiche Vorgehensweise war, das könnte also stimmen).

Kannst das mal als Ausgangspunkt hernehmen:
http://www.planet3dnow.de/photoplog/images/54308/1_Vergleich_Vishera.png
Ne noch bessere Auflistung, was was ist, gibts hier:
http://pc.watch.impress.co.jp/img/pcw/docs/430/044/6.jpg
http://pc.watch.impress.co.jp/img/pcw/docs/430/044/7.jpg

Edit:
SavageX (http://www.forum-3dcenter.org/vbulletin/member.php?u=16522)' Version entspricht schön obigen Links. Da sieht man auch, dass die Sprungvorhersagen jeweils gleich groß sind. MMn eben ein Hinweis auf den Fake. Jetzt beim 2. Blick frag ich mich auch, wo die µcode ROMs hingekommen sind.

Skysnake

2013-05-25, 14:33:17

Ja, die Int-Cluster sehen schon sehr ähnlich aus. Das habe ich mir so auch durchaus gedacht, hatte auf die Schnelle nur die Detailansicht von nem Modul nicht mehr gefunden. THX für den Link.

Die FPU sieht aber komisch aus, genau wie der Bereich, den du als Decoder bezeichnest. Es fehlt dann halt schon noch sehr viel drum rum... Hab mich davon in die Irre leiten lassen -.-

Ich würde die FPU aber nicht wie du horizontal, sondern vertikal teilen.

Es sieht schon so aus, als ob der obere und untere Teil unterschiedlich sind.

Eventuell zwecks SSE <-> AVX

S940

2013-05-25, 15:14:53

Ich würde die FPU aber nicht wie du horizontal, sondern vertikal teilen.
Ja das sind jeweils die lower und upper half -Hälften. Die Architektur davon ist schon bekannt, ich glaube damals warst Du noch nicht dabei ;-)

http://pc.watch.impress.co.jp/img/pcw/docs/430/801/html/7.jpg.html
http://pc.watch.impress.co.jp/img/pcw/docs/430/801/9.jpg
http://pc.watch.impress.co.jp/docs/column/kaigai/20110304_430801.html
Extra für Dich auch auf Englisch ;-) :
To minimize bus lengths, the datapath is split into high and low halves (Fig. 4.5.4), each acting on 64 bits for AVX/SSE/MMX or 80 bits for X87 opera-tions. Four fully pipelined FMACs each support one EP/DP or two SP ops per cycle with 5-cycle latency to dependent ops. Optimized algorithms and dense, hand-placed datapaths minimize area, reduce cap and RC delay for timing, and reduce power. Extensive fine-grain clock gating allows FP to achieve an idle active power of less than 2% of peak active power. A 160-entry 10R/6W FP register file (FPRF) reads 2 or 3 sources for 4 instruc-tions, and writes up to 6 results, per cycle. The FPRF is split horizontally into two 10-bank arrays of 91 and 73 bits respectively. Each array aligns with a split FP datapath, and differs significantly from the replicated integer unit RF array design [3]. A flexible 2 and 3-level read bitline structure is used to reduce power and latency across the large data arrays (Fig. 4.5.5)
Es sieht schon so aus, als ob der obere und untere Teil unterschiedlich sind.
Hmm ok, ein paar Unterschiede seh ich jetzt doch, in der Mitte. Spräche jetzt eher für die Echtheit. FP256 ist ja angekündigt, aber da es dafür keine extra Scheduler oder Dispatch gibt, sollte es da in der Mitte Unterschiede geben. Schaut aber irgendwie komisch aus, Abschrägungen sind eher ungewöhnlich ...

Edit:
Hab jetzt noch ein besseres Foto der BD-FPU gefunden, das sieht doch nochmal anders aus, Du könntest mit der vertikalen Teilung recht haben, die Register wurden um 90° gedreht, wenn mans so grob sagen kann.

Edit2: Habs die BD-FPU mal kopiert und hochgeladen:
http://www.abload.de/img/bd-fpur5ud8.png

reaperrr

2013-05-25, 16:12:18

Edit:
SavageX (http://www.forum-3dcenter.org/vbulletin/member.php?u=16522)' Version entspricht schön obigen Links. Da sieht man auch, dass die Sprungvorhersagen jeweils gleich groß sind. MMn eben ein Hinweis auf den Fake. Jetzt beim 2. Blick frag ich mich auch, wo die µcode ROMs hingekommen sind.
Schau mal genauer hin. Der von dir gemeinte Sprungvorhersageteil hat sich bei dem vermeintlichen Steamroller sehr wohl vergrößert, nur noch oben hin statt in die Länge wie bei Trinity. Der Teil links vom L1I sieht nach doppelt so groß wie bei BD und 33% größer als bei Trinity-PD aus.

Der L1I-Cache sieht auch nach 96KB aus, wie in den Gerüchten. Der L1D nach 32KB, was auch Sinn macht, selbst die kleinen low-power Architekturen wie Bobcat, Jaguar, Silvermont haben heutzutage 32KB L1D-Cache je Kern.

Inst.Fetch scheint auch verdoppelt worden zu sein. Den µ-Op finde ich aber auch nicht.

S940

2013-05-27, 02:49:38

@reaperrr:
Ja Du hast recht. Ich dachte zuerst, dass die Bänke wg. der guten Auflösung nur doppelt ausschauen, bei ner schlechten / pixligen Abbildung aber so aussähen wir die 8 jetzigen Bänke. Aber stimmt wohl nicht, in dem Fall wären die mittleren Bänke dann doppelt so dick, sind sie aber nicht, ergo muss es so sein, wie Du sagst.

Ansonsten:
Auf P3D haben wir auch noch darüber spekuliert, gruffi hat doppelt soviele AGUs und ALUs ausgemacht, eventuell ein CMT-Ansatz auf ALU-Ebene, aber da ist noch viel Fantasie dabei ^^

http://abload.de/image.php?img=amd_steamroller_piledizjgg.jpghttp://abload.de/img/amd_steamroller_piledizjgg.jpg

(Wer sich im INT-Cluster nicht auskennen solltem das hier hilft:
http://www.abload.de/img/filexdbu4.jpg
)

Das würde dann 2 Threads pro Cluster bedeuten, damit müsste die FPU 4 Threads schaffen... schafft sie eventuell auch, zumindest wurden die Retirementkapazitäten auch verdoppelt:

http://www.abload.de/img/4retirecontrolufzpt.png
(unterer Ausschnitt ist spiegelverkehrt zum Orginal)

.. wenn ich das richtig sehe ^^

Lustig wärs allemal ... 4 Threads pro Model :freak:

Edit:
Deckt sich eingentlich alles mit dem Post bei B3D:
http://beyond3d.com/showpost.php?p=1740893&postcount=6
Leider zu spät gesehen, aber egal ^^

Skysnake

2013-05-27, 09:43:51

Warum geht ihr deswegen davon aus, dass das 2 Threads pro Int-Cluster sind?

Was spricht denn dagegen, das man einfach nur doppelt so breite Datenpfade zum Cache hat?

Und weil man eben nicht viel mehr Aufwand hat, wenn man die Zugriffe unabhängig macht, verdoppelt man die ALU/AGU s. Würde der IPC doch zugute kommen, und genau da hat AMD ja einiges an Dresche einstecken müssen.

Und muss die Retire Control nicht zwingend verdoppelt werden, wenn man die FPU-Breite verdoppelt, und eben NICHT wie bei Intel mit AVX nur gewisse Befehle zulässt, die die volle Breite nutzen.

Aktuell ist es ja so, das ein Int-Cluster maximal einen AVX Befehl absetzen kann, also quasi jeder Int-Cluster nur eine "halbe" FPU hat im Worstcase, und im Normalfall eine ganze, und im Bestcase eben eine doppelte FPU.

Jetzt wäre es halt Worstcase eine ganze (jeder kann immer einen AVX Befehl absetzen), im Normalfall eine doppelte, halt 2 SSE Befehle zu gleichen Zeit von jedem, und im Bestcase eine vierfache FPU :ugly:

Also zumindest ICH würde mir das genau so wünschen. So hatte ich es eigentlich schon für BD 1.0 erwartet und war ganz überrascht, das es eben genau so nicht war
EDIT:

Ok vergiss es, das ist ja nur der eine Teil der FPU. Hatte das Bild falsch in Erinnerung...

Ja, das sieht dann schon seltsam aus. Gibt ja eigentlich nichts, was an Kombinationsmöglichkeit nicht schon abgedeckt ist in der bisherigen BD FPU. Der Teil darunter sieht aber komplett anders aus....

Also eventuell doch, und man hat die Teile zusammen gefasst, weil man so besser prüfen kann, wer wo was machen muss. :confused:

An 4 Threads pro Modul kann und will ich nicht wirklich glauben. Die ST Leistung wird da dann sicherlich nicht steigen.

EDIT2:

Edit:
Hab jetzt noch ein besseres Foto der BD-FPU gefunden, das sieht doch nochmal anders aus, Du könntest mit der vertikalen Teilung recht haben, die Register wurden um 90° gedreht, wenn mans so grob sagen kann.

Edit2: Habs die BD-FPU mal kopiert und hochgeladen:
http://www.abload.de/img/bd-fpur5ud8.png
Ah... ;D
Das war mir ganz unter gegangen :biggrin:

Ja, das würde schon dazu passen, das man in den oberen Teil der FPU die gesamte Logik packt bzgl retire und eben 2 Threads quasi eine "komplette" FPU zur Verfügung stellt im Worstcase.

robbitop

2013-05-27, 11:00:20

An 4 Threads pro Modul kann und will ich nicht wirklich glauben. Die ST Leistung wird da dann sicherlich nicht steigen.

Naja, wenn man die Execution Ressources wirklich verdoppelt und sie per SMT nochmal aufteilen kann (also 2x CMT Cores, die jeweils per SMT gethreadded werden können), sollte das doch möglich sein.
Man gewinnt Singlethread Leistung, da mehr Execution Ressourcen pro Kern da sind und wenn man diese im Multithreadanteil noch höher auslasten kann (siehe Intel), steigert man auch die Modulauslastung damit.
Doppelt so viele Execution Units müssen ja auch ausgelastet werden können.

Klingt alles viel zu gut um wahr zu sein...

Ggü Bulldozer/Piledriver:
- 2x Int Ressourcen pro Modul
- 2x FP Ressourcen pro Modul
- 2x Decoder
- größerer L1i Cache (64 kib -> 96 kiB), größerer L1d Cache (16 kiB ->32 kiB)

Warum nicht gleich so? :)

Locuza

2013-05-27, 11:09:39

Und wie groß soll das ganze werden?
Oder spekuliert man auf die HD-Library?
Und die Fetch-Unit müsste ja auch ziemlich potent ausfallen, um ein Modul versorgen zu können.
Im SOG wäre doch auch etwas bei so großen Umbrüchen geleaked worden oder nicht?
Also ich halte noch Abstand von diesem Bild.

robbitop

2013-05-27, 11:15:37

Von nichts kommt nichts. AMD hat im Moment ~50 % IPC aufzuholen. Da heißt es klotzen statt kleckern. Das werden sie nicht aufholen - aber sie kommen von dieser niedrigen IPC bestimmt ein gutes Stück rauf. Mit Vishera war man immerhin wieder auf Deneb Leistung.

Skysnake

2013-05-27, 11:22:39

Naja, wenn man die Execution Ressources wirklich verdoppelt und sie per SMT nochmal aufteilen kann (also 2x CMT Cores, die jeweils per SMT gethreadded werden können), sollte das doch möglich sein.
Man gewinnt Singlethread Leistung, da mehr Execution Ressourcen pro Kern da sind und wenn man diese im Multithreadanteil noch höher auslasten kann (siehe Intel), steigert man auch die Modulauslastung damit.
Doppelt so viele Execution Units müssen ja auch ausgelastet werden können.

Wenn Sie SMT implementieren würden, was schwieriger als CMT ist, könnten Sie CMT auch gleich kicken... :rolleyes:

Ich seh da absolut keine Berechtigung mehr für CMT, WENN! Sie SMT schaffen zu implementieren.

Oder siehst du noch einen Sinn hinter CMT in diesem Fall?

Locuza

2013-05-27, 11:22:52

Und mit den Ressourcen die AMD hat reicht auch der vorgestellte Steamroller , um bei der IPC deutlich nach vorne zu hüpfen.
Aber der die-shot wirkt einfach insane.

robbitop

2013-05-27, 11:37:39

Wenn Sie SMT implementieren würden, was schwieriger als CMT ist, könnten Sie CMT auch gleich kicken... :rolleyes:

Ich seh da absolut keine Berechtigung mehr für CMT, WENN! Sie SMT schaffen zu implementieren.

Oder siehst du noch einen Sinn hinter CMT in diesem Fall?
Hat man für die FPU nicht bereits SMT implementiert? FPU wird geshared und Int ist doppelt vorhanden.

CMT schafft ja eine deutlich höhere Multithreadskalierung als SMT, kostet dafür aber auch mehr Transistoren, da man Ausführungsressourcen z.T. doppelt vorhällt.

Würde man die Kerne jetzt verdoppeln, würde sich doch SMT pro Kern anbieten. Oder meinst du, dass man dann in diesem Falle, den 2. Kern rausschmeißen sollte und lieber pro fettem Kern SMT betreiben sollte (analog zu Intel). Das sehe ich auch so.
Aber danach sieht der Die Shot ja nicht aus. Der sieht offenbar danach aus, dass man das Modul mit 2x Integerkernen beibehällt und diese jeweils breiter macht. Warum dann nicht diese per SMT auslasten? Wobei dein Argument, dass die Implementierung und Validierung von SMT extrem schwierig ist, ziemlich gut ist. Es ist ja nur eine Möglichkeit/Interpretation von vielen...

Skysnake

2013-05-27, 11:51:05

Genau deswegen. CMT ist halt einfacher zu implementieren und vor allem zu validieren. Vor allem wenns so flexibel wie bei Intel ist. Also echtes SMT und kein HT.

Es macht da einfach keinen Sinn mehr in meinen Augen CMT weiter zu führen.

Bzgl SMT<->FPU bei BD. Das ist relativ überschaubar, was es da an Kombinationsmöglichkeiten gibt. Vor allem berechnest du da keine Speicheradressen usw ;)

Das macht die ganze Sache deutlich schlanker und einfacher.

Jetzt stell dir das aber noch mit jeweils 2 Threads vor... Das ist dann am Ende NOCH komplizierter als Intels SMT Variante.

Wenn könnteste das gleich richtig machen, und nen wirklich fetten Core mit 4x SMT integrieren. Das wäre wohl auch nicht schwieriger als 2x2SMT + CMT.

Knuddelbearli

2013-05-27, 11:55:58

Wtf ein Modul mit 4 Threads das wäre wirklich abartig ^^

und ihmo nur sinnvoll wenn AMD glaubt demnächst sehr viele FPU sachen auf die iGPU auslagern zu können

Duplex

2013-05-27, 12:18:37

Wozu soll AMD SMT implentieren? Macht bei dem Design kein sinn.

Dann besser 4x Integer pro Modul + 4x 128 Bit FPU.

Bei Steamroller wurde hauptsächlich das Frontend aufgebohrt,

Steamroller 8 Threads > 8 Decoder
Bulldozer 8 Threads > 4 Decoder

In Multithreading skaliert CMT bei Steamroller besser als Bulldozer.

Zusätzlich wird das Cache System aufgebohrt und einige Latenzen werden verbessert.

Mehr würde ich nicht erwarten, immerhin kann man auf 15-20% +IPC hoffen.

Excavator wird wahrscheinlich nur ein DIE Shrink werden wie Agena auf Deneb mit Taktsteigerungen.

S940

2013-05-27, 12:37:57

Warum geht ihr deswegen davon aus, dass das 2 Threads pro Int-Cluster sind?

Was spricht denn dagegen, das man einfach nur doppelt so breite Datenpfade zum Cache hat?
Hmm ja gute Frage, eventuell "nur" AVX2? Da gibts dann ja 256bit INT-Befehle. Bin mir im Moment aber nicht mehr sicher, ob die nicht in der FPU ausgeführt werden würden, zumindest XOP war da in den MMX-Einheiten zuhause, wenn ich mich recht erinnere.
Außerdem bräuchte es dafür doch keine doppelte AGU, oder? Die Adressen werden ja nicht größer. Und die INT-Retirementresourcen wurden auch verdoppelt ...

An 4 Threads pro Modul kann und will ich nicht wirklich glauben. Die ST Leistung wird da dann sicherlich nicht steigen.
Ja, aber Serverhersteller könnten sich freuen ^^
Bei Opterons aktivierbar, beim FX ausgeschalten ...
Ja, das würde schon dazu passen, das man in den oberen Teil der FPU die gesamte Logik packt bzgl retire und eben 2 Threads quasi eine "komplette" FPU zur Verfügung stellt im Worstcase.Jo, aber am Beispiel auf B3D sieht man auch, dass man das Ganze auch leicht per copy/paste bekommen könnte ... da ist mal wieder Vorsicht angesagt.
Und wie groß soll das ganze werden?
Oder spekuliert man auf die HD-Library?
Ja die HD-Lib muss dabei sein. BIs auf die FPU unten und den I-Cache oben bleibt das Größenverhältnis eigentlich gleich. Trotz doppelten L1-D-Cache und mehr (doppelter) Retirement-Resourcen (auch in den INT-Cluster). Also irgendwas muss man da einsparen können ...
Ist aber natürlich auch ein starkes Argument für nen Fake ...

Und die Fetch-Unit müsste ja auch ziemlich potent ausfallen, um ein Modul versorgen zu können. Jupp sowieso. Aber nachdem sie die L1D-Caches auf 512bit aufbohren müssen, sollte das beim L1I-Cache auch kein Problem sein ... sprich: 2x32Byte Fetches pro Takt, statt bisher 1x. Das wäre eigentlich auch für 4 Threads notwending.

Im SOG wäre doch auch etwas bei so großen Umbrüchen geleaked worden oder nicht? Ja, aber wer sagt denn, dass das ein Steamroller ist, und kein Excavator? Die fette 256bit FPU wurde gerade erst ins CPUID-PDF aufgenommen, bis sowas dann kommt, dauert es normalerweise.
Also ich halte noch Abstand von diesem Bild.Ich auch, aber der Detailgrad ist schon ziemlich gut ... wie besagt, auch die INT-Cores haben ein doppeltes Retirement, da hat sich jemand schon sehr viel Mühe gegeben, wenns ein Fake sein sollte. So oder so scheint das Kerlchen aber auch mutig zu sein, nen Fake auf B3D zu posten ist nicht der einfachste Weg.

Es macht da einfach keinen Sinn mehr in meinen Augen CMT weiter zu führen.Auf B3D schrieb einer, dass 2x2 Threads statt 1x4 mit SMT einfacher zu verdrahten wären .. keine Ahnung, obs stimmt. Außerdem bräuchte man dann nen fetten 256bit-Quad-Port L1D-Cache, das würde eventuell auch schwieriger werden. Solange AMD Einheiten in lower/upper-half aufteilen kann hat der CMT-Aufbau eventuell seine Vorteile.

Jetzt stell dir das aber noch mit jeweils 2 Threads vor... Das ist dann am Ende NOCH komplizierter als Intels SMT Variante.
Hmm, wieso? Dein früheres Argument mit den Speicheradressen stämme doch immer noch:
Bzgl SMT<->FPU bei BD. Das ist relativ überschaubar, was es da an Kombinationsmöglichkeiten gibt. Vor allem berechnest du da keine Speicheradressen usw ;)
Oder nicht?

und ihmo nur sinnvoll wenn AMD glaubt demnächst sehr viele FPU sachen auf die iGPU auslagern zu könnenHmm .. nö, das hat damit nunmal gar nichts zu tun. Die FPU wird doch auf 2x256 (oder gar 4x128) groß getunt.

Wozu soll AMD SMT implentieren? Macht bei dem Design kein sinn. Das wäre kein SMT .. das wäre CMT auf ALU-Ebene. SMT verdoppelt keine Logikeinheiten. Möglicherweise sind die Einheiten zwar nur für AVX2 da, aber wenn man die dann sowieso schon doppelt hat, könnte man sich auch nen 2 Thread Betrieb vorstellen. AVX2-256 Befehle bräuchten dann im Multitthreadbetrieb zwar 2 Takte, aber dafür gäbs halt auch 2 Threads ...

Locuza

2013-05-27, 13:07:21

Ja, aber wer sagt denn, dass das ein Steamroller ist, und kein Excavator?

Ein Excavator Prototyp die-shot Anfang 2013 im B3D wäre aber auch eine Nuss.

S940

2013-05-27, 13:15:41

Ein Excavator Prototyp die-shot Anfang 2013 im B3D wäre aber auch eine Nuss.Würd ich nicht sagen, Steamroller sollte laut UR-Plan ja schon draußen sein. Hat sich halt nur verspätet. Dass das Excavator-Team deshalb extra auf die Bremse tritt, darf man nicht erwarten.
Ansonsten gäbs auch noch die Erklärung mit dem "Steamroller B" von Fuad... angeblich wurde der Steamrollerkern nachgebessert, das geleakte Architektur-PDF war aber noch für die alte Version ... für den Fall müsste man aber eigentlich davon ausgehen, dass Steamroller B == Excavator ist, mal schnell solche Änderungen in ein Design einzupflansten geht nich in ein paar Wochen.

Kurz: Es wäre Excavator, hieße aber trotzdem Steamroller.
(Oder es ist ein Fake, darf man wirklich nicht vergessen ^^)

robbitop

2013-05-27, 13:19:48

Um einen so guten Fake zu machen, muss man sich doch ziemlich gut mit CPUs auskennen oder? Vieles wirkt doch reichlich konkludent auf unsere Experten. Die Leute, die sich so gut damit auskennen und etwas draufhaben, sind idR nicht so bescheuert und faken.

Skysnake

2013-05-27, 13:23:40

Hmm ja gute Frage, eventuell "nur" AVX2? Da gibts dann ja 256bit INT-Befehle. Bin mir im Moment aber nicht mehr sicher, ob die nicht in der FPU ausgeführt werden würden, zumindest XOP war da in den MMX-Einheiten zuhause, wenn ich mich recht erinnere.
Außerdem bräuchte es dafür doch keine doppelte AGU, oder? Die Adressen werden ja nicht größer. Und die INT-Retirementresourcen wurden auch verdoppelt ...

Ja, AVX2 mit Erweiterung auf Integer ist durchaus eine Idee. Das könnte man so leicht abdecken und trotzdem die SingleThread-Leistung bei Integer-Code etwas steigern, da man eben mehr Ports bekommt.

Die doppellten AGUs brauchst du da je nachdem, wie AVX 2 aussieht durchaus. Du kannst ja im Prinzip beliebige Versätze einbeziehen. Dann musst du eben doppelte Adressen berechnen. Quasi dann sowas wie Instructionen packaging. Je nachdem, wie intelligent man den Decoder macht, könnte man das sogar für 0815 Code verwenden. Also quasi wie Superskalarität halt.

Also ich finde die doppelten AGUs jetzt nicht verwunderlich.

Ja, aber Serverhersteller könnten sich freuen ^^
Bei Opterons aktivierbar, beim FX ausgeschalten ...

Die Serverhersteller würden aber auch einfach die doppelte Anzahl an kleineren Chips nehmen :tongue:

Also MCM halt ;)

Jupp sowieso. Aber nachdem sie die L1D-Caches auf 512bit aufbohren müssen, sollte das beim L1I-Cache auch kein Problem sein ... sprich: 2x32Byte Fetches pro Takt, statt bisher 1x. Das wäre eigentlich auch für 4 Threads notwending.

An einen Fake glaube ich tendenziell eher auch nicht. Da müsste sich schon jemand SEHR viel Mühe gegeben haben.

Der aufgebohrte Fetch ist auf jeden Fall etwas, was BD gut tut.

Da machen die doppelten AGUs ja aber auch wieder sinn, oder nicht? Man muss/kann ja die doppelte Anzahl an Zugriffen bewerkstelligen, und braucht dafür eben auch die entsprechenden Adressen.

Zudem, war es nicht so, dass die AGUs nicht etwas aufgebohrt werden sollen/sind? Also wieder etwas mehr können sollen? Ich hab da irgendwas GANZ dunkel im Hinterkopf

Auf B3D schrieb einer, dass 2x2 Threads statt 1x4 mit SMT einfacher zu verdrahten wären ..

Ja durchaus, aber die Frage ist halt, was man spart. Wenn man den zweiten Core dafür komplett raushauen kann, und die Hauptarbeit eh schon erledigt hat damit, das man SMT überhaupt zum laufen bekommt, dann kann man auch gleich auf 4xSMT gehen, statt dann noch CMT dazu zu frickeln.

Der Nutzen sollte locker den zusätzlichen Aufwand rechtfertigen. Das Meiste hat man ja eh schon erledigt. Die ganze Validierung usw.

keine Ahnung, obs stimmt. Außerdem bräuchte man dann nen fetten 256bit-Quad-Port L1D-Cache, das würde eventuell auch schwieriger werden. Solange AMD Einheiten in lower/upper-half aufteilen kann hat der CMT-Aufbau eventuell seine Vorteile.

Das kann man zur Not auch bekommen, indem man bei SMT einige kleine Einschränkungen erstellt ;)

Hmm, wieso? Dein früheres Argument mit den Speicheradressen stämme doch immer noch:
Oder nicht?

Klar, aber CMT+2xSMT ist was GANZ anderes als reines CMT oder 4xSMT ;)

Wenn du den Aufwand mit SMT einmal anfängst, dann kannste es auch gleich mit 4x machen. Den "halben Weg" biste dann ja schon gegangen, wobei wohl eher 80%.

robbitop

2013-05-27, 13:28:40

Wenn es wirklich stimmen sollte und folgende Dinge kommen:

Ggü Bulldozer/Piledriver:
- 2x Int Ressourcen pro Modul
- 2x FP Ressourcen pro Modul
- 2x Decoder
- größerer L1i Cache (64 kib -> 96 kiB), größerer L1d Cache (16 kiB ->32 kiB)

Was sind denn dann noch die verbleibenden Flaschenhälse beim Bulldozernachfahren, die man noch erweitern müsste um einigermaßen aufschließen zu können? Schnellere Caches?

Knuddelbearli

2013-05-27, 13:38:57

ja Caches sind schon extrem lahm beim Bulldozer, gerade der L1 der für seine größe extremst langsam ist.

robbitop

2013-05-27, 13:54:48

Zumindest breiter ausgeführt werden diese bei AVX2 Unterstützung ja eh sein. Das bedeutet zumindest doppelte Bandbreite. Ist bezüglich Latenzverbesserung der Caches schon etwas angekündigt?

robbitop

2013-05-27, 13:59:49

Hans de Vries sagt, dass der Die-Shot aussieht, als wäre es keine Fälschung:

This seems quite legit and it's a big module indeed.... It seems many resources are doubled:
Floating point: dual 256 bit FMA instead of dual 128 bit FMA.
Integer: 8 ALU's and 8 AGU's instead of 4 both. Dual 32kB data caches instead of dual 16 kB.
Many other resources are also doubled like rename hardware and so on.

This is how I understand this design (on inf64's request):

The single Bulldozer decoder somehow couldn't handle 2 threads running
at 100% and for benchmarks we see at most a 50% performance increase
when the "second core" becomes active. So it doesn't work good enough
for CMT (but it's more than OK for dual threaded SMT)

Now why not double up the decoder and use the capability to decode
2 threads for SMT instead?

The dual 6 cycle 256 bit FMA FP units "cry out loud" for more threads,
they will be idle and unused otherwise for most of the cycles since you
need 2x6=12 FP operations to go on simultaneously to fully utilize them.
Even with 4 threads that's still 3 FP operations in parallel per thread.

The old 128 bit FMA units used the hardware more efficiently with two
cycles used per AVX operations but I guess one needs full 256 bit AVX
units to score well at these specially designed synthetic, but otherwise
pretty useless, benchmarks.

A single "Integer core" now has 4 ALU's and 4 AGU's which can improve
the integer performance somewhat, but not a lot. Actually I hope they
can still function as dual 2 ALU/AGU integer execution cores to support
4 threads in parallel. That would really help multithreaded performance,
and a little bit of the CMT ideas would survive.

Over time, in subsequent versions, they can now incrementally improve
single threaded performance using 4 ALU as much as possible. But even
then. Integer performance wasn't really Bulldozers problem as can be
seen in the Boinc Dhrystone benchmarks which showed a similar integer
IPC as the Athlon/Phenom cores (as long as the benchmark fits in L1D)

The L1D caches are doubled to 32kB to support 256 bit reads and writes.
A single cache line of 512 bit can now be read and written in a single
cycle freeing up cycles for more program reads and writes. The double
width also reduces bank conflicts.

This strategy to improve Bulldozer/Piledriver is pretty much as I would
have done it. I hope it's indeed AMD's way as well.

Hans.

http://semiaccurate.com/forums/showpost.php?p=184500&postcount=932

4x ALU + AGU pro Core sollten ohne Weiteres aber schwer auszulasten sein...

S940

2013-05-27, 14:06:16

Ja, AVX2 mit Erweiterung auf Integer ist durchaus eine Idee. Das könnte man so leicht abdecken und trotzdem die SingleThread-Leistung bei Integer-Code etwas steigern, da man eben mehr Ports bekommt.
Aber obs da mehr Ports gibt? Es gibt nachwievor nur 2 Registersätze, für die 2 Ports, sieht nicht so aus, als ob das größer werden würde. Unterschied wäre halt jetzt nur, dass man auf jedem Registersatz nen eigenen Thread laufen lassen könnte und der auch 2 ALUs/AGUs hat.

Die doppellten AGUs brauchst du da je nachdem, wie AVX 2 aussieht durchaus. Du kannst ja im Prinzip beliebige Versätze einbeziehen. Dann musst du eben doppelte Adressen berechnen. Quasi dann sowas wie Instructionen packaging. Je nachdem, wie intelligent man den Decoder macht, könnte man das sogar für 0815 Code verwenden. Also quasi wie Superskalarität halt.Naja, es gibt im MOment ja schon 2, aber 4 wär doch etwas viel, oder nicht? Dagegen wär im ALU-CMT-Fall wieder nur 2 pro Thread, wie jetzt auch schon.

Die Serverhersteller würden aber auch einfach die doppelte Anzahl an kleineren Chips nehmen :tongue:

Also MCM halt ;)
MCM ist mit dem ganzen Snoop-Gedöns und den langsamen HTr-Verbindungen auch nicht das Gelbe vom Ei.

An einen Fake glaube ich tendenziell eher auch nicht. Da müsste sich schon jemand SEHR viel Mühe gegeben haben.Ja, einerseits richtig, andererseits will er die Freaks bei B3D hinters Licht führen, da braucht er schon was Gutes ^^

Der aufgebohrte Fetch ist auf jeden Fall etwas, was BD gut tut.Naja, für 2 Threads reichen die 1x32Byte schon, 2x32 wären eigentlich nur bei 4 Threads schön. Mit AVX und FMA-Instruktionen spart man ja Instruktionen / Instruktionslänge ein.

Da machen die doppelten AGUs ja aber auch wieder sinn, oder nicht? Man muss/kann ja die doppelte Anzahl an Zugriffen bewerkstelligen, und braucht dafür eben auch die entsprechenden Adressen.
Jaja, für 4 Threads machen die Sinn, keine Frage ;-)

Zudem, war es nicht so, dass die AGUs nicht etwas aufgebohrt werden sollen/sind? Also wieder etwas mehr können sollen? Ich hab da irgendwas GANZ dunkel im Hinterkopf
Ja die AGLUs, die hatten wir hier auch erst vor Kurzem mal angeschnitten. Spräche dann eigentlich eher gegen das Bild. Die Idee der AGLUs ist ja, den AGUs ein paar ALU-Instruktionen zu übertragen. Das wäre eher das Gegenteil der jetztigen Kopieraktion.

Ja durchaus, aber die Frage ist halt, was man spart. Wenn man den zweiten Core dafür komplett raushauen kann, und die Hauptarbeit eh schon erledigt hat damit, das man SMT überhaupt zum laufen bekommt, dann kann man auch gleich auf 4xSMT gehen, statt dann noch CMT dazu zu frickeln.Naja, da gehts dann halt ans Detail, was genau ist die "Hauptarbeit"? Außerdem kopiert AMD vielleicht die ALU/AGUs, muss also nicht testen, wie es wäre, wenn 2 Threads parallel auf einer Einheit laufen würden und die 2 Register sind unabhängig voneinander (die brächte SMT allerdings auch), also eventuell ist das einfacher mit kopierten Exec-Units?

Das kann man zur Not auch bekommen, indem man bei SMT einige kleine Einschränkungen erstellt ;)
Dein Wort in Gottes Ohr ^^

Wenn du den Aufwand mit SMT einmal anfängst, dann kannste es auch gleich mit 4x machen. Den "halben Weg" biste dann ja schon gegangen, wobei wohl eher 80%.Naja, es wär aber halt kein SMT.AMD hat ja schon früh bemängelt, dass es schlecht für die Leistung ist, wenn Exec-Units gemeinsam benutzt werden würden. Mit dem Argument wäre ein dezidierte ALU/AGU-Pärchen pro Thread nur der nächste logische CMT-Schritt, nur ne Architekturebene tiefer.

Außerdem könnte man "historisch" Argumentieren und die HD-Libs heranziehen. Die ganze Entwicklung bei AMD ist ja eher ein gewursteltes Chaos. Die prüfen "Was haben wir, was können wir, was geht am schnellsten".
Im Moment, bzw. vor 1-2 Jahren war das:

BDv1-Design
HD-Libs
Intel mit der 256bit-Vorgabe

Was geht am schnellsten? Das wäre: Mit HD-Libs die Datenpfade zw. den Pipelinestufen eindampfen und den Platz für größere Caches und Einheiten verplanen. Eine große 256bit-FMA-FPU erfordert außerdem ne Verbreiterung an den Caches, wenn man das dann auch für die INT-Kerne ausnutzen will bieten sich dann auch 2 Threads pro-INT-Cluster an.

Ein 1x4-Design mit SMT wäre halt ein fast komplett neuer Ansatz gewesen, möglicherweise zu zeitaufwendig.

@Knuddelbearli:
ja Caches sind schon extrem lahm beim Bulldozer, gerade der L1 der für seine größe extremst langsam ist. Na mit 32kB wär das dann ok. L1-Latenzen ändert man nicht soo schnell, möglich, dass sie den schon von langer Hand mit nur 4 Takten Latenz geplant hatten um den Rest der Pipeline shcon mal darauf abzustimmen. So was triviales wie ne Cache-Vergrößerung beim nächsten Die-Shrink könnte man ja wirklich schon vorhersehen / einplanen.

Duplex

2013-05-27, 14:08:14

4 Fach Superskalär Design?
Wozu braucht man 4+4?

S940

2013-05-27, 17:51:55

4 Fach Superskalär Design?
Hört sich eher nach 2x2 an, nachdem ich nochmal im offiziellen BD-Paper nachgelesen habe:

The execution unit supports single-cycle operand bypass from an instruction to a dependent instruction. Two ALU ops and two AGU ops can be executed in a cycle. AGU ops include increment/decrement (INC), address generate, and x86-64 LEA instructions. The ALUs and the INC units participate in single-cycle operand bypass. Four result buses, one from each of the units, feed four writes ports into the PRF. Each execution unit can receive data from any of the four write ports or from a PRF read. Each execution unit has two sources, requiring eight read ports in the PRF. To remove wire delay (and congestion) from the critical bypass path, the PRF is duplicated. The register file is divided into halves; the critical half, further from the output driver, has fewer pull-downs on the local bitline, reducing slew rates on critical words with minimal area impact (Fig.4.6.6). Duplicating the INC removes the vertical wire delay from the worst-case bypass path, which is from any INC to the far ALU.
AGU und ALU müssen also in einer Linie sein, da sonst die Leitungslatenzen zu groß werden würden. Spricht demnach dafür, dass die erste AGU und erste ALU in einer Ebene zusammenarbeiten und die zweiten Units entsprechend. Da sind die Längen dann jeweils identisch. Aber für nen Ebenenwechseln sollte die Leitungen immernoch zu lang sein - außer den AMD-Ingenieuren ist irgendwas Cleveres in der Zwischenzeit eingefallen.

fondness

2013-05-27, 17:53:39

4x ALU + AGU pro Core sollten ohne Weiteres aber schwer auszulasten sein...

Ohne andere Verbesserungen bringt das gar nichts. Nichts ist leichter als mehr Einheiten zu verbauen, die Kunst liegt darin diese mittels ILP auszulasten.

S940

2013-05-27, 18:14:09

Ohne andere Verbesserungen bringt das gar nichts. Nichts ist leichter als mehr Einheiten zu verbauen, die Kunst liegt darin diese mittels ILP auszulasten.Ist wohl eher 2x2, siehe oben (die Postings haben sich wohl überschnitten).

Skysnake

2013-05-27, 18:14:44

Richtig, aber dazu braucht man auch genug Einheiten ;)

AVX2 auf integer gemünzt ist ja eine SEHR einfache Art, die IPC zu steigern. Der Code hat halt schon in sich die Parallelität.

Bzgl SMT:
SMT ist halt wirklich nicht so einfach. Du musst halte ALLE! Variationen abdecken, was wann wo und in jedweder Kombination schief gehen kann, und das muss dann auch noch alles mit den Timings passsen, damit due es eben nicht zu spät merkst, und dann nicht mehr rerollen kannst.

Ich würde in die vergrößerten Ressourcen auch wirklich nicht zu viel hineininterpretieren.

AMD setzt klar auf AVX(2) und FMA. Da bekommste sozusagen die Parallelität frei Haus geliefert. Du musst nur noch die Einheiten auch mit Daten versorgen, woran es ja bei BD durchaus hapert...

Wir sollten auch nicht ganz aus dem Hinterkopf verlieren, was Gustafson bzgl Doppelter Performance bei gleichem Verbrauch gesagt hat ;)

AMD geht mit BD hier praktisch den gleichen Weg wie Intel mit Larrabee. Extrem breite FPUs. Im Endeffekt sieht nen Integercore ja auch nicht so viel anders aus. Er kann jeweils 512 Bit Instructionen dann wohl abarbeiten, bzw halt 2x256Bit, wobei eben auch nur alle 2 Takte wie bei Larrabee ;)

Also auf mich wirkt das schon sehr sehr sehr ähnlich, nur halt mit mehr Takt und deutlich weniger parallelen Threads. Man setzt aber eben auch nicht auf den Monster-Decoder, wie es Intel bei den normalen CPUs macht. Der kann schon was reisen.

Wenn man böse wäre, könnte man sagen, es ist weder Fisch noch Fleisch. Man kanns aber auch einfach als Angleichung von CPU und GPU ISAs sehen, damit der Wechsel zwischen den Einheiten leichter funktioniert.

Mit HSA will man ja am Ende einfach wechseln können auf Grundlage von Hardwareentscheidungen.

Naja, schaumer mal. Aber 2xSMT+CMT halte ich für sehr unwahrscheinlich.

S940

2013-05-27, 18:39:53

Bzgl SMT:
SMT ist halt wirklich nicht so einfach. Du musst halte ALLE! Variationen abdecken, was wann wo und in jedweder Kombination schief gehen kann, und das muss dann auch noch alles mit den Timings passsen, damit due es eben nicht zu spät merkst, und dann nicht mehr rerollen kannst.
Ja, aber hier haben wir möglicherweise ja eben kein SMT.
Jeder Thread hat seinen eigenen Registersatz plus 2 eigene ALU+AGU.
Da gibts möglicherweise deutlich weniger Probleme und Testfälle. Scheduler und Retirement würde halt gemeinsam benutzt werden, aber das sollte eher unkritisch sein, oder?

Ich würde in die vergrößerten Ressourcen auch wirklich nicht zu viel hineininterpretieren.Naja, das ist relativ eindeutig je 2 gleiche Blöcke vor und hinter 2 Registersätzen, da gibts nicht sooviel Spekuspielraum, außerdem haben wir jetzt durch Hans de Vries Aussage ne gewisse Sicherheit. Falls Dir der Name nichts sagen sollte, von Ihm ist die K8-Übersicht hier:
http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html

AMD geht mit BD hier praktisch den gleichen Weg wie Intel mit Larrabee. Extrem breite FPUs. Im Endeffekt sieht nen Integercore ja auch nicht so viel anders aus. Er kann jeweils 512 Bit Instructionen dann wohl abarbeiten, bzw halt 2x256Bit, wobei eben auch nur alle 2 Takte wie bei Larrabee ;)
Lol ja, hatte LrB nicht auch Quad-SMT?

Wenn man böse wäre, könnte man sagen, es ist weder Fisch noch Fleisch. Man kanns aber auch einfach als Angleichung von CPU und GPU ISAs sehen, damit der Wechsel zwischen den Einheiten leichter funktioniert.
Naja, würd ich nicht sagen, das Ding ist schon ein verdammt Breites Design, über die Multithreadleistung sollte sich nicht beklagen können ^^
Naja, schaumer mal. Aber 2xSMT+CMT halte ich für sehr unwahrscheinlich.Nicht 2xSMT+CMT, eher CMT + CMT -1 :)

Skysnake

2013-05-27, 19:05:34

Ja, aber hier haben wir möglicherweise ja eben kein SMT.
Jeder Thread hat seinen eigenen Registersatz plus 2 eigene ALU+AGU.

hm...

Ach so meinst du das...

Halte ich dennoch für "gewagt", wenn auch möglich. Dann müsste man den bestehenden Decoder aber eigentlich auch verdoppeln, und danach siehts nicht wirklich aus.

Zudem hätte man eben praktisch nichts gewonnen. im Vergleich zu jetzt.

Da gibts möglicherweise deutlich weniger Probleme und Testfälle. Scheduler und Retirement würde halt gemeinsam benutzt werden, aber das sollte eher unkritisch sein, oder?

Wenn es quasi wie aktuell mit CMT üder die Integercores hinweg geht, dann ja. Ich seh dann aber nicht wirklich den Gewinn an dem Design. Du müsstest die Ressourcen ja wirklich dann wieder exklusib machen...

Ich würde dann eher sogar von einer nochmals sinkenden IPC ausgehen.

Naja, das ist relativ eindeutig je 2 gleiche Blöcke vor und hinter 2 Registersätzen, da gibts nicht sooviel Spekuspielraum, außerdem haben wir jetzt durch Hans de Vries Aussage ne gewisse Sicherheit. Falls Dir der Name nichts sagen sollte, von Ihm ist die K8-Übersicht hier:
http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html

Ja, ich kenn Hans de Vries :tongue:

Er spekuliert da aber auch. Vor allem kann man meiner Meinung nach, solche Sachen nicht einfach von nem DIE-Shot heraus lesen. Da dreht sich ja dann wirklich um die Art und Weise der Implementierung, und nicht um ganz fundamental unterschiedliche Sachen. Man kann es ja so und so rum verwenden.

Lol ja, hatte LrB nicht auch Quad-SMT?

Nein, Larrabee kann aus 4 Threads pro Takt eine Instruktion annehmen, wobei von einem Thread nur maximal jeden zweiten Takt eine Instruktion kommen darf. Mit nur einem Thread/Core läuft der Quasi nur mit halber Geschwindigkeit.

Ich würde das daher eigentlich nicht als SMT, sondern als HT bezeichnen, und das mit heftiger Einschränkung (alle 2 Takte)

Naja, würd ich nicht sagen, das Ding ist schon ein verdammt Breites Design, über die Multithreadleistung sollte sich nicht beklagen können ^^

Ja durchaus, aber wenn man sich anschaut, wie stark AMD mit den Opterons bei FPU Code war, dann ist BD ein Stillstand, oder gar Rückschritt. Gerade! bei AVX Code reist man ja nichts gegen nen SB-X/IB-X, einfach weil man die FPU zu klein gemacht hat...

BD von Anfang an mit doppeltet so breiter FPU wäre schon nen knaller gewesen für Leute, die ihren Code selbst compilieren, und daher eh nur einen Vorteil aus AVX ziehen können in absehbarer Zeit.

Nicht 2xSMT+CMT, eher CMT + CMT -1 :)
[/quote]
Da stellt sich einem dann aber die Frage, wie das mit nur so wenig mehr Ressourcen funktionieren soll, ohne das man bei ST einbricht, oder bei zwei Threads pro Integer-Core nur marginale Steigerungen hat.

An sich ne nette Idee, aber in meinen Augen einfach zu viel Aufwand. Man muss halt die komplette Kontrolllogik mit verdoppeln... Da doch dann lieber einem Thread mehr Ressourcen spendieren, und schauen das man den InstructionLevelParallelism steigert. Vor allem mit AVX2 bekommt man das ja wie gesagt teils umsonst.

Wir dürfen den Energiehunger von der Kontrolllogik nicht außer acht lassen!!! Wir sind ja eh! Powerlimited. Also warum Sachen soweit ausbauen, das man eh kaum Einsparungen hat. Da doch wirklich lieber über ILP gehen, das kostet keine zusätzliche Energie für die Kontrolllogik

S940

2013-05-27, 20:15:51

hm...

Ach so meinst du das...

Halte ich dennoch für "gewagt", wenn auch möglich. Dann müsste man den bestehenden Decoder aber eigentlich auch verdoppeln, und danach siehts nicht wirklich aus.
Ja gewagt durchaus, es ist schon ne "lustige" Idee ^^
Hmm.. der Decoder wird doch beim Steamroller verdoppelt, anstatt 1x4 gibts jetzt 2x4... da ist schon Platz für nen 2. Thread. Wenns jetzt zu +80% bei 2 Threads auf 2 Clustern gereicht hat, reichts erst recht für 2 CMT-1-Threads, die mit weniger eigenen Resourcen auskommen müssen.
Zudem hätte man eben praktisch nichts gewonnen. im Vergleich zu jetzt. IPC-mäßig nichts, Durchsatztechnisch einiges. Hatte schon Anfangs beim BD-Start gemeint, dass die IPC so sch....lecht ist (unter 1), dass da ohne größere Probleme eigentlich noch ein weiterer SMT-Thread laufen könnte, damit die 2 INT Pipes wenigstens mal 100% ausgenutzt werden würden :freak:

Jetzt mit doppelten L1 (Größe+Bandbreite) erst recht, denn durch die ganzen Verdopplungen bleiben unterm Strich die gleiche Ressourcen pro Thread über, wie jetzt auch schon.

Wenn es quasi wie aktuell mit CMT üder die Integercores hinweg geht, dann ja. Ich seh dann aber nicht wirklich den Gewinn an dem Design. Du müsstest die Ressourcen ja wirklich dann wieder exklusib machen...

Ich würde dann eher sogar von einer nochmals sinkenden IPC ausgehen.
Jupp, ist wohl wahrscheinlich, aber stark sollte es nicht ausfallen, es wird ja echt fast alles verdoppelt. Es sollte sich in Grenzen halten. Außerdem --wie schon vorher geschrieben -- man könnte das CMT-1 auch nur bei den Opterons freigeben und die FXe davon "befreien", da dort sowieso nur IPC interessiert. Andererseits ist DIE-Fläche bei den APUs aber knapp, bisher gibts da nur 2 Module pro APU, da wären dann 8 Threads doch nicht verkehrt.

Ja, ich kenn Hans de Vries :tongue:Lol, ok, sorry, war nicht böse gemeint, war mir halt nur nicht sicher, da das schon länger her ist :)

Er spekuliert da aber auch. Vor allem kann man meiner Meinung nach, solche Sachen nicht einfach von nem DIE-Shot heraus lesen. Da dreht sich ja dann wirklich um die Art und Weise der Implementierung, und nicht um ganz fundamental unterschiedliche Sachen. Man kann es ja so und so rum verwenden.Hmm was genau siehst Du kritisch? Wir können gerne diskutieren, wenn Du Zeit hast, dafür ist die SPeku-Ecke ja da :)

Nein, Larrabee kann aus 4 Threads pro Takt eine Instruktion annehmen, wobei von einem Thread nur maximal jeden zweiten Takt eine Instruktion kommen darf. Mit nur einem Thread/Core läuft der Quasi nur mit halber Geschwindigkeit.

Ich würde das daher eigentlich nicht als SMT, sondern als HT bezeichnen, und das mit heftiger Einschränkung (alle 2 Takte)Ok, das klingt dann doch etwas schräg ^^ Hab die Arch nur überflogen (und das ist auch schon länger her), das Einzige was ich mir gemerkt habe, waren die 4 Threads, danke für die Richtigstellung ^^

BD von Anfang an mit doppeltet so breiter FPU wäre schon nen knaller gewesen für Leute, die ihren Code selbst compilieren, und daher eh nur einen Vorteil aus AVX ziehen können in absehbarer Zeit.
Na komm, Leute die selbst compilieren, konnten sich doch auch über FMA4 freuen :)
Waren halt leider nicht soo viele :freak:

Da stellt sich einem dann aber die Frage, wie das mit nur so wenig mehr Ressourcen funktionieren soll, ohne das man bei ST einbricht, oder bei zwei Threads pro Integer-Core nur marginale Steigerungen hat.
Siehe oben, sooo wenig mehr Resourcen sinds ja nicht. Die Decoder sind doppelt, die L1D-Größe ist doppelt, die L1D-Bandbreite ist doppelt, die Sprungvorhersage ist doppelt ...
An sich ne nette Idee, aber in meinen Augen einfach zu viel Aufwand. Man muss halt die komplette Kontrolllogik mit verdoppeln... Da doch dann lieber einem Thread mehr Ressourcen spendieren, und schauen das man den InstructionLevelParallelism steigert. Vor allem mit AVX2 bekommt man das ja wie gesagt teils umsonst.Ja, aber bis AVX2 genutzt wird vergeht viel Zeit ;-)
Der Aufwand ist nicht gering, aber dafür ist das Design einfacher als SMT zu testen, ist halt mal wieder der berühmte Trade-Off zw. Flächenverbrauch und Hirnschmalz. Wenn zusätzlich noch ne bessere Leistung als bei SMT in Aussicht steht (da man eben mehr Logik kopiert), könnte es sich unterm Strich rentieren.
Wir dürfen den Energiehunger von der Kontrolllogik nicht außer acht lassen!!! Wir sind ja eh! Powerlimited. Also warum Sachen soweit ausbauen, das man eh kaum Einsparungen hat. Da doch wirklich lieber über ILP gehen, das kostet keine zusätzliche Energie für die KontrolllogikJa Power ist wichtig, ohne Frage, aber da sehe ich dann eher Vorteile bei dem Ansatz, zumindest aus Multithreaded-/Durchsatz-Sicht.
Die Opterons takten so schon nur im 3 Ghz-Bereich, damit die vcore nicht so hoch angesetzt werden muss. Wenn da jetzt ein ALU/AGU-Pärchen mehr schaltet, fällt das nicht großartig ins Gewicht. Wenn dafür aber mal so 50-60% (ich mittel da jetzt einfach mal grob zw. den ~30% bei SMT und den ~80% bei CMT) mehr Leistung rausspringt (bei idealen Tests, z.B: SpecINTRate oder sowas), dann rentiert es sich eben.

Wenn man da noch weiter denkt, könnte man es auch unter AMDs zukünftiger Bulk-Strategie einordnen. Bisschen weniger Taktspielraum, dafür ein breiteres Design. IPC ist wahrscheinlich immer noch nicht so doll (aber m it abgeschaltenem CMT-1 sollte durch die größeren Caches etc. auch da was hängenbleiben), aber dafür qualmen bei mehreren Threads dann die Reifen ^^

Interessant wäre noch der Die-Flächenbedarf. Sooviel größer schaut das im Verhältnis ja nicht aus. Flächenfresser sind v.a. die doppelte FPU und der große L1I-Cache. Sagen wir mal ~360mm² für nen hypothetischen Orochi mit Steamroller, wär doch ok, für dann 16 Threads :freak:

Frag mich auch noch welche Flags bei den CPUID-Bits pro Modul gesetzt werden sollten, 4fach SMT? Die beste Option wäre wohl dualcore mit 2fach SMT, aus L1D-Sicht immerhin korrekt ^^

Skysnake

2013-05-27, 22:13:26

Ich geh jetzt mal nicht direkt einzeln drauf ein, sonst wird das ne WOT ;D

Reicht aber allgemein auch sehr gut ;)

Also:
Ich glaub du hast nicht ganz verstanden, was ich meinte mit "wir sind power limited". Wenn du SMT odt CMT-1, oder wie auch immer du es nennen willst verwenden, dann hast du sehr viel mehrfach ausgelegt, was Strom frisst. Im Single-Threadbetrieb pro Modul gewinnst du dadurch nichts. Erst wenn du auf JEDEM! Intergercore dann eben 2 Threads laufen lässt. Bei nem Opteron bisst du dann bei 16-32 Threads, und das nur bei Single-Sockel. Eher sogar bei 32-64 Threads.

Gleichzeitig darfst du aber nicht im Übermaß AVX usw einsetzen, mit dem ja glänzen kannst, weil die Ressourcen dafür dann eben doch wieder nicht ausreichen.

Du hast also maximalen Verwaltungsaufwand, und damit Powerconsumption, um bereits gut parallelisierte Programme zu beschleunigen.

Warum sollte ich das machen?

Warum nicht den Verwaltungsapperat "schlank" halten, und wenn, etwas die Single-Thread IPC steigern, und dann eben den "MutliThread"-Leistung der ISA überlassen.

Da wo man wirklich so viel Leistung braucht, spricht auch oft nichts gegen ein Neucompilieren.

HOT

2013-05-27, 23:50:30

Nur mal als Einwurf: AMD sprach im Zusammenhang von Steamroller immer von "mehr Multithreaded-Leistung". Jetzt wird langsam klar, warum. Singlethreaded bringt das Ganze sicherlich auch was, aber der große Wurf dürfte dann bei 8 Threads und 2 Modulen landen. Für AMD ist das ein gewaltiger Gewinn, weil man im Consumer-Bereich einen 2-Moduler als 8-Kerner verkaufen kann und trotz des aufgeblähten Moduls dank RCM, HD-Libs und kleinerer Fertigung weniger Stromverbrauch hat - man spart Module! Wir haben bei den P3Dnow!-Tests gesehen, dass die Module bis zu 90% mehr Leistung bei 2 Threads herausholen, jetzt nochmal 40-60% dank mini-CMT (sind ja auch mit Recheneinheiten unterfüttert, ist also definitiv kein SMT) reicht aus um bei 8 Threads noch tauglich zu sein. Der Gewinn für quasi nix ist dann beachtlich.

S940

2013-05-27, 23:56:24

HOT

2013-05-28, 00:00:19

S940

2013-05-28, 00:22:10

Ach ja noch was was mir auffiel. Die Fetch-Einheit fehlt auf dem Die-Plot. Da man ganz rechts am Rand erkennt, dass der L2 im Vergleich zum Modul geschrumpft ist von der Höhe her ergibt sich über dem L2 Platz. Ich nehme an, dass die Fetch-Einheit da hingezogen ist.

Hmmm ne, wieso fehlt die? Das sind doch die 2x4 kleinen Würfeltürmchen über dem L1I-Cache, links und rechts über der pinken Mitte.

Wo beim BD die Fetch Einheit war, weiss man ja seit der Übersicht ( hier oben im Bild):
http://www.abload.de/img/filexdbu4.jpg

Jetzt halt auch doppelt ...

robbitop

2013-05-28, 09:13:22

Ist wohl eher 2x2, siehe oben (die Postings haben sich wohl überschnitten).
2x2 haben wir doch schon heute - pro Modul. Wäre das dann 2x2x2? Also 4x2 also 4 Threads mit je 2x INT?

Skysnake

2013-05-28, 09:39:19

Lol, ja mir kams auch "etwas" lang vor nach dem posten ^^

Das mit der Power Consumption war mir allerdings klar, wo hast Du denn rausgelesen, dass ichs nicht verstanden hätte?

Ich steh auf dem Standpunkt, dass ein Kern/Modul gerne Strom saufen darf, solange die Leistung genauso üppig ausfällt. Solange mans mit dem Takt nicht übertreibt hat man da sicherlich kein Verbrauchsproblem, soviel ziehen die kleinen ALUs auch wieder nicht, die haben nur ein paar Transistoren. Wenn sie nichts machen werden sie powergated, wobei sich die Leakage wg. der geringen Transistorenzahl ebenfalls in Grenzen hält.

Nein, du hast es leider nicht verstanden ;)

Ein Grund, warum GPUs so effizient sind, ist darin begründet, dass Sie DUMM sind, und verdammt schlecht mit Code umgehen können, der eben nicht geradlienig ist. Insbesondere spart man sich eben den Verwaltungsaufwand für ~63 Threads und dupliziert die Information des einen einfach nur.

Und die ganze Steuerungslogik sind nicht nur mal ein "paar" Transistoren, sondern ziemlich viele, und die kannst du auch nur sehr schwer abschalten. Die müssen ja komplett! laufen, so lange der Core läuft...

Du brauchst es ja, um alle Eventualitäten ab zu fangen.

Zu AVX sagte ja Hans de Vries, dass die FPU für 4 Threads locker leicht ausreicht, da muss/kann jeder Thread immer noch mit drei AVX256/FMA-Instruktionen ankommen, das reicht und da limitiert nichts. Falls Du da irgendwo bedenken hast, sag einfach :)

Klar "langt" es, aber "will" ich das auch?

Das ist ja der springende Punkt, auf den ich hinaus will. Klar, mehr Threads geben dir mehr Flexibilität, aber du gewinnst bei CMT Designs nichts hinzu. Du treibst viel Aufwand, und könntest am Ende auch mehr oder weniger einfach das gesamte Modul duplizieren. Klar, das ist wirklich der einfache Weg, aber du hättest Ressourcen für andere Sachen frei.

Voll INT und volle FP-Last schafft eigentlich keinen "echtes" Programm, das schaffen höchstens Power-Virus-Programme.

Das hat nichts zwingend mit "volle Int-+FP-Last" zu tun. Das hat schon auswirkungen auf den Turbo usw usw. Wir haben einfach das Problem, dass du nur teile vom Chip anknipsen kannst, sonst schmilzt dir das Ding, oder die Bumps einfach weg.

Energie sparen -> schneller rechnen.

Und genau DA liegt der Knackpunkt. Wenn du mehr Threads nimmst, mit dem gleichen Verwaltungsaufwand, dann sparst du nicht viel Strom, wirst also nicht viel schneller. Du kannst höchstens niedriger takten und damit dann weniger Spannung ansetzen. Das wars dann aber auch.

Wenn du aber auf den zusätzlichen Thread verzichtest, und die Parallelität in die ISA packst, dann steht das Zeug zwar dumm rum, wenns nicht genutzt wird, du kannst es aber power Gaten zum Teil, was dann Strom spart, und du hast noch die vergrößerten Ressourcen, die dir mehr IPC bringen für den einen Thread, woran AMD ja eh knappert, und wenn alles verwendet wird durch die bessere ISA, dann verbraucht man durch die fehlende Kontrolllogik eben Strom, was man in mehr Takt umsetzen kann. Man ist unterm Strich also schneller.

Weil 2 256bit AVX Threads besser sind als einer?

Weil?

Zudem solltest du sagen 4 256 Bit AVX Threads. Du kannst je takt mehr Absetzen durch die Threads theoretisch als du Ressourcen hast. Daher wirst du nicht schneller sein.

Wie besagt, mit einem Thread lastest Du die Riesen-FPU normalerweise nicht aus.

Die Leute, die AVX/FMA usw nutzen, die schaffen das, keine Sorge ;)

Wenn doch, dann ist der Code derart parallel, dass er bei ner APU gleich besser im GPU-Teil berechnet wird.

Ja, APUs sind da durchaus interessant, aber es gibt Sie eben noch nicht, und man hat eben den größeren Programmieraufwand. HSA funktioniert ja noch nicht mit nativen C....

Und so lange DAS der Fall ist, wird es noch genug Leute geben, die die reine CPU vorziehen. Zudem muss man sich anschauen, wie viele Branches usw der Code hat. Je nachdem kann die flexibler agierende CPU da dann doch noch besser sein. Aber ja, es gibt Überschneidungen im Einsatz.

Inzwischen finde ich diese Zweigleisigkeit aber gar nicht mehr soo schlecht. Die Softwareebene entwickelt sich einfach enttäuschend :(

Und Intel zieht mit XeonPhi halt das Software-Ass aus dem Ärmel

Irgendwo gabs mal ne Kennzahl, dass selbst FPU-lastige Programme ~x% INT Code haben, ich glaube das waren so 30%, aber kann mich echt nicht mehr richtig erinnern. Wie dem auch sei, das bisschen IntCode ist dann perfekt für CSMT (nennen wirs mal so, dass -1 sieht auf die Dauer doof aus ^^)

Ist apriori erstmal egal.

Und es kommt schon einiges an Int meist rein, einfach durchs hochzählen des Schleifenzählers usw ;)

Mehrsockelsysteme sterben bei AMD mittelfristig sowieso aus, von daher würde es schon passen.

NOT!

Sorry, aber das ist Schwachsinn...

Die 8 Sockel-Systeme "sterben" langsam aus, aber die waren eh nie DIE Verkaufsschlager, sondern die 4 Sockel, welche immer mehr durch 2 Sockel-Systeme zurückgedrängt werden.

Die Dual-Sockel und auch die Quad-Sockel brauchst du aber auch in Zukunft noch. Es gibt einfach genug Leute, die Speicher brauchen, und zwar VIEL Speicher. Gerade wenn du an Hanna von SAP usw usw denkst, dann wird sich das auch nicht so schnell ändern. Ganz im Gegenteil, mit BigData wird es eher noch mehr zunehmen, das man den maximalen Speicherausbau haben will, und wenn du aus einer Kiste raus musst, um auf einen Speicherbereich zugreifen zu können, dann wird es eben lllllllllllllllllllllllllllllllaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaannnnnnnnnnnnnn nnnnnnnnnnnnnnnggggggggggggggggggggggggggggggggggsssssssssssssssssssssssssssaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaammmmmmmmmmmmmmmmmmm (im Normalfall, wenn man nicht ein paar ganz fancy Sachen macht ;))

Aber das kostet dann so viel, dass du da auch wieder gern ein Dual-Sockel System nimmst.

Also Multi-Sockel stirbt garantiert nicht so schnell aus. Eher im Gegenteil, die Custom-Boards mit >4 Sockeln werden in Zukunft eher wieder stellenweise zunehmen, wobei das dann eher als Cluster in a Node laufen würde. Halt wie SeaMicro.

Das Fette ist eventuell auch AMDs problem .. einfach mal single thread IPC steigern ist nicht so einfach. Mehr Threads ist halt die Quick- und Dirty-Lösung.

Klar ist das nicht einfach, aber Sie tun ja auch wirklich viel, um das zu schaffen ;)

S940

2013-05-28, 17:19:14

@robbitop (http://www.forum-3dcenter.org/vbulletin/member.php?u=1008):
Sagen wir einfach 4 Threads pro Modul ^^
Eventuell war ich da gerade aus dem Kontext, welchen Sachverhalt da gerade diskutiert wurde. Ich dachte Ihr meint die Threads, da gibts aktuell ja nur 2x1.

Nein, du hast es leider nicht verstanden ;)

Ein Grund, warum GPUs so effizient sind, ist darin begründet, dass Sie DUMM sind, und verdammt schlecht mit Code umgehen können, der eben nicht geradlienig ist. Insbesondere spart man sich eben den Verwaltungsaufwand für ~63 Threads und dupliziert die Information des einen einfach nur.

Das ist ja schön und gut, aber so kann man halt nicht immer programmieren.
Versteh ich Dich jetzt recht, dass Du die komplexe Steuerlogik angreifst, weil man dank AVX(2) auch bei x86 relativ "dumm" programmieren könnte?

Das mag sein, aber das geht halt auch nicht immer ... AMD hat bei GCN ja auch skalar-Einheiten eingebaut. Die 2 Methoden verschmelzen halt immer mehr, eben weils generell nicht möglich ist perfekten seriellen oder perfekten paralleln Code zu schreiben.

Und die ganze Steuerungslogik sind nicht nur mal ein "paar" Transistoren, sondern ziemlich viele, und die kannst du auch nur sehr schwer abschalten. Die müssen ja komplett! laufen, so lange der Core läuft...
Na BD hat doch 30.000 Clock-gates, da würde ich eher behaupten wollen, dass das deutlich feiner vonstatten geht, als Du es Dir vorstellst.

Außerdem dürfen wir nicht vergessen:
So wie das Design jetzt ausschaut, wird da nichts hinzugefügt, sondern ersetzt, bzw. Transistoren werden wg. der HD-Libs eingespart. In dem FPU-Teil-Beispiel, dass AMD präsentiert hatten, sprachen sie nicht nur von Platz-Einsparung sondern auch von Verbrauchseinsparung. Gut möglich also, dass sie das Eingesparte einfach re-investiert haben.

Das ist ja der springende Punkt, auf den ich hinaus will. Klar, mehr Threads geben dir mehr Flexibilität, aber du gewinnst bei CMT Designs nichts hinzu. Du treibst viel Aufwand, und könntest am Ende auch mehr oder weniger einfach das gesamte Modul duplizieren. Klar, das ist wirklich der einfache Weg, aber du hättest Ressourcen für andere Sachen frei. Naja, da ist der Kasus Knacktus ja, dass AMDs aktuelles Die-Größe/Leistungsverhältnis total mies ist. Wenn man da nur Module dupliziert, wirds nicht besser. Man muss an die µArch ran. So wies ausschaut ändert sich die Die-Größe nicht großartig, bisschen mehr, mehr nicht. Dafür steigt die IPC, und v.a. die mth-Leistung deutlich an. Unterm Strich würde es ein deutlich besserer Chip werden. (Falls alles stimmt ^^).

dass die FPU für 4 Threads locker leicht ausreicht, da muss/kann jeder Thread immer noch mit drei AVX256/FMA-Instruktionen ankommen, das reicht und da limitiert nichts.Klar "langt" es, aber "will" ich das auch?Willst DU nur einen Thread laufen lassen, kannst Du das auch machen, aber dann liegen halt 75% der Leistung auf der Straße ... Wenn man sich nen Porsche kauft, kauft man den gemeinhin nicht für die Spielstraße ^^
Wenn Dein Code besser auf ner GPU läuft, dann kauf Dir ne GPU :)
So wies ausschaut sieht AMD aber noch genug Nachfrage nach so nem CPU-Kern, sonst würden sies ja nicht machen :)

Das ist ja der springende Punkt, auf den ich hinaus will. Klar, mehr Threads geben dir mehr Flexibilität, aber du gewinnst bei CMT Designs nichts hinzu. Du treibst viel Aufwand, und könntest am Ende auch mehr oder weniger einfach das gesamte Modul duplizieren. Klar, das ist wirklich der einfache Weg, aber du hättest Ressourcen für andere Sachen frei.
Welche Ressourcen genau meinst Du genau? Die-Fläche/Stromverbrauch/Xy, alles zusammen? Läuft im Endeffekt wieder auf das µArch-Argument raus, so wies im Moment ist, ist BD für die gebotene Leistung einfach zu groß. Und auch gilt wieder der Hinweis von oben mit den HD-Libs, eventuell gibts die zusätzlichen Einheiten für lau.

Performance
Das hat nichts zwingend mit "volle Int-+FP-Last" zu tun. Das hat schon auswirkungen auf den Turbo usw usw. Wir haben einfach das Problem, dass du nur teile vom Chip anknipsen kannst, sonst schmilzt dir das Ding, oder die Bumps einfach weg.Naja, dann eben weniger Vcore und Takt. Ein fettes Design auf die Beine zu stellen, und es dann nur zur Hälfte auszulasten wär ja mal wirklich selten doof. Stattdessen könnte man dann gleich ein paar Jaguarkerne verbauen.

Energie sparen -> schneller rechnen.

Und genau DA liegt der Knackpunkt. Wenn du mehr Threads nimmst, mit dem gleichen Verwaltungsaufwand, dann sparst du nicht viel Strom, wirst also nicht viel schneller. Du kannst höchstens niedriger takten und damit dann weniger Spannung ansetzen. Das wars dann aber auch.

Wenn du aber auf den zusätzlichen Thread verzichtest, und die Parallelität in die ISA packst, dann steht das Zeug zwar dumm rum, wenns nicht genutzt wird, du kannst es aber power Gaten zum Teil, was dann Strom spart, und du hast noch die vergrößerten Ressourcen, die dir mehr IPC bringen für den einen Thread, woran AMD ja eh knappert, und wenn alles verwendet wird durch die bessere ISA, dann verbraucht man durch die fehlende Kontrolllogik eben Strom, was man in mehr Takt umsetzen kann. Man ist unterm Strich also schneller.Power-Gaten geht nicht so einfach wie clock-gaten, meistens geht das nur auf Kern-Ebene, bei AMD kann man z.B. nur ein komplettes Modul powergaten. Da wir hier aber von der µArch sprechen, die innerhalb des Kerns ist, passt das Argument nicht. Oder meinst Du Clock-gaten? Ja das ginge, aber man designt doch keine Arch, dass was "dumm herumsteht". Außerdem ist das wieder ne Sache von ILP <> TLP. AVX bringt Dir nur was bei ILP, threads eben auch bei TLP.

Zusammenfassend muss man anerkennen, dass ein µArch-Design immer die Quadratur des Kreises ist. Man will möglichst alle Programmeventualitäten schnell bearbeiten können, dabei aber möglichst wenig Die-Fläche und Strom verbraten.
Du scheinst eher von perfekten Parallel-Code auszugehen, da wäre natürlich eine GPU super, oder halt ein schlanker single-core mit AVX. Aber es gibt halt noch andere Anwendungsfälle.

Inzwischen finde ich diese Zweigleisigkeit aber gar nicht mehr soo schlecht. Die Softwareebene entwickelt sich einfach enttäuschend :(
Jupp ist leider immer so ... erst recht wenn was von AMD kommt. Intel ist da deutlich professioneller, aber die haben halt auch das Festgeldkonto dazu :(
AMD kann sich nicht mal Linuxprogrammierer leisten :freak:

NOT!

Sorry, aber das ist Schwachsinn...Nö, schau Dir die AMD-Roadmap an ... das ist trauriger Fakt. Eventuell haben wir auch ein Mißverständnis, Seamicrosysteme ordne ich unter 1P-Systeme ein.

Die 8 Sockel-Systeme "sterben" langsam aus, aber die waren eh nie DIE Verkaufsschlager, sondern die 4 Sockel, welche immer mehr durch 2 Sockel-Systeme zurückgedrängt werden.
Merkste da was? Die 8sockel wurden durch 4 sockel verdrängt und die 4 Sockel durch 2? Wo das wohl enden wird ... ^^

Ganz im Gegenteil, mit BigData wird es eher noch mehr zunehmen, das man den maximalen Speicherausbau haben will, und wenn du aus einer Kiste raus musst, um auf einen Speicherbereich zugreifen zu können, dann wird es eben langsam (im Normalfall, wenn man nicht ein paar ganz fancy Sachen macht ;))
Möglich, aber ob das System von AMD kommt ... ist die Frage. Soviel Bigdata-Fälle gibts ja auch nicht. Großkonzerne halt, aber wieviel McDonalds, UPS, Apples etc. gibts denn? Sagen wir mal 10.000. Das wär noch ein gutes Geschäft, aber blöderweise gibts da noch so ne Firma namens Intel... und Oracle und IBM werden in dem Bereich auch noch ein Wörtchen mitreden wollen ...
Der RAM-Kohärenz-Dampfer ist bei AMD seitdem abgefahren, seit sie Seamicro gekauft haben und Intel den Cray-Interconnect übernommen hat.

Also Multi-Sockel stirbt garantiert nicht so schnell aus. Eher im Gegenteil, die Custom-Boards mit >4 Sockeln werden in Zukunft eher wieder stellenweise zunehmen, wobei das dann eher als Cluster in a Node laufen würde.Multi-Sockel generell nicht, aber Multisockel von AMD. In Zukunft wirds da nur noch Seamicro1P-Nodes geben.

Noch was anderes (in Fett, damits nicht untergeht):
In nem anderen Forum hat einer angemahnt, dass das mit 2 Threads pro INT-Cluster Käse wäre, da die Register dafür nur ungenügend Read/Write-Ports hätten. Kann das jemand einschätzen? Hört sich erstmal plausibel an.

Nakai

2013-05-28, 17:31:24

Skysnake

2013-05-28, 19:01:56

Das ist ja schön und gut, aber so kann man halt nicht immer programmieren.
Versteh ich Dich jetzt recht, dass Du die komplexe Steuerlogik angreifst, weil man dank AVX(2) auch bei x86 relativ "dumm" programmieren könnte?

Naja, überleg mal.

Du hast in nem Opteron 16 Threads, die 16 SSE Instruktionen pro Takt absetzen können. Mit dem Aufbohren auf 2x256 Bit FPUs, kannst du dann 32 SSE Instruktionen pro Takt absetzen, und das jetzt mal auf Single-Sockel gerechnet. Bei ner normalen Dual-Sockel-Maschine haste schon 64 SSE-Instruktionen pro Takt. AVX sinds noch immer 32, macht aber im Prinzip nichts aus. Es sind dann halt 128! Double-Instruktionen pro Takt, und das jetzt ohne FMA. Wenn man das noch rein nimmt, sollte man bei 256 Ops pro Takt landen :ugly:

Und wir gehen jetzt mal nicht davon aus, dass das <20% vom Code ausmacht. Ansonsten würde man sich nämlich gar nicht den Stress machen, da anzufangen die Befehlssatzerweiterungen zu verwenden.

Warum willst du also bei einem derartig hohen Parallelitätsgrad dann noch mehr Threads?

Das bringt dir nur im SSE Fall etwas, im AVX Fall rein gar nichts, weil du ja theoretisch die FPU auch schon so auslasten kannst.

Das würde ja eher nur Sinn machen, wenn ich mehrere Programme parallel laufen lasse, die eben nicht so viel Leistung brauchen. Was AMD der Ansatz gebracht hat, sehen wir ja mit CMT. Sie haben im Servermarkt Boden verloren.

Deswegen wirklich meine ernst gemeinte Frage, warum denkst du, dass man die doppelte Anzahl an Threads wirklich braucht?

Das mag sein, aber das geht halt auch nicht immer ... AMD hat bei GCN ja auch skalar-Einheiten eingebaut. Die 2 Methoden verschmelzen halt immer mehr, eben weils generell nicht möglich ist perfekten seriellen oder perfekten paralleln Code zu schreiben.

GCN ist ein GANZ anderes Thema. Die Skalarunit kannst du nicht mit dem einer CPU vergleichen. Das sind schon zwei paar Stiefel.

Na BD hat doch 30.000 Clock-gates, da würde ich eher behaupten wollen, dass das deutlich feiner vonstatten geht, als Du es Dir vorstellst.

Ok, hatte jetzt nicht erwartet, dass das sooo viele sind inzwischen.

Man sollte aber nicht vergessen, dass das nicht gleichbedeutend mit den Arealen ist, die man abschalten kann.

Außerdem dürfen wir nicht vergessen:
So wie das Design jetzt ausschaut, wird da nichts hinzugefügt, sondern ersetzt, bzw. Transistoren werden wg. der HD-Libs eingespart. In dem FPU-Teil-Beispiel, dass AMD präsentiert hatten, sprachen sie nicht nur von Platz-Einsparung sondern auch von Verbrauchseinsparung. Gut möglich also, dass sie das Eingesparte einfach re-investiert haben.

Kleiner <-> weniger Strombedarf

Das ist oBdA trivial :ugly: Du musst einfach die Signale weniger stark treiben, weil deine mittlere Weglänge sich reduziert, wenn dein Chip kleiner wird.

Naja, da ist der Kasus Knacktus ja, dass AMDs aktuelles Die-Größe/Leistungsverhältnis total mies ist. Wenn man da nur Module dupliziert, wirds nicht besser. Man muss an die µArch ran. So wies ausschaut ändert sich die Die-Größe nicht großartig, bisschen mehr, mehr nicht. Dafür steigt die IPC, und v.a. die mth-Leistung deutlich an. Unterm Strich würde es ein deutlich besserer Chip werden. (Falls alles stimmt ^^).

Wenn ich an der Single-Thread Leistung nichts mache, und vor allem den Verwaltungsaufwand konstant oben halte für viele Threads, dann wird es aber auch nicht besser. Da dann lieber die Verdoppelung der Ressourcen gnaz weglassen, und nochmals dichter alles packen.

Es ist halt nicht so, das man die Threads "kostenlos" bekommt. Nein, man muss ziemlich für die Flexibilität bluten, und bei der oben aufgezeigten Parallelität ist es halt echt ne Frage, ob man das dann am Ende auch wirklich braucht.

Willst DU nur einen Thread laufen lassen, kannst Du das auch machen, aber dann liegen halt 75% der Leistung auf der Straße ... Wenn man sich nen Porsche kauft, kauft man den gemeinhin nicht für die Spielstraße ^^
Wenn Dein Code besser auf ner GPU läuft, dann kauf Dir ne GPU :)
So wies ausschaut sieht AMD aber noch genug Nachfrage nach so nem CPU-Kern, sonst würden sies ja nicht machen :)

Wer reden von EINEM Thread? Du musst erstmal die 16/32 Threads auslasten :ugly:

Und da hast du dann ja schon pro Thread mindestens 2x ILP drin. Mir stellt sich da eben dann immer die Sinnhaftigkeit. Ich kann mir eigentlich kaum etwas vorstellen, wo ich diese doppelte Flexibilität durch die Threads wirklich brauche, wenn ich bereits so einen hohen Grad der Parallelität erreicht habe.

Welche Ressourcen genau meinst Du genau? Die-Fläche/Stromverbrauch/Xy, alles zusammen? Läuft im Endeffekt wieder auf das µArch-Argument raus, so wies im Moment ist, ist BD für die gebotene Leistung einfach zu groß. Und auch gilt wieder der Hinweis von oben mit den HD-Libs, eventuell gibts die zusätzlichen Einheiten für lau.

Ganz allgemein Hardwareressourcen/Transistoren. Du brauchst halt die gesamte Branchprediction usw usw usw alles doppelt, wenn du 2 Threads laufen lassen willst. Auch die ganzen Fenster müssen doppelt so groß werden usw usw. Wenn du nicht direkt wieder Single-Thread-Leistung verschenken willst.

Und diese zusätzlichen Transistoren kosten halt Strom, und das sowohl direkt, als auch indirekt, weil die Leitungslängen größer werden usw usw.

Naja, dann eben weniger Vcore und Takt. Ein fettes Design auf die Beine zu stellen, und es dann nur zur Hälfte auszulasten wär ja mal wirklich selten doof. Stattdessen könnte man dann gleich ein paar Jaguarkerne verbauen.
Power-Gaten geht nicht so einfach wie clock-gaten, meistens geht das nur auf Kern-Ebene, bei AMD kann man z.B. nur ein komplettes Modul powergaten. Da wir hier aber von der µArch sprechen, die innerhalb des Kerns ist, passt das Argument nicht. Oder meinst Du Clock-gaten? Ja das ginge, aber man designt doch keine Arch, dass was "dumm herumsteht". Außerdem ist das wieder ne Sache von ILP <> TLP. AVX bringt Dir nur was bei ILP, threads eben auch bei TLP.

Das ist ja aber der springende Punkt. Der zusätzliche Thread bringt dir nur! etwas, wenn du ihn auch benutzt. Wenn du ihn direkt weg lässt, kannst du die freien Ressourcen für die Steigerung der Single-Thread IPC einsetzen.

Wie gesagt, wenn ich die bei nem 32/64 Thread System brauch, dann kann ich auch breitere Instruktionen verwenden, bzw eben die doppelte Anzahl dieser Absetzen. Genau DAS ist ja auch der Gedanke hinter AVX. Man bohrt SSE nochmals auf, um den Verwaltungsaufwand klein zu halten.

Intels Larrabee mit seinen 512 Bit Registern geht in die gleiche Richtung, genau wie GPUs.

Zusammenfassend muss man anerkennen, dass ein µArch-Design immer die Quadratur des Kreises ist. Man will möglichst alle Programmeventualitäten schnell bearbeiten können, dabei aber möglichst wenig Die-Fläche und Strom verbraten.

Ja durchaus.

Du scheinst eher von perfekten Parallel-Code auszugehen, da wäre natürlich eine GPU super, oder halt ein schlanker single-core mit AVX. Aber es gibt halt noch andere Anwendungsfälle.

Was heißt "perfekt"?

Das ist schlichte Grundlagenüberlegung, wann ich überhaupt erst anfange so was einzusetzen. Also wann ich mich anfange dazu Gedanken zu machen, und das ist eben der Fall, wenn das Programm einen signifikanten Anteil der Zeit in derartigem parallelem Code verbringt, und wenn das der Fall ist, und ich bereits 16/32 Threads (aktuelle Opterons) auslasten kann, dann hab ich derartige Probleme, das ich das auch relativ einfach nochmals nach oben pushen kann. Überhaupt wenn ich AVX verwende. Dann geh ich ja eh davon aus, dass die Threads die FPU auch durchaus auslasten können, sonst würde ich SSE verwenden. Genau bei AVX schlägt aber eben die zu schmale FPU durch bei BD. Das ist ja der "Witz" an der Sache...

Es ist zwar schick zu haben, aber Kosten/Nutzen gehen wir einfach total auseinander.

Nö, schau Dir die AMD-Roadmap an ... das ist trauriger Fakt. Eventuell haben wir auch ein Mißverständnis, Seamicrosysteme ordne ich unter 1P-Systeme ein.

Merkste da was? Die 8sockel wurden durch 4 sockel verdrängt und die 4 Sockel durch 2? Wo das wohl enden wird ... ^^

8 Sockel sind aber auch teuer ;)

4 Sockel wurden von den Dual-Sockel verdrängt, weil der mögliche Speicherausbau gut mitgegangen ist. Aber 2 Sockel nimmst du gern mit. Der Aufwand für 2 Sockel ist einfach verdammt gering im Vergleich zu Single-Sockel. Vorallem wenn du statt einem Maschine zwei brauchst, ist der Kosten/Nutzenfaktor extrem viel besser für Dual-Sockel

Möglich, aber ob das System von AMD kommt ... ist die Frage. Soviel Bigdata-Fälle gibts ja auch nicht. Großkonzerne halt, aber wieviel McDonalds, UPS, Apples etc. gibts denn? Sagen wir mal 10.000. Das wär noch ein gutes Geschäft, aber blöderweise gibts da noch so ne Firma namens Intel... und Oracle und IBM werden in dem Bereich auch noch ein Wörtchen mitreden wollen ...
Der RAM-Kohärenz-Dampfer ist bei AMD seitdem abgefahren, seit sie Seamicro gekauft haben und Intel den Cray-Interconnect übernommen hat.

Das ist völlig ausreichend. FusionI/O z.B. machen glaub 90% ihres Umsatzes mit 3-5 Kunden :ugly: Und die verdienen nicht! schlecht.

Die ganz großen werden halt immer wichtiger, gleichzeitig stellen die auch immer spezifischere Anforderungen, einfach weil Sie die nötige Masse auch bringen, damit sich das rechnet.

Schau dir doch mal die OpenServer (?) an, was von Google/Facebook angestoßen wurde. Das hat nur ein Ziel. Höhere Effizienz, und niedrigere Kosten, weil man ALLES! aber auch wirklich ALLES was man nicht wirklich braucht weg lässt.

Nicht nachrüstbare Server mit WaKü kommen so langsam auch auf den Markt und werden akzeptiert. Wenn ich 100k Server und mehr habe, dann ist es halt egal, wenn mal einer aussteigt, dann mach ich den komplett dicht und gut ist. Irgendeiner ist eh immer kaputt....

Die Einsparungen bei den anderen rechtfertigen das aber locker.

Multi-Sockel generell nicht, aber Multisockel von AMD. In Zukunft wirds da nur noch Seamicro1P-Nodes geben.

Nach außen sehen die wie Shared-Nothing systeme aus, Performancetechnisch bzgl der Anbindung zwischen den Sockeln liegen Sie aber eher auf dem Niveau von klassischen Multisockel, man gibt halt "nur" das SMT Design auf. Das ist kein kleiner Einschnitt, aber bei den Systemen/Problemen die man da angeht, tut es nicht weh, weil man eh auf MPI setzt, oder aber die Probleme nicht so eavy sind, das man große einzelne Systeme braucht. Man reduziert halt die Hilfe durch das OS. Das ist aber wie gesagt hier sehr verschmärzbar.

Ich würde daher nicht sooo einfach von "Single-Sockel" Systemen sprechen. Das wird der Sache einfach nicht gerecht. Es ist eine andere Philosophie hinter dem Design. Mit gewissen Einschränkungen halt, aber "Einschränkungen" öffnen einem IMMER! das Tor zu steigender Effizienz ;)

Triskaine

2013-05-28, 20:01:17

Im Anandtech Forum hat jemand eine Desktop Roadmap ausgegraben die auf einer Investor Veranstaltung gezeigt wurde:

http://i.imgur.com/2DdQH4D.png

Also 2 Module für Kaveri.

Locuza

2013-05-28, 21:54:54

Aha, FM2+.
Wieder einmal steht der HSA Application Support nur explizit bei Kaveri, womit sich da schon Unterschiede auftun sollten zwischen Kabini und Kaveri.
Wäre es dann nur die bidirektionale Kohärenz bei den Caches oder gehört dazu auch der gemeinsame Adressraum?
Weil das ja eig. verwundert, da im Kabini eine Sea Island GPU steckt.

Gipsel

2013-05-28, 23:19:47

Noch was anderes (in Fett, damits nicht untergeht):
In nem anderen Forum hat einer angemahnt, dass das mit 2 Threads pro INT-Cluster Käse wäre, da die Register dafür nur ungenügend Read/Write-Ports hätten. Kann das jemand einschätzen? Hört sich erstmal plausibel an.
Stimmt schon, das könnte nur funktionieren, falls AMD da ein paar deutliche Fortschritte in dem Bereich gemacht hat (oder der andere Prozeß verhält sich sehr viel gutmütiger). Die verdoppelten Registerfiles wurden ja nicht nur eingesetzt, um die Anzahl der nötigen Read-Ports zu halbieren, sondern auch um das Timing des Result-Forwarding-Networks zwischen den einzelnen Einheiten hinzubekommen. Das wäre wohl mit nur einem RegFile (was mit mehr Ports selber auch größer wird) schwierig geworden bzw. hätte das den gewünschten Takt eingeschränkt.
Wir müssen ja im Hinterkopf behalten, daß die SR-Kerne in 28nm kommen werden, also viele Strukturen kleiner werden und somit Leitungslängen schrumpfen können. Wenn das Taktziel nicht sonderlich oder auch überhaupt nicht steigt (und die Leitungsquerschnitte für das kritische Routing zwischen den Einheiten nicht sinken), ist es durchaus vorstellbar, daß dies bei SR nicht mehr ganz so kritisch aussieht. So könnte es sein, daß man nicht nur 4 Einheiten um ein einziges Registerfile hinbekommen hat sondern daß man sogar eine Einheit mehr an das Network flanschen konnte.
Aber man müßte wirklich die Regfiles von 4Read/4Write-Ports (was durch die Duplizierung logisch nach wie Ports für 8 Reads + 4 Writes aussieht) auf mindestens 8R/4W aufbohren (Readports sind angeblich billiger als Write-Ports, aber keine Ahnung). Und dann hätte man dort immer noch keinen Vorteil bezüglich der Single-Thread-Leistung in diesem Bereich. Dies würde nur dann gehen, wenn z.B. die "near ALUs" jeweils an beide Resultforwarding-Netze und auch an beide RegFiles hängt (dann bräuchte man also 10R/5W-Ports, wäre also ein deutlicher Fortschritt gegenüber BD, aber Intel bekommt es ja auch hin :rolleyes:).
Für den Scheduler (der jetzt 2 Threads handhabt) würde die Aufgabe nicht soo viel komplizierter werden. Es gibt zwar insgesamt 8 Issue-Ports (passend zur Zahl der Einheiten), aber 6 davon sind fest an einen Thread gepinnt (1xALU + 2xAGU). Nur um die beiden Ports für die beiden "near ALUs" streiten sich die beiden Threads. Ein Thread kann also im Peak maximal 3 ALUs und 2 AGUs benutzen, also immer, wenn der andere Thread schläft oder auch nur gerade keine ALU-Instruktionen zur Verfügung hat (und man erinnere sich, daß die Integer-IPC häufig nur um die 1 rumkrebst, das also häufig der Fall sein sollte). Wäre eine Art eingeschränktes SMT oder auch ein SMT mit einem Minimalsatz an garantierten Resourcen pro Thread. Ob sich dafür der Aufwand lohnt? Hmm.

Bei der FPU grübel ich übrigens auch noch drüber, ob es wirklich 4x128Bit FMAs sind (die Registerfiles sehen definitiv nach weiterhin 128Bit Pipelines aus, da die Hälfte 80Bit EP ist und nicht nur 1/4 [wie man das bei einer nativen 256Bit-Implementation erwarten würde]) oder nicht 2 Sets zur je 2x128Bit FMAs. Die Wege von links nach rechts sehen mir verdammt weit aus, wenn man alle FMA-Einheiten von einem Thread aus bestücken wollte (was sowieso extrem schwierig würde, da man dafür 24 unabhängige FMA-Anweisungen benötigen würde). Das macht also kaum einen Sinn.
Ein paar Einheiten (Integer-SIMD?) sitzen jetzt übrigens zwischen Registerfiles und den FMACs, nicht mehr über der äußeren Hälfte der Registerfiles wie noch bei BD. Zusammen mit der angekündigten Verringerung der Issue-Ports des FP-Schedulers von 4 auf 3 mit Steamroller, sollten eigentlich auch die Anzahl der Registerfile-Ports zurückgehen. Aber die RegFiles sehen massiv größer aus. Also nicht nur verdoppelt, wie man das bei einer Erhöhung auf 4 Threads (so es sie denn gibt) erwarten könnte, sondern deutlich mehr als das. Doch mehr Ports für 4x128Bit? Oder sind es doch 2x256Bit und AMD benutzt irgendein eigenartiges räumliches Interleaving der einzelnen 64Bit-Partitionen eines 256Bit-Vektors auf dem Die (wodurch die 1x80+3x64Bit-Aufteilung teilweise maskiert wird)? Eine Duplizierung der Regfiles wie bei BDs Integer-Teil wäre aufgrund der großen Abstände wohl schlicht aus Stromverbrauchsgründen ausscheiden.

Weiterhin sieht der Crossbar-Teil im Bereich zwischen den Registerfiles in der unteren Hälfte irgendwie ziemlich aufgebohrt aus. Insbesondere scheint es so, als wenn rechts vor den RegFiles auch vertikal geroutet wird. Und nur rechts, was bedeutet, daß man die FPU kaum in eine rechte und eine linke Hälfte teilen kann, was dann doch irgendwie für 2x256Bit spricht. Aber warum haben dann in der oberen Hälfte sowohl die linke als auch die rechte Seite ein breiteres Regfile (und nicht nur auf einer). Also mit meinem (zugegeben dürftigen Wissen) über die physische Implementation von CPUs kann ich mir bisher nicht so recht einen Reim drauf machen.

robbitop

2013-05-29, 13:42:15

Die Folie spricht gegen die Theorie mit den 4 Threads pro Modul. Das würden die hundertprozentig als 8 Kerne (bei 2x Modulen) verkaufen.

Gipsel

2013-05-29, 13:49:43

Die Folie spricht gegen die Theorie mit den 4 Threads pro Modul. Das würden die hundertprozentig als 8 Kerne (bei 2x Modulen) verkaufen.Wenn sie keine völlig getrennten (sondern nur teilweise) Integer-ALU-Kapazitäten (und Scheduler) haben, wäre eine Vermarktung als eigenständige Cores nicht gerechtfertigt, auch wenn der Speedup vielleicht größer ausfallen würde als bei normalem SMT.
Und wir wissen ja auch gar nicht, ob das überhaupt ein Steamroller-Shot ist oder nicht. Irgendeine erste Version von Excavator könnte auch schon in der Mache sein, wenn man bedenkt, daß typischerweise deutlich mehr als ein Jahr zwischen dem ersten Silizium und der Produktvorstellung vergehen. Wir wissen auch immer noch nicht, woher der Shot genau kommt, oder?

robbitop

2013-05-29, 13:57:26

Da hast du nicht unrecht. IMO klingt das ziemlich abenteuerlich mit den 4 Threads pro Modul...

S940

2013-05-29, 17:15:40

Da hast du nicht unrecht. IMO klingt das ziemlich abenteuerlich mit den 4 Threads pro Modul...Ja, aber wenn man von der Echtheit des Bildchens ausgeht, dann ist das die plausibelste Erklärung. Weiterer - wenn auch schwacher Punkt - ist der Hinweis von "greater Parallelism" auf der alten Bulldozer-Core-Roadmap.

@Skysnake:
Hmm ... ja ich geb Dir mal mit der AVX-Sache Recht, das wird alles ziemlich breit und wenn man 4 Threads @256bit mal 4-8 Kerne ausnutzen kann, wärs wohl sicherlich GPU-tauglich.

Dass es da dann Überlappungen gibt ist in dem Sinne Intels Schuld. AMD wollte ja keine 256bit für SSE5. Aber Intel hat keine breiten GPUs, also hatten die da wohl genug Motivation x86 weiter aufzudrehen.

Zu dem MP<>1P Thema:
Nach außen sehen die wie Shared-Nothing systeme aus, Performancetechnisch bzgl der Anbindung zwischen den Sockeln liegen Sie aber eher auf dem Niveau von klassischen Multisockel, man gibt halt "nur" das SMT Design auf.Auch wenn Du die Seamicro-Systeme nicht unter 1P einordnen willst, ist das die offizielle Bezeichnung dazu. Wenn jeder seine Privatdefinitionen verwenden würde, sprächen wir pausenlos aneinander vorbei. Würde vorschlagen, dass wir uns auf die offiziellen Nomenklaturen halten. Außerdem hast Du Dich da wohl vertippt, SMT ist da fehl am Platz, Du meinst sicher ccHT. ;-)
Das ist völlig ausreichend. FusionI/O z.B. machen glaub 90% ihres Umsatzes mit 3-5 KundenDas ist sicherlich auch richtig, aber wer kauft noch AMD-Server? Wenn AMD da 1-2 Großkunden hätten, würds sicherlich reichen, aber haben sie das?
Es sollte sich halt rentieren ...
Um den Bogen wieder zurück zum Thema zu spannen: Falls das Design stimmt, sollte die Leistung recht gut sein, das wiederum könnte schon ein paar Kunden anlocken. Aber langsam sollten sie echt mal PCIe in die Serversockel integrieren ... bin mal gespannt wie lange / ob sie noch nen AM3+ /C32/G34 Steamrollerchip bringen werden.

Skysnake

2013-05-29, 18:35:27

äh ich mein SMP natürlich :ugly:

S940

2013-05-30, 03:09:20

Ach SMP .. alles klar ^^

Ansonsten, passt wohl auch hier rein, es gibt jetzt nen HSA-Programmierleitfaden:
https://hsafoundation.box.com/s/m6mrsjv8b7r50kqeyyal

Skysnake

2013-05-30, 08:46:14

Danke :up:

Ich schau mal gleich rein ;)

EDIT:
Ok viel blabla.

Sieht sehr sehr ähnlich aus wie OpenCL.

Was ich gut finde ist, dass man eine "Granularität" (width) angeben kann, bzgl erwartetem branching. Das ist schon ganz nett. Damit kann der Compiler sicherlich gut entscheiden, wo er die Sachen besser hinschiebt.

Rekursionen sind jetzt auch richtig gut nutzbar, wie es scheint :up: Ich bin ja kein Freund von Rekursion, und man kann ja jede Endrekursion in eine Schleife umwandeln, aber gut, seis drum, manche Sachen lassen sich wohl wirklich viel elleganter so lösen.

Was ich noch interessant fande, war die Sache mit dem HSAIL, und dem finalizer.

Wenn ich das richtig verstanden habe, läuft HSA praktisch wie JAVA, und ermöglicht so auch den Wechsel der zugrunde liegenden ISA. Also GENAU das was Sie versprochen haben. Leider in Software :(

Wobei mit HSAIL ja auch noch eine native Ausführung bereit steht, die eben auch eine gewisse Freiheit wohl zulässt. Keine Ahnung, wie das da auf die ISA gemapped wird.

2phil4u

2013-05-30, 19:58:33

Führt diese Sprache auch dazu, dass der Compiler oder Interpreter den Code eines einzelnen Threads auf mehrer (Kerne, Ressourcen) aufteilt, oder ist die ganze Sprache völlig anders, so wie damals mit dem Beginn der objektorierntierten Programmierung ?

Diese Sprache ware dann aber nicht mehr compilierbar ?

Oder kann die Sprache, zumindest bei der C++ Erweiterung aufgrund der gewünschten Performance per Compiler auf die jeweilige CPU optimiert werden ?

Skysnake

2013-05-30, 21:43:06

JAVA kennste?

Da läuft halt ne LLVM wohl, genau wie bisher auch bei Java und auch bei den GPU-Treibern für OpenCL.

Also da tut sich eigentlich nicht wirklich was ändern.

Und "Thread" ist so ne Sache. Was ist denn ein "Thread"?

Was du meinst hat zur Folge, dass du eben dann nicht mehr einen Thread hast, sondern mehrere. Ansonsten kannst du da auch nichts parallelisieren abgesehen von MMX/SSE/AVX. Und das macht der compiler, oder man selbst von Hand, da ändert sich also rein gar nichts.

HSA abstrahiert eigentlich nur die Hardware und packt mehr in den Compiler, den man dann mit einigen Hints füttert, damit er was hiffentlich vernünftiges ausspuckt.

fondness

2013-06-01, 11:17:41

Earlier this year we reported about Kaveri also getting a GDDR5 memory interface, a rather interesting proposition but imaginable considering AMD integrated the same memory technology into the silicon for Sony's Playstation 4. A newer version of the NDA documents seen by us no longer include the references to a GDDR5 interface. The document detailing the GDDR5 interface was from last year, while the newer one we have seen is only a few months old. It seems AMDs engineers for some reason dropped GDDR5 in Kaveri. The possibility of models with 3 compute units (i.e. 6 cores) was removed as well. This is also reflected in the roadmap.

Last but not least Kaveri will be manufactured at the 28nm node. Previous mainstream APU products like Llano, Trinity and Richland were manufactured at the 32nm node with SOI technology. AMD already detailed a while ago that all their 28nm products will be on bulk silicon. This allows AMD to potentially make the product at different semiconductor manufacturers. At this point it is unknown whether Kaveri will be made at TSMC or GLOBALFOUNDRIES, but by now GLOBALFOUNDRIES should have their 28nm lines ready for prime time. Previous 28nm products from AMD were exclusively made at TSMC, even though earlier it was announced that in 2013 all processor products would be made at 28nm at GLOBALFOUNDRIES.

http://www.brightsideofnews.com/news/2013/6/1/amd-updates-roadmaps2c-shows-28nm-kaveri-for-socket-fm22b.aspx

Keine Ahnung was man davon halten soll, speziell der zweite Absatz dürfte BS sein, nachdem GF einen 28nm SOI Prozess anbietet.

Ronny145

2013-06-01, 13:54:08

Kaveri ohne GDDR5 wäre eine dicke Enttäuschung. DDR4 wäre wohl auch zu früh. Mit DDR3 kann sich jeder ausmalen, dass das stark bandbreitenlimitiert wäre.

Schaffe89

2013-06-01, 14:01:45

Hat AMD denn GDDR5 angekündigt?
Jedenfalls halte ich es für wahrscheinlicher dass AMD die Konsolenchips bei GF fertigen lässt und dafür jetzt die meisten anderen Bei TSMC fertigen lässt, Globalfoundries bekommts einfach nicht gebacken, der 32nm Prozess war einfach grottenschlecht und hat AMD auc den Absatz mit Bulldozer verhagelt.

Ronny145

2013-06-01, 14:07:18

Angekündigt hat AMD gar nichts, es hat nur jeder GDDR5 nach den Spekulationen fest erwartet.

mboeller

2013-06-01, 16:25:56

Ist wohl eher 2x2, siehe oben (die Postings haben sich wohl überschnitten).

Wäre das dann eine Kombi aus Strong-CMT und Light-CMT? ;)

Da Steamroller ja die 2 getrennte Decoder hat sollte das normale CMT ja "ein wenig" besser funktionieren als bisher; IMHO eigentlich so gut wie bei 2 getrennten Kernen (zumindest bei INT).
Wenn dann aber auch 2 Threads pro Kern laufen sollen dann würde das dann sehr wahrscheinlich schlechter funktionieren als normales CMT (wie es der Vishera benutzt); ergo CMT-light das nur ein wenig besser ist als SMT bei Intel.

Könnte aber bei 4 Threads schon was bringen.

Bisher: 2 Module mit 4 Threads = 2 x 1,5 = 3fache Leistung bei 2 oder mehr Threads (soweit ich mich erinnere bringt CMT ja meistens nur +50%)

Neu: 2 Module mit 8 Threads = 2 x 1,9 x 1,35 = 3,8-fache Leistung bei 2 Threads und >5-fache Leistung bei 4 Threads...

das würde die "greater parallism" aus der Roadmap schon rechtfertigen, oder?

S940

2013-06-01, 16:59:02

Wäre das dann eine Kombi aus Strong-CMT und Light-CMT? ;)

Da Steamroller ja die 2 getrennte Decoder hat sollte das normale CMT ja "ein wenig" besser funktionieren als bisher; IMHO eigentlich so gut wie bei 2 getrennten Kernen (zumindest bei INT).
Wenn dann aber auch 2 Threads pro Kern laufen sollen dann würde das dann sehr wahrscheinlich schlechter funktionieren als normales CMT (wie es der Vishera benutzt); ergo CMT-light das nur ein wenig besser ist als SMT bei Intel.

Könnte aber bei 4 Threads schon was bringen.

Bisher: 2 Module mit 4 Threads = 2 x 1,5 = 3fache Leistung bei 2 oder mehr Threads (soweit ich mich erinnere bringt CMT ja meistens nur +50%)

Neu: 2 Module mit 8 Threads = 2 x 1,9 x 1,35 = 3,8-fache Leistung bei 2 Threads und >5-fache Leistung bei 4 Threads...

das würde die "greater parallism" aus der Roadmap schon rechtfertigen, oder?So Pi*Daumen kann mans wohl sagen. Ich wär mit den Speedups aber etwas optimistischer. CMT schafft schon oft die +80% und das "neue" CMT/SMT in den INT-Kernen verdoppelt ja die ALUs, d.h. die Skalierung sollte besser als bei Intel sein. +35% schafft man ja auch sogar schon mit SMT, ich würde da mal grob +10% oben drauf setzen. Durch die Cachevergrößerungen und sonstigen Feintuningmaßnahmen kann man dann sicherlich auf 1,5 aufrunden.

Das gäbe dann
Alt: 2 x 1,8 = 3,6
Neu mit 4 Threads: 2x1,9x1,5 = 5,7
Durchsatzplus insgesamt für Multithread: +58%
Ist aber schwierig zu sagen denn die Faktoren beeinflussen sich ja gegenseitig durch die Doppelnutzung einiger Einheiten. Bei nur 2 Threads würde ich noch nen IPC-Faktor dazurechnen. Die 16kB L1 waren recht mickrig, 32kB sind deutlich besser, nicht nur wg. der Größe sondern auch wg. der Cachebank-Konflikte und die Riesensprungvorhersage sollte auch ihren Teil beitragen. Da kann man wohl eher optimistisch sein und zw. 10 und 20% IPC+ einfordern.

Wie dem auch sei, ich würde die Multithread-Prognose dann durch die ganzen Unsicherheiten wieder etwas aufweichen und auf grobe +50% plus/minus 10% abschätzen. Das sollte wohl ein gutes Fenster sein. Wenn denn die CPU wirklich so käme ^^

AnarchX

2013-06-05, 07:46:34

Kaveri Die gezeigt:
http://www.computerbase.de/news/2013-06/amd-zeigt-lauffaehige-kaveri-apu/
http://pc.watch.impress.co.jp/img/pcw/docs/602/280/html/05.jpg.html

Wohl wieder deutlich über 200mm².

fondness

2013-06-05, 08:58:47

Kaveri Die gezeigt:
http://www.computerbase.de/news/2013-06/amd-zeigt-lauffaehige-kaveri-apu/
http://pc.watch.impress.co.jp/img/pcw/docs/602/280/html/05.jpg.html

Wohl wieder deutlich über 200mm².

Sieht für mich durchaus nach 250-300mm² aus, eher sogar Richtung 300mm².

robbitop

2013-06-05, 09:07:00

Naja - von nichts kommt nichts. Da müssen 512 SPs und zwei der neuen Kaverimodule hinein.

fondness

2013-06-05, 09:11:20

Naja - von nichts kommt nichts. Da müssen 512 SPs und zwei der neuen Kaverimodule hinein.

Naja Cape Verde hat 640SPs und kommt inkl. Speicherkontroller und allem drum und dran mit 123mm² aus. Aber man hat wohl wie üblich das Problem das GFs Prozess nicht gerade optimal für GPUs geeignet ist.

HOT

2013-06-05, 09:13:20

Und nochmal: Wenn GDDR5, dann verlötet als BGA-Variante, also ausschließlich mobil. GDDR5-Module wird es nicht geben (welch Überraschung).

AnarchX

2013-06-05, 09:17:56

Es gibt einen GDDR5M SODIMM Standard: http://www.jedec.org/standards-documents/results/gddr5m

Vielleicht im Kaveri Refresh.

robbitop

2013-06-05, 09:18:47

Naja Cape Verde hat 640SPs und kommt inkl. Speicherkontroller und allem drum und dran mit 123mm² aus. Aber man hat wohl wie üblich das Problem das GFs Prozess nicht gerade optimal für GPUs geeignet ist.
Ja die 123 mm² kommen halt oben drauf (zur CPU). 2x große Kaverimodule (evtl mit verdoppelten Ressourcen) mit relativ großen L2 Caches, I/O etc und das bei fast schon rückständigen 28 nm. Was will man da erwarten?

Es gibt einen GDDR5M SODIMM Standard: http://www.jedec.org/standards-documents/results/gddr5m

Vielleicht im Kaveri Refresh.
Das geht sicher auf die Taktraten. (steckbarer RAM)

M4xw0lf

2013-06-05, 09:19:04

fondness

2013-06-05, 09:21:03

Weitere Informationen zum Sockel FM2+: Kompatibel mit Trinity und Richland
http://www.computerbase.de/news/2013-06/weitere-informationen-zum-amd-sockel-fm2-plus/

Ja die 123 mm² kommen halt oben drauf (zur CPU). 2x große Kaverimodule (evtl mit verdoppelten Ressourcen) mit relativ großen L2 Caches, I/O etc und das bei fast schon rückständigen 28 nm. Was will man da erwarten?

Es kommt mir trotzdem viel vor, ein Piledriver-Modul benötigt in 32nm inkl. L2 30mm². Aber mal abwarten. Vielleicht steckt zumindest ein L3-Cache drinnen^^

AnarchX

2013-06-05, 09:23:00

Das geht sicher auf die Taktraten. (steckbarer RAM)
Mit 3,2-4Gbps trotzdem noch deutlich schneller als DDR3.

Ronny145

2013-06-05, 09:26:25

Ich habe mal nachgerechnet und komme da auf ~260 mm².

Undertaker

2013-06-05, 09:40:34

Hmm, ich komme in Relation zur Euro-Münze auf knapp 240mm² (~14,3 x 16,6mm). Allerdings ist die Längsseite perspektivisch minimal verkürzt, sodass ich auf etwa 250mm² tippe.

Ronny145

2013-06-05, 09:42:47

Hmm, ich komme in Relation zur Euro-Münze auf knapp 240mm² (~14,3 x 16,6mm). Allerdings ist die Längsseite perspektivisch minimal verkürzt, sodass ich auf etwa 250mm² tippe.

http://www.hardware.fr/medias/photos_news/00/41/IMG0041639_1.jpg

Das eignet sich besser zum Nachmessen.

AnarchX

2013-06-05, 09:45:46

Sind die 210-220mm² dort nicht mit dem Lineal gemessen wurden?

robbitop

2013-06-05, 09:50:43

Trinity ist 246 sqmm groß. Ein idealer Shrink würde zu 188 sqmm führen. 250 sqmm sind ~ 33% mehr Transistoren. GCN statt VLIW4 kostet pro Ausführungseinheit schon was und die Anzahl der Ausführungseinheiten wird um 33 % erhöht. Die GPU sollte also ~ 50% mehr Transistoren kosten als vorher. Dann bleibt auch nicht mehr so viel von der Erhöhung des Transistorbudgets übrig. Wenn du mit dem Rest das Verdoppeln vieler Ressourcen bei Steamroller berücksichtigst, sollte man sich über ~ 250 sqmm nicht wundern.
28 nm ist eben kein wirklich starker Sprung.

Ronny145

2013-06-05, 10:06:54

Sind die 210-220mm² dort nicht mit dem Lineal gemessen wurden?

Das kommt nicht. Miss doch nach, Lineal ist im Bild mit drin.

Akkarin

2013-06-05, 12:56:14

Glaubt ihr CF wird eine gute option sein ? Die topversion + 512 shader gpu + CF treiber dürfte doch relativ potent und dazu sehr günstig sein.

mboeller

2013-06-05, 13:01:44

Sieht für mich durchaus nach 250-300mm² aus, eher sogar Richtung 300mm².

sehe ich nicht so.
Wenn man das Die mit dem 1-Euro-Stück vergleicht (Durchmesser 23,25mm) dann kommt man auf ca. 260mm². Genauer 257mm². Ich hab dafür die Vermessungsfunktion vom Irfanview benutzt.

AnarchX

2013-06-05, 13:05:55

Glaubt ihr CF wird eine gute option sein ? Die topversion + 512 shader gpu + CF treiber dürfte doch relativ potent und dazu sehr günstig sein.

Kommt darauf an wie sich der CF-Treiber entwickeln wird. Momentan ist wohl eher davon abzuraten.
Für das Set bezahlt man wohl möglich 180-200€. Vielleicht gibt es bis dahin aber auch einen 4 Thread HSW Pentium von Intel, den man mit einer 7790 <100€ kombinieren könnte.

dildo4u

2013-06-05, 13:13:33

Sind die IGP's nicht jetzt schon massig durch die Bandbreite limitiert?Da könnte Potenziell viel DIE Fläche für nichts verschwendet werden.6 Kerne gegen Intel Quads Intels plus kleinere GPU würde eigentlich reichen gegen HD4600,Intel CPU's mit Edram werden ja eh das doppelt und dreifache kosten.

mczak

2013-06-05, 19:53:57

Ja die 123 mm² kommen halt oben drauf (zur CPU). 2x große Kaverimodule (evtl mit verdoppelten Ressourcen) mit relativ großen L2 Caches, I/O etc und das bei fast schon rückständigen 28 nm. Was will man da erwarten?

Naja Cape Verde ist zwar 123mm² ich sehe das aber eher als aufbebohrten Mars und der ist bloss 85mm². Mars hat ja 6 CUs, Cape Verde 10 ist also genau dazwischen, aber ich denke auch die ROPs sind eher wie bei Mars (sollte die APU bloss ddr3 unterstützen dürften 4 Quad-ROPs eh rein gar nichts bringen). Wobei man allenfalls stattdessen den L2-Cache der GPU vergrössern könnte, es kommt ja sowieso auch noch irgendwelche Logik dazu für hUMA.
Alles in allem sehe ich trotzdem so auf den ersten Blick nicht gerade wieso der Chip grösser als 250mm² werden sollte, es sei denn die CPU-Kerne sind wirklich deutlich grösser geworden.

y33H@

2013-06-05, 20:03:43

Mark Papermaster deutete vorhin an, dass die Sache mit den fetteren Caches etc nicht ganz verkehrt sei, Details ließ er sich aber nicht entlocken. Dafür hörte ich was von GCN 1.1 und besseren Stromsparmodi, GDDR5 ist tot (für Desktop).

Locuza

2013-06-05, 20:14:54

2 Decoder pro Modul, größere Caches und Buffer, mehr Einträge.
Der FCL/Onion-Bus wird von 128-Bit auf 256-Bit verbreitert, dass wird wohl noch stimmen.
Vielleicht gibt es hier und da noch paar Goodies oder Verbesserungen die Platz verbrauchen, vielleicht traut man sich bei GloFo auch nicht so dicht zu packen.

S940

2013-06-05, 20:23:38

Naja größere L1-Caches sind ja schon bekannt, beim I-Cache ist es ziemlich sicher (offiziell gab AMD 30% weniger L1I-Misses an, das bekommt man nur mit ner Cachevergrößerung), beim D-Cache ziemlich wahrscheinlich.

Kurz: Schön zu wissen, dass auch Papermaster Gerüchte verbreitet, aber besser als die aktuellen Gerüchte ists auch nicht. GCN 1.1 ist auch nicht wirklich verwunderlich, selbst Kabini hat das ja.

Ronny145

2013-06-05, 22:12:50

GDDR5 ist tot (für Desktop).

Also GDDR5 für Notebooks oder wie meinst du das?

HOT

2013-06-05, 22:18:20

Also GDDR5 für Notebooks oder wie meinst du das?

Nur für BGA verlötet, maximal für S0-DIMM (glaub ich aber nicht dran). Erstmal aber wohl gar nicht, vllt. mit der nächsten Kaveri Rev.

Ronny145

2013-06-05, 22:21:12

Nur für BGA verlötet, maximal für S0-DIMM (glaub ich aber nicht dran). Erstmal aber wohl gar nicht, vllt. mit der nächsten Kaveri Rev.

Ist mir schon klar, aber er erwähnt explizit Desktop. Ich glaube da müssten wir den Originalkommentar hören um das einzuschätzen.

fondness

2013-06-05, 22:28:51

Immerhin schon Anfang Q4:
http://www.pcgameshardware.de/CPU-Hardware-154106/News/AMD-Kaveri-Sockel-FM2-Release-1072541/

Was vor wenigen Stunden noch unbestätigt war, bewahrheitet sich nun: Wie wir auf der Computex in diversen Gesprächen erfahren haben, erscheint AMDs Kaveri Anfang des vierten Quartals 2013.

Wie AMDs Investor-Roadmap zeigt, nutzt Kaveri "nur" zwei Module und auch nur DDR3-Speicher. Drei Compute Units und GDDR5 waren definitiv einst geplant, aus nicht ganz geklärten Gründen sei aber beides fallen gelassen worden - möglicherweise erhält der Nachfolger ein Modul mehr und den flotteren RAM.

HOT

2013-06-06, 09:06:37

Da hört sich an, als hätte man noch einen anderen Kaveri-Chip geplant aber später entschieden, den auch zu canceln, vermutlich zusammen mit den High-End-Varianten. Dann bleibt Kaveri also tatsächlich der einzige SR bis zur neuen Architektur. Die Leistung von SR kann also nicht berauschend sein, sonst würde das nicht alles wegfallen.

fondness

2013-06-06, 09:17:01

Mark Papermaster, CTO AMD:

Wir hakten dennoch nach und konfrontierten den CTO mit der Aussage von Andrew Feldman, dem ehemaligen CEO vom aufgekauften Seamicro, der nun bei AMD als General Manager für Data Center Server Solutions tätig ist. Dieser äußerte sich gegenüber PC-World sehr negativ über Bulldozer und bezeichnete die Architektur als Totalausfall, welcher unter anderem AMDs Ex-CEO Dirk Meyer den Job gekostet haben soll. Mark Papermaster aber widersprach seinem Kollegen deutlich, merkte jedoch an, dass jede neue Architektur erst einmal am Markt ankommen und die Software optimiert werden müsse. Mit der aktuellen Piledriver-Ausbaustufe sowie der kommenden Steamroller-Version sei AMD zudem die Schwachstellen angegangen und die Software wie auch die Fertigung seien besser geworden.

Da Steamroller die Modul-Idee etwas aufweicht wollten wir von AMDs Chief Technology Officer wissen, ob man das grundlegende Design nun nach und nach aufgeben wolle, was Mark Papermaster allerdings kopfschüttelnd verneinte - denn man habe viel in Bulldozer investiert und weite nun schlicht dessen Flaschenhälse, zudem komme ja auch noch die Excavator-Ausbaustufe. Der CTO deutet weiterhin an, vielleicht offenbare man schon auf einer der nächsten Hot Chips mehr Details, denn jede Generation werde schneller und schneller.

http://www.pcgameshardware.de/CPU-Hardware-154106/Specials/Mark-Papermaster-Interview-Bulldozer-Never-Settle-1072730/

HOT

2013-06-06, 09:30:31

Ah sehr gut. Das lässt 2014 nicht ganz so leer erscheinen ;). Dann wirds aber ein Excavator in 28nm SHP.

S940

2013-06-06, 13:38:07

Ah sehr gut. Das lässt 2014 nicht ganz so leer erscheinen ;). Dann wirds aber ein Excavator in 28nm SHP.
Ne, nicht notwendigerweise Du vergißt einen Faktor ;-)

robbitop

2013-06-06, 13:56:34

Ne, nicht notwendigerweise Du vergißt einen Faktor ;-)
Welchen denn?

S940

2013-06-06, 13:59:18

Welchen denn?
Verrate ich noch nicht, aber so doll ists nicht. Später mehr (ca. Wochenende) :)

fondness

2013-06-07, 09:32:08

Scheduled to show up before the end of this year, AMD's 28nm Kaveri APU will be based on the Steamroller CPU core, Graphics Core Next GPU and will feature support for AMD's HSA that should bring HUMA memory as well as some other features to the Kaveri APU. According to AMD, we should see up to 15 to 20 percent improvement on the CPU side of the chip, while GPU improvements will be even greater thanks to the GCN-based architecture.

http://www.fudzilla.com/home/item/31621-amd-demonstrates-kaveri-apu-at-computex-2013

Hier die gesamte Pressekonferenz:

ueHW0bJuZPQ

2phil4u

2013-06-07, 10:38:51

Ich habe ja schon einige Male daruf hingeweisen, dass FD-SOI ja bei Globalfoundries angeboten wird.
In dem Artikel ist von Risikoproduktion Ende 2013 die Rede.
FD-SOI sollte gegenüber 32nm SOI schon 20-30% bringen, aber Fusion 3 wird wohl noch im 28nm SOI Prozess gefertigt.
Keine Ahnung, ob 20nm non FDSOI leistungsfaehiger ist, wohl eher günstiger in der Herstellung.
Ist eigentlich 14nm Finet ein 20nm Prozess, der durch die 3-d Form shrinkt ?

Man liest ja immer wieder 14 nm Finfet on 20nm EOL.

Ist Intels 22nm Finfet eigentlich ein 28nm Prozess ?

Skysnake

2013-06-07, 10:43:38

Die Transistoren sind wohl 14nm Finfets, die ganze Verdrahtung der Transistoren ist dann aber 20nm

S940

2013-06-07, 13:00:21

Keine Ahnung, ob 20nm non FDSOI leistungsfaehiger ist, wohl eher günstiger in der Herstellung.Na das braucht double-pattering ...d.h. es wird teuer, gleichzeitig sinkt aber der übliche Leistungs-Zugewinn eines Full-node shrinks, da man an die physikalischen Grenzen kommt ... auch mit ein Grund wieso die Fabs ziemlich schnell auf 16nm wechseln wollen, denn da haben sie dann wie Intel jetzt schon, auch Finfets. Damit ist wieder alles im Lot.

Ist eigentlich 14nm Finet ein 20nm Prozess, der durch die 3-d Form shrinkt ?

Man liest ja immer wieder 14 nm Finfet on 20nm EOL.Nur die unterste(n) Lagen sind in der jeweilig angegebenen Struktur, darüber wird es gröber. Normalerweise shrinkt man die natürlich trotzdem mit, aber bei 16nm haben TSMC und GF angekündigt die oberen Lagen des 20nm Prozesses zu übernehmen, damit es schneller geht und man Intel einholen kann.
Wobei intel ...
Ist Intels 22nm Finfet eigentlich ein 28nm Prozess ?Ne unabhängige Webseite hat nen Ivy zerlegt und die haben 26nm gemessen ... ob man das nun 28 oder 22 nennen soll, soll jeder für sich entscheiden ;-)
Bei 32nm wars auch schon ähnlich, da hat Hans de Vries mal Bobcat und Atom verglichen, und sich gewundert, dass Bobcat so wenig Fläche braucht, obwohl Atom den Prozessvorteil hat. Bei genauerem Hinsehen hat er dann festgestellt, dass TSMCs 40nm Prozess sehr gute Nanometer-Werte hatte, Intels 32nm Prozess dagegen mal wieder recht "optimistisch" dargestellt wurde...

Fazit: Im großen und Ganzen kann man TSMCs Zahlen am meisten glauben, da muss man eher mit vornehmer Zurückhaltung rechnen, während Intel gerne übertreibt, GF scheint sich diesem anzuschließen, da sie ihren Prozess 14XM auch mit der "14" schmücken. TSMC spricht dagegen von 16nm, Intel aber bekannterweise von 14nm.

2phil4u

2013-06-07, 20:27:08

Ich habe einen relativ neuen sehr ausführlichen Artikel über die verschiedenen Prozesse von 28nm -10nm gefunden.
http://www.elektroniknet.de/halbleiter/prozessoren/artikel/98082/1/

Demanch ist 14nm Finfet von der Packdichte gleich wie 20nm Bulk und von daher eigentlich der gleiche Prozess, wie ich es vermutet habe.

Krass finde ich, dass von 28nm derzeit bis 14nm Finfet die Performance/Watt um den Faktor 2.9 steigt.

FDSOI 28nm also Anfang 2014, könnte dann unter Umstaenden für den Exavator genutzt werden, da ab 20nm die Kosten doch sehr steigen, wobei man dazusagen muss, dass dann natürlich auf weniger Flaeche gebraucht wird.
14nm Finfet ist sozusagen nur eine Weiterentwicklung der 20nm Technik, die natürlich auf Grund des nochmals grossen Sprungs in Takt oder Spannung bei gleichem Takt so schnell wie möglich eingeführt werden soll.

Problem ist natürlich, dass wenn keiner Lust auf 20 nm hat, die Foundries natürlich auch schlecht herstellen können bei den Kosten der Fabs und sich 28nm noch lange halten könnte.

Steamroller oder Verbesserung in 28nm FDSOI waere aus finanzieller Sicht gerade für kostengünstige Produkte wohl ideal.

S940

2013-06-07, 21:04:26

Steamroller oder Verbesserung in 28nm FDSOI waere aus finanzieller Sicht gerade für kostengünstige Produkte wohl ideal.
Nö, wenn schon denn schon, d.h. 14nm FDSOI^^

Wobei ich da im Moment auch nicht genau weiss was Sache ist. ST-Micro hat die Roadmap im Winter 2012 von FDSOI 20nm auf FDSOI 14nm geändert. Jetzt steht bei EEtimes aber:

Where things get tricky, though, is that FDSOI at 20nm (which ST calls “14-nm FDSOI”)http://www.eetimes.com/electronics-news/4415085/ST--once-alone--finds-FDSOI-allies-and-ecosystem-?pageNumber=1

Also wenn das stimmt, dann hat sich STM einfach an die Umlabel-Spielchen bei Finfets angepasst...
Das wäre aber im Gegenteil topp ... 20nm startet bei GF demnächst und die FDSOI-Fertigung baut darauf ja zu 80% auf, wobei die fehlenden 20% quasi Prozessschrittte sind, die man bei FDSOI *nicht* braucht :freak:
(Edit: Aber Extrasachen wie Backbiasing muss man schon anpassen).

Kurz: 20nm FDSOI sollte damit relativ unkompliziert und schnell zu haben sein - wenn GF 20nm nicht komplett vergeigt :freak:

Edit:
Auch interessant:
http://www.abload.de/img/fdsoi_manufacturing20wdj4i.jpg

Ein FD-SOI-Wafer ist also 1000 Dollar billiger in der Herstellung. Damit sollte sich SOI rechnen, ein SOI-Wafer ist ca. ~300 Dollar teurer als ein normaler, wenn ich mich recht erinnere. Also immer noch günstiger, und dann sollen auch noch Yields besser sein (da man kein Doping braucht, das sich unregelmäßig über den Wafer verteilt, sind die Dies auf dem SOI-Wafer alle ähnlicher / gleich gut) und man hat Backbiasing ... klingt wie immer ziemlich gut ^^

Ronny145

2013-06-07, 21:30:18

Ne unabhängige Webseite hat nen Ivy zerlegt und die haben 26nm gemessen ... ob man das nun 28 oder 22 nennen soll, soll jeder für sich entscheiden ;-)
Bei 32nm wars auch schon ähnlich, da hat Hans de Vries mal Bobcat und Atom verglichen, und sich gewundert, dass Bobcat so wenig Fläche braucht, obwohl Atom den Prozessvorteil hat. Bei genauerem Hinsehen hat er dann festgestellt, dass TSMCs 40nm Prozess sehr gute Nanometer-Werte hatte, Intels 32nm Prozess dagegen mal wieder recht "optimistisch" dargestellt wurde...

Fazit: Im großen und Ganzen kann man TSMCs Zahlen am meisten glauben, da muss man eher mit vornehmer Zurückhaltung rechnen, während Intel gerne übertreibt, GF scheint sich diesem anzuschließen, da sie ihren Prozess 14XM auch mit der "14" schmücken. TSMC spricht dagegen von 16nm, Intel aber bekannterweise von 14nm.

Nach den gleichen Maßstäben hat TSMC auch keine 28nm, sondern 30+. Es gibt nicht die eine Metric, um das untereinander zu vergleichen.

Intel
90 - 1.0
65 - .57 - 68nm relative to 90
45 - .346 - 51nm relative to 65, 53nm relative to 90
32 - .171 - 32nm relative to 45, 36nm relative to 65, 37nm relative to 90
22 - .092 - 23nm relative to 32, 23nm relative to 45, 26nm relative to 65, 27nm relative to 90

TSMC
90 - .99
65 - .499 - 64nm relative to 90
45 - .296 - 50nm relative to 65, 49nm relative to 90
40 - .242 - 41nm relative to 45, 45nm relative to 65, 44nm relative to 90
28 - .130 - 29nm relative to 40, 30nm relative to 45, 33nm relative to 65, 33nm relative to 90
20 - .081 - 22nm relative to 28, 23nm relative to 40, 24nm relative to 45, 26nm relative to 65, 26nm relative to 90

Regardless, one simple way to confirm that the claim of Intel's 22nm process being correctly labeled according to industry standards in to compare minimum SRAM cell size. TSMC's 28nm HP is 0.127um^2, Intel 22nm is 0.092um^2, while TSMC's upcoming 20nm process is 0.081um^2 - Intel's pretty much exactly where they should be with their 22nm label.

SRAMs
(HP and special low power versions are larger for all fabs)

Intel 45nm SRAM cell – 0.346um^2
Intel 32nm SRAM cell – 0.171um^2
Intel 22nm SRAM cell – 0.092um^2

TSMC 40nm SRAM cell – 0.290um^2
TSMC 28nm SRAM cell – 0.127um^2
TSMC 20nm SRAM cell – 0.090um^2

GF 28nm SRAM cell – 0.120um^2

ST 28nm FD-SOI SRAM cell – 0.120um^2 (this is believed to be the version with no back-gate and uncompetitive leakage – 0.152um^2 for back-gate and lowest power/leakage but of course LP versions of other processes are also larger)

Metal pitch
(once upon a time half this was the node size but as can be seen the transistors have shrunk a lot more than the metal)

Intel 22nm metal pitch – 64nm
Intel 14nm metal pitch – 48nm

TSMC 28nm metal pitch – 64nm
TSMC 20nm metal pitch – 64nm

Contacted gate pitch
(this is a key dimension in that it is no point making transistor gates shorter unless you can reduce this number to match)

Intel 32nm contacted gate pitch – 112nm
Intel 22nm contacted gate pitch – 90nm (80nm with special processing)
Intel 14nm contacted gate pitch – unknown

TSMC 40nm contacted gate pitch – 160nm
TSMC 28nm contacted gate pitch – 118nm
TSMC 20nm contacted gate pitch – unknown
TSMC 14nm contacted gate pitch – unknown

GF 28nm contacted gate pitch – 113nm
GF 20nm contacted gate pitch – 80nm

http://forums.anandtech.com/showpost.php?p=34944480&postcount=447
http://forums.anandtech.com/showpost.php?p=34852518&postcount=10
http://www.electronicsweekly.com/mannerisms/general/the-intel-nanometre-2013-02/

S940

2013-06-07, 21:41:06

Nach den gleichen Maßstäben hat TSMC auch keine 28nm, sondern 30+. Es gibt nicht die eine Metric, um das untereinander zu vergleichen.
Na doch, es wird doch immer nur eine Metrik angegeben. 45/32/22/16nm.
Das war ganz früher mal die Gate-Length, nix anderes und kein Mischmasch aus SRAM oder sonstigen Größen.

Es mag durchaus ganz andere wichtige Größen geben, aber die Prozesskennzahl basiert(e?) auf der Gate-Length.

Ronny145

2013-06-07, 21:55:33

Na doch, es wird doch immer nur eine Metrik angegeben. 45/32/22/16nm.
Das war ganz früher mal die Gate-Length, nix anderes und kein Mischmasch aus SRAM oder sonstigen Größen.

Es mag durchaus ganz andere wichtige Größen geben, aber die Prozesskennzahl basiert(e?) auf der Gate-Length.

Ok dann ist TSMC 33nm.

If intels 22nm is really 26nm then TSMC's 28nm is really like 31nm effective gate(or was it 33nm?).

You can't base nodes based on specific feature sizes anymore. It's all relative nowadays.

If a 22nm process has a 26nm gate, compared to 32nm's 30nm's gate, but offers 2x density, and traditional gains in performance(30%) then it can be considered a full shrink.

If the same "next-gen" process only offers 1.3x the density gain and 10% gains in performance, you wouldn't call that full node gain regardless of what they claim in "gate sizes" or whatever.

So metrics aren't so straightforward nowadays. It's like basing solely clock speeds or cores on power. Real CPUs are lot more complicated than that.

So sehe ich das auch. Früher war was vielleicht vergleichbar, heute nicht mehr.

Skysnake

2013-06-07, 22:07:46

Na das braucht double-pattering ...d.h. es wird teuer, gleichzeitig sinkt aber der übliche Leistungs-Zugewinn eines Full-node shrinks, da man an die physikalischen Grenzen kommt ... auch mit ein Grund wieso die Fabs ziemlich schnell auf 16nm wechseln wollen, denn da haben sie dann wie Intel jetzt schon, auch Finfets. Damit ist wieder alles im Lot.
Nur die unterste(n) Lagen sind in der jeweilig angegebenen Struktur, darüber wird es gröber. Normalerweise shrinkt man die natürlich trotzdem mit, aber bei 16nm haben TSMC und GF angekündigt die oberen Lagen des 20nm Prozesses zu übernehmen, damit es schneller geht und man Intel einholen kann.
Wobei intel ...
Ne unabhängige Webseite hat nen Ivy zerlegt und die haben 26nm gemessen ... ob man das nun 28 oder 22 nennen soll, soll jeder für sich entscheiden ;-)
Bei 32nm wars auch schon ähnlich, da hat Hans de Vries mal Bobcat und Atom verglichen, und sich gewundert, dass Bobcat so wenig Fläche braucht, obwohl Atom den Prozessvorteil hat. Bei genauerem Hinsehen hat er dann festgestellt, dass TSMCs 40nm Prozess sehr gute Nanometer-Werte hatte, Intels 32nm Prozess dagegen mal wieder recht "optimistisch" dargestellt wurde...

Fazit: Im großen und Ganzen kann man TSMCs Zahlen am meisten glauben, da muss man eher mit vornehmer Zurückhaltung rechnen, während Intel gerne übertreibt, GF scheint sich diesem anzuschließen, da sie ihren Prozess 14XM auch mit der "14" schmücken. TSMC spricht dagegen von 16nm, Intel aber bekannterweise von 14nm.
Naja, eventuell brauchen die Finfets etwas mehr geometrischen Platz, oder man kann halt das Zeug anders packen, so das man eben mit 20nm Leitungen auskommt.

Du musst ja dabei auch bedenken, das man mit 20nm eben billigere Masken und auch andere Lacke verwenden kann zum Belichten.

Man wird darüber hinaus auch noch einen höheren Durchsatz haben als bei 14nm Produktion.

Macht meiner Meinung als durchaus Sinn, die Verdrahtung in gröberen Strukturen zu machen, und dabei dann eben zur Not etwas Packungsdichte zu verschenken.

Vor allem kann man damit dann auch mehr Wafer durch die 14nm Anlagen durchjagen, weil man weniger Fertigungsschritte in diesen hat.

Die Tunnelströme zwischen den Transistoren sollte es auch freuen, wenn da etwas weniger Packdichte da ist.

Hängt aber natürlich ALLES! von den genauen Prozessparametern ab, ob das Sinn macht oder nicht. Die werden aber sicherlich wissen, was Sie da machen.

S940

2013-06-07, 22:26:55

Ok dann ist TSMC 33nm. Ohne Quelle nix wert.
So sehe ich das auch. Früher war was vielleicht vergleichbar, heute nicht mehr.Dann sollen sie sich ne neue Metrik ausdenken. Einfach so die Bedeutung zu ändern ist Marketing sonst nix.
Insofern schon mal ein Fortschritt, dass GF bei 14XM keine "nm" mehr ranschreibt :freak:

@Skysnake:
"Bisschen Dichte" ist gut, gegenüber 20nm verbessert sich die Dichte nur um 3%, das ist quasi nix:
http://www.abload.de/img/1370261501-171-foundroyu6a.jpg

Da könnte FDSOI mit 20nm(echt) 14 (Marketing) konkurrensfähig sein.

Skysnake

2013-06-07, 22:43:45

Dann würde es echt keinen Sinn machen, die Verdrahtung in 14nm zu machen. Das würde nur unnötig Kosten verursachen

Ronny145

2013-06-07, 23:08:11

Ohne Quelle nix wert.

Contacted gate pitch is ~118 nm in our initial analysis, with minimum gate length of ~33 nm

TSMC 28nm
28 - .130 - 29nm relative to 40, 30nm relative to 45, 33nm relative to 65, 33nm relative to 90

TSMC 28-nm, gate length ~33-nm
Intel 22-nm, gate length ~26-nm

http://www.chipworks.com/blog/technologyblog/2011/07/12/more-hkmg-hits-the-market-gate-first-and-gate-last/
http://forums.anandtech.com/showpost.php?p=34944480&postcount=447
http://forums.anandtech.com/showpost.php?p=33911437&postcount=83

Nowadays, the term ‘28nm’ or ‘20nm’ does not refer to a gate-length. It is merely a descriptor of a node. So the way to judge the quality of a node is no longer the number attached to it, but the characteristics of the devices made on it.

Daran muss sich jeder langsam gewöhnen. Spätestens mit 14nm kann man das ganz vergessen. Globalfoundries interpretiert das gleich ganz anders.

S940

2013-06-08, 00:55:00

http://www.chipworks.com/blog/technologyblog/2011/07/12/more-hkmg-hits-the-market-gate-first-and-gate-last/
Danke, so kommen wir weiter.
Aber was steht da:
Contacted gate pitch is ~118 nm in our initial analysis, with minimum gate length of ~33 nm, though since this is replacement gate there is no way of knowing absolutely the original poly gate width, which defines the source/drain engineering.Ergo auch nix 100%iges.
Daran muss sich jeder langsam gewöhnen. Spätestens mit 14nm kann man das ganz vergessen. Globalfoundries interpretiert das gleich ganz anders.Jo leider. Wenn das 14XM echt nur 20nm+Finfets ist, ists echt ein schlechter Witz. Aber wie schon gesagt, wenigstens schreiben sie kein nm dran, wenigstens was.
Nur das mit dem "Gewöhnen" ist so ne Sache ... oben im SChaubild haben sie z.B. wieder 14nm XM geschrieben :freak:

Andere Sache:
Wer wusste, das 20nm FD-SOI (immer noch) GateFirst ist? Hände hoch ...
Damit sollte der sog. "14nm FD-SOI" Prozess ne höhere Dichte als bulk oder Finfets haben, gate-first spart ja ca. 30% oder so ein, im obigen Schaubild müsste da dann ein Balken bei ca. 1,9 sein (1,6 (Faktor für GateLast 20nm) + 0,3)

Also unter Strich ist das der beste Prozess - mit Abstand (auf dem Papier)

Fragt sich halt nur, obs GF gebacken bekommt.

HarryHirsch

2013-06-08, 02:43:01

Gibt es inzwischen eigentlich so was wie ein UVD 4?
Ich frage weil ich gerne von einem E350 updaten würde.

Knuddelbearli

2013-06-08, 03:27:26

nö 3 ist aktuell

S940

2013-06-08, 11:54:40

Gibt es inzwischen eigentlich so was wie ein UVD 4?
Ich frage weil ich gerne von einem E350 updaten würde.
UVD interessiert keinen, ergo gibts auch keine Leaks, Infos dazu wirds vermutlich nur zum Kaveri-Launch geben. (Oder meinst Du eventuell Kabini, den Quad-Nachfolger deines E350, der gerade rauskam? In dem Fall wärst Du im falschen Thread ^^)

Knuddelbearli

2013-06-08, 12:15:05

naja x265 wäre schon interessant zumindest für jaguar der als 2 kerner sicher zu schwach sein wird für software lösung in 4k und 3d vermutlich auch sogar als 4 kerner

mboeller

2013-06-18, 06:56:11

Hi;

was könnte mit 7.8 GF/Watt gemeint sein?

http://semiaccurate.com/2013/06/17/amd-announces-seattle-berlin-and-warsaw-for-servers/

Die Folie zu den Steamroller-based "Berlin" Servern spricht zumindest davon.

2014 könnte für AMD auf jeden Fall interessant werden.

[edit]
hat sich erledigt (hätte wohl besser lesen sollen):

According to AMD the switch from a CPU only architecture to an APU design allows “Berlin” to produce 7.8 times the Gigaflops per watt of a current generation Opteron SE.

...für ne APU nicht schwer. :(

Kaveri kann anscheinend wirklich PCI-e 3....wurde ja auch Zeit. Aber wirklich nur DDR3...argg

AnarchX

2013-06-18, 08:34:03

Diverse Kaveri Varianten:
AMD1305.1 = "KV SPECTRE DESKTOP 100W (1305)"
AMD130F.1 = "KV SPECTRE DESKTOP 65W/100W (130F)"
AMD131C.1 = "KV SPECTRE EMBEDDED 35W (131C)"
AMD1313.1 = "KV SPECTRE LITE DESKTOP 65W/100W (1313)"
AMD130A.1 = "KV SPECTRE LITE MOBILE 17W (130A)"
AMD1309.1 = "KV SPECTRE LITE MOBILE 25W (1309)"
AMD130D.1 = "KV SPECTRE LITE MOBILE 35W (130D)"
AMD1304.1 = "KV SPECTRE MOBILE 35W (1304)"
AMD130C.1 = "KV SPECTRE MOBILE 35W (130C)"
AMD1307.1 = "KV SPECTRE SL DESKTOP 100W (1307)"
AMD1315.1 = "KV SPECTRE SL DESKTOP 65W (1315)"
AMD131B.1 = "KV SPECTRE SL EMBEDDED 17W (131B)"
AMD130B.1 = "KV SPECTRE SL MOBILE 17W (130B)"
AMD1306.1 = "KV SPECTRE SL MOBILE 35W (1306)"
AMD130E.1 = "KV SPECTRE SL MOBILE 35W (130E)"
AMD1311.1 = "KV SPECTRE WORKSTATION 100W (1311)"
AMD1310.1 = "KV SPECTRE WORKSTATION 65W (1310)"
AMD1316.1 = "KV SPOOKY DESKTOP 65W (1316)"
http://www.rage3d.com/board/showthread.php?t=34001853

M4xw0lf

2013-06-18, 08:46:51

Spooky Desktop ;D
Großartige Codenamen mal wieder.

AnarchX

2013-06-18, 08:53:28

Spectre ist auch nicht ganz bedeutungslos im GPU-Bereich. ;)

y33H@

2013-06-18, 09:38:53

Kaveri als Berlin mit 2M/4C für Server, "expected" für H1/2014 für FM2+.

http://abload.de/thumb/amd-2014-server-roadm50r6v.jpg (http://abload.de/image.php?img=amd-2014-server-roadm50r6v.jpg)

http://www.pcgameshardware.de/Bulldozer-Codename-238780/News/Server-Roadmap-AMD-Seattle-Berlin-Warsaw-1074820/

S940

2013-06-18, 10:06:14

Kaveri als Berlin mit 2M/4C für Server, "expected" für H2/2014 für FM2+.
Du meinst H1 ;-)

mboeller

2013-06-18, 12:08:17

Du meinst H1 ;-)

aber nur knapp:

http://community.amd.com/servlet/JiveServlet/showImage/38-2545-2548/AMD+Server+Roadmap.jpg

;)

http://community.amd.com/community/amd-blogs/business/amd-operon/blog/2013/06/17/amd-reveals-plans-and-products-to-shake-up-the-enterprise-market-in-2014

mboeller

2013-06-18, 12:17:27

doppel-Post (aber anderes Thema)

Der Berlin-Server wird ja mit dem Opteron 6386SE verglichen.

http://www.cpu-world.com/CPUs/Bulldozer/AMD-Opteron%206386%20SE%20-%20OS6386YETGGHK.html

Also 16 Kerne mit 2800 - 3200 MHz und 140W TDP

Das sind dann 8 Module mit (bei FMAC) je 16 SP-Flops pro Takt, oder?

Also insgesamt 358,4 - 409,6 GFlops

Wenn jetzt der Berlin-server 7,8x Energieeffizenter ist dann wären das ja 800 GFlops bei nur 35W, oder?

S940

2013-06-18, 12:21:07

aber nur knapp:
Nö, H1 ist doch optimal getroffen, Q1 wäre knapp ;-)
(H= Halbjahr, 6 Monate, Q= Quartal, 3 Monate)

Ronny145

2013-06-18, 12:36:10

Keine Steamroller CPU ohne Grafik in 2014. Ob es das überhaupt jemals geben wird, fraglich. Die Zeiteinordnung in der Roadmap würde ich nicht so genau nehmen. Jaguar Opteron ist ab Anfang 2013 eingezeichnet. Kommt das hin? Eher nicht. Im Zweifelsfall geht es dann wieder nur um erste Auslieferungen.

y33H@

2013-06-18, 12:41:05

Wenn jetzt der Berlin-server 7,8x Energieeffizenter ist dann wären das ja 800 GFlops bei nur 35W, oder?Berlin hat eine GCN-GPU, zuletzt hieß es mit 8 CUs. Das macht 512 ALUs und selbst bei 800 MHz spucken die schon über 800 GFLOPS aus. Dazu noch 2 CUs mit Steamroller und schon haben wir im Vergleich zu einem Abu Dhabi eine tolle Perf/Watt ratio. Auf dem Papier.

EDIT
AMD sprach auf dem FAD12 von 1.050 GFLOPS für Kaveri bei 512 ALUs und 2M/4C.

robbitop

2013-06-18, 15:02:21

In der Roadmap ersetzen die ARM SoCs die Katzen-SoCs. Ich hätte gedacht, das wäre für unterschiedliche Segmente...?

Dass Steamroller doch nur mit 4 Kernen antanzt (bei 2 Modulen) spricht btw. gegen die Spekulationen mit 4 Kernen pro Modul...

HOT

2013-06-18, 15:21:34

Es ging ja um 2 Kerne mit 4 Threads pro Modul. Dass er die 3000er-Serie ersetzt und Warschau nur mit 12-16 angegeben ist, spricht eigentlich eher für die 8 Threads... Das heißt ja im Klartext: Für 1-8 nehme Kaveri, mehr als 8 nehme Warschau.

AnarchX

2013-06-18, 15:42:15

Die Steamroller-Architektur wurde doch schon lange von AMD beschrieben und ebenso würde man wohl 8 Threads pro Chip ein gutes halbes Jahr vor dem Launch kaum noch geheim halten. Im Endeffekt wird dieser Die-Shot wohl möglich Excavator sein.

Bei den MCM-G34-CPUs sind die teildeaktiverten 2*1M/2M-Module wohl nicht sonderlich gefragt, sodass man vielleicht den Kunden die Konfiguration überlässt, ähnlich wie bei den Jaguar Opterons.

mboeller

2013-06-18, 16:53:36

Nö, H1 ist doch optimal getroffen, Q1 wäre knapp ;-)
(H= Halbjahr, 6 Monate, Q= Quartal, 3 Monate)

ich wollte eher auf Q4/2012 hinaus. Die "Berlin" CPU sollte ja laut Roadmap ab Januar 2014 verfügbar sein. ;)

Berlin hat eine GCN-GPU, zuletzt hieß es mit 8 CUs.

Weiß ich ja. :)
[edit] du hast aber reicht, so viel besser als ein Richland A10-5750M ist das auch nicht.

2phil4u

2013-06-18, 18:29:11

ill-fated Bulldozer

manlernt nie aus.;D

S940

2013-06-18, 22:41:58

robbitop

2013-06-19, 01:13:40

Die Steamroller-Architektur wurde doch schon lange von AMD beschrieben und ebenso würde man wohl 8 Threads pro Chip ein gutes halbes Jahr vor dem Launch kaum noch geheim halten. Im Endeffekt wird dieser Die-Shot wohl möglich Excavator sein.

Ein DIE-Shot einer AMD CPU, die in 1...1,5 Jahren erscheint? AMD ist nicht Intel. Ein DIE Shot heißt, dass man Silizium haben muss. Das ist bei AMD wirklich sehr selten so lange vor dem Launch der Fall.

S940

2013-06-19, 01:31:07

Ein DIE-Shot einer AMD CPU, die in 1...1,5 Jahren erscheint? AMD ist nicht Intel. Ein DIE Shot heißt, dass man Silizium haben muss. Das ist bei AMD wirklich sehr selten so lange vor dem Launch der Fall.Ich halt das Ding mittlerweile eher auch für ne Fälschung ... das linke obere Eck sieht zu komisch aus, und die Sache mit den fehlenden µCode-Roms hat mir auch keiner wirklich erklären können.
Dachte noch es könnte ein Steamroller 40h sein, die 20h Piledriver waren schließlich auch etwas anders, aber das Ding ist zu krass. Für Excavator ists aber zu früh, wenn der auch noch in 28nm käme, kann sich AMD einsalzen lassen. Alles andere als 20 wär blamable, ab eben das gibts noch nicht von TSMC/GF. Ergo kanns auch noch keine Dieshot davon geben.

Bliebe noch die Möglichkeit eines Testchips mit 32nm .. aber das wär sch..ön teuer. Jetzt in AMDs Sparzeiten machen sie sowas sicher nicht.

HarryHirsch

2013-06-19, 01:34:19

Was ist eigentlich mit UVD 4?
*nerv*
Noch weniger Verbrauch beim Fern schauen wären schon schön.

S940

2013-06-19, 10:57:11

Lol, nerv AMD und nicht uns. Wenns was Neues gibt, stehts hier, wenn nicht, dann nicht.
Es wurden jetzt Opteron-APUs präsentiert da interessiert UVD nun wirklich 0,0.

reaperrr

2013-06-19, 13:18:00

Ich halt das Ding mittlerweile eher auch für ne Fälschung ... das linke obere Eck sieht zu komisch aus, und die Sache mit den fehlenden µCode-Roms hat mir auch keiner wirklich erklären können.
Dachte noch es könnte ein Steamroller 40h sein, die 20h Piledriver waren schließlich auch etwas anders, aber das Ding ist zu krass. Für Excavator ists aber zu früh, wenn der auch noch in 28nm käme, kann sich AMD einsalzen lassen. Alles andere als 20 wär blamable, ab eben das gibts noch nicht von TSMC/GF. Ergo kanns auch noch keine Dieshot davon geben.

Bliebe noch die Möglichkeit eines Testchips mit 32nm .. aber das wär sch..ön teuer. Jetzt in AMDs Sparzeiten machen sie sowas sicher nicht.
Oder die Gerüchte von einem stark verbesserten Steamroller B stimmen, der Dieshot ist wirklich von einem Kaveri-Modul, die Einstampfung des ursprünglich geplanten dritten Moduls wurde wegen des immens gestiegenen Durchsatzes pro Kern durchgeführt, und AMD hält das ganze absichtlich geheim um Intel völlig unvorbereitet auf dem falschen Fuß zu erwischen.

Hey, ich darf doch träumen, oder?:D

S940

2013-06-19, 13:22:31

Darfst Du, aber beim Aufwachen könntest DU die Realität dann für nen Albtraum halten ^^

M4xw0lf

2013-06-19, 13:43:42

Ist sie das nicht seit Jahren...? ;)

Gipsel

2013-06-19, 14:57:01

Ich halt das Ding mittlerweile eher auch für ne Fälschung ...Das wäre ziemlich viel Aufwand. Aber sicher, möglich ist es immer.
Für Excavator ists aber zu früh,Die erste Revision solcher CPUs kommt immer mindestens 1 Jahr vor dem geplanten Launch aus dem Ofen bzw. von der Fab zurück. Auch bei AMD. Die Validierung dauert mehrere Monate und einen oder zwei Spins benötigt man meist ja auch noch.
wenn der auch noch in 28nm käme, kann sich AMD einsalzen lassen. Alles andere als 20 wär blamable, ab eben das gibts noch nicht von TSMC/GF. Ergo kanns auch noch keine Dieshot davon geben.Na klar gibt es schon 20nm Runs sowohl bei GF als auch bei TSMC. Und da testet und optimiert nicht nur GF/TSMC ihren Prozeß, das steht Kunden auch schon für genau solche Testchips zur Verfügung (edit: GF hat z.B. gesagt, daß "our Fab 8 in New York began running full-loop 20nm silicon in January [2012]. We have multiple active customer design activities with silicon delivery expected by 2H 2012.", und eine weitere Pressemeldung aus dem August 2012, daß momentan [also im August 2012] 20nm Cortex A#-Testchips durch GFs Fab8 laufen; bei TSMC lag das terminlich ähnlich, im April diesen Jahres haben sie gesagt: "20nm planar HKMG [high-k metal gate] technology has already passed risk production with a very high yield and we are preparing for a very steep ramp in two GIGAFABs"). Die Yields werden natürlich anfangs noch miserabel und auch sehr variabel sein, aber die korrekte Funktion eines Designs kann man auch testen, wenn man von einem kleinen Waferrun (nur eine Handvoll Wafer werden bearbeitet) ein paar halbwegs funktionsfähige Chips (Takt ist ja erstmal egal) runterbekommt. Mit Yields im tiefen einstelligen Prozentbereich kann man da locker leben. Also das ist kein Argument. ;)

Da dürften demnächst auch Kunden mit dem Testen anfangen (falls sie es nicht schon tun):
https://semiaccurate.com/assets/uploads/2013/01/Glofo_14nm_wafer.jpg

Bild ist aus dem Januar.

AnarchX

2013-06-19, 21:04:32

Auf den Japan Folien zu Berlin stehen sogar noch einmal die 512SPs drauf:
http://www.4gamer.net/games/107/G010782/20130619106/SS/014.jpg
http://www.4gamer.net/games/107/G010782/20130619106/screenshot.html?num=014
Da hat AMD Japan wohl die Änderung nicht mitbekommen: http://semiaccurate.com/2013/06/17/amd-announces-seattle-berlin-and-warsaw-for-servers/amd-berlin-slide/

VinD

2013-06-19, 21:39:36

Alt: 2 x 1,8 = 3,6
Neu mit 4 Threads: 2x1,9x1,5 = 5,7
Durchsatzplus insgesamt für Multithread: +58%

das sind dann aber für 8Threads 5,7 ... SMT+CMT ist rein rechnerisch unter reinem SMT und CMT anzusiedeln.

Klassisch - Intel - BD ---- "SR"
T0 ------- 1 ----- 0.8 -- 1
T1 ------- 0.35 -- 0.8 -- 0.45
T2 ------- 1 ----- 0.8 -- 0.9
T3 ------- 0.35 -- 0.8 -- 0.41

Fläche: -- 2.2 ---- 3.4 --- 3.6
Summe: - 2.7 ---- 3.2 --- 2.76
L/F ------ 1.23 -- 0.94 -- 0.77

*alles in Relation zu einem vollwertigem Kern

S940

2013-07-03, 02:27:45

Erste Steamroller-APU bei Boinc gesichtet
(http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1372810657)

Skysnake

2013-07-03, 07:12:34

Mal als Richtwert zum Vergleich mein i7-920@3,5-3,65 MHz (Turbo ist halt an...)

3156 floating points MIPS (Whetstone) per CPU
10205 integer MIPS (Dhrystone) per CPU

M4xw0lf

2013-07-03, 07:24:25

Der Steamroller lief mit nur ca 2 GHz, sowie 1,2 GHz NB-Takt und ist außerdem noch A0-Stepping... Also alles noch recht weit weg von final.

mboeller

2013-07-03, 08:22:32

Erste Steamroller-APU bei Boinc gesichtet
(http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1372810657)

läuft die APU in dem Test wirklich mit 1,8GHz?

Vergleich mit Vishera @ 4GHz:

Wetstone = 3065 FP-Mips
Drystone = 10799 INT-Mips

=>
Wetstone (also FP?) = 504,7 / 3065 = ~1/6
Drystone (also INT) = 2544,64 / 10799 = 0,235

Also entweder funktionieren die FP-Einheiten sehr schlecht, oder die INT-Leistung hat pro Takt um ca. 50% zugelegt. Wenn die FP-einheiten gleich stark geblieben sind (und darauf weisen eigentlich alle Infos hin) dann sollte das Testsample ja nur mit 1/3 des Vishera Takts gelaufen sein, also 1,3 GHz.

Dann wäre die INT-Leistung aber massiv besser geworden. 10799 / 4 GHz / 8 Threads = 337 pro GHz pro Thread

Beim Kaveri wären es aber 2544,64 / 4 Threads / 1,3GHz = ~490

490 / 337 = +45% !

Also entweder "kacken" die FP-Einheiten in dem Eng.Sample komplett ab wenn die 1,8GHz stimmen oder aber die INT-Einheiten legen massiv zu.

oder ich bin auf dem komplett falschen Dampfer :)

Skysnake

2013-07-03, 10:22:46

Ne seh ich ähnlich.

S940

2013-07-03, 18:31:05

Da gibts noch ne kleine Besonderheit des Benches .. einer ist multithread, der andere singlethread. Da im Boinc Event Log zuerst FP angezeigt wird, nehm ich an, dass der FP mth. ist, da der mth. Bench als erstes läuft.

In jedem Fall muss man INT/FP aber getrennt betrachten.

Gipsel

2013-07-03, 18:41:56

Der BOINC-Bench ist sowieso Schrott. Der reagiert nur auf bestimmte Architektursachen überhaupt und liefert typischerweise sogar über verwandte Architekturen (mit teils deutlich unterschiedlicher RealWorld-Leistung) hinweg praktisch ein Produkt aus einem konstanten Multiplikator und der Taktfrequenz als Ergebnis zurück. Die Korrelation mit der wirklichen Leistungsfähigkeit ist überaus schlecht bis kaum vorhanden.

S940

2013-07-03, 18:50:00

Ja und dann noch die Unterschiede zw. den einzelnen Versionen. Leider kennt man die Version nicht, dazu bräuchte man ne fertige WUs. Die sind aber alle schon gelöscht. Eine gibts noch, aber das ist nur ein Timeout ohne Inhalt :(

Eigentlich müsste man mal den Benchmark sinnvoll umprogrammieren ist ja alles open source ^^

Langfristig würde sich das sicher rentieren, die ersten Leaks kommen recht oft von Boinc.

MR2

2013-07-04, 22:00:22

Hiroshige Goto fasst zusammen
"AMD „Kaveri“: Architektur-Änderungen im Überblick"

http://www.computerbase.de/news/2013-07/amd-kaveri-architektur-aenderungen-im-ueberblick/

Akkarin

2013-07-04, 22:17:27

Die „Kaveri“-APU wird bekanntlich erstmals im 28-nm-Bulk-Prozess bei Globalfoundries gefertigt,

Was ist mit 28nm FDSOI passiert ?

Duplex

2013-07-05, 00:33:40

Was ist mit 28nm FDSOI passiert ?
Ist doch egal ob PDSOI, FDSOI oder bulk, 28nm ist sowieso nur half-node...
Wichtig ist das die Architektur bei der IPC & GPU Fortschritte macht, der CPU Takt wird kaum höher als Richland ausfallen.

Locuza

2013-07-05, 07:38:00

Ist doch egal ob PDSOI, FDSOI oder bulk, 28nm ist sowieso nur half-node...

:freak:

28nm FDSOI soll ein half-node Vorteil gegenüber 28nm Bulk bieten können.
Die Vorteile lesen sich teilweise echt traumhaft.
Aber man weiß ja, man sollte etwas Abstand vom Candy-Man halten. ;)

Mir stellt sich weiterhin nur die Preisfrage ob es 28nm Bulk oder 28nm SOI sein wird, da GloFo auch einen 28nm SHP auf einer Roadmap geführt hat.

S940

2013-07-05, 11:05:41

Wenn dann PD-SOI / SHP. Dazu gabs wenigstens nen kleinen Informationsfetzen, als der GF-Tpye sagte, dass AMD damit seine CPUs herstellen würde, zu FD-SOI dagegen gabs direkt 0, das liest sich nur gut. Bei 28nm kann mans wohl abhaken.

So wies aussschaut hat AMD sich etwas "entschleunigt", lieber kleine Schritt, aber die dafür ohne Verschiebungen und dicke Bugs. Das rentiert sich dann sogar, wenn man gleich die A1-Revisionen verkaufen kann, die es früher nur als Samples gab. Ein Jahr später dann ne entbuggte Rev. mit schönem Leistungsplus - ohne viel Investition. AMD könnte damit gut fahren. Richland ist besser als Trinity und VIshera besser als die ersten FXe, obwohl technisch da nicht viel Unterschied ist.

Jetzt will AMD sogar nochmal ne neue Revision für die Opterons rausbringen, da bin ich mal gespannt, was da Kleines mit großer Wirkung geändert wird.

Zurück zu den Herstellungsprozessen:
Vermutlich wird AMD da ähnlich konservativ sein. Erstens aus obiger "Vorsichtsstrategie" zweitens sind sie seit GFs 32nm Problemen und 28nm Fiasko ein gebranntes Kind.

28nm FDSOI fällt also aus, wäre zu neu und kam auch zu kurzfristig. Das Teil basiert auch auf den LP-Libraries, da hätte man bestehende SHP-Designs dann doch stärker umstricken müssen.

Zusammen mit dem Streichen der 20nm SHP-Node mach 28nm SHP am meisten Sinn. Bisschen besser als Bulk, nicht viel Unterschied zum normalen 28nm Prozess und da man davon ausgehen kann, dass AMD später auf 20nm wechselt und länger auf 28 setzt (wg. obiger konservativen Herangehensweise), lässt es den Abstand nicht zu groß werden.

Vermutlich warten sie dann ab, was GF auf die Reihe bekommt, Finfets oder FDSOI @20nm und nimmt dann das was funktioniert. Als Test könnten sie ja wahlweise nen ARM-Opteron oder ne Jaguar-APU auf beide Prozesse shrinken.

Locuza

2013-07-05, 11:35:29

So wies aussschaut hat AMD sich etwas "entschleunigt", lieber kleine Schritt, aber die dafür ohne Verschiebungen und dicke Bugs.

Die kleineren Schritte resultieren am Ende aber dennoch in eine Verschiebung, sei es mangelndes Geld, GloFos Probleme oder sonst was.
Kaveri war vermutlich nichts bis auf den letzten Drücker 2013 geplant, wo man Richland ein paar Monate vorschiebt, von dem vorher nie die Rede war.

Kriton

2013-07-05, 15:19:11

So wies aussschaut hat AMD sich etwas "entschleunigt", lieber kleine Schritt, aber die dafür ohne Verschiebungen und dicke Bugs. Das rentiert sich dann sogar, wenn man gleich die A1-Revisionen verkaufen kann, die es früher nur als Samples gab. Ein Jahr später dann ne entbuggte Rev. mit schönem Leistungsplus - ohne viel Investition. AMD könnte damit gut fahren. Richland ist besser als Trinity und VIshera besser als die ersten FXe, obwohl technisch da nicht viel Unterschied ist.

Jetzt will AMD sogar nochmal ne neue Revision für die Opterons rausbringen, da bin ich mal gespannt, was da Kleines mit großer Wirkung geändert wird.

Read hatte doch ein schnelleres time to market seitens AMD angekündigt. Sieht man doch auch schon bei den Grafikkarten.

S940

2013-07-05, 15:56:07

Kaveri war vermutlich nichts bis auf den letzten Drücker 2013 geplant, wo man Richland ein paar Monate vorschiebt, von dem vorher nie die Rede war.
Kaveri war halt noch Altplanung, Richland das kleine aber feine Trinityupdate für lau.

Read hatte doch ein schnelleres time to market seitens AMD angekündigt. Sieht man doch auch schon bei den Grafikkarten.Jo, aber wieviel neue Grafikkarten gabs in letzter Zeit? Die 7790 und sonst?

Worüber man noch spekulieren könnte wäre, dass AMD im Moment nur so lahm ist, da sie mit 2 Konsolen SoCs beschäftigt waren, aber falls das stimmt sollte AMD dann 2014 nen Strauß neuer Produkte für 2015 verkünden. Ich glaubs aber im Moment nicht.

Kriton

2013-07-05, 16:06:23

Jo, aber wieviel neue Grafikkarten gabs in letzter Zeit? Die 7790 und sonst?

Ich bezog das auf die Art und Weise wie sie neue Karten in den Handel bringen: Stichwort: GCN 1.1
Also evolutive Änderungen welche bereits eingebracht werden wenn eine oder einzelne neue Karten kommen im Gegensatz zu den bisherigen Generationswechseln.

Duplex

2013-07-05, 16:23:23

28nm FDSOI soll ein half-node Vorteil gegenüber 28nm Bulk bieten können.
Die Vorteile lesen sich teilweise echt traumhaft.
Aber man weiß ja, man sollte etwas Abstand vom Candy-Man halten. ;)

Intels 22nm Prozess sieht auf dem Papier wegen den 3D Transistoren auch gut aus, aber was haben die letzten beiden Generationen bzgl. Taktbarkeit für Vorteile gegenüber 32nm SB gebracht, garnichts! AMD braucht 28nm nicht Primär wegen den SR Kernen, sondern wegen der GPU. Das CPU Design wird wegen den besseren Frontend so oder so Leistungsfähiger als BD werden.

Akkarin

2013-07-05, 16:45:18

Sowohl Architectur als auch Prozess sind bei IVB auf stromsparen ausgelegt. Vergleich mal den verbrauch von Ivy und Sandy CPUs, vor allem auch im mobile bereich. Das da nicht mehr so viel für takt übrig bleibt ist klar. Z.t. kommt auch noch hinzu, dass der Die nicht mehr an den Heatspreader verlötet ist.

Zu sagen 22nm hat keinen vorteil in der taktbarkeit gebracht mag stimmern, aber das bedeutet nicht das es keinen vorteil gab.

Gipsel

2013-07-05, 17:45:00

Ich bezog das auf die Art und Weise wie sie neue Karten in den Handel bringen: Stichwort: GCN 1.1
Also evolutive Änderungen welche bereits eingebracht werden wenn eine oder einzelne neue Karten kommen im Gegensatz zu den bisherigen Generationswechseln.Der einzige Chip mit GCN1.1-Architektur am Markt ist Temash/Kabini. Bonaire (HD7790) und auch der kleinere Mars/Oland sind noch Original-GCN. Es gibt bisher keine diskrete Karte mit GCN1.1.

mczak

2013-07-05, 18:30:03

Der einzige Chip mit GCN1.1-Architektur am Markt ist Temash/Kabini. Bonaire (HD7790) und auch der kleinere Mars/Oland sind noch Original-GCN. Es gibt bisher keine diskrete Karte mit GCN1.1.
Bonaire (aber nicht Mars/Oland) ist GCN 1.1.
Benötigt zumindest im Linux-Treiber genau dieselbe Initialisierung wie Kabini/Kaveri (Compute-Queue Initialisierung etc. ist ja definitiv verschieden, die Aenderungen scheinen ja auf den ersten Blick nicht so gross, der Code ist aber verschieden genug dass er komplett von SI gesplittet wurde (der Hauptteil findet sich hier, http://cgit.freedesktop.org/~airlied/linux/tree/drivers/gpu/drm/radeon/cik.c?h=drm-next)). Wird dort übrigens unter "CIK" Familie geführt, was auch immer das heissen mag ("CI" stand doch mal für "Sea Islands", also vielleicht Sea Islands + Kabini/Kaveri?).

Gipsel

2013-07-05, 19:47:43

Offenbar hast Du recht (Dave Baumann hat das auch mal erwähnt (http://beyond3d.com/showthread.php?p=1724886#post1724886)). Das hat AMD damals bei der Vorstellung aber ziemlich unter den Tisch gekehrt. Das haben die auf keiner der Folien wirklich erwähnt oder hat jemand das komplette pdf, was an die Presse ging, wo das drin stand? Weißt Du zufällig ob da auch die neueren ACEs (aber eben nur 2 davon) drinstecken oder nur die Evolution der CUs?

mczak

2013-07-05, 20:21:06

Naja also zumindest bei anandtech wurde GCN 1.1 beim 7790 Review thematisiert.

Aus dem Code:
/*
* CP.
* On CIK, gfx and compute now have independant command processors.
*
* GFX
* Gfx consists of a single ring and can process both gfx jobs and
* compute jobs. The gfx CP consists of three microengines (ME):
* PFP - Pre-Fetch Parser
* ME - Micro Engine
* CE - Constant Engine
* The PFP and ME make up what is considered the Drawing Engine (DE).
* The CE is an asynchronous engine used for updating buffer desciptors
* used by the DE so that they can be loaded into cache in parallel
* while the DE is processing state update packets.
*
* Compute
* The compute CP consists of two microengines (ME):
* MEC1 - Compute MicroEngine 1
* MEC2 - Compute MicroEngine 2
* Each MEC supports 4 compute pipes and each pipe supports 8 queues.
* The queues are exposed to userspace and are programmed directly
* by the compute runtime.
*/

Scheint auf jeden Fall für Kabini/Kaveri/Bonaire gleich zu sein. Wobei ich dachte Kabini hätte nur einen "MEC" (4 compute pipes). Ich blicke da nicht ganz durch wie das im Vergleich zu GCN 1.0 aussieht. Hatte es dort keinen eigenen compute CP und was genau war denn da ein ACE. Der SI-Code hat leider keinen solch schönen Kommentar :-).

Gipsel

2013-07-05, 22:45:02

mczak

2013-07-05, 23:55:40

So weit hatte ich da erst gar nicht gelesen. Aber wenn mal ein wenig genauer schaut, gibt es Fallunterscheidungen bei der Initialisierung. Nur bei Kaveri wir Microcode für zwei MECs geladen, sonst nur für einen. Und da findet sich auch noch das hier:
* KV: 2 MEC, 4 Pipes/MEC, 8 Queues/Pipe - 64 Queues total
* CI/KB: 1 MEC, 4 Pipes/MEC, 8 Queues/Pipe - 32 Queues total
*/
if (rdev->family == CHIP_KAVERI)
rdev->mec.num_mec = 2;
else
rdev->mec.num_mec = 1;
rdev->mec.num_pipe = 4;
rdev->mec.num_queue = rdev->mec.num_mec * rdev->mec.num_pipe * 8;
Also sind die Blockdiagramme von Bonaire, die nur zwei ACEs zeigen offenbar falsch. Das sollten genau wie bei Kabini vier sein.
Ah ja tatsächlich. Die 2 MECs scheinen also eher ein Maximum der Familie zu sein, der Rest ist aber immer gleich. Müsste ich raten würde ich sagen bei Kabini surde der zweite MEC weggespart weil der definitv für den Minichip Overkill wäre während bei Bonaire als diskretem Chip ebenfalls kein Bedarf da ist da eher nicht zu erwarten ist dass man soviele Queues braucht - nur bei Kaveri macht das also Sinn. Ist ja übrigens interessant die Chip-Initialisierung des Kaveri ist an anderer Stelle unvollständig, das möchte man ja eigentlich so nicht im Kernel-Treiber haben.
Die RLC-Firmware ist offenbar auch ziemlich unterschiedlich zwischen Kabini/Kaveri und Bonaire, ist doch letztere deutlich kleiner. Hängt aber womöglich auch damit zusammen dass letzterer ein diskreter Chip ist.

YfOrU

2013-07-06, 02:29:57

Intels 22nm Prozess sieht auf dem Papier wegen den 3D Transistoren auch gut aus, aber was haben die letzten beiden Generationen bzgl. Taktbarkeit für Vorteile gegenüber 32nm SB gebracht, garnichts! AMD braucht 28nm nicht Primär wegen den SR Kernen, sondern wegen der GPU. Das CPU Design wird wegen den besseren Frontend so oder so Leistungsfähiger als BD werden.

Darum geht es heute nicht mehr. Der Fokus liegt allgemein auf Mobility und damit zwangsläufig auf Effizienz. Intel packt in die 15W TDP eines 1,5 Ghz Kabini Quad (und das ist AMDs LP Serie) Big-Core Produkte wie den i7-4650U mit 2.9 GHz DC Turbo. Da liegen ganze Welten dazwischen. AMD braucht insgesamt dringend Produkte welche unterhalb von 50 Watt wirklich konkurrenzfähig sind.

fondness

2013-07-06, 08:53:41

Darum geht es heute nicht mehr. Der Fokus liegt allgemein auf Mobility und damit zwangsläufig auf Effizienz. Intel packt in die 15W TDP eines 1,5 Ghz Kabini Quad (und das ist AMDs LP Serie) Big-Core Produkte wie den i7-4650U mit 2.9 GHz DC Turbo. Da liegen ganze Welten dazwischen. AMD braucht insgesamt dringend Produkte welche unterhalb von 50 Watt wirklich konkurrenzfähig sind.

Der Vergleich hinkt. Kabini ist vor allem auch Low-Cost. Natürlich kann man nicht gegen hochselektierte Produkte antreten. Es gibt auch Richland ULVs Prozessoren mit ähnlicher TDP und mehr Leistung. Aber natürlich hat Intel dank des 22nm FinFET-Prozesses einen gehörigen Vorteil was Perf/Watt betrifft und natürlich ist diese Vorteil immer wichtiger. Ob allerdings hier irgendwer mit Intel mithalten kann solange sie mehrere Jahre vor der Konkurrenz liegen was die Fertigung betrifft darf getrost bezweifelt werden. Mit Silvermount bekommen dann auch Größen wie Qualcomm ein Problem.

Undertaker

2013-07-06, 09:36:56

Der Vergleich hinkt. Kabini ist vor allem auch Low-Cost. Natürlich kann man nicht gegen hochselektierte Produkte antreten. Es gibt auch Richland ULVs Prozessoren mit ähnlicher TDP und mehr Leistung.

Singlethread ja, aber bzgl. Multi-Thread-Leistung schlägt Kabini die komplette hausinterne Konkurrenz. Der A4-5000 mit 15 Watt ist hier rund 50% schneller als der A6-4455M mit rund 20 Watt für CPU + Chipsatz; daran wird auch Richland nichts entscheidendes ändern können. Wenn Kabini nur einen vernünftigen CPU-und GPU-Turbo für alle Modelle hätte, wären die Trinity- und Richland-ULVs der 17W-Klasse praktisch überflüssig.

fondness

2013-07-06, 09:49:31

Singlethread ja, aber bzgl. Multi-Thread-Leistung schlägt Kabini die komplette hausinterne Konkurrenz. Der A4-5000 mit 15 Watt ist hier rund 50% schneller als der A6-4455M mit rund 20 Watt für CPU + Chipsatz; daran wird auch Richland nichts entscheidendes ändern können. Wenn Kabini nur einen vernünftigen CPU-und GPU-Turbo für alle Modelle hätte, wären die Trinity- und Richland-ULVs der 17W-Klasse praktisch überflüssig.

Richland ist gerade in diesem Grenzbereich energieffizienter als Trinity, der A8-5545M wird bei nur 19W TDP (plus vielleicht 2-3W für den Chipsatz) zB einen A6-5200 mit 25W schlagen. Ist aber auch egal. Jedenfalls ist Kabini ein SoC mit weniger als 120mm² Die-Fläche in einem 28nm bulk Prozess von der Stange, das ist aus preissicht einfach nicht vergleichbar mit irgend welchen ULV-Prozessoren auf hochoptimierten Prozessen.

Undertaker

2013-07-06, 09:57:23

Multithreaded ist das sehr unwahrscheinlich, der Trinity-Vorgänger A8-4555M ist noch nicht einmal so schnell wie der A4-5000. Das Kabini allerdings in höheren Taktbereichen ineffizient wird - der A6-5200 ist da das Extrembeispiel - ist natürlich klar. Ebenso, dass man Kabini eher mit der kommenden Atom-Generation vergleichen muss.

YfOrU hat aber Recht wenn er sagt, dass AMDs größte Schwierigkeiten derzeit ganz klar im ULV-Bereich liegen.

YfOrU

2013-07-06, 10:07:03

Der Vergleich hinkt.... Natürlich kann man nicht gegen hochselektierte Produkte antreten.

Im Großen und Ganzen würde ich bei Haswell ULT nicht von hoch selektiert sprechen. Zum einen konnte Intel den Markt bereits bei IB problemlos mit 17W CPUs fluten und zum anderen spricht es für sich wenn die ULT Varianten vor allen anderen Dualcores auf den Markt gebracht werden (DC Turbo im Mittel bei 2,6Ghz).

Kabini ist vor allem auch Low-Cost
Sehe ich auch so. Kabini ist tendenziell mehr Low-Cost als Low-Power. Meiner Ansicht nach wäre hier durchaus ein gutes Stück mehr möglich gewesen (Effizienz und Performance). Mit den "Big-Cores" kann AMD in diesem Segment einfach wenig ausrichten und daran dürfte auch Kaveri kaum etwas ändern. Klar, kleine Brötchen backen aber bei einer guten ULV CPU (APU) gibt es halt auch höhere Margen und der Markt ist in jeden Fall vorhanden. AMD hat die IP und die 28nm Fertigung bei TSMC ist mit Blick auf Qualcomm (->S800, 28nm HPm) ziemlich gut. Gegenüber den i3 (ULT) hätte man sich mit einem etwas aggressiveren Design auf Jaguar Basis vermutlich ganz gut positionieren können und ich denke nicht das es so viel teurer (Entwicklung, Fertigung) geworden wäre.

...
Ebenso, dass man Kabini eher mit der kommenden Atom-Generation vergleichen muss.

Das ist etwas problematisch da Silvermont vor allen auf untere bis mittlere einstellige TDP Bereiche abzielt während Jaguar am Ende eher zweistellig ist.

AnarchX

2013-07-16, 12:27:01

AMD Kaveri supply may be delayed to early 2014: http://www.digitimes.com/news/a20130716PD202.html

Ronny145

2013-07-16, 12:30:39

Überraschend ist das nun wirklich nicht. Launch Anpassungen sind Normalität. Realistisch gesehen sind Kaveri Notebooks nicht vor mitte 2014 zu erwarten gewesen. Desktop Modelle könnten mit Glück im Frühjahr auf den Markt kommen.

AnarchX

2013-07-16, 12:39:14

Aber selbst Desktop erwartet man nicht vor April.

Bzgl. Codenamen und dem im Artikel genannten Kaveri Nachfolger Carrizo:
• Worked in the APU Emulation group on the Single Emulation/Simulation Work Area and Build Flow project for the Kaveri, Carrizo and Basilisk APUs.
http://www.linkedin.com/pub/curtis-rantz/9/432/b58/de

Ronny145

2013-07-16, 12:45:22

Geändert hat sich genau genommen das:

mass production will not be ready until the end of 2013

Für Ende 2013 war anfangs die Auslieferung von Desktop Modellen geplant. Jetzt ist zu dem Zeitpunkt die Massenfertigung geplant. Das ist eine Verschiebung von 2 Monaten? 3 Monaten? Und vielleicht nicht die letzte Verschiebung.

S940

2013-07-16, 13:50:25

Geändert hat sich genau genommen das:

Für Ende 2013 war anfangs die Auslieferung von Desktop Modellen geplant. Jetzt ist zu dem Zeitpunkt die Massenfertigung geplant. Das ist eine Verschiebung von 2 Monaten? 3 Monaten? Und vielleicht nicht die letzte Verschiebung.

Jupp klingt nach nem weiteren, nötigen Metal-Gate-Respin.
Wenn der ursprüngliche Kaveri für April Rev. A war, dann ist/war der aktuell im Dez. geplante B0 und jetzt brauchts anscheinend noch ne B1-Version. Schade, aber besser so, als nachträglich ein TLB-Bug-Fiasko :(

Duplex

2013-07-16, 14:04:15

Wahrscheinlich auch Probleme beim Prozess von GF.

R.I.P.

2013-07-16, 14:22:53

Wie Kacke ist das denn? Schon wieder....mit jedem eher grösseren Chip diesselbe Verspätung.

y33H@

2013-07-16, 16:42:51

Hat jemand ernsthaft an 2013 geglaubt? Lieber ausgereift(er).

dildo4u

2013-07-16, 16:55:41

PS4/Xbox One SOC's werden vor rang haben.

Duplex

2013-07-16, 17:13:00

PS4/Xbox One SOC's werden vor rang haben.
Die Konsolen Chips (Jaguar+GCN) sind synthetische Designs mit ausgereifter 28nm HP bulk Fertigung bei TSMC.
Kaveri ist kein synthetisches Design wie bei den Konsolen Chips, Kaveri ist wie Bulldozer, dazu noch in 28nm SOI von GF, bisher habe ich noch keine 28nm SHP Produkte von GF gesehen.

Coda

2013-07-16, 17:40:20

PS4/Xbox One SOC's werden vor rang haben.
Die sind doch schon längst fertig und in Massenproduktion.

S940

2013-07-16, 17:50:57

Zitat von dildo4u http://www.forum-3dcenter.org/vbulletin/images/3dc/insanedruid/buttons/viewpost.gif (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=9844919#post9844919)
PS4/Xbox One SOC's werden vor rang haben.
Die sind doch schon längst fertig und in Massenproduktion.
Genau das meint er doch :freak:

dildo4u

2013-07-16, 17:56:08

Jup denke nicht das sie 10Mio in einem Monat produzieren,die werden bis Ende 2013 ausgelastet sein.Die Nachfrage wird erst Anfang 2014 geringer wenn ne Weile keine neuen Games kommen.

Schaffe89

2013-07-16, 19:26:22

Sehr sehr schade, wenn überhaupt dann werden wir wahrscheinlich erste flächendeckende Produkte zum Haswell Resfresh sehen.

robbitop

2013-07-16, 23:58:33

Die Konsolen Chips (Jaguar+GCN) sind synthetische Designs mit ausgereifter 28nm HP bulk Fertigung bei TSMC.
Kaveri ist kein synthetisches Design wie bei den Konsolen Chips, Kaveri ist wie
Werden die nicht bei GF gefertigt?

Coda

2013-07-17, 00:12:22

Sicher nicht GF allein. Falls es der GF-Prozess ist, dann wird auch IBM etc. dabei sein.

Kann mir nicht vorstellen, dass Wafer-Kapazität das Problem ist nachdem AMD in letzter Zeit schon mehrfach Strafzahlungen leisten mussten, nachdem sie nicht genügend abgenommen hatten.

S940

2013-07-17, 00:24:44

Kann mir nicht vorstellen, dass Wafer-Kapazität das Problem ist nachdem AMD in letzter Zeit schon mehrfach Strafzahlungen leisten mussten, nachdem sie nicht genügend abgenommen hatten.
Na so kannst Du das auch nicht sagen, schließlich gibts 32nm und 28nm Kapazitäten, das sind 2 Paar Schuhe, das eine (NewYork) hat mit dem anderen (Dresden) nichts zu tun.

Coda

2013-07-17, 01:13:31

Läuft New York überhaupt schon?

Gipsel

2013-07-17, 02:21:50

Läuft New York überhaupt schon?Na klar, schon seit mehr als einem Jahr. Mehr oder weniger. So ganz klar ist nicht, was da am Ende vom Band fällt.

Ronny145

2013-07-27, 15:04:49

These documents also show that AMD’s upcoming Kaveri APU has been delayed. AMD first showed off Kaveri, its first APU to support its heterogeneous, unified memory architecture at Computex, and said it was scheduled for a “late 2013” release date.

According to this revised schedule we obtained, engineering samples of Kaveri won’t be ready until August, production candidate samples will go out in October and initial production will begin in December. The target launch into channel is now mid-February 2014.
http://vr-zone.com/articles/new-confirmed-details-on-amds-2014-apu-lineup-kaveri-delayed/47455.html#ixzz2aFb1vwYt

Kaveri determine postponed until after the second quarter of 2014, ASUS has just released A88X motherboards will continue to use until 2015.

The paper noted that in accordance with our hands, AMD is expected to release in 2013, the Kaveri APU determined from the roadmap postponed until the second quarter of 2014, as the launch date, and is currently unable to confirm.
http://translate.google.de/translate?sl=zh-CN&tl=en&prev=_t&hl=de&ie=UTF-8&u=http://chinese.vr-zone.com/75619/amd-will-use-carrizo-to-replace-kaveri-at-2015-and-scoping-ddr4-07262013/&act=url

Die Verschiebung scheint gesichert zu sein.

S940

2013-07-27, 16:51:02

So ganz klar ist nicht, was da am Ende vom Band fällt.Naja immerhin haben sie den Rockchip ARM-SoC bestätigt, der muss wg. 28nm aus NY kommen.
http://www.globalfoundries.com/newsroom/2013/20130617.aspx

Ronny145

2013-08-05, 15:23:40

Roy Taylor, AMD’s VP of channel sales, had a confusing answer when asked about Kaveri’s delays. He claimed that AMD never said the launch would be before Christmas, and the chip would be available shortly after its formal launch at CES. He chalked up delays to HSA’s marketing not yet being complete, saying the architecture itself was ready to go.

Read more: http://vr-zone.com/articles/hold-for-publication-why-its-a-big-deal-that-amd-is-delaying-kaveri/49389.html#ixzz2b6HjN0KJ

Wie erwartet, im Notfall bezieht sich auf AMD auf sonst irgendwas: Produktions Start, Sample Lieferungen etc. OEMs werden ganz anders mit Infos versorgt. Solange die Roadmaps nicht Confidential ist, ist das mehr Show als brauchbare Info. Bei Kaveri war das das schon seit dem Leslie Sobon während der CES klar. Viele haben die public Roadmap für bare Münze genommen. Auch lustig das er die Verschiebung auf HSA schiebt.

Gipsel

2013-08-05, 15:41:50

Auch lustig das er die Verschiebung auf HSA schiebt.Er schiebt es auf die bisher nicht ausgedachte Marketingstrategie für HSA, was selbst angeblich bereits bereit wäre.
He chalked up delays to HSA’s marketing not yet being complete, saying the architecture itself was ready to go.

boxleitnerb

2013-08-05, 15:44:10

Finde ich dämlich. Wenn man ein Produkt fertig hat, sollte man es auch veröffentlichen. Gerade im Mobilbereich kann AMD jedes Quentchen mehr Performance und Effizienz brauchen. Stattdessen wartet man...

fondness

2013-08-05, 16:03:40

Ronny145

2013-08-05, 16:19:44

Er schiebt es auf die bisher nicht ausgedachte Marketingstrategie für HSA, was selbst angeblich bereits bereit wäre.

Glaubst du ihm das? Also ich nicht. Die Strategieausarbeitung müsste länger dauern als die langwierige APU Entwicklung selber, Utopie ist das. Das klingt nach einer Marketingausrede, um die Architektur selber aus der Schusslinie zu nehmen. Würde sonst ziemlich dämlich klingen, wenn er stattdessen den wahren Grund nennt, etwa Bugs im CPU Design oder der unreifen 28nm Fertigung. Davon abgesehen wäre das sowieso Confidential, er dürfte den wahren Grund ohne AMD Erlaubnis gar nicht nennen.

Locuza

2013-08-05, 16:24:34

Verstehe ich das richtig, theoretisch hätte Kaveri schon nach Weihnachten auf den Markt kommen können, aber weil die Praktikanten die PR-Folien noch nicht fertig haben, wird es vermutlich erst Februar? ;)
Hört sich zunächst plausibel an.

Skysnake

2013-08-05, 16:37:12

Jedenfalls kommt irgendwas mit einer Billiardkugel in Forum einer schwarzen Acht. Denn die hat er jetzt bereits mehrmals her gezeigt und als nächsten APU "Marketingstreich" vorgestellt^^

https://twitter.com/amd_roy/status/362893245543505920
Die 8 wird wohl nur eine Anspielung auf Pool-Billiard (8er Ball), bei der die 8 eben die "finale" Kugel ist, die man noch einlochen muss.

Wenn man scheise baut, zuerst Weiß, dann die 8 kann man sich aber selbst noch ins Aus schiesen ;)

Finde die "Anspielung" passend. HSA wird entweder ziemlich nett, oder nen herber flopp, und das täte AMD richtig richtig weh.

Duplex

2013-08-05, 17:05:21

Gipsel

2013-08-05, 20:08:29

Glaubst du ihm das?So richtig nicht. Deswegen auch das "angeblich" in meinem Satz.
Jedenfalls kommt irgendwas mit einer Billiardkugel in Forum einer schwarzen Acht. Denn die hat er jetzt bereits mehrmals her gezeigt und als nächsten APU "Marketingstreich" vorgestellt^^

https://twitter.com/amd_roy/status/362893245543505920Also wenn die neuen APUs nicht im Sinne eines "Magic 8 Ball" (https://de.wikipedia.org/wiki/Magic_8_Ball) Voraussagen über die Zukunft treffen können, würde mir spontan die Ausweitung des Never Settle Forever (als Never Settle Unlimited) aus APUs in den Sinn kommen. Symbolisiert dann als "Never Settle ∞". Oder die bekommen ganz langweilig einfach einen neuen Namen mit 8xx Series oder so.

Knuddelbearli

2013-08-06, 05:36:28

boxleitnerb

2013-08-06, 07:09:14

Noch billiger verkloppen.

Knuddelbearli

2013-08-06, 07:44:14

tja da haste das problem ja richtig erkannt ^^

noch billiger wäre eben verlustzone

Duplex

2013-08-06, 10:23:47

noch billiger wäre eben verlustzone
Seit Anfang 2012 bis jetzt hat AMD 1,4 Milliarden Verlust gemacht, wie man sieht hat sich das über Jahre zum Standard entwickelt.
Vor 8 Jahren war das Unternehmen viel mehr wert, heute ist man trotz GPUs noch nicht auf den Stand von damals zurück.

Ronny145

2013-08-06, 10:43:26

Jedenfalls kommt irgendwas mit einer Billiardkugel in Forum einer schwarzen Acht. Denn die hat er jetzt bereits mehrmals her gezeigt und als nächsten APU "Marketingstreich" vorgestellt^^

https://twitter.com/amd_roy/status/362893245543505920

Marketingkampagne.

http://www.pcgameshardware.de/A10-6800K-CPU-257454/News/AMD-8-Ball-Werbekampagne-1081540/

fondness

2013-08-07, 16:28:28

Kommando zurück?

"Kaveri is still on track for 2013 ..."

http://seekingalpha.com/article/1606962-advanced-micro-devices-responds-to-kaveri-delays-new-never-settle-bundle?source=feed

Auch bei VR-Zone gab es ein Update:

Update Aug 6: The AMD PR office in Taiwan said that there is no change to Kaveri’s schedule.

http://vr-zone.com/articles/hold-for-publication-why-its-a-big-deal-that-amd-is-delaying-kaveri/49389.html#ixzz2bIGR7lrf

M4xw0lf

2013-08-07, 17:44:05

Das wäre äußerst wünschenswert.

Ronny145

2013-08-07, 18:06:20

AMD's PR department responded and stated that "Kaveri is still on track for 2013 ..."

Ob das gehaltvoll ist? Sehr zweifelhaft. Wie gesagt, vertrauen kann man nur Confidential Roadmaps, die nicht für die Öffentlichkeit gedacht sind. Wenn Vr-zone so eine Roadmap in die Hand bekommen hat, ist von 2014 auszugehen. Es ist doch gar nicht klar, was mit on track gemeint ist. On track für erste Samples im Dezember? Im Zweifel werden die sich darauf berufen. Von (hard)launch ist nirgends die Rede, schaut euch das Taylor Rumgeeiere diesbezüglich an.

Gipsel

2013-08-07, 18:47:02

Still on track for (production in) 2013?

Ronny145

2013-08-07, 18:55:00

Wenn sie das meinen widerspricht das der Vr-zone Meldung nicht, in der steht:

In late July VR-Zone obtained a series of documents given to OEMs by AMD behind closed doors (the document we obtained is heavily watermarked so we can’t post it publicly). This document says that engineering samples of Kaveri won’t be ready until August, production candidate samples will go out in October and initial production will begin in December. The target launch into channel is now mid-February 2014 meaning that consumers will be able to buy the chip until the spring.

On track ist typisch wischiwaschi Marketingantwort. Das ist eine Nullaussage. Dazu passend Taylors Aussage:

Roy Taylor, AMD’s VP of channel sales, had a confusing answer when asked about Kaveri’s delays. He claimed that AMD never said the launch would be before Christmas

Rechtlich ist AMD auf der sicheren Seite solange die Roadmap oder die Aussage nicht genau spezifiziert wird.

Skysnake

2013-08-07, 21:32:48

Ob das gehaltvoll ist? Sehr zweifelhaft. Wie gesagt, vertrauen kann man nur Confidential Roadmaps, die nicht für die Öffentlichkeit gedacht sind. Wenn Vr-zone so eine Roadmap in die Hand bekommen hat, ist von 2014 auszugehen. Es ist doch gar nicht klar, was mit on track gemeint ist. On track für erste Samples im Dezember? Im Zweifel werden die sich darauf berufen. Von (hard)launch ist nirgends die Rede, schaut euch das Taylor Rumgeeiere diesbezüglich an.
Du meinst wohl eher, so lange keine offizielle! Roadmap für die Öffentlichkeit draußen ist, ist alles fürn Arsch!

Denn auf den Confidential steht IMMER! drauf, dass das NUR! Planungen sind, die sich OHNE! Ankündigung jederzeit ändern können. Das hat Aktienrechtlich usw überhaupt gar keine Bedeutung. Eine offizielle Roadmap schon. Da muss dann im Zweifel nämlich auch eine Gewinnwarnung wegen Verschiebung usw usw usw ausgesprochen werden.

Ronny145

2013-08-07, 21:55:42

Du meinst wohl eher, so lange keine offizielle! Roadmap für die Öffentlichkeit draußen ist, ist alles fürn Arsch!

Nein nicht unbedingt. Die Infos müssen davon stammen, das ist Wesentliche.

Denn auf den Confidential steht IMMER! drauf, dass das NUR! Planungen sind, die sich OHNE! Ankündigung jederzeit ändern können.

Das sind immer Planungen.

Eine offizielle Roadmap schon.

Was ist für dich eine offizielle Roadmap?

Skysnake

2013-08-07, 23:16:17

Eine Roadmap die auf Investorenveranstaltungen, bzw eben auf Quartalsberichten usw ausgegeben werden. Also im Rahmen der Veröffentlichungspflichten, denen Firmen aufgrund des Aktiengesetzes unterliegen.

Alles andere kannste in der Pfeife rauchen.

Ronny145

2013-08-07, 23:35:06

Aus Erfahrung raus sind nur Confidential Roadmaps brauchbar, alles andere ist sehr zweifelhaft. Confidential freie sind in aller Regel public Roadmaps für die Masse. Bei Intel enthalten diese nur bekanntes, ja nicht zu viel verraten. Bei AMD zuletzt sind das mehr Show Roadmaps gewesen. Produktionsstart am 31.12.2013? Klar, nehmen wir Kaveri mit auf die 2013er Roadmap drauf. Macht sich besser auf einer Messe, da hat AMD doch gleich was vorzeigbares mit dem sie positive Presse erzeugen können. Aus vergangenen AMD Confidential Roadmaps ist bekannt, dass dort genauere Monatsangaben vom Produktionsstart oder launch drauf sind. Genau das, von dem vr-zone berichtet hat. Diese Infos wirst du auf einer public Roadmap nicht finden.

Skysnake

2013-08-08, 08:48:24

Es ist doch SCHEIS egal, ob Confidentials mehr/bessere Infos enthalten oder nicht. Sie sind schlicht nichtssagend, weil eben NICHT! bindend. Da kannste im Prinzip drauf schreiben was du willst. Bei dem Sach, was offiziell raus geht, muss Hand und Fuß dran sein, weil du ansonsten schnell Probleme mit dem Aktienrecht bekommen kannst...

Ronny145

2013-08-08, 11:23:34

Confidential Roadmaps sind immer offiziell. Bei Intel steht dein subject to change normalerweise immer drauf (edit: bei AMD das gleiche), nur mal so nebenbei. Sollte aber auch selbsterklärend sein. Wenn sie dort Scheiße drauf schreiben wird das auf Dauer bei ihren Abnehmern nicht gut ankommen. Das glaube ich nicht. Nur Confidential Roadmap sind aussagend. Alles andere kannst du knicken.

Skysnake

2013-08-08, 11:52:52

Nein sind Sie eben nicht weil "für den internen Gebrauch".

Und genau da liegt das Problem. Diejenigen, an die die Dinger addressiert sind, wissen immer noch, wie denn das jetzt genau zu verstehen ist, und auf was GENAU sich die Roadmap bezieht. Es handelt sich dabei fast nie um Zeitangaben für Endkunden. Deswegen kannste das ZEug auch in der Pfeife rauchen. Zumal es realtiv normal ist, dass sich derartige Roadmaps hin und wieder auch verschieben. In vielem steckt man ja einfach nicht drin, und das wissen die Leute auch. Bei ner Roadmap für >2 Jahre kann es halt mal dazu kommen, das ein Quartal später wird, Ramps langsamer anlaufen oder what ever.

Das hat aber alles für den Endkunden null Bedeutung. Deswegen kannste dich auch nur auf die offiziellen Roadmaps beziehen, die auf irgendwelchen Investorenveranstaltungen usw der Öffentlichkeit presentiert werden. Die Angaben müssen nämlich stimmen UND! realistisch/belastbar sein. Wenn sich da was ändert, dann kan man von Problemen/Fail reden, bei allem anderen sollte man sich sehr zurückhalten.

Ronny145

2013-08-08, 12:18:16

Nein sind Sie eben nicht weil "für den internen Gebrauch".

Was bedeutet für dich interner Gebrauch? Confidential Roadmaps sind für Hardware Partner wie Asus, Acer etc. vorgesehen. Die müssen entsprechend planen können. Mit irgendwelchen wischiwaschi public Roadmaps, die nur basic Sachen enthalten oder aus Show eine CPU ins Jahr quetschen, wird kein OEM abgespeist. Dort stehen empfindliche Sachen drin wie Codenamen von geheimen CPUs oder genaue Zeitangaben, deswegen ist es Confidential. Ich habe noch keine non-Confidential Roadmap von Intel oder AMD gesehen, die mit diesen Angaben mithalten kann. Ist ja auch logisch. Wenn das anders wäre bräuchte das nicht Confidential sein. Bei Intel stehen auch genauere Angaben zu nicht nicht erhältlichen CPUs drin. Schau dir eine Confidential Platform Roadmap von Intel an und vergleiche das mit der public Roadmap. Solange deine Investor Roadmap empfindliche Sachen enthält, wird sie genauso Confidential sein.

Das hat aber alles für den Endkunden null Bedeutung.

Das hat auch keiner behauptet. Confidential Roadmaps sind nie für Endkunden gedacht, sondern für die entsprechenden Partnern. Ich dachte das wäre automatisch klar.

Cyphermaster

2013-08-08, 13:37:07

Deswegen kannste dich auch nur auf die offiziellen Roadmaps beziehen, die auf irgendwelchen Investorenveranstaltungen usw der Öffentlichkeit presentiert werden. Die Angaben müssen nämlich stimmen UND! realistisch/belastbar sein. Wenn sich da was ändert, dann kan man von Problemen/Fail reden, bei allem anderen sollte man sich sehr zurückhalten.Alles, was an die Öffentlichkeit oder als "confidential" an Geschäftspartner geht, muß gewisse Mindestgrade an Zuverlässigkeit haben. Daher sind diese Dokumente je nach Zielpublikum mehr oder weniger stark abgespeckt/vergröbert - aber natürlich können sie sich in den wesentlichen Dingen nicht von intern-geheimen Dokumenten unterscheiden (erst die enthalten dann wirklich alle Daten), sonst wäre es eine absichtliche Fehlinformation, die man rausgibt.

Ronny145

2013-08-08, 13:58:08

Korrekt. Public Roadmaps sind abgespeckt, empfindliche Sachen enthalten diese nicht. Sonst bräuchten wir ja nicht auf geleakte Roadmaps hoffen. OEMs und andere Partner werden viel genauer informiert, aber das ist eben alles Confidential.

y33H@

2013-08-08, 14:47:05

Es ist doch SCHEIS egal, ob Confidentials mehr/bessere Infos enthalten oder nicht. Sie sind schlicht nichtssagend, weil eben NICHT! bindend.Unfug.

Skysnake

2013-08-08, 15:26:28

Dann verklag mal ne Firma wegen ner "geleakten" Confidential Roadmap...

Mit ner offiziellen für Investoren ist das kein Problem, wenn da entsprechend bullshit verzapft wird.

Und nur damit wir uns nicht falsch vestehen. Die confidantials sind natürlich im Prinzip "genauer", nur fehlen einem meist wichtige Infos, und man weiß praktisch nie, von wann denn die Roadmap ist. Es sind halt nur geleakte Sachen, können also auch falsch sein.

Das ist doch das Problem. Man redet über irgend welche Sachen, wo man die Hälfte nicht weiß, und sich irgendwas zusammenspinnt. Vor allem selbst bei den "normalen" Confidentials wird viel zu wenig gesagt. Das sind ja zu 99% "nur" die Sachen für die OEMs und vielleicht wenn man glück hat mal noch für Boardpartner usw. Richtig interessant wird es aber erst, wenn man die "echten" Technik Confidentials bekommt. Das "normale" Zeug ist da oft nen Witz dagegen, auch wenn gerade Intel nach einiger Zeit relativ viel von dem "echten" Zeug freigibt, gibt es noch immer genug, was gar nie öffentlich wird.

Sorry, aber für mich ist viel von dem ganzen Confidential HokusPokus inzwischen einfach nur noch verarsche. Man bekommt ein paar Brocken, und es wird virales Marketing betrieben, aber wirklich interessante Sachen, die Hand und Fuß haben bekommt man eh nicht zu Gesicht. Da sind die Hersteller auch durchaus hart hinter her.

Und ja, das ist ganz allein meine Meinung, die man teilen kann oder auch nicht. Das muss jeder für sich selbst entscheiden, und ja, ich bin da auch nicht immer Konsequent in der Abschätzung. Man nimmt halt immer das was man hat, und nicht von jedem Hersteller weiß man gleich viel ;)

Ronny145

2013-08-08, 17:48:47

nur fehlen einem meist wichtige Infos,

welche Infos fehlen denn, die du auf einer Investor/public Roadmap zu Gesicht bekommst?

und man weiß praktisch nie von wann denn die Roadmap ist. Es sind halt nur geleakte Sachen, können also auch falsch sein.

Datumsangaben sind drauf, es sei denn sie sind vom Leaker rausgeschnitten, aber das ist wieder was anderes. Da kann doch die Roadmap nichts dafür.

Sorry, aber für mich ist viel von dem ganzen Confidential HokusPokus inzwischen einfach nur noch verarsche. Man bekommt ein paar Brocken, und es wird virales Marketing betrieben

Ein paar Brocken? Virales Marketing? Was erzählt du denn für eine Scheiße? :freak:

aber wirklich interessante Sachen, die Hand und Fuß haben bekommt man eh nicht zu Gesicht.

Was wären für dich wirklich interessante Sachen?

fondness

2013-08-08, 19:02:24

Direkt von AMD:

AMD’s ‘Kaveri’ high-performance APU remains on track and will start shipping to customers in Q4 2013, with first public availability in the desktop component channel very early in Q1 2014. ‘Kaveri’ features up to four ‘Steamroller’ x86 cores, major heterogeneous computing enhancements, and a discrete-level Graphics Core Next (GCN) implementation – AMD’s first high-performance APU to offer GCN. ‘Kaveri’ will be initially offered in the FM2+ package for desktop PCs. Mobile ‘Kaveri’ products will be available later in the first half of 2014.

http://vr-zone.com/articles/amd-confirms-kaveri-will-be-in-the-hands-of-enthusiasts-in-2014/50308.html

Ronny145

2013-08-08, 19:08:54

Shipping Start Q4 ist mehr oder weniger die Bestätigung für Dezember, vermutlich eine paper launch Aufführung auf der CES mit erster Verfügbarkeit im Februar/März. Notebooks mit Kaveri mitte des Jahres. Da das ganze noch ein paar Monate entfernt liegt, sollte man das ganze natürlich mit Vorsicht betrachten.

S940

2013-09-21, 13:22:06

Kaveri mit 13 Compute-Units / 832 Shader? | Planet 3DNow! (http://www.planet3dnow.de/cms/?p=3279&preview=true).

Duplex

2013-09-21, 13:30:38

Es gab mal ne Folie von Kaveri mit 3 SR Module, kann sein das man 1 Modul gestrichen hat und dafür die iGPU aufbohrt, in 28nm sollte man außerdem noch etwas Flächenvorteil gegenüber 32nm besitzen, also nicht unmöglich.

robbitop

2013-09-21, 13:32:00

Klingt seltsam. Zu wenig Bandbreite, um das zu versorgen und ein wenig unbalanciert (zu ungunsten der CPU).

S940

2013-09-21, 13:39:51

Klingt seltsam. Zu wenig Bandbreite, um das zu versorgen und ein wenig unbalanciert (zu ungunsten der CPU).
Siehe Text, für GPGPU wär Bandbreite nicht so wichtig. Für Grafik hast Du natürlich recht.

@Duplex: Ja hmm gute Überlegung, tausche 1 BD-Modul gegen 5 CUs :freak:
Müsste man jetzt mal schauen, wie sich das Die-size-technisch ausginge.

Gibts irgendwo ne Flächenmessung von nem CU? Das Steamroller-Modul kann man wohl Pi*Daumen wg. der größeren L1-Caches trotz Shrink auf 28nm wieder um die ~30mm² einschätzen.

M4xw0lf

2013-09-21, 13:48:07

Noch eine Semi-Custom-APU, dieses mal für die Steambox? Dann ebenfalls mit verlötetem GDDR5. Oder so. ;)

Nakai

2013-09-21, 13:48:09

Eine CU müsste unter 28nm etwa 5,5mm² groß sein. 5 CUs sind damit etwa bei 27,5mm². Passt doch in etwa. Ich würde da eher Dieshots abwarten...oder Gipsel fragen.^^;D

S940

2013-09-21, 13:58:47

Noch eine Semi-Custom-APU, dieses mal für die Steambox? Dann ebenfalls mit verlötetem GDDR5. Oder so. ;)
Ne die Typenbezeichnung 1305 ist die offizielle, die auch im Treiber steht. Also nix custom. Aber vermutlich ist das Ding schon halb auf DDR4 ausgelegt. Der Nachfolger Carrizo oder wie das Ding heißt, soll ja auch noch in 28nm kommen, ergo wird das nur ein Kaveri B sein. Das Ding dann mangels µArch-Änderungen oder Shrink mit DDR4 zu bringen wär eigentlich fast logisch. Gäbe sicherlich auch ein nettes Plus.

@Nakai (http://www.forum-3dcenter.org/vbulletin/member.php?u=22065):
Lol, würde dann echt gut passen :freak:

Nakai

2013-09-21, 15:23:40

@Nakai (http://www.forum-3dcenter.org/vbulletin/member.php?u=22065):
Lol, würde dann echt gut passen :freak:

Nur mal etwas genauer:
http://www.3dcenter.org/news/aufschluesselung-der-chipgroesse-von-amds-r1000tahiti-chip

http://www.forum-3dcenter.org/vbulletin/showthread.php?p=9197796#post9197796

Tahiti hat 32CUs, welche zusammen etwa 175,5mm² fressen. Eine CU misst dann etwa 5,48mm². 5 CUs -> ~27,42mm²

reaperrr

2013-09-21, 15:32:15

Eine CU müsste unter 28nm etwa 5,5mm² groß sein. 5 CUs sind damit etwa bei 27,5mm². Passt doch in etwa. Ich würde da eher Dieshots abwarten...oder Gipsel fragen.^^;D
Das gilt für die Tahiti-CUs mit 1/4-DP-Rate, die CUs der kleineren Chips mit 1/16-DP sind nur etwa 4,5 mm². In der Fläche eines Modules könnte man davon sogar ca. 6-7 unterbringen.

Könnte durchaus Sinn machen.

- Selbst Chips mit mehreren defekten CUs hätten noch eine voll konkurrenzfähige pro-MHz-Leistung und würden Kreise um Trinity/Richland sowie die meisten Intel-Chips rennen.
- Man braucht für gute Performance weniger Takt und damit auch weniger Spannung -> bessere Perf./Watt, zudem
- einfachere Kühlung (weniger Hitze pro mm²).
- Im Vollausbau enorme Compute-Leistung für eine integrierte Grafikeinheit.

AnarchX

2013-09-22, 09:39:49

13 wäre schon eine sonderbare Anzahl. Zumal das schon fast der Bereich ist wo sich ein Doppel-Front-End lohnen würde. Wobei die APU natürlich auch einen Compute-Fokus hat.

Wie erfasst SiSoft eigentlich Hybrid-Crossfire-Setups? 13 würde auch gut zu den bekannten 8 CU von der AMD Folie und einem zusätzlichen Hainan mit 5 CUs passen.

S940

2013-09-22, 10:53:46

Wie erfasst SiSoft eigentlich Hybrid-Crossfire-Setups? 13 würde auch gut zu den bekannten 8 CU von der AMD Folie und einem zusätzlichen Hainan mit 5 CUs passen.
Gute Frage, je nachdem was Sandra da anzeigt, könnte es auch sowas sein. Fände es zwar etwas komisch, denn immerhin wird die Grafik ja schon als "R5 M200" erkannt und nirgends steht was von Dual Graphics etc. aber wer weiss .. was mir noch aufgefallen ist, beim neuen System steht:

Number of Devices / Threads: 1 / 2Da stand bei der alten Version mit 8 CUs nur 1/1.

Aber bei nem Dual-Setup müsste da doch wenigstens ne 2 bei den Devices stehen, oder nicht?

Edit: Hmm selbst bei einer HD7900 steht da 1/1 ... könnte also doch sein, dass es ein CF-Setup ist. Wg. Crossfire wird beides als 1 Device geloggt und es bleiben dann vielleicht 2 Threads übrig.

robbitop

2013-09-22, 11:32:21

Siehe Text, für GPGPU wär Bandbreite nicht so wichtig. Für Grafik hast Du natürlich recht.

Gerade für GPGPU brauchst du immens Bandbreite.

AnarchX

2013-09-22, 11:54:01

Gute Frage, je nachdem was Sandra da anzeigt, könnte es auch sowas sein. Fände es zwar etwas komisch, denn immerhin wird die Grafik ja schon als "R5 M200" erkannt und nirgends steht was von Dual Graphics etc. aber wer weiss .. was mir noch aufgefallen ist, beim neuen System steht:

Da stand bei der alten Version mit 8 CUs nur 1/1.

Aber bei nem Dual-Setup müsste da doch wenigstens ne 2 bei den Devices stehen, oder nicht?

Edit: Hmm selbst bei einer HD7900 steht da 1/1 ... könnte also doch sein, dass es ein CF-Setup ist. Wg. Crossfire wird beides als 1 Device geloggt und es bleiben dann vielleicht 2 Threads übrig.
Hainan ist mit seinen fehlenden Display-Ausgängen wohl möglich etwas besonders und wird auch von Windows eventuell anders erfasst.

Die +5CU@Hainan-These scheint mir jedenfalls schlüssiger als 13 CUs auf Kaveri.
Bei Trinity+Turks kommen auch solche seltsamen CU/SP-Zahlen heraus: http://www.sisoftware.eu/rank2011d/show_run.php?q=c2ffccfddbbadbe6d2ebdfe8d8fe8cb181a7c2a79aaa8cffc2f2&l=de , wenn auch natürlich 2 Devices.

edit:
Hainan ist vielleicht auch schon HSA-fähig. Das würde diesem in seiner vormal fragwürdigen Positionierung (noch ein <100mm² Chip neben Oland) etwas mehr Bedeutung geben.
R5 M200 ist laut den Treibern wohl auch keine IGP, sondern hat eine dGPU-Device-ID. Insofern ist dort bei SiSoft wohl das ganze korrekt beschrieben Kaveri + R5 M200(Hainan).

Gipsel

2013-09-22, 12:43:28

Gerade für GPGPU brauchst du immens Bandbreite.So pauschal kann man das nie sagen. Für viele Sachen stimmt es, für einige aber auch nicht.

Skysnake

2013-09-22, 12:54:19

Klar, aber selbst bei denen, bei denen es "nicht" stimmt, macht es die Arbeit einfacher. Also Arbeit im Sinne von Software schreiben, die die GPU auch auslastet.

R.I.P.

2013-09-22, 15:41:36

Kann man so viele Monate vor release eigentlich schon abschätzen, wie performant Kaveri sein wird? Kann man von hUMA vor Benutzung von DDR4 (2015?) überhaupt etwas (performancetechnisch) erwarten?

dildo4u

2013-09-22, 15:45:03

Kann man so viele Monate vor release eigentlich schon abschätzen, wie performant Kaveri sein wird? Kann man von hUMA vor Benutzung von DDR4 (2015?) überhaupt etwas (performancetechnisch) erwarten?Bringt fast nix zum Anfang,die schnelleren DDR4 kommen erst später,aber so oder so braucht man entweder edram oder gddr5,um die GPU vernüftig nutzen zu können.

Duplex

2013-09-22, 15:47:15

Kann man so viele Monate vor release eigentlich schon abschätzen, wie performant Kaveri sein wird?
Ich schätze 20% mehr CPU Leistung & 60-80% mehr GPU Leistung als Richland.