TRINITY & Co: alles um Bulldozer-based APUs von AMD und deren Plattform

GPU-seitig dürften sich hier eh alle einig sein.

Zum Vergrößern anklicken....

Nö, gehe bei der GPU immer noch von gleichem Verbrauch bei 30% Mehrleistung aus, womit die 125W TDP Version deutlich mehr bringen sollte...

Wer geht hier denn davon aus, dass die GPU im Vergeich zu Llano bei gleichem TDP-Anteil langsamer sein wird? Vllt. sind die 25W mehr bei der TDP ja einzig dem CPU-Part geschuldet?

Ich bin eher konservativ und rechne nicht mit einer deutlichen Verbesserung bei der Fertigung oder den Yields; leider ist hier AMD an GloFo gebunden [oder eben TSMC, die aber mit 32 nm auch so ihre Probleme haben].

Gefixt. Bei gleicher Verbrauch 30% Mehrleistung GPU & 20% Mehrleistung CPU.

EDIT:
Wobei das nicht bei den Topmodellen sein wird sondern eher bei den 17 W - 45 W Modellen, wo nicht so grosser Takt und Spannung und Strom benötigt wird. Also dort wo über 50% der Produkte verkauft wird.

Der fehlende L3 Cache dürfte jetzt angesichts des großen L2 nicht so sehr ins fallen. Zudem war der FX4100 bei Phoronix dem A8 3850 meistens doch deutlich überlegen. Wenn Windows auch mal seinen Scheduler richtig gepatched bekommt, ist dann vlt. dort ja auch noch ein bisschen mehr drin.
Wie stark sich die Verbesserungen von Piledriver auswirken bleibt ja noch abzuwarten, aber letztendlich steht und fällt alles auch mit dem Fertigungsprozess. Wenn dieser auf dem gleichen stand von Llano bleibt, ist nicht viel mit Effizienzverbesserungen drin, aber vielleicht schaffen sie es bis Trinity ja auch noch ein paar Dinge an diesem zu optimieren...

Was dabei meiner Meinung nach noch viel interessanter wird sind die mobile-Nachfolger von Llano. Dort müsste man im 35W TDP-Segment einen A6 mit 1,4GHz CPU-Takt gegebenenfalls mit 1,7 GHz Piledriverkernen ersetzen. Klingt angesichts der vorhandenen 45W Opterons machbar, nur wird dabei hoffentlich der GPU kein noch deutlich höherer TDP-Anteil spendiert. Denn die ist, nicht nur meiner Meinung nach, im Vergleich zur CPU schon ausreichend stark.

Auf die Idee bin ich noch gar nicht gekommen. Kann man beim BD den L3 abschalten beim Deneb ging das doch auch mit einigen Boards wenn ich das richtig in Erinnerung habe.
Zumindest könnte man dann mal grob testen was der L3 im besten/schlechtesten Fall so liefert.

Bei HT4U ist ein FX-4100 nur minimal vor einem A8-3850, bei PCGH aufgrund des Spiele-Fokus und ohne Turbo sogar dahinter. Und da liegen mindestens (im Falle des Turbos) 700 MHz zwischen beiden CPUs. Bleibt die Frage ob der L3 mehr Strom kostet als er Performance bringt, hinzu kommen noch die Piledriver-Optimierungen. Am Ende könnte Trinity keine 20-25% mehr Takt, sondern nur 10-15% mehr benötigen um mit Llano gleich zu ziehen.

Was dabei meiner Meinung nach noch viel interessanter wird sind die mobile-Nachfolger von Llano. Dort müsste man im 35W TDP-Segment einen A6 mit 1,4GHz CPU-Takt gegebenenfalls mit 1,7 GHz Piledriverkernen ersetzen. Klingt angesichts der vorhandenen 45W Opterons machbar, nur wird dabei hoffentlich der GPU kein noch deutlich höherer TDP-Anteil spendiert. Denn die ist, nicht nur meiner Meinung nach, im Vergleich zur CPU schon ausreichend stark.

Zum Vergrößern anklicken....

Wenn man sich die bisherigen mobilen A6 anschaut welche mit bis zu 1.27V kommen bei 2.3GHz und 45W TDP und sich bei eben diesem Takt auf bis mind. 1.1V oder gar noch weiter untertakten lassen sollten (System verbraucht mit Turbo und GPU max. 50W, wobei da mindestens 10W auf Bildschirm, Wlan, HDD, SDD gehen, also wohl ca. 40W für APU). Da sollten die 1.7GHz+GPU bei 35W TDP schon drinnliegen.

