News Bobcat-Nachfolger Jaguar bekommt Unterstützung für AVX

[Opteron]

<div class="newsfloatleft"><a href="link"><img src="http://www.planet3dnow.de/photoplog/images/54308/1_AMD-Logo.png" border="0"></a></div>Bisher wurden die Low-Power-Prozessoren sowohl bei Intel als auch bei AMD in den Befehlssätzen beschnitten. Es schien fast so, also ob sich beide Firmen stillschweigend geeinigt hätten, denn sowohl Ontario/Zacate mit Bobcat-Kernen als auch Intels Atom-Prozessoren unterstützten maximal SSSE3. Kein SSE4.1 oder 4.2, oder gar AVX. Dies ändert sich nun.

AMDs kommender Mobilprozessor Kabini mit Jaguar-Kernen, der laut der <a href="http://www.planet3dnow.de/photoplog/file.php?n=20704&w=o">aktuellen Roadmap</a> für 2013 in 28 nm geplant ist, wird laut Aussage eines AMD-Compiler-Programmierer mit AVX-Unterstützung aufwarten können:
<div style="margin: 5px 20px 20px;"><div class="smallfont" style="margin-bottom: 2px;">Zitat:</div><table border="0" cellpadding="6" cellspacing="0" width="100%"><tbody><tr><td class="alt2" style="border: 1px inset;"><i>There are ISA changes as well like btver2 supports AVX, BMI.</i></td></tr></tbody></table></div>Zusätzlich werden auch die nicht so bekannten Bit-Manipulations-Instruktionen (BMI) implementiert.

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 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 SSSE3, sehr verwunderlich.

Des weiteren gibt es noch ein kleines Detail zur Hardwarekonfiguration. Die Entwickler änderten die Compiler-Optimierungs-Variable für den L2-Cache von 512 kB auf 2048 kB. Allerdings ist es höchst fragwürdig, ob die Jaguar-Kerne wirklich 2MB-L2-Cache pro Kern bekommen. Schließlich handelt es sich bei Jaguar um ein kostengünstiges Low-power-Design. 2 MB L2-Cache pro Kern würden selbst im platzsparenden 28nm-Prozess bei einem Quad-Core-Prozessor zuviel Fläche verbrauchen, wodurch die Produktion zu teuer werden würde. Worüber man spekulieren könnte, wäre vielmehr ein gemeinsamer, vereinigter L2-Cache für alle 4 Kerne einer Kabini-APU. Pro Kern bliebe es im Schnitt dann bei den schon bisher üblichen 512 kB.

Dies wäre dann natürlich kein Höchstleistungs-Design, aber erstens ist die Bocat-Reihe eben keine Höchstleistungs-Architektur, zweitens läuft der L2-Cache der aktuellen Bobcats schon mit nur halbem Takt und drittens hätte man Vorteile in den immer noch verbreiteten Single-Thread-Last-Szenarien, da einem Thread die vollen 2 MB L2-Cache zur Verfügung stünden.

<a name="Update"><b>Update 24.7.2012</b></a>
Unser Forenmitglied tex_ hat sich den Code genau angesehen und festgestellt, dass dort in den Compiler-Änderungsbeschreibungen bereits eine komplette Befehlssatzübersicht zu finden ist (<a href="http://www.planet3dnow.de/vbulletin/showthread.php?p=4642681#post4642681">Link</a>). Die Jaguar-Architektur unterstützt demnach alle Befehlssätze, die vor dem Erscheinen von AVX gebräuchlich waren, also SSE 4.1, SSE 4.2 und AES. Unsere obige Spekulation zu älteren Befehlssätzen war somit eigentlich unnötig, aber immerhin ist sie damit jetzt auch bestätigt. Was im Vergleich zu Bulldozer fehlt ist nur die <a href="http://www.planet3dnow.de/vbulletin/showthread.php?t=384394&garpg=18#content_start">FMAC-Fähigkeit</a> der FPU. Diese ist aber für einen günstigen Einstiegsprozessor - selbst im nächsten Jahr - sicherlich noch nicht nötig. Ansonsten würde auch die FPU und damit der gesamte Chip zu groß werden, was sich negativ bei die Fertigungskosten auswirken würde und damit dem Ziel, einen günstigen Prozessor anbieten zu können, entgegenwirken würde.

