AMD - Kabini - 28nm Low-End-APU mit bis zu 4 Kernen Jaguar-Kernen - FS1b Pin-Sockel H1/14 [Archiv]

S940

2012-07-21, 15:27:31

Ich denke jetzt rentiert sich mal ein extra Kabini -Thread:

Kabini mit AVX:
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1342872950

Und noch aus dem Kaveri Thread:
AMD9833.1 = "KB 2C 12W (9833)"
AMD9834.1 = "KB 2C 5W (9834)"
AMD9831.1 = "KB 4C 17W (9831)"
AMD9832.1 = "KB 4C 17W (N-1) (9832)"
AMD9830.1 = "KB 4C 25W (9830)"http://www.forum-3dcenter.org/vbulletin/showthread.php?p=9332446#post9332446

Roadmaps:
http://www.3dcenter.org/artikel/neue-roadmaps-zu-den-amd-prozessoren-grafikchips-20122013

Jaguar-Präsentation:
http://www.3dcenter.org/artikel/amds-praesentation-zu-den-jaguar-rechenkernen-des-bobcat-nachfolgers-kabini

Edit 22.7.2012:
Temash kann hier natürlich auch diskutiert werden, ist ja nur ne low-power Version von Kabini.

FS1b Pin-Sockel für mehr Flexibilität:
http://www.forum-3dcenter.org/vbulletin/showthread.php?p=10022564#post10022564

Coda

2012-07-21, 16:08:37

Ich geh mal davon aus, dass man AVX zwar unterstützen wird, aber trotzdem nur eine 64 bit breite SIMD-Einheit verbaut (evtl. 128 bit).

SSE4-Derivate werden nicht direkt erwähnt, allerdings ist auch von deren Support auszugehen, denn AVX ist eine Obermenge aller früheren Befehlssatzerweiterungen und stellt dadurch z.B. 3-Operand-Befehle aller vorherigen SSE-Befehle bereit, die nur für nur zwei Operanden ausgelegt waren. Deshalb ist die Funktionalität aller SSE-Befehle mit einer AVX-Unterstützung bereits gegeben und somit die Kompatibilität zu SSE denkbar einfach sicherzustellen. Aus diesem Grund wäre eine Nicht-Unterstützung der höheren SSE-Erweiterungen nach SSE3, sehr verwunderlich.
Das stimmt übrigens nicht.

S940

2012-07-21, 16:42:51

Ich geh mal davon aus, dass man AVX zwar unterstützen wird, aber trotzdem nur eine 64 bit breite SIMD-Einheit verbaut (evtl. 128 bit).Ja, das wird interessat werden, ob sie die FPU wirklich anfassen, oder bei 256bit einfach nur 4x loopen ^^

Das stimmt übrigens nicht.Hmm ... was genau stimmt nicht? Das letzte Mal, als ich geschaut hatte, gabs für jeden alten SSE Befehl nen neuen mit VEX-Präfix, selbst für AES :freak:

Coda

2012-07-21, 17:30:10

Das AVX SSE4 beinhalten würde.

Per VEX-Prefix kann auch SSE-Instructions enkodieren (kürzer und mit 3 registern etc.), das heißt aber nicht, dass die Instructions alle da sein müssen.

S940

2012-07-21, 20:57:24

Das AVX SSE4 beinhalten würde.

Per VEX-Prefix kann auch SSE-Instructions enkodieren (kürzer und mit 3 registern etc.), das heißt aber nicht, dass die Instructions alle da sein müssen.Das hieße es gäbe SSE-Instruktionen ohne neuem VEX-Präfix? Wie besagt, das letzte Mal als ich da grob nachschaute gabs von allen SSE Befehlen ne neue Version mit selben Name, nur mit nem "v" vorne dran für AVX. Intel gibt auch in Ihren Leitfäden an, dass man alten SSE Code in ihre AVX-Äquivalente überführen sollte:
The final method to avoid the AVX-SSE transition penalty is to manually convert any legacy Intel® SSE assembly instructions to their VEX encoded equivalent, which removes the AVX-SSE transition.Von http://software.intel.com/en-us/articles/avoiding-avx-sse-transition-penalties/
Von Ausnahmen steht da nichts. Aber wenn Du mir nen SSEx Befehl nennst, den es nicht als V-Version gibt, glaub ich Dir :)

SavageX

2012-07-21, 21:07:38

S940

2012-07-22, 01:29:05

Ein Forum-User hat einfach mal in den Patch geguckt, sieht (unabhängig davon, ob AVX nun SSE4 voraussetzt) danach aus, als wäre SSE4 an Bord:

http://www.planet3dnow.de/vbulletin/showpost.php?p=4642681&postcount=11
Ja, damit sollte das dann wohl in trockenen Tüchern sein. Sogar movbe ist mit dabei :freak:

Leonidas

2012-07-22, 09:58:09

Gipsel

2012-07-22, 11:25:37

Mich würde ja stark interessieren, ob AMD den Grafikchip aufbohrt. Wenn man die bisherigen GCN-Cluster weiterverwendet, dann sind ja vielfache von 64 zu erwarten ... also 64 oder 128 SE. Aber wie man 128 SE auf einer maßvollen Chipfläche unterbringen will, wenn man bis zu 4 Kerne macht, das wird spannend.Eine CU ist bei Tahiti nur rund 5,5mm² groß, inklusive TMUs, shared memory und L1-Caches bzw. den Anteilen an Caches, die ja von bis zu 4 CUs geteilt werden. Bei Pitcairn und CapeVerde sind sie noch etwas kleiner (kein ECC, langsameres double precision), also vermutlich etwas unter 5mm² (gibt keine hochaufgelösten Dieshots, um das sicher sagen zu können). Für Kabini könnte man auch zusätzlich noch minimal etwas sparen, z.B. bei der Anzahl der Bänke (also der Geschwindigkeit) des shared memory (machen die low End VLIW-GPUs auch) und Ähnlichem oder auch weitere Optimierung auf ein dichtes Layout unter Aufgabe von ein wenig Taktfähigkeit. Vermutlich könnte man eine CU so noch auf ~4mm² drücken. Also an zusätzlichen 4mm² werden 128 SPs im Vergleich zu 64SPs nicht scheitern. Insbesondere, da ja wie schon erwähnt, einige Caches und Strukturen von bis zu 4 CUs geteilt werden können. Existieren die also mit der allerersten CU bereits, werden zusätzliche CUs etwas billiger. Ich würde deswegen auch bald vermuten, daß das Topmodell mit bis zu 256 SPs kommen könnte (also 4 CUs).
Allgemein sind eigentlich bei allen bisherigen Low-End-GPUs nicht die Shader die Platzfresser, sondern eher der fixed-function-Kram und die externen Interfaces (und sogar bei Tahiti nehmen Speicherinterface + PCI-Express + Display + VCE + UVD über 100mm² ein).

Edit:
Wenn man die Tahiti-Zahlen hier nimmt (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=9197796#post9197796), kann man eine ganz grobe Abschätzung für den GPU-Teil machen:
4 CUs: 18 mm²
8 ROPs + L2: 5,5 mm² (geviertelt von Tahiti)
einfaches Frontend: <5 mm² (nur 1 oder 0,5 Dreiecke pro Takt, weit einfachere work distribution)
PCI-Express/Display,UVD/VCE: <30mm² (nur 3 statt 6 Display-Outputs, Abspeckungen bei UVD?, k.A. habe ich kein Gefühl für)

Zum Vergleich, Bobcat belegt ja nur 5,5mm² pro Kern, die Zacate-Grafik hat also mitsamt Speicherinterface und Northbridge so ungefähr 57mm² benötigt, wobei man beachten sollte, daß die externen Interfaces beim Schritt auf 28nm nicht schrumpfen (ein 64Bit- Speicherinterface bleibt also bei ~10-15mm² benötigter Pad-Area, genau wie PCI-Express gleich groß bleibt).

AnarchX

2012-07-22, 12:24:31

Bei >128SPs und 4 CPU-Kernen, wäre wohl dann schon eher ein 128-Bit SI angebracht.

Leonidas

2012-07-22, 13:03:56

256 SE bei so was Kabini wäre überaus stark. Das müsste AMD dann noch auf TabletPC-Bedürfnisse herunterbrechen - voila, da kann der Rest der Meute hinterherhecheln.

Knuddelbearli

2012-07-22, 13:10:07

was ich bei AMD nie verstanden haben. wieso bitteschön beschneiden die die meisten Mobilechips bei der Anzahl der shader .... eine viel besser Energieeffizienz hätte man doch wenn man die Shader gleich lässt und Taktratren senkt. Oder hat AMD soviel Ausschuss?

Nakai

2012-07-22, 13:24:47

256 SE bei so was Kabini wäre überaus stark. Das müsste AMD dann noch auf TabletPC-Bedürfnisse herunterbrechen - voila, da kann der Rest der Meute hinterherhecheln.

Wenn Kabini wirklich mit 4 Kernen und 256SPs kommt, könnte er eher mit Trinity im unteren Segment konkurrieren. Ich denke AMD sollte das vermeiden.
Ich hätte natürlich gegen sowas nichts gegen. ;)

Bei >128SPs und 4 CPU-Kernen, wäre wohl dann schon eher ein 128-Bit SI angebracht.

128Bit wäre ganz nett.
Könnten die CPU-Kerne nicht wie bei Bulldozer in Modulen angeordnet werden? Ergo zwei Jaguarkerne teilen sich eine 128Bit-FPU(wäre pro Kern wieder bei 64Bit wie bei Bobcat).

Undertaker

2012-07-22, 13:31:47

Bei >128SPs und 4 CPU-Kernen, wäre wohl dann schon eher ein 128-Bit SI angebracht.

Das klingt irgendwie zu "mächtig" für ein Modell, welches den low-cost-Bereich anpeilt und einen möglichst geringen Verbrauch aufweisen soll. In erster Linie werden doch weiterhin Atom und vielleicht ein stark abgespeckter ULV-Celeron die Konkurrenz sein - da dürften 128 SPs und ein 64 Bit SI mehr als genug sein. Es gibt ja viele Hersteller, die selbst Trinity nur mit einem Speichermodul bestücken. ;)

Coda

2012-07-22, 13:35:35

Das hieße es gäbe SSE-Instruktionen ohne neuem VEX-Präfix?
Nein, ich sage, du musst nicht SSE4 unterstützen um AVX abzudecken. Du kannst nur mit VEX auch "alte" Instructions enkodieren. Das heißt für alle SSE-Erweiterungen, die sie hat muss sie auch VEX-Encodings beherrschen, falls sie zusätzlich auch AVX unterstützt.

Ist aber auch eher theoretischer Natur, wenn die CPU sowieso auch SSE4 unterstützt. Und vielleicht hab ich auch unrecht, und die AVX-Spec erfordert tatsächlich auch eine bestimmte SSE-Untermenge :)

Was ist eigentlich mit XOP?

ndrs

2012-07-22, 14:01:38

Wenn Kabini wirklich mit 4 Kernen und 256SPs kommt, könnte er eher mit Trinity im unteren Segment konkurrieren. Ich denke AMD sollte das vermeiden.
Warum sollte man vermeiden, ein eigenes Produkt durch ein anderes deutlich günstiger zu fertigendes zu ersetzen?

Undertaker

2012-07-22, 14:04:22

Warum sollte man vermeiden, ein eigenes Produkt durch ein anderes deutlich günstiger zu fertigendes zu ersetzen?

Ein günstiger Trinity sollte zumindest bei Singlethread-Workloads noch immer klar schneller sein, allzu hohe Taktraten erwarte ich bei einem 4-Kern Kabini nicht.

S940

2012-07-22, 14:28:07

Nein, ich sage, du musst nicht SSE4 unterstützen um AVX abzudecken. Von "Müssen" war aber ja nicht die rede. Natürlich könnte man den SSE-Support einstellen, wenn man unbedingt ein paar µm² im x86-Dekoder einsparen will, aber da SSE-Code im Moment weit mehr verbreitet ist als AVX, wäre das ein schlechtes Geschäft.
Ist aber auch eher theoretischer Natur, wenn die CPU sowieso auch SSE4 unterstützt. Ja die Sache hat sich nun ja schon erledigt, die Angaben im Compiler werden schon stimmen.
Was ist eigentlich mit XOP?Na das würde FMA4 bedeuten, das hätte den Rahmen einer low-cost FPU sicherlich gesprengt. Reicht ja schon, wenn sie die auf 128bit verbreitern.
Vielleicht hatten sie auch Angst, dass sonst keiner mehr Bulldozer kaufen würde :freak:

Zum Speicherinterface:
Wg. der Die-Size werden sie wohl bei einem Kanal bleiben wollen. Wer mehr haben will soll halt Trinity/Kaveri kaufen. 2014 kommt dann sicherlich ein Update auf DDR4, damit hat man dann auch seine Bandbreiten-Verdoppelung.

Coda

2012-07-22, 14:43:03

Von "Müssen" war aber ja nicht die rede. Natürlich könnte man den SSE-Support einstellen, wenn man unbedingt ein paar µm² im x86-Dekoder einsparen will, aber da SSE-Code im Moment weit mehr verbreitet ist als AVX, wäre das ein schlechtes Geschäft.
Ich rede zum Beispiel von SSE4.2. Soweit ich weiß wird das von AMD nicht unterstützt.

Tun sie doch. Das meinte ich trotzdem nicht ;)

Na das würde FMA4 bedeuten
XOP sind Integer-Befehle. FMA4 ist ein anderes Flag.

S940

2012-07-22, 15:15:16

XOP sind Integer-Befehle. FMA4 ist ein anderes Flag.Ach stimmt ja die Teile gibts ja auch noch, ganz vergessen. Naja, dafür bringt Intel ja demnächst AVX2, da wird ne Menge an INT-Instruktionen nachgeliefert. Ich habs noch nicht genau verglichen, aber allein von der Befehlsmenge ist XOP dagegen eher ein kleiner Fisch.

Von daher haben sie sich sicherlich gedacht, dass sie sich die Arbeit für AMDs Extrawurst gleich sparen können, und später mal bei Bedarf AVX2 nachlegen.
Bei ner low-cost APU braucht man schließlich nicht das jeweils Neueste unterstützen, AVX an sich ist mMn schon ne größere Überraschung.

fondness

2012-07-22, 17:14:09

Das interessante am dem Chip ist IMO nicht der CPU-Core, denn da kann man nicht viel falsch machen, auch ein Bobcat ist mehr als nur konkurrenzfähig.
Interessant daran ist vorallem das es der erste echte x86 SoC wird, also CPU, GPU plus Chipsatz vollständig auf einem Single-Die. Das sollte doch deutlich Vorteile bringen was Kosten, Platzbedarf und Stromverbrauch betrifft.

AnarchX

2012-07-22, 17:22:57

Das interessante am dem Chip ist IMO nicht der CPU-Core, denn da kann man nicht viel falsch machen, auch ein Bobcat ist mehr als nur konkurrenzfähig.
Ganz außer acht darf AMD den CPU-Teil nicht lassen, mit Silvermont könnte Intel gleichziehen und hat noch den Vorteil von 22nm, dazu soll der Umstieg auf 14nm sehr schnell vollzogen werden.

Coda

2012-07-22, 17:59:38

Undertaker

2012-07-22, 18:18:50

Das interessante am dem Chip ist IMO nicht der CPU-Core, denn da kann man nicht viel falsch machen, auch ein Bobcat ist mehr als nur konkurrenzfähig.

Da muss man allerdings auch die TDP sehen: Selbst die C-Serie liegt beim Verbrauch fast die Hälfte über einem N2850, und so riesig ist der Abstand CPU-seitig da auch nicht mehr. Singlethread (immernoch am wichtigsten) ist ein C-60 vielleicht 20% schneller, Multithread etwa um das gleiche Maß langsamer. Der Atom disqualifiziert sich derzeit vor allem durch seine GPU-Probleme.

Wie AnarchX schon sagte, muss sich AMD ja auch auf die nächste Generation Silvermont vorbereiten - da erscheinen mir gewissen Leistungssteigerungen im CPU-Bereich nicht überflüssig.

ndrs

2012-07-22, 18:29:30

https://en.wikipedia.org/wiki/Vortex86
Dann ergänzen wir: Es ist das erste x86 SOC mit FPU :)

fondness

2012-07-22, 18:30:10

Da muss man allerdings auch die TDP sehen: Selbst die C-Serie liegt beim Verbrauch fast die Hälfte über einem N2850, und so riesig ist der Abstand CPU-seitig da auch nicht mehr. Singlethread (immernoch am wichtigsten) ist ein C-60 vielleicht 20% schneller, Multithread etwa um das gleiche Maß langsamer. Der Atom disqualifiziert sich derzeit vor allem durch seine GPU-Probleme.

Wie AnarchX schon sagte, muss sich AMD ja auch auf die nächste Generation Silvermont vorbereiten - da erscheinen mir gewissen Leistungssteigerungen im CPU-Bereich nicht überflüssig.

Na klar ist eine Leistungssteigerung nie überflüssig, und gegen Intels enormen Ressourcen und Fertigungsvorsprung kann man langfristig realistischerweise ohnehin wenig ausrichten. Aber im Grunde gibst du dir ja selbst die Antwort: Die TDP ist im dem Bereich mindestens ebenso wichtig. Ein Bobcat-Shrink wäre IMO eine ausreichend gute Wahl, gerade wo man auch von 2 auf 4 Kerne geht. Den CPU-Core weiter aufzublasen halte ich nicht unbedingt für sinnvoll. Abnehmender Grenzertrag und so. Für 10% mehr IPC pulvert man schnell mal deutlich überproportional mehr Transistoren hinein. Ich denke daher das man eher auf den Stromverbrauch achten sollte als auf die Leistung.

@Coda: Sorry solche Steinzeitchips sind mir nicht geläufig. :)

y33H@

2012-07-22, 18:32:53

Ich halte in dem Segment zwei starke Kerne für sinnvoller als vier schwächere. Daher sucken die Atoms ja auch so ...

AnarchX

2012-07-22, 18:36:22

Da Kaveri auch in 28nm Bulk erscheinen wird, stellt sich wirklich die Frage warum man nicht bei den 17-25W Versionen auf einen 1-Modul-Kaveri mit 192-256SPs bei knapp über 100mm² setzt.

