Bulldozer 2.0 / BDver2: Sepang, Terramar, Komodo, Trinity, Vishera

Was ist das für ein Die auf Seite 7? Kennt das jemand? Oder ist das lediglich ein Testchip mit Testlogik?
 
Was ist das für ein Die auf Seite 7? Kennt das jemand? Oder ist das lediglich ein Testchip mit Testlogik?
Auf den anderen Seiten nehmen sie andauernd nen Cortex A9 als Beispiel, vielleicht also ein ARM.
Aber nur reine Vermutung, keine Ahnung ^^
 
3DCenter hat eine ganz interessante Theorie bezüglich der aufgetauchte Roadmap mit 28nm-Fertigungsschritt.
Auszug aus News-Meldung vom 05.08.11:

Sofern dies kein Schreibfehler ist und hiermit die eigentlich mal geplante 22nm-Fertigung gemeint ist, würde dies ein hochinteressanter Schritt seitens AMD sein: Denn das Problem von GlobalFoundries bezüglich der eigentlich langfristig geplanten Fertigung von AMD-Grafikchips ist, daß der bisherige Fertigungspartner und GlobalFoundries-Konkurrent TSMC derzeit auf einer anderen Strategie bezüglich der Fertigungstechnologie als GlobalFoundries ist. GlobalFoundries will eigentlich von 45nm auf 32nm auf 22nm gehen, während TSMC von 40nm auf 28nm auf 20nm geht. Wenn GlobalFoundries nun auch noch AMD-Grafikchips fertigen wollte und nicht gerade mit seinen Fertigungsschritten sogar früher als TSMC spruchreif wird (arg unwahrscheinlich), müsste GlobalFoundries nur für die Grafikchip-Fertigung alle diese Fertigungsschritte auflegen, also 32nm, 28nm, 22nm, 20nm, 16nm und 14nm.

Dieses Mitgehen jedes Halfnodes macht nicht einmal Intel, obwohl die über deutlich mehr Kapazitäten und Werke verfügen, ergo ist dies keine wirklich gangbare Option. Es bleibt für GlobalFoundries somit nur die Lösung, komplett auf dieselbe Fertigungsstrategie wie TSMC zu setzen, um mit TSMC um Grafikchip-Aufträge konkurrieren zu können. Sofern die Aussagen der Roadmap stimmen, bedeutet dies also nichts anderes, als daß AMD nach der 65nm-, 45nm- und 32nm-Fertigung nicht mit der 22nm- und der 16nm-Fertigung weitermachen wird, sondern dagegen mit der 28nm-, 20nm- und 14nm-Fertigung. Dies hat dann natürlich auch erhebliche Auswirkungen auf den CPU-Bereich, denn damit wird man generell nicht mehr dieselben Fertigungsgrößen wie Intel anbieten. Allerdings ergibt dies den interessanten Seiteneffekt, daß AMD unter Umständen bezüglich der Fertigungstechnologie nur noch einen Halfnode (Schritt zwischen zwei verwandten Fertigungsverfahren wie zwischen 32nm und 28nm) zu Intel zurückliegt – und nicht wie bisher einen ganzen Fullnode (Schritt zwischen zwei generell unterschiedlichen Fertigungsverfahren wie zwischen 45nm und 32nm).

Ich habe den Auszug mal so direkt eingestellt. Eine sinngemäße Wiedergabe benötigt gleich viel Platz ;-)
Das macht mMn schon Sinn.
 
So gesehen macht das sinn vor allem da AMD APU Roadmap, nur die 20nm/14nm Nodes vorsieht. Und die verbleibenden CPUs wohl damit mitziehen, da sich für deren Produktion nicht lohnt die x86 Kerne auf die anderen Halfnodes anzupassen (mobile zu ~100% APUs und Desktop zu über 60% APUs), was dann aber definitiv eine Abkehr von SOI wäre, da dieses ja 22nm und 16nm wäre.
 
Das macht mMn schon Sinn.
Das macht mMn überhaupt keinen Sinn, denn wie im PDF steht, dass ich auf der letzten Seite gepostet hat, ist 28nm fertig bei GF, während 3DC schreibt:
GlobalFoundries will eigentlich von 45nm auf 32nm auf 22nm gehen, während TSMC von 40nm auf 28nm auf 20nm geht. Wenn GlobalFoundries nun auch noch AMD-Grafikchips fertigen wollte und nicht gerade mit seinen Fertigungsschritten sogar früher als TSMC spruchreif wird (arg unwahrscheinlich), müsste GlobalFoundries nur für die Grafikchip-Fertigung alle diese Fertigungsschritte auflegen, also 32nm, 28nm, 22nm, 20nm, 16nm und 14nm.
Bitte verbesser mich, wenn ichs falsch verstehe, aber das hört sich für mich so an, als ob 3DC meint, dass GF im Moment keine Ahnung von 28nm hätte ...