Alleine durch die bloße Verwendung von AVX darf man allerdings keine dramatische Leistungserhöhung erwarten. Auch wenn der Befehlssatz 256 Bit vorsieht, böte das gegenüber alten 64-Bit-Instruktionen keinen Vorteil, wenn die Rechenwerke diese z.B. nur in vier Takten zu je 64 Bit abarbeiten können. Um einen der oft gescholtenen Auto-Vergleiche zu bemühen: Ohne größere Motorumbauten ist der Effekt eines besseren Treibstoffes (z.B. Super-Plus statt Normalbenzin) eher gering. In etwa den ähnlichen Effekt wird man von den restlichen AVX-Verbesserungen (3-Operanden-Format und leicht kürzere Befehle, dank VEX-Präfix) erwarten können - zumindest solange AMD nicht auch etwas am Motor, d.h. den Rechenwerken ändert und diese z.B. auf 128 Bit erweitert.

Genauere Informationen werden im August erwartet, wenn AMD die Jaguar-Architektur auf der Hotchips-Konferenz präsentiert.


<b>Links zum Thema:</b><ul><li><a href="http://www.planet3dnow.de/vbulletin/showthread.php?t=362353">AMDs SSE5 ist tot - lang lebe AVX</a></li><li><a href="http://www.planet3dnow.de/vbulletin/showthread.php?t=385065">Bobcat, das Bulldözerchen</a></li><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1339699724">AFDS 2012: AMD aktualisiert und erweitert Roadmaps für 2012 und 2013</a></li></ul>
<b>Quellen:</b><ul><li><a href="http://gcc.gnu.org/ml/gcc-patches/2012-07/msg01023.html" target="b">RE: [PATCH, i386]: AMD btver2 enablement</a></li><li><a href="http://www.phoronix.com/scan.php?page=news_item&px=MTE0Mzc" target="b">Phoronix: AMD Prepares "Bobcat 2" Compiler Support</a></li></ul>

 

[gruffi]

Das wäre natürlich mal ein interessanter Ansatz, ein shared L2 für alle Kerne. Da stellen sich für mich allerdings 2 Fragen. Wirkt sich das negativ auf die Leistungsaufnahme aus, wenn Kerne ideln? Schliesslich wären dann immer 2048 KiB aktiv und nicht nur die jeweiligen L2 der aktiven Kerne. Und würde ein shared L2 nicht für eine komplett inklusive Cache-Hierarchie sprechen?

 

[TNT]

Das liest sich doch ganz gut...

Sehr gut, dass AMD sich den ISA auch auf diesem Niveau annimmt - bleibt zu hoffen, dass sie auch dort von Nutzen sein kann...

 

[Opteron]

Das wäre natürlich mal ein interessanter Ansatz, ein shared L2 für alle Kerne. Da stellen sich für mich allerdings 2 Fragen. Wirkt sich das negativ auf die Leistungsaufnahme aus, wenn Kerne ideln? Schliesslich wären dann immer 2048 KiB aktiv und nicht nur die jeweiligen L2 der aktiven Kerne.

Bestimmt, aber Cache hat schon immer nicht viel verbraucht, und in 28nm kann mans sich dann vermutlich erst recht leisten, da es noch weniger ausmacht.

Und würde ein shared L2 nicht für eine komplett inklusive Cache-Hierarchie sprechen?

Kommt drauf an. Nachdem AMD beim Bobcat ja die L1 halbierte und nur 2x32 statt 2x64 hat, wärs wohl noch ok, da man "nur" 4x2x32kB = 256kByte verlöre. Also 100%ig ausschließen würde ich es nicht.

@TNT:
Ja bin gespannt, ob die FPU etwas schneller wird, viel erwarte ich aber nicht, die Winz-FPU im Bobcat schlägt sich für die Größe und dem Stromverbrauch eigentlich ganz gut.

 

[gruffi]

Bestimmt, aber Cache hat schon immer nicht viel verbraucht, und in 28nm kann mans sich dann vermutlich erst recht leisten, da es noch weniger ausmacht.

Naja, ein bisschen was braucht auch der Cache. Und wir reden hier ja eh von Prozessoren mit wenig TDP. Da schmerzt im Endeffekt jedes Watt zu viel.

 

[Opteron]

Naja, ein bisschen was braucht auch der Cache. Und wir reden hier ja eh von Prozessoren mit wenig TDP. Da schmerzt im Endeffekt jedes Watt zu viel.