Für Tablets und Ulra-Low-Cost, könnte man wohl wieder etwas mit zwei Jaguar-Cores bei ~70mm² bauen.

Undertaker

2012-07-22, 18:37:40

Die 5W und 12W Kabinis haben ja wohl nur 2 Kerne, was recht passend erscheint - wenn man das TDP-Budget per Turbo flexibel zwischen CPU und GPU aufteilt, verspricht das dank 28nm-Fertigung recht ordentliche Zugewinne in der pro-Kern Performance. :) Man darf auch nicht vergessen, dass es eine gewisse CPU-Leistung braucht, um die GPU-Ressourcen in Spielen wirklich sinnvoll nutzen zu können.

Da Kaveri auch in 28nm Bulk erscheinen wird, stellt sich wirklich die Frage warum man nicht bei den 17-25W Versionen auf einen 1-Modul-Kaveri mit 192-256SPs bei knapp über 100mm² setzt.

Gibt ja einen 17/25W-Trinity, wenn auch auf Basis eines teildeaktivierten Dies (beim 17W-Modell).

Coda

2012-07-22, 20:23:18

Dann ergänzen wir: Es ist das erste x86 SOC mit FPU :)
Die gibt's auch mit FPU.

mczak

2012-07-23, 02:53:47

Ach stimmt ja die Teile gibts ja auch noch, ganz vergessen. Naja, dafür bringt Intel ja demnächst AVX2, da wird ne Menge an INT-Instruktionen nachgeliefert. Ich habs noch nicht genau verglichen, aber allein von der Befehlsmenge ist XOP dagegen eher ein kleiner Fisch.

Naja genau wie AVX kaum neue Instruktionen hat (mit Ausnahme ein paar Shuffles) sondern "nur" alle alten SSE-Befehle mit VEX-Encoding zur Verfügung stellt und eben die sse-float Befehle zusätzlich in einer 256bit breiten Version zur Verfügung stellt ist avx2 im Wesentlichen bloss das Aufbohren der 128bit-int Befehle auf 256bit, viel Neues ist da nicht dabei, allerdings gibt es da 2 wichtige Ausnahmen:
- "echter" Vektorshift (mit variablem Shift-count, gibt's bei XOP auch und hätte IMHO wirklich schon zu SSE2 gehört, den vermisse ich immer wieder und jeder vernünftige SIMD-Befehlssatz unterstützt das)
- "gather". Sehr sehr interessant, auch wenn noch nicht klar ist wie schnell genau der Befehl wird. Gibt's bei XOP nicht.
XOP hat aber einiges mehr an wirklich neuen Befehlen, sind aber eben halt alle nur 128bit, und ob man die wirklich alle unbedingt braucht weiss ich nicht - sehen zumindest durchaus alle ziemlich nützlich aus. Aber Bulldozer ist viel zu sehr Nischenprodukt als dass das viele interessieren würde.
Und wie schon gesagt wurde, alle SSE-Befehle gibt's als AVX-Version, da bloss den Decoder einzusparen so dass man AVX-Support hat aber nicht SSE42 macht wirklich null Sinn. (btw dass alle sse-Befehle als AVX vorhanden sein müssen ist übrigens ziemlich zwingend da man AVX-256 und SSE im selben Code nicht wirklich vernünftig
mischen kann, AVX-128 und AVX-256 aber schon.)
Sollte Kabini wirklich AVX unterstützen gehe ich aber sehr davon aus dass die SIMD-Einheiten auf 128bit aufgebohrt werden.

Coda

2012-07-23, 11:33:47

XOP hat aber einiges mehr an wirklich neuen Befehlen, sind aber eben halt alle nur 128bit
Wirklich? Ich dachte das sind auch YMM-Instructions.

Shink

2012-07-23, 12:41:11

@Coda: Sorry solche Steinzeitchips sind mir nicht geläufig. :)
So alt sind die doch gar nicht. (Die letzte Version von 2009, eine neue soll kommen.)
Ist halt ein x86-kompatibler Embedded-Chip.

mczak

2012-07-23, 23:52:46

Wirklich? Ich dachte das sind auch YMM-Instructions.
Du hast durchaus Recht, das war nicht ganz korrekt. Die meisten XOP-Instruktionen sind halt für Integer-Werte (wie z.B. die imacs, "richtige" Vektorshifts, Byte Shifts), und bei denen gibt's genau wie bei AVX keine 256bit Versionen. Es gibt aber ein paar XOP-Befehle die für Float-Werte gedacht sind und bei denen gibt's auch 256bit Versionen (so über den Daumen gepeilt sind das "Fraction Extract", "Vector Conditional Move" und ein paar sehr nützlich aussehende float-permutes die intel mal wieder "vergessen" hat). Die FMAs natürlich auch aber die gehören ja nicht zu XOP.
Sollte aber AMD einmal AVX2 unterstützen müssten eigentlich alle XOP-Befehle auf 256bit aufgebohrt werden, die sind sonst nicht mehr wirklich sinnvoll nutzbar. Also entweder XOP2 oder die ganze XOP-Geschichte wieder vergessen (sinnvoll wäre XOP2 schon noch, AVX2 hat zwar immerhin meinen Favoriten, den "echten" Vektorshift aus XOP lässt aber sonst so ziemlich alles vermissen das in XOP enthalten ist - aber es ist wohl schwierig jemanden zu überzeugen dafür zu programmieren wenn man quasi ein kleiner Nischenplayer ist).

S940

2012-07-24, 11:56:49