Sinn machts auf alle Fälle dahingehend, da man mit der APU Strategie sowieso CPU&GPU Design synchronisieren sollte. Jeweils die GPU auf den voll node und die CPU auf nen half-node schritt zu designen stell ich mir nicht billig vor.
 
Also ich sehe auch recht wenig Sinn darin, was 3DCenter da hinein interpretiert. Zumal Intel nach 22 nm auch auf Half-Node geht, also 14 statt 16 nm.
 
Sinn machts auf alle Fälle dahingehend, da man mit der APU Strategie sowieso CPU&GPU Design synchronisieren sollte. Jeweils die GPU auf den voll node und die CPU auf nen half-node schritt zu designen stell ich mir nicht billig vor.

Sorry, da hätte ich den letzten Satz abtrennen sollen. Auf den bezog sich das "macht mMn Sinn". Sehen wir das also ähnlich.

@gruffi
Was Intel treibt, habe ich nicht so im Fokus.... wenn wir von Deiner Info ausgehen, ist in der Meldung also recht viel Spekulatius
 
Um nochmals auf die Trinity "Roadmap" zurückzukommen, welche y33H@ vor einer Seite gepostet hat:

http://www.planet3dnow.de/vbulletin/showthread.php?t=387886&page=5
direktlink:http://www.donanimhaber.com/islemci...MDnin-2012-model-mobil-Fusion-islemcileri.htm

War/Ist Weatherford und Richland als Bezeichnung für einen kastrierten Trinity schon bekannt und/oder irgendwo bestätigt? Wenn ja wärs doch ne gute Sache, die "Roadmap" ins Startposting einzubinden, mit den Infos zu Trinity/Richland/Weatherford....

wobei Richland und insbesondere Weatherford für mich nicht neu sind, ich meine diese Codenamen schon mal in DB Blog gesehen zu haben, kann mich aber auch irren... ich such mal ;D

EDIT:
http://www.donanimhaber.com/islemci...yeni-nesil-Fusion-platformlari-detaylandi.htm

offenbar hat Donanimhaber schon am May31 eine unbestätigt AMD Roanmap "geleaked", wobei diese im selben Stil angefertigt ist wie diverse ander unbestätigte AMD roadmaps. Entweder ein konsequenter Fälscher oder doch wirklich von AMD?
Jedenfalls tauchen dort die beiden APU Codenamen Weatherford und Richland das erste mal auf, allerdings nicht in konkretem Zusammenhang von TDP und Kern/Shader - Anzahl.

Da jedoch wirklich alle Infos von Donanimhaber kommen bin ich mir nicht sicher, ob man ihnen(den Infos) trauen kann. Die Herren Türken waren zwar in der Vergangenheit recht genau wenn es um AMD roadmaps geht, doch die Geschichte mit disem tschechischen "Blogger"/Witzbold gibt doch zu denken.

EDIT2:
jaja meine Augen sind mit blindheit geschlagen :D. Es gab sogar mal ne News auf eierne mir relativ bekannten Seite dazu:
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1312547238
Asche auf mein Haupt...

Bin jedoch trozdem noch dafür, richland/Weatherford in den Startpost aufzunehmen

mfg memory_stick
 
Zuletzt bearbeitet:
Das macht mMn überhaupt keinen Sinn, denn wie im PDF steht, dass ich auf der letzten Seite gepostet hat, ist 28nm fertig bei GF, während 3DC schreibt:
Bitte verbesser mich, wenn ichs falsch verstehe, aber das hört sich für mich so an, als ob 3DC meint, dass GF im Moment keine Ahnung von 28nm hätte ...

Sinn machts auf alle Fälle dahingehend, da man mit der APU Strategie sowieso CPU&GPU Design synchronisieren sollte. Jeweils die GPU auf den voll node und die CPU auf nen half-node schritt zu designen stell ich mir nicht billig vor.
Dass GlobalFoundries 28nm anbietet ergibt durchaus Sinn.