Klar, aber dafür gibts dann ja auch mehr Leistung. Ist ja immer die Optimierung zw. Leistung/Stromverbrauch und Die-Fläche. Bei 28nm könnte sich das nun rentieren, da man dank der kleinen Fertigung sowieso schon den angepeilten Watt-Bereich einfach einhalten kann.

 

[gruffi]

Dafür hat man allerdings auch doppelt so viele Kerne. Die muss man auch irgendwie in die TDP quetschen.

 

[Opteron]

Dafür hat man allerdings auch doppelt so viele Kerne. Die muss man auch irgendwie in die TDP quetschen.

5W gibts nur mit 2 Kernen, die Quads haben mind. 17W, stand mal im letzten Cat. Treiber:

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)"

Eventuell schalten sie da dann auch etwas vom L2 ab, dann hättest Du quasi recht ^^

 

[rkinet]

Das wäre natürlich mal ein interessanter Ansatz, ein shared L2 für alle Kerne.

Da stellen sich für mich allerdings 2 Fragen.
Wirkt sich das negativ auf die Leistungsaufnahme aus, wenn Kerne ideln?
Schliesslich wären dann immer 2048 KiB aktiv und nicht nur die jeweiligen L2 der aktiven Kerne.
Und würde ein shared L2 nicht für eine komplett inklusive Cache-Hierarchie sprechen?

Der größere L2 dürfte laum mehr Leistung ziehen. Ggf. deaktiviert AMD ja bei IDLE noch Teile davon (gabs da nicht ein altes Intel-Patent beim Centrino ? )

Die anderen genannten Optimierungen klingen auch sinnig.

Was etwas wundert ist deutlich mehr SSE/AVX Power die dann 4-fach und meist inaktiv Strom zieht. Vielleicht wird da die Fließkomma auf 4 Cores shared verteilt ?

Oder AMD übernimmt die Modulbauweise des Bulldozer und baut 2-Core Integer-Module mit jeweils shared 2MB L2 und je 1* SSE/AVX ?!

Auf jeden Fall muß das Design kompakt bleiben damit der Energieverbrauchsvorteil sich steigert und nicht stagniert.

 

[pipip]

Was ich mich frage, es gibt ja auch abgespecktere Versionen mit 2 Cores. Somit hätten die dann ja auch automatisch 2mb l2 cache oder ? Oder könnte man das so easy auf 1 MB reduzieren ?

Vielleicht wird da die Fließkomma auf 4 Cores shared verteilt

Ein Modul mit 4 cores ?

Wenn die FPU Performance eines 17 watt tdp Trinity 1Modul die des Zacate übertreffen würde, wäre es dann kein Nachteil oder ?

 

[tex_]

Im Diff steht übrigens noch folgendes:

+ {"btver2", PROCESSOR_BTVER2, CPU_GENERIC64,
+ PTA_64BIT | PTA_MMX | PTA_SSE | PTA_SSE2 | PTA_SSE3
+ | PTA_SSSE3 | PTA_SSE4A |PTA_ABM | PTA_CX16 | PTA_SSE4_1
+ | PTA_SSE4_2 | PTA_AES | PTA_PCLMUL | PTA_AVX
+ | PTA_BMI | PTA_F16C | PTA_MOVBE},

Damit wäre dann auch die Sache mit der SSE4 Unterstützung geklärt.
Interessant bleibt aber noch ob man die Vektoreinheit auf 64bit belässt oder nun auf 128bit geht.

Das mit dem shared-cache halte ich auch für recht wahrscheinlich. Vielleicht kann man diesen ja dann auch auf oder nahe des CPU-Taktes bekommen.

 

[ONH]

Ist doch bis jetzt nur ein platzhalter und es sollen ja noch weitere patchs folgen, welche mehr modifizieren sollen, denke mal da kommt noch das eine oder andere.

 

[gruffi]

5W gibts nur mit 2 Kernen, die Quads haben mind. 17W, stand mal im letzten Cat. Treiber:


Eventuell schalten sie da dann auch etwas vom L2 ab, dann hättest Du quasi recht ^^

Ja, womöglich gibt's 2 Kerne dann nur mit 1024 KiB L2. Dann wären eigentlich auch 2 separate Designs sinnvoll, ein Quad- und ein Dual-Core Design.