@mczak:
Danke für die XOP-Info. Bisher (nach einem Überfliegen der Specs) hatte ich den Eindruck, dass AVX2 so ne Art XOP+Scatter/gather+256bit wäre. Schade, dass da doch noch etwas fehlt :(

Ravenhearth

2012-08-28, 21:17:06

Neue Informationen zu Jaguar von der Hot Chips Conference:
[...] Jaguar soll im Vergleich zu Bobcat rund 15 Prozent mehr Instruktionen pro Taktzyklus liefern, rund 10 Prozent höher takten und dabei mit dem gleichen Power-Budget auskommen. Neu mit an Bord sind Befehle für: SSE 4.1 und 4.2, AES, AVX, CCMUL, MOVBE, XSAVE, F16C und BMI. Zudem erweitert AMD den physischen Adressraum von 36 auf 40 Bit. [...]
Mehr hier: http://www.heise.de/newsticker/meldung/Hot-Chips-AMDs-juengstes-Kaetzchen-1677679.html
Über die FPU steht nichts genaueres drin.

y33H@

2012-08-28, 21:24:15

Hach ja, NDAs sind doch was Feines :usad:

SavageX

2012-08-28, 21:28:24

y33H@

2012-08-28, 21:32:31

Korrekt.

Ronny145

2012-08-28, 22:36:31

15%? Dann müsste Kabini mehr IPC als der kommende Vishera haben :freak:

Ravenhearth

2012-08-28, 22:41:50

Ich wusste, dass sowas kommt:freak:

EDIT: Nun auch bei PCGH. (http://www.pcgameshardware.de/CPU-Hardware-154106/News/AMD-Jaguar-Bobat-Nachfolger-Architektur-Hot-Chips-24-AVX-1021097/)

Screemer

2012-08-29, 11:12:40

gibts was zur verbauten igpu? intel legt ja mit den vally view atoms tierisch zu, wenn man mit dem direkten vorgänger vergleicht.

AnarchX

2012-08-29, 11:14:18

Bei der Quad-Core Version kann man wohl mindestens mit 128SPs GCN rechnen.
Aber mit 4 Gen7 EUs sollte Valley View auch kein Performance-Wunder sein.

Gipsel

2012-08-29, 11:18:33

Bei der Quad-Core Version kann man wohl mindestens mit 128SPs GCN rechnen.
Hat AMD die 128 GCN SPs nicht sogar schon in irgendeiner Fußnote zu stehen gehabt?

AnarchX

2012-08-29, 11:24:56

Beim gecancelten Wichita gab es eine Fußnote mit 2 SIMDs: http://www.forum-3dcenter.org/vbulletin/showthread.php?t=512822#post8887991

Aber 128SPs GCN mit ~800MHz Turbo, wären wohl schon ein ordentlicher Sprung gegenüber den aktuellen 80SPs VLIW5 @ 680MHz.

robbitop

2012-08-29, 11:29:52

Der nur 1x 64 bit Speicherkontroller könnte aber etwas bremsen. Ich weiß nicht ob man das zu Kabini geändert hat.
Intel wird bei Silvermont 2x Kanäle haben.

Gipsel

2012-08-29, 12:02:55

Aber 128SPs GCN mit ~800MHz Turbo, wären wohl schon ein ordentlicher Sprung gegenüber den aktuellen 80SPs VLIW5 @ 680MHz.
Die Flops gehen ordentlich hoch, aber vermutlich wird die Grafikperformance vor allem für den Einstiegsbereich nicht den gleichen Sprung machen, da man vermutlich die Anzahl der TMUs und ROPs nicht erhöht. Die Ontario/Zacate Teile haben ja zwei SIMDs halber Breite (40 SPs) mit jeweils 4 TMUs (also insgesamt 8). Ich bezweifle ein wenig, daß AMD jetzt noch halbe SIMDs verbauen will (gehen würde es natürlich trotzdem), so daß es vermutlich 2 CUs mit jeweils 64 SPs und 4 TMUs werden, genau so wie bei den größeren Brüdern. Aber für moderne Anforderungen ist das auch die bessere Auslegung. Ontario/Zacate war ja nach Cedar (HD5000er-Serie) das letzte Modell mit halben SIMDs, sogar bei Caicos (HD6000er) hat man auch beim Einstiegsmodell volle SIMDs verwendet (weswegen Cedar und Caicos auch die gleiche TMU-Zahl hatten, Caicos nur doppelt so viele SPs). Selbst auf gleichem Takt sollten mit 2 GCN-CUs eine glatte Verdoppelung der Performance im Vergleich zu Zacate bei rumkommen, natürlich nur solange der Speicher nicht zu stark bremst (aber hohe AA-Einstellungen dürften kaum zum angepeilten Performancegebiet gehören; mal sehen, wie gut AMD für den Rest das durch die verbesserten und vergrößerten Caches abfangen kann).

mboeller

2012-08-29, 12:19:19

nicht schlecht...

2,5-fache CPU-Leistung (QuadCore + 15%IPC + 10% clock) + sehr wahrscheinlich doppelte GPU-Leistung.

Das reicht sogar für mittlere Notebooks aus.

S940

2012-08-29, 12:23:04

Das reicht sogar für mittlere Notebooks aus.Jo und das dann bei nur so ~20W TDP max.
Mal schauen ob Intel die SB/IV ULVs im Preis senken wird, solange sie den neuen Atom noch nicht haben.

robbitop

2012-08-29, 12:33:11

Gut, dass AMD eine Schippe nachlegt. Denn das wird gegen Silvermont vermutlich nötig sein. Es ist immernoch Intel als Konkurrent über den wir hier sprechen. Wenn Intel will, können sie in jedem Feld den Markt Core-2en. ;)

Ronny145

2012-08-29, 12:38:04

Wann soll Jaguar kommen, gibt es da genaueres als nur die Jahreszahl?

Undertaker

2012-08-29, 12:38:52

Jo und das dann bei nur so ~20W TDP max.
Mal schauen ob Intel die SB/IV ULVs im Preis senken wird, solange sie den neuen Atom noch nicht haben.

Dafür gibt es ja die Pentium/Celeron ULVs, die jetzt schon in der Preisklasse der E-Serie spielen. Es könnte für Intel allerdings nötig werden, diese Modelle etwas aufzuwerten (mehr Takt oder Features?).

S940

2012-08-29, 14:54:13

Wann soll Jaguar kommen, gibt es da genaueres als nur die Jahreszahl?Offiziell glaube ich nicht, aber da Brazos 2.0 nur ne Art Lückenfüller ist, eher früh als spät. Sprich eher H1 als H2, später als Q3 wäre peinlich. Dafür spricht auch, dass sie jetzt die Architektur präsentiert haben, die Steamrollerinfos waren dagegen etwas dürftiger, der kommt damit wohl eher später in H2/13. Über Kaveri spekulierte man mal über H1, aber mit den ganzen Verschiebungen und Trinity 2.0 Gerüchten glaub ich das eigentlich nicht mehr.

mczak

2012-08-29, 16:42:12

Der nur 1x 64 bit Speicherkontroller könnte aber etwas bremsen. Ich weiß nicht ob man das zu Kabini geändert hat.
Intel wird bei Silvermont 2x Kanäle haben.
Das sehe ich anders. Meine Interpretation ist dass intel entweder 2x32bit lpddr2 oder 1x64bit (+ecc) ddr3l unterstützt. Gibt also nicht mehr Bandbreite.
Wenn man das ALU:Speicherbandbreite Verhältnis anschaut ist 1x64bit für 128 GCN-ALUs aber eh nicht so schlecht (mit ddr3-1333 besser als bei HD7770/HD7870, auch wenn das natürlich geshared mit der CPU ist und ausserdem die fixe Bandbreite für Display-Scanout propoprtional viel höher ist).

Ronny145

2012-08-29, 16:45:46

Das sehe ich anders. Meine Interpretation ist dass intel entweder 2x32bit lpddr2 oder 1x64bit (+ecc) ddr3l unterstützt. Gibt also nicht mehr Bandbreite.

Es sind Zwei Speicherkanäle in der Grafik verzeichnet. ECC wäre nur Singlechannel.

http://s7.directupload.net/images/120827/jyhxqwju.png

Gipsel

2012-08-29, 16:51:42

Es sind Zwei Speicherkanäle in der Grafik verzeichnet. ECC wäre nur Singlechannel.

http://s7.directupload.net/images/120827/jyhxqwju.png
Ich würde das auch so wie mczak sehen. Da steht explizit beim Speicherinterface 32/64Bit Breite. Vermutlich kann man das als 1x oder 2x 32 Bit (Dual-Channel!) LP-DDR2 für den ultramobilen bzw. embedded Bereich konfigurieren oder eben einen 64Bit single Channel für den (für uns) eher interessanten Bereich mit DDR3. Solange Valleyview nicht recht groß wird, ist auf dem Die sowieso nicht viel mehr Platz als für ein 64Bit-Speicherinterface. Das Ding bekommt ja keine extra Southbridge, sprich die ganzen anderen PHYs und Interfaces müssen auch irgendwo sitzen.

Gipsel

2012-08-29, 18:41:52

Neue Informationen zu Jaguar von der Hot Chips Conference:

Mehr hier: http://www.heise.de/newsticker/meldung/Hot-Chips-AMDs-juengstes-Kaetzchen-1677679.html
Über die FPU steht nichts genaueres drin.
Laut http://semiaccurate.com/2012/08/28/amd-let-the-new-cat-out-of-the-bag-with-the-jaguar-core/ ist die FPU jetzt 128 bit breit.
Bei hardware.fr gibt es ein paar mehr Slides (http://www.hardware.fr/focus/71/amd-devoile-steamroller-jaguar.html).
Am DP-Multiplier in der FPU wird anscheinend kräftig gespart, der kann nur 1:4 Rate.

http://www.abload.de/img/img0038028_123p7u.jpg

mczak

2012-08-29, 19:28:46

Bei hardware.fr gibt es ein paar mehr Slides (http://www.hardware.fr/focus/71/amd-devoile-steamroller-jaguar.html).
Am DP-Multiplier in der FPU wird anscheinend kräftig gespart, der kann nur 1:4 Rate.

Da sieht man mal wieder dass diese half-rate DP Multiplikationen eben wohl doch nicht so ganz billig zu haben sind.
Sparen bei der SIMD-Mul Einheit scheint sowieso recht beliebt zu sein. Der Atom hatte ja 4x32bit Add aber bloss 2x32bit Mul (also theroetisch höhere simd-SP-Leistung als der Bobcat). Auch dessen Mul-Einheit konnte 2x32bit Mul pro Takt aber nur 1x64bit Mul alle zwei Takte (1/4 Rate). Wobei ich davon ausgehe dass Silvermont da eine Schippe drauflegt (und auch das DP-Problem behebt mit den nicht-skalaren Werten das war ja wirklich eine Katastrophe).
Auch der Bobcat hatte übrigens schon einen 1/4-Rate DP Multiplizierer da hat sich am Design also in der Hinsicht eigentlich nichts geändert.
Trotzdem, die simd-Einheit des Jaguar sieht gut aus. Kann alle relevanten Extensions, und wenn man bedenkt dass alle K8-CPUs nur 64bit-simd-Einheiten hatten (und so lahm waren die auch wieder nicht) so ist das sehr nett.

sputnik1969

2012-08-29, 19:37:09

15%? Dann müsste Kabini mehr IPC als der kommende Vishera haben :freak:
nein, ganz so schllimm wird es nicht sein, aber Kabini wird in Alltagsaufgaben wohl ungefähr an die IPC eines Bulldozers ranreichen. Was zeigt, wie undurchdacht Bulldozer in Wirklichkeit ist :(

nicht schlecht...

2,5-fache CPU-Leistung (QuadCore + 15%IPC + 10% clock) + sehr wahrscheinlich doppelte GPU-Leistung.

Das reicht sogar für mittlere Notebooks aus.

Durch die limitierte Speicherbandbreite würde ich am Ende eher von 2 fache CPU und etwa 1,5 fache GPU-Leistung ausgehen

Gipsel

2012-08-29, 19:41:10

Da sieht man mal wieder dass diese half-rate DP Multiplikationen eben wohl doch nicht so ganz billig zu haben sind.In dem Zusammenhang fällt mir ein wenig OT gerade ein, daß eine Tahiti-CU etwa 20% größer zu sein scheint als eine Pitcairn-CU (http://forum.beyond3d.com/showthread.php?p=1663406#post1663406). Aber das gehört eigentlich in den SI-Dieshot-Thread.

Ronny145

2012-08-29, 19:45:38

nein, ganz so schllimm wird es nicht sein, aber Kabini wird in Alltagsaufgaben wohl ungefähr an die IPC eines Bulldozers ranreichen. Was zeigt, wie undurchdacht Bulldozer in Wirklichkeit ist :(

Liegt nicht Brazos schon fast auf IPC Niveau von Bulldozer?

Undertaker

2012-08-29, 20:36:48

Also wenn ich auf Cinebench schaue, ist da doch ein recht großer Abstand. Zumindest Singlethread. Bei Multithreading sind zwei Bobcat-Kerne ähnlich schnell wie zwei Trinity-"Kerne", also ein Modul - da macht sich wohl die geteilte FPU bemerkbar.

sputnik1969

2012-08-29, 21:56:33

Ich würde einfach mal behaupten, der CineBench ist keine "Alltagsaufgabe" für "normale User". Sofern man jedoch nur Dinge benchen würde, die 90% der Nutzer machen (Webbrowsen, Videos schauen, Texte bearbeiten, evtl. Fotos zuschneiden oder minimal korrigieren, Casual Games zocken und ähnliches) wird Jaguar mit einem gleichgetakteten Bulldozer mit der selben Anzahl an "Kernen" absolut mithalten können. Bei solchen Aufgaben ist ein Bobcat ja bereits nicht spürbar (also weniger als 10%) langsamer als ein Bulldozer-Modul mit gleichem Takt.

Von daher ist ein Jaguar Core dann doch eher für "normale" Anwender, während ein Bulldozer/Trinity auf den "Power-User" zielt. Dummerweise will ein Power-User meist keine so "lahme Krücke" wie einen Bulldozer/Trinity haben, wenn er für wenig mehr Geld einen SB oder IB bekommen kann... Deshalb bin ich der Meinung, dass der Bulldozer vollkommen "am Markt vorbei" designed ist und die potenzielle Zielgruppe mit erscheinen von Jaguar (fast) in Richtung 0 zustrebt. Traurig, aber wahr....Dann ist die einzige Zielgruppe für Bulldozer und Nachkommen Leute, die hohe Multithreaded Integerleistung brauchen....

Skysnake

2012-08-29, 22:32:17

Oder wahrscheinlich Webserver usw, wo man halt viele parallele Anfragen abarbeiten muss mit sehr sehr vielen Kerneltraps, was Zeit kostet, aber nicht sonderlich viel Performance braucht.

Screemer

2012-08-29, 22:32:49

als nächstes kommt dann amds-core als ableger von brazos wie damals bei intel als ableger des p3m ;)

sputnik1969

2012-08-29, 22:45:12

als nächstes kommt dann amds-core als ableger von brazos wie damals bei intel als ableger des p3m ;)
Du wirst es nicht glauben, nach der Vorstellung von Bulldozer habe ich mir etwas ähnliches gedacht. Da Brazos ja nur ein abgespeckter K8-kern ist wäre es für AMD wohl deutlich sinnvoller den Bulldozer als reinen Serverprozessor weiter zu entwickeln und dem Normalanwender eine weiterentwickelte Stars-Architektur anzubieten.
Oder wahrscheinlich Webserver usw, wo man halt viele parallele Anfragen abarbeiten muss mit sehr sehr vielen Kerneltraps, was Zeit kostet, aber nicht sonderlich viel Performance braucht.
Solange der Bulldozer so verschwenderisch mit Energie umgeht kann ich mir das auch nur bedingt vorstellen. Dazu müsste die Entwicklung nach Trinity nochmal überdacht werden.Noch mehr in die Breite und weniger Wert auf "Gimmicks" wie AVX wäre dann angebracht.
Alternativ könnte AMD aber auch die SingleThread-Performance pushen, indem sie auch die 4 ALUS und AGUS pro Modul dynamisch den Threads zuweist. Allerdings wird das dann deutlich mehr Prozessoren Transistoren verbrauchen, ob das wirtschaftlich ist weiss ich ehrlicherweise nicht so recht.

Skysnake

2012-08-29, 22:51:23

Da wird wohl eher der Reroll bei ner falschen Branchprediction das richtig große Problem.

Bei der FPU scheint es da kein Ding zu sein (btw. Branchprediction für Float, ist das überhaupt relevant?), aber bei Int kann ich mir das schon sehr komplex vorstellen, vor allem, wenn da noch ein zweiter Thread rein wurschtelt. Wobei das dann ja praktisch SMT wäre, wenn ich so richtig drüber nachdenke :ugly:

Btw. SMT soll EXTREM komplex sein, eben wegen der Branchprediction, und was man macht, wenn die in die Binsen geht. Genau so auch die Cachekohärenz usw. Mein Computer-Architektur-Prof meinte mal, dass das schon ziemlich gut ist, was Intel da gebaut hat, und bei weitem nicht trivial.

mczak

2012-08-29, 23:18:23

Du wirst es nicht glauben, nach der Vorstellung von Bulldozer habe ich mir etwas ähnliches gedacht. Da Brazos ja nur ein abgespeckter K8-kern ist.

Also so kann man das sicher nicht sagen. Bobcat scheint mir in gewisser Weise näher bei BD zu sein als bei K8 (mal abgesehen von der Modul-geschichte). z.B. die getrennten per-pipe scheduler die gibt's nicht mehr.
Aber der Vergleich von BD zu Jaguar ist natürlich auch ein bisschen unfair, kann schon sein dass Jaguar ungefähr die IPC von BD erreicht, nur ist ersterer halt für die doppelte Frequenz ausgelegt. Wollte man einen 4Ghz Jaguar bräuchte man nicht bloss mehr Transistoren sondern auch mehr pipeline-stages da sinkt dann die IPC was man wiederum mit besserer branch-prediction etc. kompensieren muss.
Jaguar soll ja 3.1mm^2 messen in 28nm bulk (ohne L2), ein BD-Modul (ohne L2) misst etwa 20mm^2 (32nm SOI). 2 Jaguar-Kerne sind also nur rund 1/3 so gross wie ein BD-Modul, erreichen aber auch bloss (aufgrund des halben Taktes) nur etwa die halbe Performance - so schlimm sieht das also für BD auch nicht aus (ausserdem soll da ja noch Platz "verschwendet" worden sein) - ok das ist jetzt sehr verinfacht habe z.B. die Unterschiede zwischen 28nm bulk und 32nm SOI einfach ignoriert...

Skysnake

2012-08-30, 02:16:51

Ich seh das Ding auch eher bei BD als bei K8. Man muss sich nur die Features wie AVX und den allgemeinen Aufbau anschauen. Da sieht man schon sehr große Ähnlichkeiten. Man lässt halt nur den Zugriff des einen Cores auf den FPU-Teil der anderen CPU weg.

Mehr Unterschiede erkenne ich eigentlich nicht wirklich zu einem BD Modul. Jaja, der Cache ist nun shared über alle 4 Cores nicht über 2....

mboeller

2012-08-30, 08:04:25

Auch der Bobcat hatte übrigens schon einen 1/4-Rate DP Multiplizierer da hat sich am Design also in der Hinsicht eigentlich nichts geändert.

Steht wo? Das würde mich wirklich interessieren. Ich dachte, Bobcat wäre hier ein wenig stärker, schließlich kann er bei FP AFAIR ja fast mit einem K8 mithalten (MHz für MHz).

Ailuros

2012-08-30, 12:10:41

http://semiaccurate.com/2012/08/29/another-nugget-on-amds-jaguar/

Nakai

2012-08-30, 12:53:29

Ich seh das Ding auch eher bei BD als bei K8. Man muss sich nur die Features wie AVX und den allgemeinen Aufbau anschauen. Da sieht man schon sehr große Ähnlichkeiten. Man lässt halt nur den Zugriff des einen Cores auf den FPU-Teil der anderen CPU weg.

Naja also ich sehe Bobcat und Jaguar schon eher als Mischung zwischen K8 und Bulldozer.
Natürlich hat man nicht die Modulbauweise übernommen, aber die Execution sieht ziemlich nach Bulldozer aus(2fach Skalar). Ansonsten sind viele Ähnlichkeiten mit dem K8 vorhanden. Aufbau und Größe der Caches, die Pipeline und keine Shared-Frontend(wie bei Bulldozer).
AMD hat auf jedenfall den K8 als Ausgangslage benutzt und hat versucht die Entwicklungen von Bulldozer einfließen zu lassen.

Du wirst es nicht glauben, nach der Vorstellung von Bulldozer habe ich mir etwas ähnliches gedacht. Da Brazos ja nur ein abgespeckter K8-kern ist wäre es für AMD wohl deutlich sinnvoller den Bulldozer als reinen Serverprozessor weiter zu entwickeln und dem Normalanwender eine weiterentwickelte Stars-Architektur anzubieten.

Ich hab mir auch ähnliches gedacht, aber Bobcat noch Jaguar sind in der Lage in diese Höhen vorzustoßen. AMDs Idee mit den Modulen war ja eigentlich nicht schlecht, nur die IPC hat hier seeehr gelitten.

Jaguar ist auf jeden Fall ein dicker Brocken. Eine sehr starke und mächtige CPU für den kleineren Bereich. Die Kerne sind winzig und anscheinend leichter zu verbessern(IPC), als bei Bulldozer. Bobcat und Jaguar sind eben ein straight-forward Designs.

Gipsel

2012-08-30, 14:49:09

Natürlich hat man nicht die Modulbauweise übernommen, aber die Execution sieht ziemlich nach Bulldozer aus(2fach Skalar). Ansonsten sind viele Ähnlichkeiten mit dem K8 vorhanden. Aufbau und Größe der Caches, die Pipeline und keine Shared-Frontend(wie bei Bulldozer).
Bobcat/Jaguar/BD: physical register files
K7-K10 hat die nicht sondert speichert die Registerwerte in den ROBs (hat fundamentale Auswirkungen auf den innersten Teil der ALU-Pipelines!)

Bobcat/Jaguar/BD: "normale" Integer register files mit klassischem Renaming
K7-K10: komplett anderes System mit sogenannten "future register files"

Bobcat/Jaguar/BD: ein gemeinsamer Scheduler für alle Integer-Ops, handhabt einzelne decodierte µOps, die an einzelne ALUs und AGUs weitergereicht werden
K7-K10: jede Integer-Pipeline besteht aus einem ALU/AGU-Paar, jede Pipeline hat einen einzelnen Scheduler (wird nach dem Decoding zugewiesen, Instruktionen können die Pipeline nicht wechseln). Am Ende des Decodings werden MacroOps als Pärchen aus 2 µOps (ALU+AGU µOp) an die einzelnen Scheduler gegeben, die werden erst dort gesplittet. Die ganze Verwaltung basiert auf Basis der MacroOps, nicht der µOps.

Will sagen, ich sehe da nicht wirklich viele Gemeinsamkeiten zum K7/K8/K10.

Nakai

2012-08-30, 17:56:51

Bobcat/Jaguar/BD: physical register files
K7-K10 hat die nicht sondert speichert die Registerwerte in den ROBs (hat fundamentale Auswirkungen auf den innersten Teil der ALU-Pipelines!)

Bobcat/Jaguar/BD: "normale" Integer register files mit klassischem Renaming
K7-K10: komplett anderes System mit sogenannten "future register files"

Bobcat/Jaguar/BD: ein gemeinsamer Scheduler für alle Integer-Ops, handhabt einzelne decodierte µOps, die an einzelne ALUs und AGUs weitergereicht werden
K7-K10: jede Integer-Pipeline besteht aus einem ALU/AGU-Paar, jede Pipeline hat einen einzelnen Scheduler (wird nach dem Decoding zugewiesen, Instruktionen können die Pipeline nicht wechseln). Am Ende des Decodings werden MacroOps als Pärchen aus 2 µOps (ALU+AGU µOp) an die einzelnen Scheduler gegeben, die werden erst dort gesplittet. Die ganze Verwaltung basiert auf Basis der MacroOps, nicht der µOps.

Ich muss zugeben, dass ich bzgl CPU-Architektur noch zu wenig Erfahrung habe. In der Execution, wie bereits von mir angesprochen und bemerkt, sind Bulldozer und Bobcat/Jaguar sehr ähnlich. IMO ist Bobcat/Jaguar abseits von der Ausführung eher ein K8/K10 Ableger.

Will sagen, ich sehe da nicht wirklich viele Gemeinsamkeiten zum K7/K8/K10.

Mhh, für mich hat Bobcat/Jaguar wirklich seeehr wenig mit Bulldozer gemeinsam. Klar sie haben viele Ähnlichkeiten, aber der Grundgedanke von Bobcat/Jaguar ist imo eher ein K8-artiges Design, welches viele Verbesserungen von Teile von Bulldozer übernommen hat.

mczak

2012-08-30, 17:57:57

Steht wo? Das würde mich wirklich interessieren. Ich dachte, Bobcat wäre hier ein wenig stärker, schließlich kann er bei FP AFAIR ja fast mit einem K8 mithalten (MHz für MHz).
Da es keinen Family 14h Optimization Guide gibt verlasse ich mich auf die (gemessenen) Werte von Agner Fog: http://www.agner.org/optimize/instruction_tables.pdf
Da stehen dann auch gleich die Werte vom Atom drin.
Kann aber schon sein dass die simd-Einheit fast so schnell wie die eines K8 ist (denn der 1/4-Rate DP Mul ist ja etwas sehr spezifisches). Die Latenzen bei den simd-Instruktionen sind jedenfalls eher tiefer (wobei die beim Jaguar ja um 1 Takt höher sein sollen dann sind sie im Schnitt eher etwas höher) und der Durchsatz meist auch gleich. Wobei der K8 3 statt nur 2 simd-Einheiten hatte, die zusätzliche fmisc-pipe hilft zwar ausser bei float/int Konversion praktisch nur bei load/store aber das müsste eigentlich reichen dass der K8 bei simd-Code etwas schneller ist.
Die simd-Einheit des Jaguar müsste dann aber (pro Takt) deutlich schneller sein als die des K8 (und etwas langsamer als die des K10).

mboeller

2012-08-30, 18:39:50

Da es keinen Family 14h Optimization Guide gibt verlasse ich mich auf die (gemessenen) Werte von Agner Fog: http://www.agner.org/optimize/instruction_tables.pdf
Da stehen dann auch gleich die Werte vom Atom drin.

Danke!

BlackBirdSR

2012-08-31, 07:58:53

Ich muss zugeben, dass ich bzgl CPU-Architektur noch zu wenig Erfahrung habe. In der Execution, wie bereits von mir angesprochen und bemerkt, sind Bulldozer und Bobcat/Jaguar sehr ähnlich. IMO ist Bobcat/Jaguar abseits von der Ausführung eher ein K8/K10 Ableger.

Mhh, für mich hat Bobcat/Jaguar wirklich seeehr wenig mit Bulldozer gemeinsam. Klar sie haben viele Ähnlichkeiten, aber der Grundgedanke von Bobcat/Jaguar ist imo eher ein K8-artiges Design, welches viele Verbesserungen von Teile von Bulldozer übernommen hat.

Da musst Du sehr aufpassen.
Die abstrakten Layout-Bilder und Powerpoint Folien zu Funktionseinheiten, Fron- und Backend sind alles nur Bilder.
Die wirkliche Implementation dahinter ist so nur schwer oder kaum zu erkennen. Was auf dem ersten Blick nach in Bildern einem Design ähnlich dem K10 = K8 = K7 = DEC Alpha 6 aussehen mag, ist dann im Detail doch etwas ganz anderes.

mboeller

2012-08-31, 19:25:04

Liegt nicht Brazos schon fast auf IPC Niveau von Bulldozer?

Also wenn du nach dieser Seite (http://www.anandtech.com/show/5057/the-bulldozer-aftermath-delving-even-deeper/9) gehst, dann ist der Bobcat sogar schon 25% besser als Bulldozer (0,9 laut AMD-Slide <-> ~0,72) ;)

Gipsel

2012-08-31, 19:42:13

Na ich vermute mal ganz stark, daß AMD seine Zahlen aus anderen bzw. einer Zusammenstellung von deutlich mehr Anwendungen hat. Insofern ist das praktisch nicht vergleichbar.

mboeller

2012-10-28, 18:25:18

HOT

2012-10-28, 19:08:03

Bobcat/Jaguar/BD hat wahrscheinlich mehr mit dem Nexgen/K6 gemeinsam als mit K7/8/10... Mir kommt Jaguar so vor wie ein eigenes Frontend aus längst vergangenen Tagen, ein abgespecker BD-Integer-Cluster und eine völlig eigene FPU und das bei der wahnsinns Packdichte. Vielleicht steckt ja Ur-K8 oder K9-Technik mit drin ;). Da ist sicher ne Menge Arbeit hineingeflossen. Ist eigentlich CM dabei?

y33H@

2012-10-28, 19:10:59

Jaguar ist der CPU-Part, Kabini hat aber eine GCN-iGPU, ja.

Gipsel

2012-10-28, 21:46:32

http://xtreview.com/addcomment-id-25023-view-Some-details-about-the-characteristics-of-Kabini-processors.html

Quadcore @ 1,4GHz und 15W

gefunden habe ich den Link hier: http://semiaccurate.com/forums/showthread.php?t=6709
Klingt realistisch. Die 1.75 GHz liegen wahrscheinlich ohne Grafiklast bzw. bei entsprechender Teillast an. Wären also maximal 3-4 W pro Kern. Da kann man davon ausgehen, daß die 25W-Version das in etwa als Basistakt hat. Das paßt dann auch in etwa mit der versprochenen 10%+ höheren Frequenz zu Bobcat (wäre mit 1,9GHz erfüllt). Und in der TDP ist der Chipsatz ja auch schon mit drin (ist mit integriert, Kabini ist ein richtiger SoC). Wenn dann noch die +15% IPC stimmen (bei SIMD-Kram ist es ja eher +100%), sieht das ganz brauchbar aus.

AnarchX

2012-12-19, 08:31:49

Ob man wohl Dual-Graphics Systeme mit Kabini und Mars (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=536548)sehen wird?
Wenn man beim Quad-Kabini irgendetwas über 100mm² investiert, wäre wohl durchaus auch eine 384SPs GPU möglich. Mars belegt wohl 80mm².

y33H@

2012-12-19, 09:45:44

Bisher wurde die E2-, E- und C-Serie bereits mit dGPUs (gerne die 7470M) kombiniert, so wie ich das sehe. Auch wenn es IMO ziemlicher Unfug ist.

AnarchX

2012-12-19, 10:04:01

Quad Jaguar steigert die CPU-Performance schon ein gutes Stück. Besser wäre es natürlich noch, wenn ein Turbo Takt in Richtung 2,5GHz möglich wäre, wie es wohl die Silvermont Atoms trotz Low-Power-Eigenschaften erlauben.

4x 2,2GHz + 2*384SPs@~500MHz (Dual-Frontend, homogenisierte Frametimes), wäre wohl schon eine ziemlich nette Kombo und mit wohl ~200mm² Die-Size auf 2 Dies auch wohl ziemlich günstig. Theoretisch könnte man wohl APU und die GPU mit 4 GDDR5-Chips auch auf ein fettes BGA-Package löten.

Deinorius

2012-12-19, 14:15:10

Bobcat ist 75 qmm groß und ihr redet von über 100 oder gar 200? :|

AnarchX

2012-12-19, 14:20:40

200mm² inklusive der 80mm² von Mars.
Ein 120mm² 4C/384SPs/128-Bit Chip könnte doch durchaus sinnvoll sein.

Ravenhearth

2012-12-19, 14:35:27

Nur wird es anscheinend beim 80mm² 4C/128SPs/64-Bit Chip bleiben. ;)

Deinorius

2012-12-19, 15:16:39

Was für einen SoC, der sowohl wenig verbrauchen, als auch wenig kosten soll, auch Sinn macht.

128bit Speicherinterface sind ja schon zu teuer für das Board, auch wenn es der Grafikleistung sehr gut tun würde. Da sind die 128 SPs fast schon Overkill.
Würde mich interessieren, ob es irgendwann sogar einen zusätzlichen kleinen GDDR Speicher geben könnte, damit das Bandbreitenlimit umgangen werden könnte.

AnarchX

2012-12-19, 15:31:55

Mit 25W TDP orientiert sich Kabini durchaus etwas höher als Bobcat. Auch auf der Roadmap gibt es einen Schnittbereich zu Trinity: http://www.3dcenter.org/artikel/neue-roadmaps-zu-den-amd-prozessoren-grafikchips-20122013

128-Bit würde ich da doch schon auf jeden Fall erwarten. On-Package GDDR5 wäre natürlich nett, aber ist wohl eher unrealistisch.

Deinorius

2012-12-19, 16:02:34

25W TDP? Dann wird Kabini wie Bobcat recht flexibel, wenn nicht noch mehr und die 25W wird man eher im Desktop-Bereich vorfinden, um die Taktfrequenzen hochtreiben zu können. Aber 128bit? Es würde mich deutlich wundern.

mczak

2012-12-19, 19:51:32

Ich sehe die 128bit auch nicht. Bis zu 4 Kerne und 4 CUs dürften trotzdem noch sinnvoll sein. Hat man bloss 2 CUs sind 128bit Speicherinterface eigentlich gar nicht nötig (hätte unter Berücksichtigung des Taktes wohl sogar höheres Rechenleistung/Bandbreitenverhältnis als z.B. HD7770).
Bei mehr als 2 CUs allerdings wäre die Bandbreite bei 64bit ddr3 natürlich schon etwas mager.
Auch verglichen mit ARM-SoCs liegt man mit 64bit ddr3 (angenommen ddr3-1866) sogar noch (knapp) hinter dem A6X zurück (der ja eigentlich weniger Bandbreite für eine bestimmte Grafikleistung brauchen sollte).
Aber vor allem für die Versionen (Temash oder Kabini) die eher bei 5W als bei 20W sind dürften 128bit wohl nicht sinnvoll sein - und die sollen ja imho alle denselben "Sockel" (FT3) verwenden, was dann bei 64bit Versionen bedeuten würde dass das pinout unnötig kompliziert ist falls der Chip selbst wirklich 128bit wäre.

Undertaker

2012-12-19, 19:57:38

128 Bit macht imo auch aus Sicht der Produktplatzierung wenig Sinn. Wenn der Chip am Ende in puncto Leistung und Größe zu nah an Trinity herankommt, hat man

a) zwei viel zu ähnliche Produkte
b) macht sich die Preise der A-Serie kaputt
c) treibt die Produktionskosten in die Höhe - vor allem, wenn viele Modelle dann teildeaktiviert erscheinen sollten