Der Orochi musste halt auf das Snooping hin getrimmt werden.
Deshalb sieht die Cache-Architektur auch gant anders aus.
Trinity muss nicht abchecken, ob es im Cache eines anderen Sockels eine "Dirty-Cacheline" gibt.
Die Caches und der Memory-Controller werden ein Segen für Trinity werden.
Die aktuellen Llanos haben schon jetzt eine bessere IPC im Vergleich zu den 6-Kernern, mit ein Grund dafür ist die ganz andere Cache-Architektur und die schnelleren Speicherzugriffe.

Trinity verwendet eine Weiterentwicklung von Onion und Garlic (das war Version 1 dieses Interconnects). Mit Trinity ist Version 2 am Start.

Ich verspreche mir eigentlich viel von Trinity - besonders in Laptops wird Trinity deutlich effizienter zu Werke gehen können als Llano - dort hilft dann auch 2-Issue-Wide.

Die IPC eines Thuban-Kerns liegt über der einen Husky-Kerns. Der IMC ist fei klasse, mit DDR3-2133 nutzt AMD das schnellste RAM, was die JEDEC spect - mit dem IMC eines Llano undenkbar.

y33H@ schrieb:

Bei HT4U ist ein FX-4100 nur minimal vor einem A8-3850, bei PCGH aufgrund des Spiele-Fokus und ohne Turbo sogar dahinter. Und da liegen mindestens (im Falle des Turbos) 700 MHz zwischen beiden CPUs. Bleibt die Frage ob der L3 mehr Strom kostet als er Performance bringt, hinzu kommen noch die Piledriver-Optimierungen. Am Ende könnte Trinity keine 20-25% mehr Takt, sondern nur 10-15% mehr benötigen um mit Llano gleich zu ziehen.

Zum Vergrößern anklicken....

Woraus liest du die IPC für einen Kern/Kern-Vergleich ab, wenn du lediglich Messwerte für ganze CPUs (bzw. APUs) aus mehreren Kernen eingebettet in weiterführende Infrastruktur (Speicherkontroller, Interconnects, etc.) vorliegen hast?
Warum sollte ein (bzw. mehrere) BD-Kern(e) eingebettet in das Speicher-Design von Llano bzw. Trinity nicht sogar eine höhere Performance für Desktop-Anwendungen bieten, als die aktuell verfügbaren Zambezi?
Schließlich wäre nach deiner Logik fehlender L3-Cache ausnahmslos mit Performance-Einbußen verbunden, welche stets die von AMD beworbenen Effizienzsteigerungen des Piledriver-Kerns zunichte machen würden. Das muss aber nicht so sein.

FredD schrieb:

Schließlich wäre nach deiner Logik fehlender L3-Cache ausnahmslos mit Performance-Einbußen verbunden, welche stets die von AMD beworbenen Effizienzsteigerungen des Piledriver-Kerns zunichte machen würden. Das muss aber nicht so sein.

Zum Vergrößern anklicken....

Kein L3 verringert idR die Leistung (beim K10.5 rund 5-15%), die Effizienz ist ein völlig anderes Thema.

FredD schrieb:

Woraus liest du die IPC für einen Kern/Kern-Vergleich ab, wenn du lediglich Messwerte für ganze CPUs (bzw. APUs) aus mehreren Kernen eingebettet in weiterführende Infrastruktur (Speicherkontroller, Interconnects, etc.) vorliegen hast?

Zum Vergrößern anklicken....

Die ICP lässt sich bei gleicher Kernzahl und gleichem Takt problemlos vergleichen - unter den Bedingungen, die der Hersteller spect. Anders geht das auch nicht.

FredD schrieb:

Warum sollte ein (bzw. mehrere) BD-Kern(e) eingebettet in das Speicher-Design von Llano bzw. Trinity nicht sogar eine höhere Performance für Desktop-Anwendungen bieten, als die aktuell verfügbaren Zambezi?

Zum Vergrößern anklicken....

Das würden Sie, wenngleich nur minimal mehr, da der reine CPU-Part bei üblichen Desktop-Benchmarks die Performance kaum tangiert.

y33H@ schrieb:

Ich bin eher konservativ und rechne nicht mit einer deutlichen Verbesserung bei der Fertigung oder den Yields