Was ich mich allerdings auch noch frage, ob AVX bei Jaguar überhaupt was bringt? Die FPU ist doch schon zu schwach, um packed SSE Instruktionen in einem Rutsch zu verarbeiten. Mit AVX wird das doppelt problematisch. Selbst wenn man die FPU auf 128-bit aufbohrt, hat man immer noch keinen Vorteil durch AVX.

 

[Opteron]

Was ich mich allerdings auch noch frage, ob AVX bei Jaguar überhaupt was bringt? Die FPU ist doch schon zu schwach, um packed SSE Instruktionen in einem Rutsch zu verarbeiten. Mit AVX wird das doppelt problematisch. Selbst wenn man die FPU auf 128-bit aufbohrt, hat man immer noch keinen Vorteil durch AVX.

Naja, kommt halt auf die FPU drauf an. Ansonsten hat man halt noch den 3op-Vorteil. Der bringt bei Bulldozer nichts, da BD sowieso schon Werte look-ahead einlesen kann, aber wenn das Bobcat nicht kann, hätte man da nen klitzekleinen Vorteil.

@tex_:
Ah Danke, das hatte ich ganz übersehen

 

[Opteron]

Im Diff steht übrigens noch folgendes:

+ {"btver2", PROCESSOR_BTVER2, CPU_GENERIC64,
+ PTA_64BIT | PTA_MMX | PTA_SSE | PTA_SSE2 | PTA_SSE3
+ | PTA_SSSE3 | PTA_SSE4A |PTA_ABM | PTA_CX16 | PTA_SSE4_1
+ | PTA_SSE4_2 | PTA_AES | PTA_PCLMUL | PTA_AVX
+ | PTA_BMI | PTA_F16C | PTA_MOVBE},

Weils mir gerade erst aufgefallen ist, MOVBE ist ein spezieller Befehl, den es bisher nur beim Atom gab ... richtig drollig, extra Befehle für den Kleinen
Diskussion hier: http://board.flatassembler.net/topic.php?t=10374

 

[OBrian]

Ja, womöglich gibt's 2 Kerne dann nur mit 1024 KiB L2. Dann wären eigentlich auch 2 separate Designs sinnvoll, ein Quad- und ein Dual-Core Design.

Kaum, denn man spart wenig Diefläche damit ein. Immerhin reden wir nicht von einer reinen CPU, wo 4 Kerne mit Cache schon den Großteil der Fläche ausmachen, sondern es ist ein SoC mit flächenfressender GPU. Bei Trinity würde ja ein weiteres Modul auch nicht die Fläche verdoppeln. Nein, das wird derselbe Die bleiben, ob es nun eine 2- oder 4-Kern-Variante ist.

Was ich mich allerdings auch noch frage, ob AVX bei Jaguar überhaupt was bringt? Die FPU ist doch schon zu schwach, um packed SSE Instruktionen in einem Rutsch zu verarbeiten. Mit AVX wird das doppelt problematisch. Selbst wenn man die FPU auf 128-bit aufbohrt, hat man immer noch keinen Vorteil durch AVX.

AVX bringt ne Menge, und auch oder gerade auf niedrigem Niveau ist das wichtig. Doppelt so viel von ganz wenig ist immer noch wenig, aber evtl. schon ausreichend. Und es geht wohl auch einfach um Kompatibilität und eine möglichst breite Hardwarebasis.

 

[gruffi]

Kaum, denn man spart wenig Diefläche damit ein. Immerhin reden wir nicht von einer reinen CPU, wo 4 Kerne mit Cache schon den Großteil der Fläche ausmachen, sondern es ist ein SoC mit flächenfressender GPU.

4 Kerne + 2048 KiB würde beim aktuellen Bobcat Design etwa die Hälfte der Fläche ausmachen. Zudem könnte man beim Dual-Core Jaguar Design auch weniger GPU Shader verbauen, zB nur die Hälfte. Grob geschätzt könnte man so sicherlich 1/3 der Fläche einsparen. Je nach dem wie viele Prozessoren man absetzen kann, könnten sich 2 Designs durchaus lohnen.

AVX bringt ne Menge

Naja, wir sehen ja bei Bulldozer, dass es so gut wie nichts bringt. Nur FMA kann im Moment noch ordentlich Performance rauskitzeln. Bulldozer wird erst dann richtig von AVX profitieren, wenn man die FMACs auf 256-bit aufbohrt.