Ein nativer 2-Kerner ist wohl ohnehin nicht geplant?

AnarchX

2012-12-19, 20:07:51

128-Bit und LP-DDR3 könnten wohl auch eine sparsame Kombo für Temash ergeben. Ähnlich macht es ja auch Apple mit A5X/A6X.

Deinorius

2012-12-19, 22:30:48

Ein nativer 2-Kerner ist wohl ohnehin nicht geplant?

Die Jaguar Kerne brauchen gerade dank 28 nm noch weniger Platz als im Bobcat. Da kann man ohne weiteres gleich 4 Kerne nehmen. Hauptsache die können sich deaktivieren.

Knuddelbearli

2012-12-20, 01:08:49

naja fma und co brauchen ja auch diespace

mczak

2012-12-20, 03:25:09

naja fma und co brauchen ja auch diespace
Jaguar kann vieles aber kein FMA.
Aber klar die Jaguar-Kerne sind schon etwas komplexer als die Bobcat-Kerne (schon allein wegen der 128bit vs. 64bit breiten SIMD-Einheiten).
Trotzdem wäre ein Chip dessen einziger Unterschied zwischen 2 oder 4 Kernen besteht sicher nicht sinnvoll. So etwas wie 2C/2CU und 4C/4CU (auch mit weniger L2 und ROP-Cache) könnte aber Sinn ergeben, das wären dann wohl so etwa 60mm² vs. 100mm² (ok die Schätzung ist sehr sehr gewagt aber der Unterschied müsste jedenfalls einigermassen signifikant sein).

mboeller

2012-12-20, 08:34:12

naja fma und co brauchen ja auch diespace

1 Jaguar-Kern hat nur 3,1mm² @28nm (siehe die Hotchip-Präsentation)

mboeller

2012-12-20, 08:36:35

Quad Jaguar .....4x 2,2GHz + 2*384SPs@~500MHz .

Also einen QuadCore mit >2GHz würde ich eigentlich nur zusammen mit FD-SOI erwarten. Und da schaut es ja ziemlich mau aus.

AnarchX

2012-12-20, 08:44:05

S940

2012-12-20, 11:03:15

Ist das denn wirklich vom Prozess abhängig oder ist hier eher das Design ein Problem?

Die HP Variante des Cortex A9 soll laut TSMC wohl auch in Richtung 3GHz laufen können, wenn man hier entsprechende Spannung verwendet: http://betanews.com/newswire/2012/05/03/tsmcs-28nm-based-arm-cortex-a9-test-chip-reaches-beyond-3ghz/
Ähnliches auch bei A15: http://www.forum-3dcenter.org/vbulletin/showthread.php?p=9526666#post9526666
In dem Fall wohl eher prozessabhängig. Die verwenden da auf den geposteten ARM Folien jeweils nen HP-Prozess. Vorteil ist, dass solche Prozesse eine hohe Vcore zulassen, die die LP Prozesse nicht schaffen, Nachteil ist, dass sie dafür ne hohe Rate an Leckströmen haben.
Möglicherweise hat TSMC da trotzdem irgendwas gedreht, denn die Leckströme sollten auch bei den geringeren Taktraten durchschlagen, was hier scheinbar nicht der Fall ist, allerdings ist da die Preisfrage, ob der abgebildete 20SoC-Prozess nun eher LP oder HP-Charakteristika haben wird.

Auffallend ist auf alle Fälle der starke Knick beim rechten Punkt für 2,9 Ghz mit dem 28nm HPM Prozess, da steigt der Verbrauch ggü. 2,5Ghz stark an, bei der 20SoC Version bleibts fast bei nem linearen Anstieg, obwohl auch die 0,1V mehr Vcore hat und sogar 100 Mhz mehr schafft.

Weiss jemand, was das 9T und 12T bei den verschiedenen Configs jeweils bedeutet?

Skysnake

2012-12-20, 11:11:01

Das 9T 12T steht ziemlich sicher für den SRAM.

Es gibt bei TSMC wohl nicht nur die klassischen SRAM Zellen aus 6 Transistoren, was ja der Name schon anbeutet, sondern zumindest auch solche aus 9 Transistoren. Die 3 zusätzlichen Transistoren sollen wohl gerade bei Registern usw nötig sein, um sehr hohe Taktraten erzielen zu können.

Gibt wohl anscheinend auch ne Variante mit 12 Transistoren.

S940

2012-12-20, 12:20:20

Ok Danke, dachte auch zuerst daran, aber 12T fand ich dafür dann etwas viel. Aber gut... scheints dann ja doch zu geben.

Knuddelbearli

2012-12-20, 13:56:55

sry meinte avx nicht fma ^^

mboeller

2012-12-20, 15:50:17

sry meinte avx nicht fma ^^

das kann er:
http://www.planet3dnow.de/photoplog/file.php?n=21296&w=l

hat aber trotzdem nur 3,1mm²

http://www.planet3dnow.de/photoplog/file.php?n=21286&w=l

Die Bilder sind von hier:
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1346188254

Deinorius

2012-12-20, 18:34:29

Weil es mir gerade auffällt: Könnte mir jemand bitte kurz und prägnant die macros erklären. Ich verstehe jetzt nicht, wieso es bei Jaguar weniger gibt.

Trap

2012-12-20, 20:31:46

S940

2012-12-20, 21:25:03

In dem Zusammenhang würde ich macro als "parametrisierbare Design-Komponente" verstehen.

Weniger Macros heißt wahrscheinlich einfach nur, dass sie mittlerweile größere/bessere/flexiblere Design-Komponenten entwickelt haben und deshalb nicht so viele davon brauchen.
Jo das sind wohl irgendwelche Blöcke. Wenn man genau hinsieht, dann sieht man die unterschiedlichen Blöcke links und recht, da sind jeweils 7 bzw. 3 Blöcke weiß umrahmt.
Vermutlich laufen die automatischen Layout-Tools mit weniger Blöcken schneller durch? Ist dann ja ne ziemliche Komplexitätsreduktion.

Deinorius

2012-12-20, 21:35:03

OK, klingt plausibel. Danke für die Aufklärung.

Skysnake

2012-12-20, 21:50:13

Jo das sind wohl irgendwelche Blöcke. Wenn man genau hinsieht, dann sieht man die unterschiedlichen Blöcke links und recht, da sind jeweils 7 bzw. 3 Blöcke weiß umrahmt.
Vermutlich laufen die automatischen Layout-Tools mit weniger Blöcken schneller durch? Ist dann ja ne ziemliche Komplexitätsreduktion.

Eher umgekehrt!

Du hast ja viel mehr chip, die du auf einmal optimieren kannst. Du hast aber eben dadurch auch den Vorteil, dass du eben globaler otpimieren kannst. Du hast also tendenziell mehr potenzial, wenn du mehr DIE auf einmal durch die tools jagst.

S940

2012-12-20, 23:36:35

Hm ok, dann muss es an der Portabilität liegen, AMD will da ja sparen und möglichst einfach die Designs an alle möglichen Fabs weiterleiten.
Weniger Macros = weniger Konvertierungs-Arbeit, oder?

Trap

2012-12-21, 08:00:10

Weniger Macros = weniger Konvertierungs-Arbeit, oder?
Ich hab von Hardwaresynthese kaum Ahnung, aber würde darauf tippen, dass man vor allem die Macros selbst portieren muss. Wie oft man die Macros in einem Design verwendet ist dagegen so gut wie egal.

Skysnake

2012-12-21, 09:14:01

Naja, innerhalb deines Macros sollte eigentlich das Tool "alles" machen. Man wirft das Zeug halt rein, und gut ist. (Und nein, so einfach wies klingt ist es bei weitem nicht! Man muss halt constraints setzen, und Wissen/Ahnen, was dem Tool hilft, und was nicht. Ansonsten kommt da NUR! Grütze bei raus)

Wenn du aber einzeln simulierte Teile dann zusammen pappst, dann musst DU! schauen, dass die Laufzeiten usw. stimmen. Zudem kannst du eben die Bereiche eben nicht "ineinander laufen" lassen um zu optimieren. Bei SRAM usw ist das ziemlich Jacke wie Hose, aber beim eigentlichen Core ist das doof. Heutzutage packst du ja die Funktionalität nicht an eine Stelle und verbindest dann alles mit Leitungen, sondern du packst die Leitungen mit der Logik voll, so dass du eigentlich gar keine Leitungen hast, sondern Logik mit Logik soweit wie möglich verbindest.

Damit reduziert man halt Laufzeiten und auch die Strecken, die man zurücklegen muss.

fondness

2012-12-22, 10:12:58

Die Jaguar Kerne brauchen gerade dank 28 nm noch weniger Platz als im Bobcat. Da kann man ohne weiteres gleich 4 Kerne nehmen. Hauptsache die können sich deaktivieren.

Das tolle ist ja vorallem das man durch den shared Cache wirklich nur den Core selbst an Die-Fläche "verliert". Den 2MB L2-Cache können die restlichen Cores unter sich aufteilen.

mboeller

2012-12-27, 14:41:06

dumme Frage zum Jaguar:

in der Hotchips24-Präsentation (HC24.28.120-Jaguar-Rupley-AMD.pdf) zum Jaguar wird auf Seite 9 erwähnt, das die FPU jetzt 128bittig ist und folgendes unterstützt:

128b native hardware
–4 SP muls + 4 SP adds
–1 DP mul + 2 DP adds

Heißt das nun, das der Jaguar eine 128bit-FMAC-Einheit ähnlich wie die Radeons hat?

Andernfalls hätten sie doch geschrieben: 4 SP muls or 4 SP adds???

Coda

2012-12-27, 14:54:50

Es gibt kein FMA, aber Jaguar kann gleichzeitig Multiplizieren und Addieren. Das müssen dann aber verschiedene Befehle im Programm sein.

Der maximale Durchsatz ist also tatsächlich 8 Flops/Takt, wenn Mul/Adds im Programm entsprechend und ohne Abhängigkeiten untereinander auftreten.

Gipsel

2012-12-27, 15:33:57

Und das DP:SP Verhältnis sieht genauso aus, wie bei AMDs (Highend-)GPUs. 1:4 mit Multiplikationen und 1:2 mit Additionen.

Coda

2012-12-27, 15:53:04

Was haben die GPUs eigentlich für nen DP-FMA-Durchsatz?

Nakai

2012-12-27, 16:21:52

Was haben die GPUs eigentlich für nen DP-FMA-Durchsatz?

Mhh, wenn man danach geht?

Und das DP:SP Verhältnis sieht genauso aus, wie bei AMDs (Highend-)GPUs. 1:4 mit Multiplikationen und 1:2 mit Additionen.

Tahiti hat ein 1/4 Durchsatz der Rest dann 1/16.
Da geht man aber wohl nach dem Durchsatz bei Multiplikationen.
Bei Additionen könnte es 1/8 bei den Kleineren sein, aber ich hab da keine Ahnung

Gipsel

2012-12-27, 16:39:42

Was haben die GPUs eigentlich für nen DP-FMA-Durchsatz?
Wie Nakai schon sagte, bei AMD (Cypress [edit: der 5. t-Slot kann kein FMA, nur MADD, bei MUL/MADD ist es deswegen 1:5, bei ADD 2:5], Cayman, Tahiti) 1:4 zu SP-FMA, bei den kleinen GCN-Chips 1:16 und bei den kleinen Keplers (außer GK110) wohl 1:24.

mboeller

2012-12-28, 22:12:15

noch was neues zum Jaguar.

Der Kabini soll anscheinend die Trinity/Llano A6/A4/E2/E1 beerben. Siehe hier: http://semiaccurate.com/2012/12/28/amd-says-goodbye-to-their-vision-branding/

und die TopVersion des Kabini soll anscheinend X4 heißen (X4 5110); Quadcore = X4; Siehe hier: http://wccftech.com/amd-kabini-x4-5110-flagship-entrylevel-apu-launches-q2-2013/

Knuddelbearli

2012-12-28, 22:28:40

A6 ? kann ich mir fast nicht vorstellen, außer es geht rein um die namensgebung und der Richard nachfolger heisst dann A12, A10, A8 und nur der allerkleinste A6

Undertaker

2012-12-29, 09:12:38

Das macht schon Sinn. Mit Trinity waren die A6-Modelle nur mit einem Modul bestückt, also quasi "1,5-Kerner". Ein Quad-Core Kabini könnte diese recht gut beerben, selbst wenn die pro-Thread-Leistung etwas geringer wäre. Dazu spart man sich die Teildeaktivierung des großen Trinity-Dies.

Knuddelbearli

2012-12-29, 12:54:16

IPCore wird wohl bei alten code mehr als nur ein bisschen geringer sein

S940

2012-12-29, 13:04:18

IPCore wird wohl bei alten code mehr als nur ein bisschen geringer seinWieso? Die Neuerungen sind doch größtenteils codeunabhängig. AVX Code mag noch ein paar Pünktchen besser laufen, aber jeder uralte SSE2 128bit Befehl profitiert nun von der 128bit breiten FPU. Dafür braucht es keinen neuen Code.
Der allseits beliebte Cinebench sollte z.B. deutlich zulegen.

SavageX

2012-12-29, 14:03:27

IPCore wird wohl bei alten code mehr als nur ein bisschen geringer sein

Der üble Scherz ist ja, dass schon Bobcat bei Integer-Berechnungen ja schon ca. K8 IPC hat (nicht jedoch bei Fließkomma). Wenn man Jaguar ungefähr 10% mehr Integer-Leistung unterstellt und mehr als 50% bei SIMD-Berechnungen, dann liegt pi mal Daumen bei einer IPC, die nicht weit weg ist vom K10. Dann ist man aber auch ganz nah an Piledriver, der dann nur die höhere Taktbarkeit vorweisen kann... Jaguar dürfte dank separater Cores sogar besser mit Kernen skalieren.

robbitop

2012-12-29, 14:15:15

Tja - nur schade, dass man immer eine Taktbarkeit von nur 50 % der BD Cores hat. Sonst könnte man die Bobcat-Familie irgendwie aufpeppen und BD streichen.
IMO sollten sie so oder so BD streichen - das ist sowieso eine unbalancierte Architektur, die man nun versucht zu flicken. Dann lieber eine neue ausbalancierte große Architektur.