Zum Vergrößern anklicken....

Von welchen Yields gehst Du dabei aus?
.
EDIT :
.

y33H@ schrieb:

Die IPC eines Thuban-Kerns liegt über der einen Husky-Kerns.

Zum Vergrößern anklicken....

Die IPC?

Dass "IPC" mit modernen Mehrkern-CPUs und unter unterschiedlichen Last-Szenarien ein recht schwammiger Begriff ist, wurde ja schon mehrfach in diesem Forum angesprochen. Will man aber Vergleiche über die reinen Kern-Architekturen unabhängig von den umgebenden Komponenten wie v.a. Caches erstellen, wird das schon schwierig. Die vom AMD-Marketing machen das zwar, vermutlich aber aufgrund einer besseren Datenbasis als in Spekulationsforen. Worauf ich hinaus will ist, dass die Caches durchaus ihren Anteil an der IPC haben - bei SB wurden auf ht4u etwa 3%-5% des ~15% IPC-Vorsprungs gegenüber Nehalem auf den schnelleren Uncore veranschlagt - bei Orochi bzw. Zambezi liegt wiederum ein Write-Through Cache-Design vor, mit vergleichsweise niedrigen Durchsätzen und hohen Latenzen; der "uncore" ist soweit kein Teil des Kerns/der Architektur (d.h. "Bulldozer" bzw. "Piledriver"), trägt aber seinen Teil zur letztlich messbaren IPC bei.

Ob Piledriver in Trinity-Gestalt sich bei gängigen Anwendungen wirklich nicht von Zambezi absetzen kann, oder die Marketing-Verlautbarungen dieses Mal sogar angebracht sind, bleibt eben weiterhin Spekulation (daher auch reichlich Konjunktiv verwenden )

Stop(p)t dieses sinnlose Streiten im Fred - macht dies per PM !

Trinity ist kein Bulldozer (AMD Family 15h Model 00-0F ) sondern die nächste Stuffe (AMD Family 15h Model 10-1F ) - also passen auch nicht ganz die Vergleiche mit dem FX-41xx.

Ps - es gibt/wird auch neue Opterons geben, die zur Family 15 Model 10-1F gehören

jo es wird langsam lächerlich dieses Gestreite hier.
Und es nervt und stört die User, die hier direkt am Thema freundlich diskutieren und Fakten zusammentragen wollen.
Der Thread wird zur internen Beratung vorrübergehend geschlossen.
Vllt. sollte der eine oder andere sich mal entspannt zurücklehnen bei einer Tasse Glühwein und ein paar Plätzchen.

Edit: es ist Weihnachten.... wir machen noch mal auf und gucken mal
Auch um derer Willen, die hier vernünftig und themenbezogen freundlich posten...

Trinity ist kein Bulldozer (AMD Family 15h Model 00-0F ) sondern die nächste Stuffe (AMD Family 15h Model 10-1F ) - also passen auch nicht ganz die Vergleiche mit dem FX-41xx.

Ps - es gibt/wird auch neue Opterons geben, die zur Family 15 Model 10-1F gehören

Zum Vergrößern anklicken....

Wollte mal ganz lieb fragen was du damit meinst?
Wird es Low-Voltage-Single-Socket-Opterons mit Trinity geben?
Bin grad verwirrt.

AMD bringt erst einmal die Opteron 3xxx für Sockel AM3*

Ob AMD in nächster Zeit ein APU-Opteron bringt, steht in den Sternen, da sich AMD so selbt ins eigene Fleisch schneiden würde (AMD Firestream !). Es ist wahrscheinlicher, dass AMD keine APU-Opterons bringt sondern ggf. ein ECC-fähigen Bobcat für den Embedded bzw Microserverbereich.

Zum Thema AMD Family 15h Model 10-1Fh:
Tja AMD verwendet Modulbauweise dh alles ist Modular:

Var1 - AMD verwendet:
2 Pile-Module
1 Memory Controller
1 Xrossbar
1 Grafikkern
1 PCIe-Root-Complex
0 L3 Cache
0 HT-Links
und fertig ist ein Trinity

Var2 - AMD verwendet:
4 Pile-Module
1 Memory Controller
1 Xrossbar
0 Grafikkern
0 PCIe-Root-Complex
1 L3 Cache
1 HT-Links
und fertig ist ein Opteron oder ein neuer FX