Die Halbleiterfab will ja nicht nur AMD bedienen, sondern die ganze Branche! Und da ergeben auch ausgebaute Half-Nodes Sinn. Die 32nm scheinen sozusagen AMD-Exclusive zu sein - was sich in der Zukunft aber ändern könnte, wenn aktuelle Chipentwickler von derzeitigen 65nm und 45nm auf kleinere Strukturgrößen wechseln. Da könnte dann die erprobte/eingefahrene Technik mit 32nm SOI eine Alternative sein.

Die 28nm scheinen so etwas wie High-End Standard zu sein, der auch von TSMC und ULI angeboten werden wird. Hier "muss" sogar GlobalFoundries präsent sein - damit sie eine Alternative zu TSMC und UMC bleiben.

Und wenn Samsung nun schon erste Testreihen mit 20nm fährt - dann muss sich Glofos Fabs in Dresden/New York auch dranhängen. Wie weit SOI-Technik genutzt wird, kann ich nicht sagen. SoiTec hat jedenfalls die Weichen dafür gestellt. Hatte ich auch in dem alten Fertigigungstechnikthread "Fertigungstechnologie; Doch nicht das Ende der Si Basistechnologie?" auch explizit als neue Einträge "2011: Trigates/finFETs fdSOi 22nm 20nm 14nm 7nm" + "fdSOI bei 22/20nm und fuer 450 mm Wafer" ergänzt!

MFG Bobo(2011)
 
Na denn hab ich mich erstmals auch an den Startpost rangemacht - 32nm SOI und "bis 50% mehr FLOPs" ;)
 
Ich weiß, dass ist jetzt rechthaberisch, aber VLIV4 war schon seit AFDS sicher. Trinity wurde gemunkelt basiert auf NI, bzw. auf der 6900er Serie.


Hier eine Quelle dazu: http://pcper.com/news/Graphics-Cards/AFDS11-Upcoming-Trinity-APU-will-use-VLIW4-Cayman-Architecture



It was offered that Trinity in fact used a VLIW4 architecture rather than the VLIW5 design found in the just released Llano A-series APU.

That means that Trinity APUs will ship with Cayman-based GPU technology (6900 series) rather than the Evergreen (5000 series). While that doesn't tell us much in terms of performance simply because we have so many variables including shader counts and clocks, it does put to rest the rumor that Trinity was going to keep basically the same class of GPU technology that Llano had.
 
Zuletzt bearbeitet:
Ja, dennoch fehlte es auf Seite 1. ;)

Das Bild aus der Quelle hab ich mal auch mit eingefügt unter Juni 2011. Danke für die Erinnerung samt Quelle deadohiosky. :)
 
Zuletzt bearbeitet:
mal ne grundsatzfrage: Spekus über Trinity hier rein oder in den neuen Thread von unserem Bayrischen Optimisten: http://www.planet3dnow.de/vbulletin/showthread.php?t=397974?

Overall Infos zu Trinity/Nachfolger finde ich hier im Startpost sinnvoll, aber Diskusionen eher nicht. Denn wenn es wieder so ausartet wie mit Llano/Fusion-thread, ist der Thread von BR sicherlich besser geeignet.

mfg memory_stick
 
mal ne grundsatzfrage: Spekus über Trinity hier rein oder in den neuen Thread von unserem Bayrischen Optimisten: http://www.planet3dnow.de/vbulletin/showthread.php?t=397974?

Overall Infos zu Trinity/Nachfolger finde ich hier im Startpost sinnvoll, aber Diskusionen eher nicht. Denn wenn es wieder so ausartet wie mit Llano/Fusion-thread, ist der Thread von BR sicherlich besser geeignet.

mfg memory_stick
Hab ich mich auch gerade gefragt ^^

Deine Idee ist gut, dort der Spam und die Info hier *g*

Machen wir so - es muss sich halt nur immer jemand finden, der das hier auch aktualisiert ;-)

Und wenns nur ein Link auf ein Posting dort im Thread wird, eine Art Inhaltsverzeichnis hilft schon viel :)

Mir fällt oft was ein, was ich im BD Thread nachschlagen will, die Sucherei danach ist vielleicht ein Spaß ... :(
 
Ich habe mal die Thread-Überschrift um "Trinity" ergänzt...
Gut :)

Hmm, hatten wir das hier schon mal:
BDVER2 has optimized REP instruction for medium sized blocks, but for
+ very small blocks it is better to use loop. For large blocks, libcall
+ can do nontemporary accesses and beat inline considerably. */
http://old.nabble.com/AMD-bdver2-enablement.-td32040151.html
hier noch in bunt:
http://patchwork.ozlabs.org/patch/104268/