fondness

2012-12-29, 14:36:27

Der üble Scherz ist ja, dass schon Bobcat bei Integer-Berechnungen ja schon ca. K8 IPC hat (nicht jedoch bei Fließkomma). Wenn man Jaguar ungefähr 10% mehr Integer-Leistung unterstellt und mehr als 50% bei SIMD-Berechnungen, dann liegt pi mal Daumen bei einer IPC, die nicht weit weg ist vom K10. Dann ist man aber auch ganz nah an Piledriver, der dann nur die höhere Taktbarkeit vorweisen kann... Jaguar dürfte dank separater Cores sogar besser mit Kernen skalieren.

Und das alles auf winzige 3.1mm² in 28nm und bei einem Stromverbrauch pro Core von vielleicht 2 Watt. Das zeigt wie enorm aufwändig und eigentlich ineffizient es ist IPC und Takt weiter in die Höhe zu schrauben. Und genau das hat ARM rechtzeitig erkannt.

robbitop

2012-12-29, 14:53:13

Sie haben das Gesetz des sinkenden Grenzertrags erkannt? :uclap:
Wobei sie notgedrungenermaßen auch immer weiter in richtung IPC kommen. A15 zeigt, dass die Kerne auch dort immer mehr Leistung aufnehmen und Kernfläche benötigen. Das versucht man durch big.LITTLE zu kompensieren. Aber irgendwann braucht man einfach mehr IPC oder Takt. Man kann nicht beliebig parallelisieren.

SoCs gehen langsam auch die Entwicklung, die CPUs und GPUs gegangen sind. Sie wachsen überproportional zu den Möglichkeiten, die Shrinks bieten und bewegen sich immer weiter an das Limit heran.
ARM SoCs haben mal unter FullLoad < 1 W gebraucht. Heute sind es bis zu 5 W.

Im PC kamen High End CPUs in den 90ern mit 10 W klar, Anfang der 2000er waren es schon 30...40 W und heute sind wir mit 90...140 W langsam am Limit. GPUs 5 W in den 90ern. Vieleicht 20...30 W Anfang der 2000er und heute sind es fast 300 W.

Letztenendes will der Endkunde die Leistung sehen, bzw hat sich daran gewöhnt, also wurde die Leistungsaufnahme immer höher.

Intels Atom verbraucht insbesondere idle aktuell wesentlich weniger als Jaguar. Und FullLoad natürlich auch. Und Jaguar ist aber nicht um den Faktor schneller, den er mehr Energie benötigt.

Ganz klar oben genanntes Gesetz. Je nach Anwendungszweck ist es gut im unteren Bereich zu sein und manchmal muss man in den super teuren oberen Bereich.

fondness

2012-12-29, 15:17:05

Sie haben das Gesetz des sinkenden Grenzertrags erkannt? :uclap:

Sie haben erkannt das es hier eine enorme Marktlücke gibt.

Wobei sie notgedrungenermaßen auch immer weiter in richtung IPC kommen. A15 zeigt, dass die Kerne auch dort immer mehr Leistung aufnehmen und Kernfläche benötigen. Das versucht man durch big.LITTLE zu kompensieren. Aber irgendwann braucht man einfach mehr IPC oder Takt. Man kann nicht beliebig parallelisieren.

Klar, deshalb hat ARM mittel- bis langfristig IMO auch ein Problem. Das Instruction-Set alleine wird ihnen nichts nützen, die winzige x86-Decoder spielen defacto keine Rolle.

Im PC kamen High End CPUs in den 90ern mit 10 W klar, Anfang der 2000er waren es schon 30...40 W und heute sind wir mit 90...140 W langsam am Limit.

Eigentlich stagniert die Leistungsaufnahme bei CPUs schon seit dem P4 Prescott. Da hat man notgedrungen auch damit aufgehört die Taktraten zu erhöhen.

GPUs 5 W in den 90ern. Vieleicht 20...30 W Anfang der 2000er und heute sind es fast 300 W.

Die Masse der verkauften GPUs hat weit unter 100W. Und auch hier wird es bald eine Trendwende geben müssen, die Zukunft gehört den SoCs.

Intels Atom verbraucht insbesondere idle aktuell wesentlich weniger als Jaguar. Und FullLoad natürlich auch. Und Jaguar ist aber nicht um den Faktor schneller, den er mehr Energie benötigt.

Mutige Aussage angesichts dessen das ein Jaguar noch nirgends getestet wurde. Die Atom Architektur ist alles andere als taufrisch. Das der SoC mehr braucht ist natürlich klar, da steckt aber auch eine relativ große DX11.1 GPU plus der komplette Chipsatz drinnen, beim Atom nur eine extrem lahme DX9 GPU ohne Chipsatz.

robbitop

2012-12-29, 15:51:39

Sie haben erkannt das es hier eine enorme Marktlücke gibt.
Vor Jahrzehnten aber schon. Genau wie MIPS. ;) Kalter Kaffe also.

Klar, deshalb hat ARM mittel- bis langfristig IMO auch ein Problem. Das Instruction-Set alleine wird ihnen nichts nützen, die winzige x86-Decoder spielen defacto keine Rolle.
Absolut. Intel holt dank brutaler Fertigungstechnologie stark auf. ARM lebt aber vor allem durch:

- mittlerweile hohe Verbreitung und Quasi-Standard im SFF Bereich - hier hat x86 nichts zu sagen
- fertige Designs spottbillig lizenzierbar und auch die reine ISA ist lizensierbar
- gibt wesentlich mehr Hersteller von SoCs und damit sehr günstige SoC Preise

In Punkto Leistung und Leistungsaufnahme ist Intel bald dran und zukünftig vieleicht auch überlegen. (abhängig von Silvermont und der Anpassung des Fertigungsprozesses).

Eigentlich stagniert die Leistungsaufnahme bei CPUs schon seit dem P4 Prescott. Da hat man notgedrungen auch damit aufgehört die Taktraten zu erhöhen.
Beim Prescott hat man halt das thermisch sinnvolle Limit erreicht. Jetzt bleibt man dort.
Das ist wie ein Stadioneffekt. In der Halbzeit stehen alle auf, um besser sehen zu können. Würden alle sitzen bleiben, könnten sie genauso gut sehen und würden bequemer sitzen. Wäre man bei damaligen Envelopes geblieben hätte man heute nicht solche großen Geräte mit so hoher Leistungsaufnahme. Man wäre aber sicherlich technologisch dann auch gute 2-3 Shrinks - also 4-6 Jahre hinten. Das ist aber nur ein einmaliger Offset, den man gutgemacht hat.

Die Masse der verkauften GPUs hat weit unter 100W. Und auch hier wird es bald eine Trendwende geben müssen, die Zukunft gehört den SoCs.
Mir ging es um High End ASICs. Nicht um die Masse.
Letztenendes will auch keiner die jetziger Leistung wieder aufgeben - andererseits will man auch Fortschritt. Eine Trendwende würde nur durch einen Rückschritt möglich sein. :)

Mutige Aussage angesichts dessen das ein Jaguar noch nirgends getestet wurde. Die Atom Architektur ist alles andere als taufrisch. Das der SoC mehr braucht ist natürlich klar, da steckt aber auch eine relativ große DX11.1 GPU plus der komplette Chipsatz drinnen, beim Atom nur eine extrem lahme DX9 GPU ohne Chipsatz.
So mutig muss man dazu nicht sein. TDPs sind bereits bekannt und was ein Shrink bringt, ist auch abschätzbar. Das ist alles sehr sehr gut abschätzbar. Auch die zugewonnene Leistung.

Auch im idle frisst Atom weniger. Als Gesamtsystem. Und zwar deutlich. Oder bei asymetrischer Last (CPU Only) ebenfalls. Und zwar deutlicher als der Leistungsfaktor dazwischen.
Das ist einfach Intels super guter Fertigungsprozess und ein Design, was wenig IPC macht steht auf der Kurve des Grenzertrags immer besser da.

fdk

2012-12-29, 16:39:10

fondness

2012-12-29, 16:48:13

Nachdem nun mit Kabini die Singlethreaded-Leistung im Laptopbereich weiter stagniert und das Konzept "Netbook" ohnehin ausläuft bleibt wohl nur die 5w Version für eventuelle win8 Tablets attraktiv. Wenn man sich die aktuelle Verfügbarkeit von Trinity Notebooks ansieht allerdings kein großer Verlust.

Allerdings sehe ich in dem doch recht speziellen Anwendungsfall jetzt nicht wirklich eine Daseinsberechtigung für das ganze Design.

Die Single-Thread-Leistung steigt bei 15% mehr IPC und 10% mehr Takt immerhin um fast 30%. Auch ansonsten ist der Chip IMO durchaus attraktiv, immerhin ist es der erste "echte" x86 SoC. Also CPU, GPU und Chipsatz vollkommen auf einen Single-Die. Das senkt den Verdrahtungsaufwand auf dem Mainboard, spart Platz und senkt den Stromverbauch und damit letztlich auch den Preis. Kabini wird ggü. Trinity also wesentlich preiswertere und natürlich auch stromsparendere Geräte ermöglichen. Dazu modernste Features wie DX11.1 oder USB3.0 onboard. Und seine wird mal ehrlich, für den Durchschnittlichen Nutzer ist der Chip mehr als schnell genug.

Und natürlich wird die Stromsparvarianten im Tablet Bereich leichtes Spiel haben mit Intels Atom, die Frage bleibt nur wie weit man die TDP senken kann. 5W für den kompletten Chip wäre schon durchaus konkurrenzfähig, immerhin benötigt der Chipsatz beim Atom auch noch 1-2W.

So mutig muss man dazu nicht sein. TDPs sind bereits bekannt und was ein Shrink bringt, ist auch abschätzbar. Das ist alles sehr sehr gut abschätzbar. Auch die zugewonnene Leistung.

Auch im idle frisst Atom weniger. Als Gesamtsystem. Und zwar deutlich. Oder bei asymetrischer Last (CPU Only) ebenfalls. Und zwar deutlicher als der Leistungsfaktor dazwischen.
Das ist einfach Intels super guter Fertigungsprozess und ein Design, was wenig IPC macht steht auf der Kurve des Grenzertrags immer besser da.

Jaguar ist vieles, aber sicher kein Shrink von Bobcat. Man sieht schon am Floor Plan das da nicht mehr viel übrig ist vom Bobcat-Design.

robbitop

2012-12-29, 17:11:27

AnarchX

2012-12-29, 17:11:34

Und natürlich wird die Stromsparvarianten im Tablet Bereich leichtes Spiel haben mit Intels Atom, die Frage bleibt nur wie weit man die TDP senken kann. 5W für den kompletten Chip wäre schon durchaus konkurrenzfähig, immerhin benötigt der Chipsatz beim Atom auch noch 1-2W.

Smartphone/Tablet-Atoms sind mittlerweile SoCs mit TDPs um die 1-2W.

mboeller

2012-12-29, 21:14:29

Und das alles auf winzige 3.1mm² in 28nm und bei einem Stromverbrauch pro Core von vielleicht 2 Watt. Das zeigt wie enorm aufwändig und eigentlich ineffizient es ist IPC und Takt weiter in die Höhe zu schrauben. Und genau das hat ARM rechtzeitig erkannt.

Ja ein Quadcore mit 2MB L2-Cache würde nur < 25-30mm² benötigen, je nachdem wie aufwendig die L2-Cache Anbindung wird.

Beim Trinity zumindest hat ein 2MB L2-Cache nur ca. 12mm²

16 Jaguar-Kerne incl. 8MB L2-Cache zB. würden nur 100-120mm² benötigen......

mboeller

2012-12-29, 21:36:20

Die Single-Thread-Leistung steigt bei 15% mehr IPC und 10% mehr Takt immerhin um fast 30%. Auch ansonsten ist der Chip IMO durchaus attraktiv,

zu den 10% mehr Takt kommt dann ja noch der neue 28nm Prozess dazu. Ich gehe zumindest davon aus, das die 10% den Umstieg von 40nm auf 28nm nicht mit beinhalten.

Knuddelbearli

2012-12-29, 21:50:10

doch sicher ist das eingerechnet

Gipsel

2012-12-29, 22:05:40

doch sicher ist das eingerechnet
Nee, ist es nicht. AMD hat gesagt, daß die "µarchitectural improvements" (die beiden zusätzlichen Pipelinestufen) >10% Frequenz bringen.

Edit:
http://www.planet3dnow.de/photoplog/file.php?n=21284&w=l

Deutlich höhere Frequenzen wegen 28nm würde ich trotzdem nicht erwarten. Immerhin sind es doppelt so viele Kerne und mehr als doppelt so viele Transistoren. Wenn der Stromverbrauch nicht deutlich hoch gehen soll, muß AMD mit der Auslegung auf hohe Taktraten zurückhaltend bleiben (zumal der Chipsatz ebenfalls ondie integriert wird und somit zur TDP des SoC beiträgt).

HarryHirsch

2012-12-30, 01:43:16

hat das ding eigentlich noch uvd3 oder kommt da was neues?

und kann wer eine zusammenfassung machen ob der cpu teil schneller wird und bei wieviel mehrverbrauch?

Pentium M

2012-12-30, 02:18:59

Wurde ein neuer Videostandart entwickelt der es nötig macht das AMD(UVD 3) oder Nvidia(Pure Video) ihre Hardwaredecoder sich dementsprechent anzupassen,und Kabini wird schneller als Bobcat sein.(Im CPU Teil)

HarryHirsch

2012-12-30, 02:34:28

hätte ja sein können das die effizienz von uvd3 verbessert wurde.
mit den aktuellen standardeinstellungen vom treiber verbrauchen die ja mehr strom als intel/nv.
liefern aber auch die bessere bq.

wenn der cpu-teil schneller wird, wird er auch mehr verbrauchen?

Felixxz2

2012-12-30, 02:44:05

Absolut? Nein, denn es wird parallel ja auch geshrinkt (40nm -> 28nm). Und relativ wird dir das wohl niemand sagen können.

Pentium M

2012-12-30, 03:08:28

Aber nur 2-4 Watt .

HarryHirsch

2012-12-30, 03:20:08

was ist denn zu erwarten bzgl. der cpu?
ein bobcat ist so lahm das er eine ssd bremst.

Pentium M

2012-12-30, 03:28:01