AMD Family 15h Model 10-1Fh bedeutet, 2. Generation Bulldozer - nicht mehr und nicht weniger wobei nicht alles mit Grafik sein muss

Crashtest schrieb:

AMD Family 15h Model 10-1Fh bedeutet, 2. Generation Bulldozer - nicht mehr und nicht weniger wobei nicht alles mit Grafik sein muss

Zum Vergrößern anklicken....

Das ist dann aber der Sepang / Terramar - und der dauert ja noch minimum bis Q3 2012.

Zum Thema AMD Family 15h Model 10-1Fh:
Tja AMD verwendet Modulbauweise dh alles ist Modular:

Var1 - AMD verwendet:
2 Pile-Module
1 Memory Controller
1 Xrossbar
1 Grafikkern
1 PCIe-Root-Complex
0 L3 Cache
0 HT-Links
und fertig ist ein Trinity

Var2 - AMD verwendet:
4 Pile-Module
1 Memory Controller
1 Xrossbar
0 Grafikkern
0 PCIe-Root-Complex
1 L3 Cache
1 HT-Links
und fertig ist ein Opteron oder ein neuer FX

Zum Vergrößern anklicken....

Das ist ja einfach - das könnte ja auch ein Praktikant
Und von welchem Prozessor nehmen wir den Kabelbaum(die Cachepipeline)?
Paul de Mone (gut der ist ein bisschen sehr Intel-Biased) meinte, dass die Cachepipeline mittlerweile genau so viel Projektzeit beansprucht, wie die Pipeline eines CPU-Kerns.
Und ganz ehrlich -> ich glaub ihm das.

Die Cache-Zellen bleiben gleich und nur bestimmte Tag-Columns werden nicht genutzt (deshalb waren ja auch die L2- und L3-Cache-zellen/-blöcke beim Istanbul gleich).

Aber es kann tatsächlich sein, dass ihnen hier dann doch das Geld ausgeht und man an solchen stellen wirklich wiederverwerten muss, auch wenn man Performance liegen lässt.

Sandy-Bridge mit seinem Full-Speed-L3 ist schon ein krasses Geschoss.
Sandy-Bridge-EP hat meines wissens nach keinen Full-Speed-L3. Ich frage mich, wie sie es geschafft haben die Performance gleich zu halten.

*kopfschüttel*
Was werden denn hier für Vergleiche angestellt? - Nur weil Orochi auf dem DEsktop nicht toll performt kann Trinity garnichts werden? Oo - Nur weil ein schiffsdiesel auf Räder gestellt kein Vernünftiges Fahrzeug ergibt, ist es nicht möglich mit der selben Grundbauweise einen effizienten Motor für ein Fahrzeug zu bauen?
Das wäre in etwa die selbe Analogie.
Trinity kann mit einem anderen Cachedesign kommen, braucht den L3 garnicht weil der bei Desktopsoftware eh wenig bringt und der L2 vergleichsweise groß ist. Zudem scheinen die Piledriverkerne einige Kinderkrankheiten weniger zu haben als die BDs im Orochi, unter anerem soll das Trashing-Problem mit dem L1 besser gelöst sein. Und wir wissen doch noch nichtmal ob vielleicht der L1 vergrößert wurde o.ä. Die L2-Größe hat AMD bei den K8-Kernen ja auch "on the fly" angepasst, warum soll man da nicht auch bei Trinity fortschritte gemacht haben.
Dazu kommt ein neuer Turbo, der vielleicht etwas effizienter arbeitet als der von Llano/Orochi.
Übrigens scheint schon Llano einen Mechanismus zu enthalten, der es erlauben sollte das TDP-Budget zwischen GPU und CPU hin- und her zu schieben. Im Llano-Thread wurde dazu mal ein sehr interessanter Link gepostet... es wird von "Power Credits" gesprochen, die ausgetauscht werden. Das bedeutet, es existiert keine wirklich starre Aufteilung der TDP. Nur erlauben Llanos K10-Kerne wahrscheinlich schlicht nicht mehr als Llano im moment bietet... das Powergating wurde ja "angeflanscht" und die Kerne takten im Llano nicht so wahnsinnig toll.
Ich könnte mir sehr gut vorstellen dass die Piledriver-Kerne im Trinity da viel ausgefeiltere MEchanismen enthalten um einerseits Strom zu sparen und andererseits auch das vorhandene Budget besser auszunutzen wenn keine GPU-Last anliegt etc.
Also noch ist nicht aller Tage Abend... Übrigens habt ihr bei der ewigen IPC-Diskussion mal wieder vergessen zu erwähnen für welchen Code das gilt. Mich würde mal interessieren ob auf aktuellen Bulldozern z.B. die höheren SSE-Level auch genutzt werden von entsprechender Software. Es ist nämlich ein unterschied ob man Prüft
if(intel) {SSE-Pfad} else { x87-Pfad }
oder ob man abprüft
if(SSEvorhanden) {SSE-Pfad} else { x87-Pfad }
Man konnte in beiden Fällen bis zum erscheienn von BD draufschreiben dass man SSE4 unterstützt. Dennoch macht das unter Umständen einen deutlichen unterschied.