Da gibts auch die komplette BDVer2 "Kostentabelle", könnte man mal gut mit BDver1 vergleichen. Hab gerade aber keine Zeit.

Kostentabelle BDVer2:
+struct processor_costs bdver2_cost = {
+ COSTS_N_INSNS (1), /* cost of an add instruction */
+ COSTS_N_INSNS (1), /* cost of a lea instruction */
+ COSTS_N_INSNS (1), /* variable shift costs */
+ COSTS_N_INSNS (1), /* constant shift costs */
+ {COSTS_N_INSNS (4), /* cost of starting multiply for QI */
+ COSTS_N_INSNS (4), /* HI */
+ COSTS_N_INSNS (4), /* SI */
+ COSTS_N_INSNS (6), /* DI */
+ COSTS_N_INSNS (6)}, /* other */
+ 0, /* cost of multiply per each bit set */
+ {COSTS_N_INSNS (19), /* cost of a divide/mod for QI */
+ COSTS_N_INSNS (35), /* HI */
+ COSTS_N_INSNS (51), /* SI */
+ COSTS_N_INSNS (83), /* DI */
+ COSTS_N_INSNS (83)}, /* other */
+ COSTS_N_INSNS (1), /* cost of movsx */
+ COSTS_N_INSNS (1), /* cost of movzx */
+ 8, /* "large" insn */
+ 9, /* MOVE_RATIO */
+ 4, /* cost for loading QImode using movzbl */
+ {5, 5, 4}, /* cost of loading integer registers
+ in QImode, HImode and SImode.
+ Relative to reg-reg move (2). */
+ {4, 4, 4}, /* cost of storing integer registers */
+ 2, /* cost of reg,reg fld/fst */
+ {5, 5, 12}, /* cost of loading fp registers
+ in SFmode, DFmode and XFmode */
+ {4, 4, 8}, /* cost of storing fp registers
+ in SFmode, DFmode and XFmode */
+ 2, /* cost of moving MMX register */
+ {4, 4}, /* cost of loading MMX registers
+ in SImode and DImode */
+ {4, 4}, /* cost of storing MMX registers
+ in SImode and DImode */
+ 2, /* cost of moving SSE register */
+ {4, 4, 4}, /* cost of loading SSE registers
+ in SImode, DImode and TImode */
+ {4, 4, 4}, /* cost of storing SSE registers
+ in SImode, DImode and TImode */
+ 2, /* MMX or SSE register to integer */
+ /* On K8:
+ MOVD reg64, xmmreg Double FSTORE 4
+ MOVD reg32, xmmreg Double FSTORE 4
+ On AMDFAM10:
+ MOVD reg64, xmmreg Double FADD 3
+ 1/1 1/1
+ MOVD reg32, xmmreg Double FADD 3
+ 1/1 1/1 */
+ 16, /* size of l1 cache. */
+ 2048, /* size of l2 cache. */
+ 64, /* size of prefetch block */
+ /* New AMD processors never drop prefetches; if they cannot be performed
+ immediately, they are queued. We set number of simultaneous prefetches
+ to a large constant to reflect this (it probably is not a good idea not
+ to limit number of prefetches at all, as their execution also takes some
+ time). */
+ 100, /* number of parallel prefetches */
+ 2, /* Branch cost */
+ COSTS_N_INSNS (6), /* cost of FADD and FSUB insns. */
+ COSTS_N_INSNS (6), /* cost of FMUL instruction. */
+ COSTS_N_INSNS (42), /* cost of FDIV instruction. */
+ COSTS_N_INSNS (2), /* cost of FABS instruction. */
+ COSTS_N_INSNS (2), /* cost of FCHS instruction. */
+ COSTS_N_INSNS (52), /* cost of FSQRT instruction. */
+
+ /* BDVER2 has optimized REP instruction for medium sized blocks, but for
+ very small blocks it is better to use loop. For large blocks, libcall
+ can do nontemporary accesses and beat inline considerably. */
+ {{libcall, {{6, loop}, {14, unrolled_loop}, {-1, rep_prefix_4_byte}}},
+ {libcall, {{16, loop}, {8192, rep_prefix_8_byte}, {-1, libcall}}}},
+ {{libcall, {{8, loop}, {24, unrolled_loop},
+ {2048, rep_prefix_4_byte}, {-1, libcall}}},
+ {libcall, {{48, unrolled_loop}, {8192, rep_prefix_8_byte}, {-1, libcall}}}},
+ 6, /* scalar_stmt_cost. */
+ 4, /* scalar load_cost. */
+ 4, /* scalar_store_cost. */
+ 6, /* vec_stmt_cost. */
+ 0, /* vec_to_scalar_cost. */
+ 2, /* scalar_to_vec_cost. */
+ 4, /* vec_align_load_cost. */
+ 4, /* vec_unalign_load_cost. */
+ 4, /* vec_store_cost. */
+ 2, /* cond_taken_branch_cost. */
+ 1, /* cond_not_taken_branch_cost. */


+};
+</pre>
 