Link (http://www.imagebanana.com/view/q94w3ymu/4l6p08.jpg)

SavageX

2012-12-30, 13:07:49

Nee, ist es nicht. AMD hat gesagt, daß die "µarchitectural improvements" (die beiden zusätzlichen Pipelinestufen) >10% Frequenz bringen.

Und hier nochmal die konkrete Aussage, dass sich die > 10% mehr Takt auf einen 28 nm Bobcat beziehen: http://www.youtube.com/watch?feature=player_embedded&;v=_GXA38vFPXA#t=4048s

S940

2012-12-30, 15:16:22

Und hier nochmal die konkrete Aussage, dass sich die > 10% mehr Takt auf einen 28 nm Bobcat beziehen: http://www.youtube.com/watch?feature=player_embedded&;v=_GXA38vFPXA#t=4048s
Naja, ist ja nichts Neues, das ist genau die Definition von "Verbesserung durch Mikroarchitektur". Jaguar in 28nm kann mit 10% mehr Takt als ein hypothetischer Bobcat@28nm laufen.

Ein Jaguar@40nm wär auch um die gleichen 10% schneller taktbar als Bobcat@40nm. Eben nur architektur- und nicht prozess-abhängig.

Oder meintest Du Dein Post nur als abermalige Bestätigung von Gipsels Aussage?

Undertaker

2012-12-30, 15:33:21

Link (http://www.imagebanana.com/view/q94w3ymu/4l6p08.jpg)

Die Folie klingt wiederum danach, das es unterm Strich auf gut 10% Mehrtakt hinausläuft. "architectural improvements" ist imo ohnehin wischiwaschi - geht man da auch von gleicher Kernzahl, gleichem TDP-Budget usw. aus?

Für ein volles Quadcore-Modell mit <=18 Watt würde ich auf höchstens 2 GHz tippen. Das wären ~14% mehr als bei Bobcat.

fondness

2012-12-30, 15:47:37

Die Folie klingt wiederum danach, das es unterm Strich auf gut 10% Mehrtakt hinausläuft. "architectural improvements" ist imo ohnehin wischiwaschi - geht man da auch von gleicher Kernzahl, gleichem TDP-Budget usw. aus?

Für ein volles Quadcore-Modell mit <=18 Watt würde ich auf höchstens 2 GHz tippen. Das wären ~14% mehr als bei Bobcat.

Es wird jedenfalls ausdrücklich und klar betont das die µArchitektur >10% mehr Takt erlauben soll als Bobcat. Jeff Rupley sagt eindeutig >10% ggü. einem Bobcat in 28nm. Wäre Wichita nicht gecancelt worden könnte man das heute natürlich besser abschätzen, so muss man abwarten was der 28nm Prozess von GF ggü. dem 40nm Prozess von TSMC bringt. Hier antwortet er auf die Frage nach den Taktraten: http://www.youtube.com/watch?feature=player_embedded&;v=_GXA38vFPXA#t=4048s

Da Bobcat auch einen Turbo bekommen wird kann ich mir durchaus vorstellen das man auch >2Ghz geht.

SavageX

2012-12-30, 19:01:21

Oder meintest Du Dein Post nur als abermalige Bestätigung von Gipsels Aussage?

Yup, genau das. Ist halt schön, dass es nicht nur indirekt auf den Folien steht, sondern auch als Narrative verbürgt ist.

S940

2012-12-30, 22:23:52

Yup, genau das. Ist halt schön, dass es nicht nur indirekt auf den Folien steht, sondern auch als Narrative verbürgt ist.
Ahh ok, also doch war mir nicht 100% sicher. Auf der einen Seite stehts ja schwarz auf weiss auf ner AMD Folie, auf der anderen Seite reden wir über eine AMD Folie ^^
Also hast DU da schon recht, doppelt genäht hält besser ;)

Undertaker

2012-12-30, 22:38:10

Es wird jedenfalls ausdrücklich und klar betont das die µArchitektur >10% mehr Takt erlauben soll als Bobcat. Jeff Rupley sagt eindeutig >10% ggü. einem Bobcat in 28nm.

Wie gesagt: Unter welchen Randbedingungen? Ohne die ist das hier alles nur sehr vage Spekulation.

Mein Tipp von max. 2 GHz betrifft natürlich den 4-Kern Takt. Die Turbostufen bei Teillast hängen letztlich nur davon ab, wieviel Energieeffizienz man für eine höhere ST-Leistung opfern will.

Undertaker

2012-12-31, 14:33:08

fondness

2012-12-31, 17:24:46

Waren die TDP-Stufen bislang schon bekannt?

http://www.computerbase.de/news/2012-12/weitere-details-zu-amds-kabini-sickern-durch/

Bei maximal 25 statt bislang nur 18 Watt sollten die Taktraten wohl doch recht brauchbar ausfallen.

Naja dafür ist auch der Chipsatz und eine wohl relativ brauchbare GCN-GPU dabei. Minimal 3.6W für die Tablet-Version ist durchaus noch im Rahmen für ein Tablet.

y33H@

2012-12-31, 19:16:21

Die TDP-Stufen waren vor Monaten schon auf einer offiziellen (für die Presse gedachten) Slide, auch die 25W statt 18W. Die ist ja im Artikel drin und die Meldung zudem verlinkt. Da es kein Trinity-Ultrathin mit 11,6er gibt ... ich hoffe auf Kabini.

Dural

2012-12-31, 21:21:05

x86 hat gegen die ARM CPUs im tablet bereich wohl nicht wirklich eine chance.

zudem die 3,6Watt version sicher nur ein Dual Core CPU hat. da steht es dann ca. A15 Quad Core @ 2GHz vs Jaguar Dual Core @ 1,2GHz

und allgemein scheint der Kabini Die mit bis zu 25Watt ziemlich fett für den tablet bereich zusein.

Knuddelbearli

2012-12-31, 22:25:10

wieso sollte x86 keine Chance haben? selbst in der aktuellen typischen arm cpu größe braucht der x86 decoder nur paar wenige prozent an die space

ob jaguar auch für den typischen tabelt bereich designt ist, bzw sich eignet muss man dann hingegen erst schauen

fdk

2012-12-31, 22:28:08

Ob x86 oder arm wäre in der tat egal. Um relevant zu sein/werden müsste x86 aber richtig in der Android Welt ankommen.

StefanV

2013-01-01, 00:33:14

x86 hat gegen die ARM CPUs im tablet bereich wohl nicht wirklich eine chance.
Ja, weil X86 bisher immer als High Performance designt wurde und nie irgendwann als lowest Power CPUs...

Undertaker

2013-01-01, 10:14:50

Hmm? Natürlich gibt es low-power x86 SoCs, die teils sogar weniger als manches ARM-Modell verbrauchen.

Dural

2013-01-01, 11:21:40

aber nicht an das Per./Watt verhältnis eines ARM kommen.

fdk

2013-01-01, 12:51:17

Dann solltest du evtl mal den x86 Power myth Artikel bei anand lesen.

dildo4u

2013-01-01, 15:20:14

aber nicht an das Per./Watt verhältnis eines ARM kommen.
Du irrst dich A15 wird sogar recht hungrig,ein Grund warum fast jede SOC Variante mit einem Sparcore daher kommen wird.Nvidia hat den schon bei Tegra 3 verbaut und wird das bei T4 fortsetzen.

http://www.arm.com/products/processors/technologies/biglittleprocessing.php

http://www.androidnext.de/news/tegra-4-spezifikationen/

Und natürlich wurde Atom von Anfang an Richtung geringer Verbrauch getrimmt.

Officiating x86 Vs. ARM Using Hard Data

http://www.tomshardware.com/reviews/atom-z2760-power-consumption-arm,3387-5.html

StefanV

2013-01-01, 15:28:45

Natürlich gibt es low-power x86 SoCs, die teils sogar weniger als manches ARM-Modell verbrauchen.
Welche meinst du?
Die alten Kerne, die aus der Pentium Ära stammen??
Oder die ganzen 8086, 80186, 80286, 80386, 80486??

Aber genau das is ja der Punkt: Es gab bisher kein wirkliches Lowest Power x86 Design, dass so in die Richtung ARM ging. X86 war bisher immer High Performance und sogar die lahmsten x86 Designs einer Zeit (Bobcat), haben die schnellsten ARMs mit der Pfeife geraucht...

Wobei wir wieder bei ARM Designs sind, die bisher eher Lowest Power Designs und weniger High Performance Designs waren.

Buttom Line:

Der Vergleich von ARM und x86 ist daher, momentan, nicht wirklich möglich, da es keine vergleichbaren Designs gibt...
Der A15 könnte in den Bereich eines Bobcats vorstoßen. Dann könnte man hier einen Vergleich zwischen den beiden anstellen.

Und dass x86 (immer noch) so schlecht ist, wie von vielen behauptet bzw eher geglaubt wird, bezweifle ich hier mal ganz stark...
Der Punkt ist eben, dass niemand bisher ein x86 Design gebaut hat, dass bedingungslos auf hohe Effizienz und einen Verbrauch von unter einem Watt kommt...

Ronny145

2013-01-01, 15:58:18

low power ist ein weit gedehnter Begriff. Das können 10W sein oder 2W. Atom war definitiv für den low power Bereich gemacht und erst recht nicht für high performance. Was du meinst sind wohl 1-2W Bereiche für Smartphones. Keine Ahnung, ob die alte Atom uarch von Anfang an dafür vorgesehen war. Mittlerweile ist der alte Atom ziemlich darauf getweakt. x86 ist nicht per se für Bereiche um 1-2W ungeeignet. Das wird aber noch lange dauern, bis das bei der Allgemeinheit ankommt. Man sieht am A15, dass ARM den extrem niedrigen Verbrauch aufgeben muss, wenn höhere performance Bereiche angepeilt werden. x86 bzw. Intel nähert sich von der anderen Richtung an.

dildo4u

2013-01-01, 16:02:01

Und Intel hat zur Zeit nich mal ein Fertigungsvorteil beim Atom,die 32nm Versionen müssen gegen 28nm A15 SOC's antreten.

mboeller

2013-01-01, 16:16:07

also wenn ihr hier wirklich über low-power X86 diskutieren wollt habe ich hier was für euch:

http://www.hotchips.org/wp-content/uploads/hc_archives/hc24/HC24-6-Tech-Scalability/HC24.29.625-IA-23-Wide-Ruhl-Intel_2012_NTV_iA.pdf

Nachbau eine alten Pentium mit NTV-Logik. Resultat:
1,5mW bei 10MHz; 9,5mW bei 66MHz; 128mW bei 408MHz; 445mW bei 741MHz

Locuza

2013-01-01, 18:00:27

Das low-power Potential sollte doch wohl geringer sein als bei ARM.
Wegen x86 hat man eine zusätzliche Decoder-Stufe und auch sonst ist der Decoding Schritt komplizierter.
Die X86-ISA sollte auch deutlich aufgeblähter als bei ARM sein.

StefanV

2013-01-01, 18:25:44

Locuza, ich denke, du irrst und dass es einfach darauf ankommt, was man designen möchte bzw welches Ziel man hat.

Da würde ich nicht (mehr) sagen wollen 'x86 ist scheiße' oder 'ARM viel toller'. Der Punkt ist, wie ich oben schon sagte, dass sich ARM momentan für Lowest Power durchgesetzt hat und das bisher das Designziel der Architekturen war, während sich X86 für 'High Performance' durchgesetzt hat...

Genauso wäre es auch möglich eine CPU hin zu bekommen, die einen ARM Befehlssatz hätte, aber die Performance aktueller Desktop Prozessoren erreichen könnte.
Allerdings wäre die Leistungsaufnahme dann aber NICHT unter aktueller Desktop Prozessoren...

Womit wir wieder beim Design(ziel) des Prozessors wären...

Locuza

2013-01-01, 18:42:55

Das ist aber falsch.
Nur weil man ein Designziel hat, ist mit vorhanden Mitteln nicht alles erreichbar, wenn die Mittel dich bei irgendetwas einengen und das tut x86 indem es beim decodieren mehr Strom verbraucht und einen aufgeblähten Befehlssatz hat.

Bei x86 muss ich sicherlich mehr architektonische Leistung erbringen, um auf dem selben Level agieren zu können.

SavageX

2013-01-01, 19:43:17

Bei x86 muss ich sicherlich mehr architektonische Leistung erbringen, um auf dem selben Level agieren zu können.

Sehe ich nicht zwangsweise so. Was x86 so "kompliziert" zu Decodieren macht ist ja zum einen die variable Befehlslänge und das Hinzuflicken von neuen Befehlsbereichen über Präfixe. Auch ist die Anzahl der Befehle schlicht recht groß.

Allerdings kann variable Befehlslänge zu kompakteren Binaries führen (die komplizierteren Befehle sind auch größer, die simpleren bleiben kleiner - könnte man als eine Art Entropiekodierung sehen), was zu einer besseren Ausnutzung der Instruction-Caches führen kann, mithin etwas weniger energieintensiven Datentransfer zwischen CPU und RAM. Vermutlich nur ein kleiner Effekt, andererseits ist es ganz nett, wenn man gute Ergebnisse auch mit kleinen Caches erzielt.

edit: Vermutlich ist x86 aber kein Musterbeispiel von Kompaktheit, da sind doch viele Präfixe andauernd zu kodieren.

Bei den Präfixen gab es wohl einigen historischen Wucher, aber ich meine gehört zu haben, dass ab x86_64 halbwegs Ordnung herrscht die nicht ganz nach verrücktem Hutmacher aussieht und dass Zeug wie AVX halbwegs elegant kodiert wird. Da moderne CPUs sowieso mehrere Decoder haben, würde ich erwarten, dass man sich hier spezialisieren kann, man den ganzen alten Krempel, den man Teils vom 8080 geerbt hat, also auf einen langsamen Decoder schieben kann, der auch nur bei Bedarf Energie fressen muss.

So oder so gehen sowohl Intel als auch AMD zu Designs über, in dem es kleine Caches für decodierte Instruktionen gibt, womit die Decoder sowieso einen Gutteil der Zeit schlafen.

Weiterhin hat der Befehlswucher bei x86 natürlich auch was Gutes: Wo für x86 nur ein komplexer Befehl decodiert werden muss (der dann für das jeweilige Design "energieoptimal" in mehreren µops vorliegt) können es für ARM vermutlich auch schon mal mehrere sein, die jeweils einzeln verarbeitet werden müssen.

Dass unterm Strich so oder so ausgerechnet der Befehlssatz entscheidenden Einfluss auf die Energieeffizienz hat glaube ich schlicht nicht. Wenn es nicht gerade Itanium ist ;-)

robbitop

2013-01-02, 12:35:46

Und Intel hat zur Zeit nich mal ein Fertigungsvorteil beim Atom,die 32nm Versionen müssen gegen 28nm A15 SOC's antreten.
Du willst doch nicht wirklich Intels Fertigungsprozess mit dem von Samsung oder TSMC vergleichen? Intel passt seinen Fertigungsprozess an die Designs an. Bei den SoC Herstellern im ARM Bereich ist es umgekehrt.
Ich wette, dass nahezu alle Prozessparameter bei Intels Prozess deutlichst besser sind als bei den Fremdfertigern.
Außerdem ist 28 nm ein Halfnode - die sind idR nur kleiner nicht aber besser als die Fullnodes.

@x64 vs ARM
Mittlerweile ist der Anteil an Mehrverbrauch an Fläche für den Decoder (x86 ggü ARM) so gering, dass es sich kaum lohnt darüber zu sprechen. Man kann heute mit nahezu jeder ISA jedes Designziel erfüllen.
Es kommt mehr auf das Design und den Fertigungsprozess an.
Intels Atom war nie für SFF gedacht, wurde dort aber über etliche Shrinks und Integration hingeprügelt. Das ist eben Intel. Die kriegen das hin.
Wenn Intel aber mal ein natives SFF Design herausbringt, sind alle anderen vermutlich in großen Schwierigkeiten. Sie sind einfach überlegen in allen Kategorien.
Ihr Nachteil ist, dass ARM ein Quasi-Standard im SFF Bereich ist (daran wird auch Windows RT wenig ändern) und dass ihre Produkte viel teurer sind als billige SoCs, die es von sehr vielen Anbeitern gibt.

fondness

2013-01-02, 12:50:00

Du irrst dich A15 wird sogar recht hungrig,ein Grund warum fast jede SOC Variante mit einem Sparcore daher kommen wird.Nvidia hat den schon bei Tegra 3 verbaut und wird das bei T4 fortsetzen.

http://www.arm.com/products/processors/technologies/biglittleprocessing.php

http://www.androidnext.de/news/tegra-4-spezifikationen/

Und natürlich wurde Atom von Anfang an Richtung geringer Verbrauch getrimmt.

Officiating x86 Vs. ARM Using Hard Data

http://www.tomshardware.com/reviews/atom-z2760-power-consumption-arm,3387-5.html

Es geht ja schon damit los das die Performance der ARM-Cores von vielen selbsternannten Experten völlig überschätzt wurde. Man sah schon einen A9 in punkto IPC deutlich über einem Atom. Das viel zu simple Argument war in-order vs. out-of-order. Dazu gab es noch ein paar cherry picked Benchmarks von ARM und Nvidia. Leute mit Ahnung die hier von Anfang an deutlich vorsichtiger ware wurden nicht ernst genommen.

Heute weiß man das ein A9 unter einem Atom liegt und erst der A15 in der Lage ist den Atom zu schlagen. Da ist es dann mit der besseren Energieefffizienz aber auch vorbei. Bereits ein Bobcat hat allerdings eine 60-70% höhere IPC als ein Atom, Jaguar wird hier laut AMD nochmal 15% drauf legen, das sind im CPU-Bereich wo man nicht beliebig parallelisieren kann einfach Welten.

reaperrr

2013-01-02, 19:18:36

Bereits ein Bobcat hat allerdings eine 60-70% höhere IPC als ein Atom
Nur in bestimmten Fällen, jedenfalls was "real-world"-Performance angeht.