Also fassen wir zusammen:
Trinity vs. Llano:
- Neue GPU
- Neuer Turbomodus
- Neue CPU-Architektur
- mehrere Änderungen am Uncore-Bereich / interconnects

Trinity vs. Orochi:
- PCIEx Statt Htr
- kein Snooping nötig / ggf. Anpassungen am Cachedesign
- Piledriver-Verbesserungen
- Fertigungsverbesserungen (niedrigere Spannungen?)
- besserer Turbomodus / höhere Takte wenn keine CPU-Last anliegt.
- kein L3-Cache

So.
Das mal zum kurzen Überblick ohne Rücksicht auf Vollständigkeit.
Jedenfalls ist es verdammt schwer die Performance eines TRinity abzuleiten. Orochi leidet als Zambezi daran dass er als Serverprozessor auf eine DEsktopplattform gesteckt und mit DEsktopsoftware versort wird. Trinity hat dieses Problem nicht. Bei ihm war von vorneherein der Desktop bzw. Mainstream-Fokus klar. Und das ermöglicht ganz andere Optimierungen als im Zambezi-Fall.

@deadohiosky
Danke für die mithilfe, beim enträtseln

Wir haben eine Trinity Mobile ES Passmark-Benchmark gefunden und identifiziert.
4-Kerne / 2-Module
2,3 Ghz / Turbo evtl. 3,2 GHz
5,413 Punkte

Wenn das stimmt, dann wären in diesem Bench die beiden Modul schon mit 2,3 GHz 20% schneller als die 3,6 Ghz Module des FX-4100 (4,342 Punkte)
Eigentlich unvorstellbar ...

Ich war mal so frei einen Vergleich mit meinen APUs anzustellen
Wobei die Notebook A6-APU mit 1,6 / 2,6 Ghz lief.



Gruß Lehmann

Nochmal meine Deutung (hab ich dummer Weise auch im BD-Thread platziert):

32/23/16 = Max-Turbo/AllCore-Turbo/Standard? (edit: hatte ich eben verdreht)

Passmark scheint irgendwie GPU-Leistung zu berücksichtigen, die Llanos sind nach meiner Beobachtung bereits sehr weit oberhalb der K10-4-Kerner angeordnet - was ohne GPU-Hilfe schonmal nicht sein kann.
.
EDIT :
.
Beispiele: Phenom II X4 965: 4293, A8-3850: 5472

Mit geänderter CPU- und GPU-Architekturen kommt da reichlich Unsicherheit mit in's Spiel. Wenn der Turbo-Spielraum (1600 MHz als Idle-Takt ist definitiv zu hoch) stimmt, spricht das für seht ordentliche Verbesserungen beim Turbo-Spielraum.

Edit: hier nochmal der Link zum möglichen Trinity Engeneering Sample: AMD Eng Sample, ZM232263C4450_32/23/16_9900_654 / 4-Kerne / 5413 Passmark-Punkte, Quelle

nazgul99 schrieb:

1600 MHz als Idle-Takt ist definitiv zu hoch

Zum Vergrößern anklicken....

Hmm, wenn mich meine Erinnerung nicht trügt, ist der Idle-Takt von Zambezi aber in diesem Bereich, aber leider kann ich dementsprechenden Angaben nicht mehr finden.
Durch effektives Powergating ist ein all zu niedriger Idle Takt imo nicht mehr so wichtig wie schon mal war.
Wie hoch ist überhaupt der Idle-Takt von SB? 1GHz? Höher?

LG

Also der i5-2500k hat als niedrigsten Standard-Takt 1,6 GHz ab Werk.

jap alle Desktop Sandys haben 1,6GHz idle bei ~0,95V ich weiß aber nicht wie es bei den Mobielen aussieht.