und auch oder gerade auf niedrigem Niveau ist das wichtig. Doppelt so viel von ganz wenig ist immer noch wenig, aber evtl. schon ausreichend.

Eine doppelt so breite ISA nützt dir aber absolut gar nichts, wenn die Hardwareeinheiten dafür zu schwachbrüstig sind. Das gleiche Thema hatten wir doch schon beim K8 und dessen 64-bit FPU. Die 128-bit SSE Pipeline hat dem überhaupt nichts gebracht. Das 64-bittige 3DNow! war im Endeffekt genauso schnell, sofern denn die Software mal Support dafür bot. Erst der K10 konnte aufgrund seiner 128-bit FPU auch von der Breite der SSE Pipeline profitieren.

Oder anderes gesagt, es ist völlig wurscht, ob du 64-bit an Daten in einem Takt durch eine 64-bit Hardwarepipeline schleust oder 128-bit an Daten in zwei Takten oder 256-bit an Daten in vier Takten. Unterm Strich brauchst du für 256-bit an Daten in jedem Fall 4 Takte. Und das ist ja nicht der Sinn von AVX. Der Sinn ist, 256-bit an Daten in einem Takt zu verarbeiten. 256-bit an Daten in 2 oder 4 Takten schafft man auch mit SSE.

Wie gesagt, der einzige Vorteil für Bulldozer ist im Moment FMA. Nur ob Jaguar FMACs bekommt, erscheint mir eher unwahrscheinlich.

 

[Dr@]

Eine Verkleinerung der GPU kann ich mir beim besten Willen nicht vorstellen, denn bisher war die aktuelle GPU des Ontario-Dies zumeist schon zu schwach um für GPGPU-Anwendungen relevant zu werden. Dies ist doch aber der elementare Baustein, der die Hochzeit von CPU und GPU erst zu einer APU werden lässt.

Die richtige Balance zwischen CPU- und GPU-Leistung ist wichtig, wenn es ums GPGPU-Computing geht.

 

[gruffi]

Wer mehr GPU Performance braucht, kann doch zum "grossen" Jaguar Design greifen. Das wird es schliesslich auch als abgespeckte Version mit 2 Kernen und niedrigerer TDP geben. Also ich sehe da kein Problem.

Mal abgesehen davon ist doch die Balance zwischen 4 Kernen + x Shadern grob erstmal die gleiche wie bei 2 Kernen + x/2 Shadern.

 

[isigrim]

Bei der TDP sollte man noch bedenken, dass das höchstwahrscheinlich ein SoC inklusive Southbridge wird, das war ja schon bei Krishna und Wichita geplant.
Damit sind die 5 Watt für den Dualcore dann schon nett. Noch netter wäre es wenn da auch noch Stacked RAM dabei wäre, aber das ist vielleicht zu viel des guten.
Mit 25 Watt geht man dann aber auch nach oben deutlich weiter in den Mainstream-Bereich.

 

[tex_]

Wer mehr GPU Performance braucht, kann doch zum "grossen" Jaguar Design greifen. Das wird es schliesslich auch als abgespeckte Version mit 2 Kernen und niedrigerer TDP geben. Also ich sehe da kein Problem..

Meintest du jetzt Trinity/Kaveri oder was meintest du mit großem Jaguar Design?

Zu AVX in Bobcat. Der eigentliche Vorteil sind ja nun die neuen SSE4 Instruktionen. Da man dadurch im Prinzip alle Anforderungen für AVX erfüllt hat wird man es denke ich einfach mitnehmen, damit Softwareentwickler ggf. ihren AVX optimierten Code hier gleich mitverwenden können, bevor man nur irgendeinen generic code abbekommt.

 

[gruffi]

Meintest du jetzt Trinity/Kaveri oder was meintest du mit großem Jaguar Design?

Nee, Trinity / Kaveri ist Bulldozer. Wir sprachen von Jaguar, also den Kernen im nächsten Bobcat. Mit dem "grossen" Jaguar Design war das Design mit 4 Jaguar Kernen gemeint. Das was bisher als Kabini bekannt ist. Die Spekulation war eben, dass eventuell auch ein separates "kleines" Design mit lediglich 2 Jaguar Kernen Sinn macht. So in etwa wie das mit Propus und Regor der Fall war, nur halt noch mit iGPU. Ob Temash das ist oder doch nur ein teildeaktivierter Kabini, bleibt abzuwarten.