Im Test auf planet3dnow.de (http://www.planet3dnow.de/vbulletin/showthread.php?t=407332#content_start) liegt die pro-Takt-Leistung des Atom D2700 gegenüber einem E-450 nur bei Cinebench R10 single-thread und bei herkömmlicher AES-Verschlüsselung so weit hinter Bobcat wie du schreibst. In den anderen Tests liegt der D2700 trotz "nur" 30% höherem Takt oft sogar knapp vorne, selten um 10% zurück. Mit 60-70% höherer Praxis-IPC müsste ein E-450 abzüglich Takt-Nachteil durch die Bank 30-40% schneller sein, was absolut nicht der Fall ist.

fondness

2013-01-02, 19:27:01

Nur in bestimmten Fällen, jedenfalls was "real-world"-Performance angeht.

Im Test auf planet3dnow.de (http://www.planet3dnow.de/vbulletin/showthread.php?t=407332#content_start) liegt die pro-Takt-Leistung des Atom D2700 gegenüber einem E-450 nur bei Cinebench R10 single-thread und bei herkömmlicher AES-Verschlüsselung so weit hinter Bobcat wie du schreibst. In den anderen Tests liegt der D2700 trotz "nur" 30% höherem Takt oft sogar knapp vorne, selten um 10% zurück. Mit 60-70% höherer Praxis-IPC müsste ein E-450 abzüglich Takt-Nachteil durch die Bank 30-40% schneller sein, was absolut nicht der Fall ist.

Das war natürlich auf Single-Thread bezogen. Wenn der Atom seine 4 Threads verwenden kann sieht die Sache naturgemäß anders aus. Es gab dazu auch mal einen Test bei AnandTech mit annähernd gleichen Taktraten.

/Edit: Bei deinen Test sind relativ wenig Werte die rein die CPU-Performnace betrachten.

Knuddelbearli

2013-01-02, 20:37:03

IPC bedeutet in 99% der fälle pro Kern

S940

2013-01-02, 22:59:51

@x64 vs ARM
Mittlerweile ist der Anteil an Mehrverbrauch an Fläche für den Decoder (x86 ggü ARM) so gering, dass es sich kaum lohnt darüber zu sprechen.
Das ist einerseits richtig, andererseits multipliziert sich das Problem aber wieder je mehr Kerne man einsetzt. Das werden in Zukunft immer mehr, da würde ich es zumindest noch im Hinterkopf behalten.
In dem Fall kann nur SMT/CMT helfen.

YfOrU

2013-01-03, 13:22:47

Das ist einerseits richtig, andererseits multipliziert sich das Problem aber wieder je mehr Kerne man einsetzt. Das werden in Zukunft immer mehr, da würde ich es zumindest noch im Hinterkopf behalten.
In dem Fall kann nur SMT/CMT helfen.

Klassisches SMT (HTT) sehe ich im LP Bereich als den falschen Weg und zu dem Schluss ist man wohl auch bei Intel gekommen.

Ganz oben steht auf diesem vergleichsweise niedrigen Performance-Level die IPC pro Kern denn das ist bei alltäglichen Anwendungen der limitierende Faktor. Parallelisierung ist zwar nett aber funktioniert in der Praxis häufig nur sehr eingeschränkt. Ein schönes Beispiel sind die Quad A9 Implementierungen. Denen ist eine Umsetzung mit nur zwei Kernen und dabei höherer IPC immer noch vorzuziehen.

Zusätzlich sind die Kerne in Relation zum gesamten SoC vergleichsweise winzig und da macht es dann auch einfach mehr Sinn direkt zwei oder vier zu integrieren. Alles darüber hinaus ist auch mit Blick auf heutige Desktop CPUs selbst auf recht lange Sicht kaum sinnvoll. Zwischen einem i7 mit bzw. ohne SMT liegen auf dem Desktop je nach Benchmarkauswahl (Anwendungen) gerade mal 10%. Wobei da noch hinzuzufügen ist das dieses Ergebnis bezogen auf LP noch negativ beeinflusst wird. Rendering und Co wird keiner auf Geräten mit einer TDP von unter 10W ernsthaft betreiben.

y33H@

2013-01-03, 13:32:29

Fuad schreibt, Kabini ließe sich mit einer HD 8700M, 8600M, 8500M und 8400M kreuzen. Kabini nutzt die ersten drei GCN, die 8400M sollen aber auf VLIW basieren - bisher geht hier KEIN Dual Graphics. Würde mich wundern wenn AMD extra wegen einer Kombi es irgendwie hinkriegt GCN und VLIW zu koppeln ...

http://fudzilla.com/home/item/29985-kabini-can-be-coupled-with-discrete-hd-8000-cards

fondness

2013-01-03, 13:39:06

Ronny145

2013-01-03, 13:42:02

die ULV Cores von Intel viel zu teuer um gegen Kabini zu konkurrieren.

Die Celeron und Pentium sind sicherlich nicht zu teuer. Mal sehen, wann Jaguar überhaupt in den Markt entlassen wird und ganz besonders, wann die ersten paar Notebooks erhältlich sind. Aus Erfahrung raus kann sich das bei AMD in die Länge ziehen.

Nakai

2013-01-03, 13:48:34

Synthetische Benchmarks, die das gute Threading bestimmter Architekturen offenlegen sind eh für die Katz.
Hier zählen eher richtige Nutzeranwendungen und hier ist ein Bobcat-SOC gegenüber einem Atom-SOC dramatisch überlegen.

fondness

2013-01-03, 13:49:18

Die Celeron und Pentium sind sicherlich nicht zu teuer.

Natürlich sind sie deutlich teurer, alleine schon weil sie zusätzlich noch eine Chipsatz benötigen (erhöht auch den Verdrahtungsaufwand) und weil Intel sicherlich nicht weniger Marge als AMD will. Dazu lässt man sich die ULV-Modelle noch extra bezahlen.

Mal sehen, wann Jaguar überhaupt in den Markt entlassen wird und ganz besonders, wann die ersten paar Notebooks erhältlich sind. Aus Erfahrung raus kann sich das bei AMD in die Länge ziehen.

Ach wenn Produkte überzeugen geht das naturgemäß ganz schnell. Auch Bobat-Geräte waren relativ schnell verfügbar.

Ronny145

2013-01-03, 13:56:08

Natürlich sind sie deutlich teurer, alleine schon weil sie zusätzlich noch eine Chipsatz benötigen (erhöht auch den Verdrahtungsaufwand) und weil Intel sicherlich nicht weniger Marge als AMD will. Dazu lässt man sich die ULV-Modelle noch extra bezahlen.

Notebooks mit Celeron/Pentium sind ab 250€ kaufbar. Sogar die Zacate kosten mehr. AMD müsste Kabini billiger als Ontario anbieten, glaube kaum, dass AMD diese billiger anbietet.

fondness

2013-01-03, 14:02:39

Notebooks mit Celeron/Pentium sind ab 250€ kaufbar. Sogar die Zacate kosten mehr. AMD müsste Kabini billiger als Ontario anbieten, glaube kaum, dass AMD diese billiger anbietet.

Du willst doch soetwas nicht wirklich als konkurrenzfähig zu einem Kabini ansehen:
http://geizhals.at/de/?cat=nb&sort=p&v=e&xf=29_Celeron~29_Celeron+Dual-Core~29_Pentium+900~29_Pentium+B~29_Pentium+Dual-Core~29_Pentium+P~29_Pentium+SU~29_Pentium+U~29_Pentium-M

Ronny145

2013-01-03, 14:08:52

Du willst doch soetwas nicht wirklich als konkurrenzfähig zu einem Kabini ansehen:
http://geizhals.at/de/?cat=nb&sort=p&v=e&xf=29_Celeron~29_Celeron+Dual-Core~29_Pentium+900~29_Pentium+B~29_Pentium+Dual-Core~29_Pentium+P~29_Pentium+SU~29_Pentium+U~29_Pentium-M

Bis dahin gibt es Ivy Bridge Celeron/Pentium. Gegenüber den Dualcores wären die definitiv konkurrenzfähig. Bei den schnelleren Quadcores ist die Frage, wo die sich preislich einsortieren. Die Namensgebung A4 und A6 deutet eher darauf hin, dass sich die schnelleren Kabini in höhere Preisgefilde wagen. A4/A6 Modelle fangen derzeit ab 350€ an, was dann bereits i3 Land wäre.

y33H@

2013-01-03, 14:12:47

=Floi=

2013-01-03, 14:21:36

Nachdem Intels 22nm OoO-Atom endgültig nicht mehr vor 2014 erscheint, könnte man hier im Low-Cost/Low-Power/Small-Form-Factor Bereich durchaus in eine nette Marktlücke stoßen. Die ARM-Chips sind viel zu langsam, die ULV Cores von Intel viel zu teuer um gegen Kabini zu konkurrieren.

ich verstehe sowieso nicht, warum man hier nicht stärker ansetzt und extra auf arm setzen will. fertige produkte kann man sofort verkaufen.

Ronny145

2013-01-03, 14:28:04

Ein 847er Celeron ist für Internet, Videos schauen und Office nicht nennenswert schlechter als das was man von Kabini erwartet. Wer Anwendungsfälle für die bessere iGPU oder vier Kerne findet, der greift zu (den wohl teureren Geräten mit) AMD. Für "all day" und die Akku-Laufzeit würde ich einen 847er aber für die Masse durchaus als konkurrenzfähig ansehen.

Der langsamste IVB Celeron, der dieses? Quartal in den Markt entlassen werden soll, taktet mit 1,5 Ghz und löst den schnellsten 17W SB Celeron ab (887 1,5 Ghz). Jaguar soll erst mitte des Jahres kommen. Bei den Kabini Quads sollte man wie gesagt erstmal die Preisgestaltung abwarten.

YfOrU

2013-01-03, 15:36:08

Der langsamste IVB Celeron, der dieses? Quartal in den Markt entlassen werden soll, taktet mit 1,5 Ghz und löst den schnellsten 17W SB Celeron ab (887 1,5 Ghz). Jaguar soll erst mitte des Jahres kommen. Bei den Kabini Quads sollte man wie gesagt erstmal die Preisgestaltung abwarten.

Es sind trotzdem keine SoCs und genau um die führt sowohl im Low-Power als auch im Low-Cost Segment kein Weg vorbei.

Je höher die Integration desto besser lassen sich die Kosten für das Endprodukt drücken. Gleiches gilt für die Leistungsaufnahme der gesamtem Plattform.

Ronny145

2013-01-03, 15:52:06

Es sind trotzdem keine SoCs und genau um die führt sowohl im Low-Power als auch im Low-Cost Segment kein Weg vorbei.

Je höher die Integration desto besser lassen sich die Kosten für das Endprodukt drücken. Gleiches gilt für die Leistungsaufnahme der gesamtem Plattform.

Wenn wir von Smartphones und Tablets reden würden, müsste ich zustimmen. Ein Soc alleine macht es noch nicht billig, wie man an Haswell ULT sicherlich bemerken wird. Entscheidend ist erstens der Preis, den ich für ein entsprechende Notebooks bezahlen muss. Und als zweites die Leistung. Das entscheidet darüber, ob Kabini mit Celeron/Pentium Notebooks konkurriert oder nicht. In Anbetracht der derzeitigen Celeron/Pentium/Brazos Preisgebung wird Kabini mit hoher Wahrscheinlichkeit in Konkurrenz treten. Die Namensgebung ist ein Hinweis darauf, dass die Preise bzw. die Einordung der schnelleren Kabini höher sind als manch einer hier vermutet. Die werden eher die kleineren Trinity ersetzen.

Windi

2013-01-03, 15:57:24

S940

2013-01-03, 16:01:26

Wenn wir von Smartphones und Tablets reden würden, müsste ich zustimmen. Ein Soc alleine macht es noch nicht billig, wie man an Haswell ULT sicherlich bemerken wird. Entscheidend ist erstens der Preis, den ich für ein entsprechende Notebooks bezahlen muss. Und als zweites die Leistung. Das entscheidet darüber, ob Kabini mit Celeron/Pentium Notebooks konkurriert oder nicht. In Anbetracht der derzeitigen Celeron/Pentium/Brazos Preisgebung wird Kabini mit hoher Wahrscheinlichkeit in Konkurrenz treten. Die Namensgebung ist ein Hinweis darauf, dass die Preise bzw. die Einordung der schnelleren Kabini höher sind als manch einer hier vermutet. Die werden eher die kleineren Trinity ersetzen.

Naja, es wird dual und quads geben. Die Duals ersetzen Zacate Designs, die Quads die kleinen Trinitys. Passt schon.

Zu den Preisen: Der kleine 847er Sandy Celeron steht bei Intel für 134 Dollaer in der Liste. Das es trotzdem (sehr) billige Notebooks und ITX Boards gibt lässt darauf schließen, dass Intel mal wieder großzügige Rabatte gewährt. War gegen Transmeta auch schon die gleiche Geschichte, damals gabs plötzlich günstige Intel ULV Chips. Intel kanns sichs halt leisten.

Ronny145

2013-01-03, 16:05:13

Naja, es wird dual und quads geben. Die Duals ersetzen Zacate Designs, die Quads die kleinen Trinitys. Passt schon.

Genau das sage ich doch.

Zu den Preisen: Der kleine 847er Sandy Celeron steht bei Intel für 134 Dollaer in der Liste. Das es trotzdem (sehr) billige Notebooks und ITX Boards gibt lässt darauf schließen, dass Intel mal wieder großzügige Rabatte gewährt. War gegen Transmeta auch schon die gleiche Geschichte, damals gabs plötzlich günstige Intel ULV Chips. Intel kanns sichs halt leisten.

Oder der Preis ist falsch. Die größeren Celeron 877 und 887 kosten $86.

SavageX

2013-01-03, 16:05:13

Die Namensgebung ist ein Hinweis darauf, dass die Preise bzw. die Einordung der schnelleren Kabini höher sind als manch einer hier vermutet. Die werden eher die kleineren Trinity ersetzen.

Preise und Einordnungen sind ja nur Erwartungen über die Marktposition und entsprechend dynamisch.

Was bleibt ist dass Kabini als SoC wohl eine geringere Die-Size hat als ein Celeron/Pentium + Chipsatz und auch nur ein Package braucht. Die Boards dürften auch simpler sein (nur ein Chip und nur ein Speicherkanal). Entsprechend müsste beim Preis auch Luft sein, wenn es die Marktsituation erfordert.

Ronny145

2013-01-03, 16:06:34

Das die Rechnung nicht immer aufgeht, haben wir an den 28nm GPUs und 22nm CPUs gesehen.

YfOrU

2013-01-03, 16:16:43

Für Smartphones und Tablets gibt es ARM und ATOM.

Temash (ULP Kabini) wird den aktuellen Atom SoC bezogen auf Windows 8 Tablets wohl in jedem Bereich frühstücken.

Die Notebooks liegen eigentlich alle im Bereich von 250€ bis 350€, je nach Ausstattung. Die AMD-Notebooks sind im Durchschnitt vielleicht 10€ günstiger. Ein großer Vorteil scheint das aber nicht zu sein.

Die Bobcat APUs gibt es nicht als SoC sondern benötigen immer einen separaten Chipsatz. Ich denke hier auch ganz explizit an 15 Zoll und Nettops denn ein großer Teil der Menschen auf diesem Planeten kann sich nicht mal ein Notebook für 350€ leisten ;) SoC-> schwächerer Akku, kompaktere Platine, weniger Bauteile, günstigeres Gehäusedesign.

S940

2013-01-03, 16:17:34

Genau das sage ich doch.Ach, mit "schnellere Kabinis" meintest Du die Quads? Ok, ja dann passts.

Oder der Preis ist falsch. Die größeren Celeron 877 und 887 kosten $86.Stimmt, die größeren hab ich gar nicht gesehen. Vielleicht ist es der Preis der Embedded Variante, die hat auch noch ECC, 16 PCIe Lanes aber den gleichen Listenpreis:

http://ark.intel.com/compare/56056,55764

Ronny145

2013-01-03, 16:40:33

Die Bobcat APUs gibt es nicht als SoC sondern benötigen immer einen separaten Chipsatz. Ich denke hier auch ganz explizit an 15 Zoll und Nettops denn ein großer Teil der Menschen auf diesem Planeten kann sich nicht mal ein Notebook für 350€ leisten ;) SoC-> schwächerer Akku, kompaktere Platine, weniger Bauteile, günstigeres Gehäusedesign.

Und trotzdem sagt das nichts über den Preis aus. Genau das Gegenteil kann gut möglich sein. Lösen die Kabini Quads die unteren Trinitys ab, wonach die Namensgebung stark hindeutet, steigen die Preise an.

YfOrU

2013-01-04, 08:24:25

Und trotzdem sagt das nichts über den Preis aus. Genau das Gegenteil kann gut möglich sein. Lösen die Kabini Quads die unteren Trinitys ab, wonach die Namensgebung stark hindeutet, steigen die Preise an.

Da kann ich genauso umgekehrt argumentieren denn E1-2210 und E1-3310 lösen von der Namensgebung die ganz billigen Bobcat APUs (E1) ab. Mit Kabini lässt sich einfach ein größeres Spektrum als bisher abdecken.
Kabini mit vier Jaguar Kernen sehe ich nicht in der gleichen Kategorie wie zwei Bobcat Kerne.

Ronny145

2013-01-04, 13:50:21

Da kann ich genauso umgekehrt argumentieren denn E1-2210 und E1-3310 lösen von der Namensgebung die ganz billigen Bobcat APUs (E1) ab. Mit Kabini lässt sich einfach ein größeres Spektrum als bisher abdecken.
Kabini mit vier Jaguar Kernen sehe ich nicht in der gleichen Kategorie wie zwei Bobcat Kerne.

Was willst du da umgekehrt argumentieren? Das bestätigt mich doch. Nur die schwächsten Kabini ersetzen die C-xx, E1-xx Brazos, die wiederum mit Celeron/Pentium in Konkurrenz treten. Das sieht bei A4/A6 Modellen anders aus.

AnarchX

2013-01-04, 19:15:00

Wohl möglich doch Dual-Channel für Kabini: http://semiaccurate.com/forums/showpost.php?p=174270&postcount=65

Die Package-Size ist gegenüber Brazos auch gestiegen.

Ronny145

2013-01-04, 19:25:40

Associate claims that the production of processors Kabini E series will begin in March and April, the announcement is scheduled for June this year.

Bedeutet frühestens Juni wenn man die Regel +3 Monate anwendet.

Gipsel

2013-01-04, 20:03:20

Die Package-Size ist gegenüber Brazos auch gestiegen.Da ist ja auch ein kompletter Chipsatz mit integriert. SATA, USB und der restliche Kleinkram müssen auch irgendwie runter vom Package. 769 Pins bei Kabini gegenüber 413 bei Ontario/Zacate ist aber schon ein ziemlich deutlicher Anstieg.

y33H@

2013-01-04, 20:11:45

Wohl möglich doch Dual-Channel für Kabini: http://semiaccurate.com/forums/showpost.php?p=174270&postcount=65

Die Package-Size ist gegenüber Brazos auch gestiegen.Tippe eher auf schlechtes English ;-)

Ronny145

2013-01-08, 01:40:28

+50% performance increase from Brazos 2.0: http://images.anandtech.com/doci/6567/AMD-018.jpg

Bezieht sich das auf Kabini Quadcore vs Brazos Dualcore?

(2) Test conducted in AMD Performance Labs using FutureMark 3DMark
Vantage P as a metric for GPU performance and PCMark Vantage as a metric
for CPU performance. The AMD Z-60 APU-based system scored 455 and 1914 in
3DMark and PCMark respectively. The AMD A6-1450 APU-based system delivers
scores of 981 and 3123 in 3DMark and PCMark respectively. The platforms
tested were the AMD Z-60 APU with AMD Radeon(TM) HD 6250 graphics, 2x 2GB
DDR3-1066, Microsoft Windows 7 and the "Larne" reference platform with an
AMD A6-1450 Quad Core 1.0GHz APU, AMD Radeon(TM) HD 8280 Series graphics,
2GB DDR3-1066 system memory and Microsoft Windows 7. TEM-2

(3) Test conducted in AMD Performance Labs measuring productivity
performance with PCMark Vantage. The "Kabini" A6 APU-based system scored
5271 while the "Brazos" APU-based system scored 2807. "Kabini" PC config
is based off the "Larne" reference design with 2013 AMD A6-5200 APU with
AMD Radeon HD 8400 graphics, 4G DDR3 1600, and Windows 8 64bit. "Brazos"
PC config is based off the "Renmore" reference resign with 2012 AMD
E2-1800 APU with AMD Radeon HD 7340 graphics, 4G DDR3 1333 and Windows 7
Ultimate. KBN-3
http://www.reuters.com/article/2013/01/08/idUSnMKW71658a+1c0+MKW20130108

Knuddelbearli

2013-01-08, 08:37:40

von overclockers.com.au/showthread.php?p=15028374

Temash (Jaguar-based APU for tablets)

Testbed:
* AMD Z-60 APU (Hondo) with Radeon HD 6250 IGP
=> 1.0Ghz, dual-core
=> 2x 2GB DDR3-1066
=> Windows 7
VS
* AMD A6-1450 (Temash) with Radeon HD 8280 IGP
=> 1.0Ghz, quad-core
=> 2GB DDR3-1066
=> Windows 7

FutureMark 3DMark Vantage P (Synthetic GPU test)
=> Z-60 (Hondo): 455
=> A6-1450 (Temash): 981

PCMark Vantage (Synthetic CPU test)
=> Z-60 (Hondo): 1914
=> A6-1450 (Temash): 3123

Kabini (Jaguar-based APU for ultrathin notebooks and SFF PCs)

Testbed:
* AMD E2-1800 APU (Brazos 2.0) with Radeon HD 7340 IGP
=> 1.7Ghz, dual-core
=> 4GB DDR3-1333
=> Windows 7 Ultimate.
VS
* AMD A6-5200 APU (Kabini) with Radeon HD 8400 IGP
=> ???Ghz, quad-core? (undisclosed! )
=> 4GB DDR3-1600
=> Windows 8 64bit.

PCMark Vantage (Synthetic CPU test)
=> E2-1800 APU (Brazos 2.0): 2807
=> A6-5200 APU (Kabini): 5271

also 2 vs 4 Kerne

mboeller