Zumindest das VLIW4-Design für Trinity scheint ja nun mehr oder minder sicher zu sein.
Soweit würde ich nicht gehen. Auf der Folie steht ja lediglich HD 7000. Und da scheint laut letzten Infos GCN im Fokus zu stehen. Mehr oder weniger sicher sein kann man, dass es kein VLIW5 mehr ist, so wie bei Llano. Ob VLIW4 oder doch schon GCN wird man sehen müssen. Wobei ich VLIW4 momentan auch für die wahrscheinlichere Variante halte.
 
Soweit würde ich nicht gehen. Auf der Folie steht ja lediglich HD 7000. Und da scheint laut letzten Infos GCN im Fokus zu stehen. Mehr oder weniger sicher sein kann man, dass es kein VLIW5 mehr ist, so wie bei Llano. Ob VLIW4 oder doch schon GCN wird man sehen müssen. Wobei ich VLIW4 momentan auch für die wahrscheinlichere Variante halte.
Das passt schon der AMD Grafik Produktmanager hat VLiw4 schon bestätigt, Gipsel hatte das mal verlinkt, Zitat:
Zitat von Dave Baumann
<table width="100%" border="0" cellpadding="5" cellspacing="0"><tbody><tr><td class="alt2 QuoteBorder">
Zitat von LordEC911
I was talking about the supposed Freudian slip from Mr. Houston...
Zitat:

<table width="100%" border="0" cellpadding="5" cellspacing="0"><tbody><tr><td class="alt2 QuoteBorder">
Zitat von PCPer
7:55 Trinity has a "6850" kind of thing....interesting....
7:55 I think that slipped!
7:56 But then he stated Trinity would be "VLIW4" so Cayman-based... interesting.
</td></tr></tbody></table> </td></tr></tbody></table>That was a confusion. He thought that the 6800 was based on VLIW4. He meant to say that the architecture is based on the 6900 series.
Dass das ne HD7xxx Nummer bekommt paßt auch, die Llano Grafik ist ja auch HD6xxx, obwohls noch VLIW5 ist, genauso wie die 68x0er ;-) Sogar für die AMD Leute verwirrend, wie man an obigen Zitat sieht, aber ist halt so ^^

Edit:
Noch zu obigen Compilerzitat:
Nichts Neues, nur ne 1:1 Kopie von bdver1. Das Zitat zu den REP instructions gibts schon seit K10 *g*
 
Zuletzt bearbeitet:
Ihr tut gerade so als ob das was irgendwelche Schliepsies von sich geben technisch relevant wäre.


Ist es nicht. Die Schliepsies haben schon einiges verpeilt, zum Beispiel Llano dem K10 zugeordnet.
 
Ihr tut gerade so als ob das was irgendwelche Schliepsies von sich geben technisch relevant wäre.


Ist es nicht. Die Schliepsies haben schon einiges verpeilt, zum Beispiel Llano dem K10 zugeordnet.

Lol, da hast Du recht.

Das Problem ist halt, dass nur die Schliepsies reden ^^

Abgesehen von diversen Hot Chips und ISSCC Sachen, aber bis dort endlich mal die tech. Details genannt werden und alles Hand und Fuß hat, gabs die erste Schlips-Äußerung dazu schon 2-3 Jahre vorher *chatt*
 
Wow was ist das denn, dickes Herumreißen des Runder bei AMD?

Hat der neue CEO schon angefangen zu entscheiden?

Angeblich hat 4Gamers in Japan neue Roadmaps bekommen. Demnach wird Komodo doch ein AM3+ Chip:
0028bwo.jpg

http://www.microsofttranslator.com/...www.4gamer.net/games/135/G013527/20110901092/