Zu AVX in Bobcat. Der eigentliche Vorteil sind ja nun die neuen SSE4 Instruktionen. Da man dadurch im Prinzip alle Anforderungen für AVX erfüllt hat wird man es denke ich einfach mitnehmen, damit Softwareentwickler ggf. ihren AVX optimierten Code hier gleich mitverwenden können, bevor man nur irgendeinen generic code abbekommt.

Naja, die SSE4 Funktionalität ist aber schon recht spezifisch. Viel hat das bei den "grossen" Architekturen jedenfalls nicht gebracht. Ob sich der Aufwand dafür lohnt, ist eher fraglich. AVX lohnt sich eigentlich nur richtig, wenn man den 256-bittigen Durchsatz auch ausspielen kann. Aber wer weiss, vielleicht hat man die FPU in Jaguar ja ordentlich gepimpt. Ich könnte mir zB eine recht flexibel arbeitende FPU vorstellen, die je nach Anforderung Bereiche schlafen legt, um Strom zu sparen.

 

[tex_]

Ok das hatte ich dann etwas falsch verstanden.^^
Wer wirklich mehr GPU Leistung braucht könnte eben zum Beispiel auch zum 17Watt Trinity greifen.

Das man jedem Core eine 256Bit FPU gönnt halte ich aber weiter für recht unwahrscheinlich, das wäre dann ja schon fast auf dem Niveau eins ganzen Bulldozer Moduls. Gegebenfalls müsste diese Einheit wirklich zwischen mehreren Kernen geteilt werden.
Gerade sehr breite FPUs halte ich aber irgendwie für das APU Konzept zukünftig etwas deplaziert wenn man neben dran sowieso ein paar 512bit GPU SIMD Einheiten hat.

Die kommende Hotchips wird in der Hinsicht auf alle Fälle recht interessant werden.

 

[gruffi]

Das man jedem Core eine 256Bit FPU gönnt halte ich aber weiter für recht unwahrscheinlich

Müsste man vielleicht auch nicht mal. Bulldozers Flex FPU zeigt ja, dass man 256-bit auch mit zwei 128-bit Einheiten realisieren kann. Zwei FP Pipes hat Bobcat im Moment. Wenn man diese auf 128-bit aufbohrt und dafür sorgt, dass an jeder Pipe ADD oder MUL verarbeitet werden kann, käme man auf den AVX Durchsatz. Ok, hört sich ein bisschen wie Bulldozer ohne FMA an. Aber wer weiss ...

Im Moment denke ich, dass es bei der 64-bit FPU in Bobcat bleibt und man keine Performance durch AVX gewinnt. Mal abgesehen von den Instruktionen, die bisher nicht vorhandene Funktionalität mitbringen. Wird wohl wirklich nur auf ISA Kompatibilität hinauslaufen. Nach dem Motto, friss AVX oder stirb mit Legacy Code. Wenn's ganz dumm kommt halt mit x87.

 

[Opteron]

Nee, Trinity / Kaveri ist Bulldozer. Wir sprachen von Jaguar, also den Kernen im nächsten Bobcat. Mit dem "grossen" Jaguar Design war das Design mit 4 Jaguar Kernen gemeint. Das was bisher als Kabini bekannt ist. Die Spekulation war eben, dass eventuell auch ein separates "kleines" Design mit lediglich 2 Jaguar Kernen Sinn macht. So in etwa wie das mit Propus und Regor der Fall war, nur halt noch mit iGPU. Ob Temash das ist oder doch nur ein teildeaktivierter Kabini, bleibt abzuwarten.

Ein weiterer Vorteil wäre, dass man da dann noch extra am Prozess drehen könnte, um weiter auf für super-low-power optimieren zu können. Z.B. für nen dual-core Temash den fd-soi Prozess einsetzen.

Blöderweise steht bei Tamesh aber auch "up to 4 cores" in der Roadmap, so dass es wohl doch nur das gleiche Die sein wird. Vielleicht aber auch nur ein Druckfehler, wer weiss ... 3,6W - 5W TDP klingen mit 4 cores ja schon krass Selbst wenn man davon ausgeht, dass die 3,6W für nen dual gelten, und die 5W für den Quad.

Edit: Bemerke gerade: Das Teil heißt Tamesh nicht Temash ^^
Edit2: Lol, auf der letzten AFDS Roadmap steht Temash, in den alten Tamesh, da hats AMD mal wieder verbockt ^^