2013-01-08, 08:40:44

Die PCMark Vantage Werte des Kabini sind schon mal nicht schlecht. 5271 Punkte...das ist fast so viel wie ein Trinity A10-4600M!

Siehe:
http://www.notebookcheck.com/Test-Acer-Aspire-V3-551G-10468G50Makk-Notebook.81634.0.html 4951 - 5552 Punkte (HDD)

zum Vergleich ein E2-1800:
http://www.notebookcheck.com/Test-Lenovo-ThinkPad-Edge-E135-NZV5YGE-Netbook.82179.0.html 2669 Punkte

Undertaker

2013-01-08, 09:28:06

fondness

2013-01-08, 09:52:25

Hier die komplette Präsentation: http://www.computerbase.de/news/2013-01/amd-auf-der-ces-grober-fahrplan-fuer-2013/
Man verspricht 100% mehr GPU- und 50% mehr CPU-Leistung.

mboeller

2013-01-08, 09:57:53

Beim PCMark Vantage sollte man immer vorsichtig sein, schon eine schnellere HDD mit 7200rpm kann das Gesamtergebnis kräftig befeuern - ist halt kein reiner CPU- oder GPU-Test.

Aber die Tendenz ist sicherlich vielversprechend.

Da hast du recht. Deshalb habe ich den Brazos-score mit rausgesucht.
AMD: 2807; Notebook: 2669

Das sollte also zumindest von der Tendenz passen.
___

Was mir noch aufgefallen ist:

Temash Quadore @ 1,0GHz und 5W TDP > Brazos E2-1800 mit 18W beim PCMark Vantage

Hat damit ein Temash-Quadcore eigentlich eine geringere TDP als zB. ein Tegra4? Nach den bisherigen Infos könnte es schon so sein. :eek:

Jetzt müsste man nur noch wissen wie die Performance ist. ;)

fondness

2013-01-08, 09:59:47

Hat damit ein Temash-Quadcore eigentlich eine geringere TDP als zB. ein Tegra4? Nach den bisherigen Infos könnte es schon so sein. :eek:

NV rückt wohl nicht ohne Grund keine TDP-Werte raus.

Jetzt müsste man nur noch wissen wie die Performance ist. ;)

Das ein A15 mit keinem Jaguar mithalten kann ist kein Geheimnis.

Noch ein paar Infos zur Verfügbarkeit:
07:27PM EST - Kabini - 50%+ performance increase from Brazos 2.0, first quad-core x86 SoC, shipping 1H2013
07:33PM EST - Kaveri will be 2H2013 with GCN support

Auch sonst noch ein paar interessante Details: http://www.anandtech.com/show/6567/amd-ces-2013-press-event-live-blog

Knuddelbearli

2013-01-08, 11:15:59

Hier die komplette Präsentation: http://www.computerbase.de/news/2013-01/amd-auf-der-ces-grober-fahrplan-fuer-2013/
Man verspricht 100% mehr GPU- und 50% mehr CPU-Leistung.

50% mehr cpu leistung bei doppelt sovielen kernen höherer ipc und selber takt ?!?

AnarchX

2013-01-08, 11:21:23

Fraglich ob bei 4 Threads der Takt gleich bleibt, bei den 15W Modellen. Die 25W A6 Modelle haben dann vielleicht den vollen Takt.

Spasstiger

2013-01-08, 12:52:52

Jetzt müsste man nur noch wissen wie die Performance ist. ;)
Ein Tegra 4 kann nur davon träumen, 3DMark Vantage überhaupt darstellen zu können. Die GPU-Score von Temash entspricht einer Radeon HD 3650 (Quelle (http://www.computerbase.de/artikel/software/2008/bericht-3dmark-vantage-der-performance-report/6/)). Tegra 4 ist imo bestenfalls auf NV40-Niveau anzusiedeln (GeForce 6800 Ultra), aber mit schwächerem Featureset bzw. geringerer Präzision.
5 Watt finde ich übrigens viel für einen Tablet-SoC. Intels CloverTrail braucht max. 1,6 Watt, Tegra 4 kommt vermutlich auch nicht auf 5 Watt.

fondness

2013-01-08, 13:04:04

5 Watt finde ich übrigens viel für einen Tablet-SoC. Intels CloverTrail braucht max. 1,6 Watt, Tegra 4 kommt vermutlich auch nicht auf 5 Watt.

AMD gibt 3.6W bis 5.9W an:
http://www.computerbase.de/news/2012-12/weitere-details-zu-amds-kabini-sickern-durch/

y33H@

2013-01-08, 13:54:37

Inklusive FCH, der PCH ist beim Z2760 iirc extern - der NM10 braucht noch mal so viel Watt.

EDIT
Sorry, der Z2760 ist ja ein kompletter SoC mit "NB" und "SB".

44699

disap.ed

2013-01-09, 11:11:31

GCN-ALUs sind aber schon deutlich effizienter wie die VLIW4-ALUs von Trinity. Allerdings hat Kabini wohl nur ein 64-bit SI, deshalb wird er kaum schneller sein. Dafür ist das gesamte System allerdings auch deutlich stromsparender ohne Chipsatz und mit nur einem Speicherkanal.

Ich dachte Kabini hat ein Dual-Channel-Interface?

robbitop

2013-01-09, 11:48:55

Das war ein Übersetzungsfehler. Kabini hat aus Leistungsaufnahmegründen nur Single Channel.

Ich finde es auch ein wenig lächerlich, das anzuzweifeln, was die PCGH Redakteure selbst getestet haben. Und die Jungs machen das jeden Tag...
Das ist ja nun keine Glaubensfrage. Getestet ist getestet.

Hat Kabini eigentlich zu jeder Situation 1/2x Coretakt = L2 Cachetakt (analog zu Bobcat)? Oder hat der auch die Möglichkeit, bei Bedarf auf volle Taktfrequenz zu gehen=

fondness

2013-01-09, 12:01:52

Hat Kabini eigentlich zu jeder Situation 1/2x Coretakt = L2 Cachetakt (analog zu Bobcat)? Oder hat der auch die Möglichkeit, bei Bedarf auf volle Taktfrequenz zu gehen=

Nachdem der L2 über alle vier Kerne geshared ist hat der Sicher seine eigenen Taktdomain.

Locuza

2013-01-09, 12:32:56

Hat Kabini eigentlich zu jeder Situation 1/2x Coretakt = L2 Cachetakt (analog zu Bobcat)? Oder hat der auch die Möglichkeit, bei Bedarf auf volle Taktfrequenz zu gehen=
Er hat auch die Möglichkeit vollen Coretakt zu fahren.

mboeller

2013-01-09, 12:35:07

Das war ein Übersetzungsfehler. Kabini hat aus Leistungsaufnahmegründen nur Single Channel.

Da Kabini ja anscheinend 114mm² groß ist gehe ich momentan eigentlich von einem Dual-Channel aus. Außer natürlich die Southbridge nimmt den meisten Platz ein.

edit (zwar im falschen Thread, aber egal):
in der neuen Roadmap steht bei Kabini übrigens 9-15W dabei. Die 25W Version wird es anscheinend nicht geben, wäre Richland wahrscheinlich auch zu dicht auf den Pelz gerückt. :)
Außerdem scheint der Quadcore mit 1,7GHz zu laufen. Der Temash-Quadore erreicht ja bei 1GHz 3123 PCMark-Punkte und Kabini 5271 Punkte. 5271/3123 = 1,69 Damit ist natürlich die Single-thread-Leistung nur ca. 10% besser als beim E2-2000....Schade! Allerdings ist der PCMark ziemlich ungenau und kann durch einfache Änderungen (HDD mit 7200 od. 5400 U/min) schon andere Resultate liefern.

robbitop

2013-01-09, 13:03:43

@voller L2 Takt
Interessant: gibt es dazu auch eine Quelle? :)

Da Kabini ja anscheinend 114mm² groß ist gehe ich momentan eigentlich von einem Dual-Channel aus. Außer natürlich die Southbridge nimmt den meisten Platz ein.
Das hat nichts mit der Kerngröße zu tun. Ein zweiter Speicherkontroller kostet halt auch Leistungsaufnahme. Und das ist für Jaguar offenbar nicht vorgesehen. Zumindest liest sich das im P3DNow Thread so. Konkretes dazu gibt es von AMD AFAIK nicht.

robbitop

2013-01-09, 13:17:06

Nice! Das sollte die Singlethread IPC ordentlich steigern.

y33H@

2013-01-09, 13:30:38

Bei ST hat der eine Kern zudem den kompletten L2 für sich, da shared.

mboeller

2013-01-09, 13:38:50

ich poste mal meinen Kommentar aus dem Bulldozer-Thread hier nochmal (hier passt es schließlich besser rein):

Kabini ist anscheinend 114mm² groß (siehe http://semiaccurate.com/forums/showpost.php?p=174715&postcount=121) Deshalb gehe ich momentan eigentlich von einem Dual-Channel Speicherinterface aus, Platz genug wäre dafür vorhanden.
Außer natürlich die Southbridge nimmt den meisten Platz ein.

in der neuen Roadmap (siehe AMD_Client_Roadmap_1_7_13.pdf) steht bei Kabini übrigens 9-15W dabei. Die 25W Version wird es anscheinend nicht geben, wäre Richland wahrscheinlich auch zu dicht auf den Pelz gerückt.
Außerdem scheint der Quadcore mit 1,7GHz zu laufen. Der Temash-Quadore erreicht ja bei 1GHz 3123 PCMark-Punkte und Kabini 5271 Punkte. 5271/3123 = 1,69 Damit sollte die Single-thread-Leistung nur ca. 10% besser als beim E2-2000....Schade!
Allerdings ist der PCMark ziemlich ungenau und kann durch einfache Änderungen (HDD mit 7200 od. 5400 U/min) schon andere Resultate liefern.

Ravenhearth

2013-01-09, 13:54:44

in der neuen Roadmap (siehe AMD_Client_Roadmap_1_7_13.pdf) steht bei Kabini übrigens 9-15W dabei. Die 25W Version wird es anscheinend nicht geben, wäre Richland wahrscheinlich auch zu dicht auf den Pelz gerückt.

Ich gehe davon aus, dass es ihn geben wird, wenn auch nicht im Mobile. Schließlich wäre er auch günstiger als ein Richland.

Außerdem scheint der Quadcore mit 1,7GHz zu laufen. Der Temash-Quadore erreicht ja bei 1GHz 3123 PCMark-Punkte und Kabini 5271 Punkte. 5271/3123 = 1,69 Damit sollte die Single-thread-Leistung nur ca. 10% besser als beim E2-2000....Schade!
Allerdings ist der PCMark ziemlich ungenau und kann durch einfache Änderungen (HDD mit 7200 od. 5400 U/min) schon andere Resultate liefern.
Was rechnest du denn da? Du teilst das Ergebnis des Kabini, welcher 70% höher taktet, durch das des Temash (beide Quads) und stellst fest, dass ersterer nur 69% schneller ist und schließt dann auf die ST-Leistung im Vergleich mit den Bobcat-Chips? ;D

robbitop

2013-01-09, 14:15:58

Good one! :D :D :D

mboeller

2013-01-09, 14:16:41

Ich gehe davon aus, dass es ihn geben wird, wenn auch nicht im Mobile. Schließlich wäre er auch günstiger als ein Richland.

Die Roadmap heißt aber nicht "Mobile-Roadmap" sondern "Client Roadmap". Da sollte der Desktop mit dabei sein.

mboeller

2013-01-09, 14:18:28

Was rechnest du denn da? Du teilst das Ergebnis des Kabini, welcher 70% höher taktet, durch das des Temash (beide Quads) und stellst fest, dass ersterer nur 69% schneller ist und schließt dann auf die ST-Leistung im Vergleich mit den Bobcat-Chips? ;D

Lesen würde helfen. :)

ich gehe davon aus, das der Kabini mit 1,7GHz taktet, da er einen 69% höheren PCMark-wert erreicht als der Temash der mit 1GHz taktet.

zum 2. Punkt: ja das ist ein wenig schräg geschrieben, aber laut AMD erreicht Jaguar eine ~15% höhere IPC als Bobcat. Bei 1,7GHz im Vergleich zu 1,75GHz beim E2-2000 erreicht der Jaguar/Kabini wohl nur eine 10% höhere ST-Leistung als der Bobcat. Offener Punkt: 2MB L2-Cache beim Jaguar bei ST im Vergleich zu den 512KB beim Bobcat.

Deinorius

2013-01-09, 14:24:33

Kabini ist anscheinend 114mm² groß (siehe http://semiaccurate.com/forums/showpost.php?p=174715&postcount=121) Deshalb gehe ich momentan eigentlich von einem Dual-Channel Speicherinterface aus, Platz genug wäre dafür vorhanden.

Vergiss nicht, dass Kabini ein vollwertiger SoC ist.

disap.ed

2013-01-09, 14:31:38

Das ist Tegra4 auch und der hat DualChannel AFAIK.

robbitop

2013-01-09, 14:41:29

Tegra 4 hat wesentlich weniger Leistung.Hat also anderswo mehr Reserven, die man dafür nutzen konnte. Und soweit ich weiß, nutzt Tegra kein DDR3 sondern LP-DDR. Das sind andere Takt- und Leistungsaufnahmeregionen. Irgendwo dran muss man sparen. AMD hat die Leistungsaufnahme in die CPU und die GPU investiert.

AnarchX

2013-01-09, 14:43:33

Bei den ARM-SoCs bedeutet Dual-Channel häufig 2x32-Bit.

Die Die-Size könnte bei Kabini durchaus für 2x64-Bit sprechen. Wenn man bedenkt das Mars mit 384SPs/128-Bit GDDR5/PCIe/Displayausgängen gerade mal 77mm² @ 28nm benötigt.

Hier ist übrigens auch das Pin-Out zu sehen: http://www.forum-3dcenter.org/vbulletin/showthread.php?p=9610625#post9610625 ... da kann man vielleicht die SI-Breite ablesen?

Ronny145

2013-01-09, 14:45:06

Die Roadmap heißt aber nicht "Mobile-Roadmap" sondern "Client Roadmap". Da sollte der Desktop mit dabei sein.

Für Richland sind aber auch nur mobile TDP Werte auf der Roadmap angegeben.

~110 mm² hört sich recht viel an. Macht der Chipsatz so viel aus?

robbitop

2013-01-09, 14:52:29

Dagegen spricht, dass Tamesh die gleiche Anzahl von Pins hat wie Kabini. Und Tamesh hat wohl definitiv Single Channel. Wenn Kabini Dual Channel hätte und Tamesh nicht, hätte Tamesh aus Kosten und Bauraumbedingten Gründen weniger Kontakte.

Bei den ARM-SoCs bedeutet Dual-Channel häufig 2x32-Bit.

Zumindest der A5X/A6x haben 2x 64 bit. Aber eben LP-DDR. Das kann man nicht mit "normalem" DDR vergleichen (Takt, Leistungsaufnahme).

AnarchX

2013-01-09, 14:58:12

Dagegen spricht, dass Tamesh die gleiche Anzahl von Pins hat wie Kabini. Und Tamesh hat wohl definitiv Single Channel. Wenn Kabini Dual Channel hätte und Tamesh nicht, hätte Tamesh aus Kosten und Bauraumbedingten Gründen weniger Kontakte.
Apple setzt bei A5X/A6X auch auf 128-Bit (4x32-Bit) und LP-DDR. Warum sollte AMD nicht ähnliches machen? Es sind wohl immerhin 4 Kerne mit IPC auf Swift/A15-Niveau und mindestens 2 GCN CUs, da braucht es schon etwas an Bandbreite, die man nicht unbedingt mit hochgetaktetem DDR3 erreichen sollte.

Ein Pin-Out entscheidet zudem nicht darüber, was schlussendlich auf dem Mainboard angebunden ist. So könnte man auch ein 128-Bit Package auf PCB setzen, wo es nur mit 64-Bit angebunden wird.

robbitop

2013-01-09, 15:08:58

Apple setzt bei A5X/A6X auch auf 128-Bit (4x32-Bit) und LP-DDR. Warum sollte AMD nicht ähnliches machen? Es sind wohl immerhin 4 Kerne mit IPC auf Swift/A15-Niveau und mindestens 2 GCN CUs, da braucht es schon etwas an Bandbreite, die man nicht unbedingt mit hochgetaktetem DDR3 erreichen sollte.
AMD verbrät aber schon anderweitig verdammt viel Leistung. Vieleicht war einfach kein DC mehr drin? Die Jaguars wischen mit jedem verfügbaren ARM Cores den Boden auf. Die GPU ist vermutlich auch deutlich fixer als SGX554-MP4.

LP-DDR hat ja widerrum so wenig Takt, dass es nicht mehr Bandbreite bietet als Single Channel DDR3.

Ein Pin-Out entscheidet zudem nicht darüber, was schlussendlich auf dem Mainboard angebunden ist. So könnte man auch ein 128-Bit Package auf PCB setzen, wo es nur mit 64-Bit angebunden wird.
Das macht ja furchtbar viel Sinn aus Kostensicht. Wenn Tamesh wirklich nur Single Channel hätte und Kabini DC, hätte Tamesh garantiert weniger Pins. Das Package wird allein schon viel kleiner und billiger dadurch.

Schau mal bitte in den P3DNow Thread. Im Moment sieht es nach Single Channel aus.

AnarchX

2013-01-09, 15:19:27

AMD verbrät aber schon anderweitig verdammt viel Leistung. Vieleicht war einfach kein DC mehr drin? Die Jaguars wischen mit jedem verfügbaren ARM Cores den Boden auf. Die GPU ist vermutlich auch deutlich fixer als SGX554-MP4.
Laut den Benchmarks von AMD entspricht die Temash GPU etwa einer 80SPs VLIW5 GPU @ 600MHz.

LP-DDR hat ja widerrum so wenig Takt, dass es nicht mehr Bandbreite bietet als Single Channel DDR3.

LP-DDR3 gibt es wohl bald mit 1600Mbps: http://pc.watch.impress.co.jp/img/pcw/docs/580/768/html/2.jpg.html

Und da AMD beim Temash Setup nur 1066MHz DDR3 angibt, stellt sich die Frage ob es denn nicht schon LP-DDR3 ist.