Grund - was ich so im Bingpanisch zu verstehen glaube - ist Unzufriedenheit mit PCIe 3.0 und dann auch schon DDR4, da wollen sie wohl auf Nummer sicher gehen, und gleich nen PCIe3 + DDR4 Plattformschritt machen.

Außerdem wird Komodo als 150W Teil beschrieben, mit oder ohne PCIe ist mir nicht so klar, aber die 140W kompatiblen Phenom2 Am3+ Mainboards können das wohl besser wegstecken als die 95W Llano "Spielzeuge".

Hört sich aber langsam wirklich wie Preshott an *g*

Und zum Schluß nochmal der Hinweis:
Alles ohne Gewähr, Quelle + fragwürdige Bing Übersetzung + etwas Spekulation, da kann viel schief gehen (siehe auch Fehlerliste).

Vor allem frage ich mich gerade, was dann aus den Opterons wird. Glaube kaum, dass es von den Stückzahlen da noch Sinn macht extra PCIe zu integrieren. Aber vielleicht wirds beim AM3+ Komodo dann ja einfach deaktiviert. Wäre das Naheliegenste. Zwar irgendwie schade, aber Hauptsache kompatibel.
Außerdem könnten sie wenigstens die Hudson SB dann für AM3+ freigeben, sollte kein Problem sein.

Aja das FM2 Update fällt damit eher mau aus. Ebenfalls nur PCIe2 und noch neuer Support für DDR3-2133 sowie 1,25V DIMMs.

Fehler in der Grafik:
- Schreibfehler "Hadson"
- Schreibfehler "Grafphics"
- Logischer Fehler, die SB950 hat kein USB3.
- wahrscheinlich logischer Fehler: Zambezi kann angeblich nur DDR3-1600, statt 1866.
- wahrscheinlich logischer Fehler: nur 4 statt 5 Module //könnte sich aber natürlich geändert haben.
 
Zuletzt bearbeitet:
Ein Link wär schick.

Obwohl ich die Aussagen irgendwie als nicht soooo plausibel erachte sehe ich da jetzt keine so deutlich negative Entwicklung.

150 Watt TDP für 1Modul/2Kerne mehr bzw. 10 Kerne insgesamt... das liegt ja wohl im Rahmen der Erwartungen, oder? Besonders da wir hier ja von der Desktop-Version ausgehen.

Ich finde auch das Festhalten an AM3+ für mehr als ein Jahr (wobei "Jahr" leider im Auge des Betrachters liegt) durchaus im Sinne des Kunden.


PCIe 3.0 ist im Moment auch nur "nice to have" im Gegensatz zu USB 3.0 meines Erachtens keine Grund sich zu grämen. (Selbst PCIe 2.0 wird bis jetzt kaum ausgelastet, das ist ja schon seit ein paar Ewigkeiten bekannt, CB hat mit ihrem putzigen Test keine neuen Erkenntnisse gebracht, besonders sinnlos sind jedoch die Auflösungen in den getestet wurde ;))


Aber wie gesagt, das alles ist für mich relativ unplausibel, zumal die Entwicklung von Piledriver offensichtlich (Trinity) schon abgeschlossen ist, ich kann mir nicht vorstellen, dass Komodo sich wesentlich von den Kernen in Trinity unterscheidet.
.
EDIT :
.

Auch nur 8, anstatt bis zu 10 Kerne?
 
Hab den Link dazu gebastelt (unter dem Bild).

Trinity hat nix mit Komodo zu tun. Die Piledreiverkerne samt Trinity sind bestimmt schon fertig, aber für das Komodo/Viperfish DIE muss das mal nichts bedeuten. Neuer Chip, neues Glück. Nachdem LLano viel früher eingeplant war, BD aber später, ist es naheliegend, dass Komodo noch nicht in trockenen Tüchern ist/war, v.a. nachdem sich BD so verspätete. Könnte auch ein Grund sein, mit der BD Verspätung kann man sich auch für Komodo etwas länger Zeit lassen.

8/10; Kerne: Habs mal in die Fehlerliste aufgenommen, aber wer weiß - könnte sich auch geändert haben.
 
Zuletzt bearbeitet:
Nja gut, aber das könnte ja indirekt auch für den Servermarkt bedeuten, dass Sepang und Terramar auch weiterhin nur bis zu 8/16 Kerne haben, wenn man davon ausgeht, Desktop und Server auf dem gleichen Die basieren. (Oder die FX-Plattform wird künstlich beschnitten)
 
Zurück
Oben Unten