Trinity: AMD zeigt die kommenden APUs plus den HD Media Accelerator

[ruyven_macaran]

Zambezi ist der aktuelle Bulldozer, du meinst Vishera.

 

[Systemcrash]

Jetzt bin ich verwirrt

Ich meine schon was ich schrieb, nämlich das der Trinity (APU-Piledriver) einen Ausblick darauf geben könnte um wieviel sich der Desktop-Piledriver (Vishera fiel mir da nicht ein) gegenüber dem Zambezi verbessern könnte.

Klar ist er kein endgültiges Maß wg. L3-Cache, aber er könnte zeigen um sich die grausam schlechte IPC merklich bessern könnte

 

[Jan565]

Für mich Baut AMD einfach die besten APU´s. Eine CPU mit genug Power für jedes Spiel und Anwendungen die mal im normalen Alltag nutzt und eine Grafikeinheit die alle Games die es heute gibt Flüssig abspielen kann, zwar auf Low wenn es sein muss, aber es geht! Würde ich mir jetzt einen LAN PC oder HTPC zusammen bauen würde da zu 100% eine APU von AMD drin sein.

In Sachen APU finde ich, hängt Intel denen mächtig hinter her, zwar mehr CPU Leistung, aber brauche ich die wenn ich mir so eine CPU anschaffe? Mit der AMD APU kann ich zocken mit der Intel HD3k nicht wirklich. Aber muss jeder selber für sich wissen.

Jetzt bin ich verwirrt

Ich meine schon was ich schrieb, nämlich das der Trinity (APU-Piledriver) einen Ausblick darauf geben könnte um wieviel sich der Desktop-Piledriver (Vishera fiel mir da nicht ein) gegenüber dem Zambezi verbessern könnte.

Klar ist er kein endgültiges Maß wg. L3-Cache, aber er könnte zeigen um sich die grausam schlechte IPC merklich bessern könnte

Ja das stimmt. Zumindest lässt sich dadurch zumindest einmal etwas erahnen ob die besser geworden sind.

 

[Superwip]

Gibt keinen öffentlichen.

Und einen nicht öffentlichen?

Na ja, egal, bin mittlerweile wieder in Wien und alles, was ich von AMD gefunden habe war eine Broschüre, die auf die Stände diverser Mainboard, Notebook und GraKa Hersteller verwies

 

[Systemcrash]

Wer baut denn sonst noch APUs?

Intel baut CPUs mit integrierter Grafik, konzentrierte sich bisher eher auf die CPU-Leistung, weniger auf die Grafik; das ändert sich wohl erst richtig mit Haswell.

AMD hingegen betont mehr den GPU-Part bei den APUs, letztlich zu verstehen da der CPU-Part hinter 2 Jahre alten Intels rumgurkt.

Da mir jedoch CPU-Part bei CPUs nunmal wichtiger ist als eine Grafik die für meine Begriffe eh zu schwach ist tendiere ich insgesamt zu INtel.

Wobei ich nicht bezweifle das für HTPC-Fans eine AMD-APU die bessere Wahl ist. Allerdings könnte man anführen das auch eine SB mit HD3000 für HD-Wiedergabe reicht

 

[ruyven_macaran]

AMD hat "APU" als Begriff für einen Chip definiert, in dem CPU und GPU fusionieren. Wenn man das zugrundelegt, muss man feststellen, dass AMD bislang nur Chips fertigt, auf denen eine CPU und eine GPU sitzen, die auf ein gemeinsames Speicherinterface/eine gemeinsame Northbridge zurückgreifen. Intel dagegen baut Chips, bei denen CPU und GPU sich z.B. auch den Cache teilen und so eine funktionale Einheit bilden. Rein Definitions-technisch betrachtet gibt es also bislang nur einen "APU"-Hersteller: Intel. Faktisch muss man anmerken, dass "APU" auch ein afaik von AMD Geschützter Begriff für die Vermarktung von (erstmal beliebiger) AMD-Technik ist - und somit ausschließlich AMD "APUs" herstellen kann.
(Genauso, wie ohne Intel-CPU niemand ein "Netbook" oder "Ultrabook" bauen darf, sondern nur mangelhaft ausgestattete bzw. extrem flache Subnotebooks )

Jetzt bin ich verwirrt

Ich meine schon was ich schrieb, nämlich das der Trinity (APU-Piledriver) einen Ausblick darauf geben könnte um wieviel sich der Desktop-Piledriver (Vishera fiel mir da nicht ein) gegenüber dem Zambezi verbessern könnte.

Ah, verstehe. "vielleicht gibt er einen Wink, was der Desktop-Piledriver besser kann, als Zambezi" war gemeint. Macht auch irgendwie mehr Sinn.
Ich habe das ganze als verunstaltete Variante von "vielleicht gibt er einen Wink, was der Desktop-Piledriver (als "Zambezi") besser kann" gelesen

 

[gruffi]

Nicht nur, das man in der Leistung total hinterher rennt, erst werden die BE in K umbenannt, jetzt nimmt man fast den gleichen Namen wie beim alten Intel Graphics Media Accelerator

Achso, wenn Intel die AMD Namensgebung kopiert (HD 2000, HD 3000, HD 4000, ...) ist das iO. Wenn AMD aber andere Namensgebungen verwendet, sind sie lächerlich? Die Logik muss man wohl nicht verstehen. Ausserdem sehe ich nirgendwo, wo die Namen des alten GMA verwendet werden sollen. Kannst du das mal genauer erklären? AMDs Namensschema der A- und E-Serie erinnert doch eher an das bekannter Autohersteller.

Intel baut CPUs mit integrierter Grafik

Nee, ganz sicher nicht. Das wäre ja ein Paradoxon. Denn wenn die GPU integriert ist, dann ist es auch keine CPU mehr. Also wenn, dann "baut Intel Prozessoren mit integrierter Grafik". Dass sie mehr Wert auf die CPU legen, ist klar. Denn mit ihren GPUs können sie auch keinen Blumentopf gewinnen. Da gurken sie hinter 5 Jahre alten Konkurrenzprodukten von AMD und Nvidia rum. Übrigens, ich sehe kein Problem, auch Intels Prozessoren als APUs zu bezeichnen. Auch wenn Intel mit der Fusionierung von CPU und GPU technisch noch nicht so weit wie AMD ist. Bisher klatscht Intel ja mehr oder weniger nur CPU und GPU auf ein Die. AMD ist da mit dem Onion/Garlic Interface schon einen Schritt weiter. Wobei mir der Begriff HPU besser gefällt, Heterogeneous Processing Unit.

Trinity hat also schon die verbesserten Bulldozer Kerne (Piledriver), sowie eine bessere GPU der 7000er Serie.

Allerdings wohl noch kein GCN, sondern VLIW4. GCN basierte APUs gibt's dann wohl erst im kommenden Jahr mit Kaveri.

 

[ruyven_macaran]

Öh: Wie direkt über deinem Post geschrieben klatsch Intel mitnichten "nur CPU und GPU" auf einen DIE. Das haben sie auch noch nie gemacht. Zugegeben: Beim Atom sind es CPU und eine komplette Northbridge mit klassischer IGP (afaik gibt es selbst den FSB intern noch), was bezüglich der GPU-Integration auf Niveau der Llanos ist (dafür ist die CPU-Northbridge-Integration schlechter). Aber bei Sandy und Ivy Bridge hängt die GPU am Ringbus der CPU und ist damit auf gleicher Eben integriert, wie ein CPU-Kern - deutlich enger, als bei AMD.

 

[PCGH_Marc]

Vor allem hat die IGP via Ringbus Zugriff auf den L3, was enger ist als die Implementierung von AMD.

 

[OctoCore]

Auch wenn Intel mit der Fusionierung von CPU und GPU technisch noch nicht so weit wie AMD ist.

Hach - das muss ich mir wirklich auf der Zunge zergehen lassen und genießen. Herrlich.
Zusätzlich könnte man zu dem bereits Erwähnten noch sagen - wenn der GPU-Teil bei AMD bei ähnlich geringer Leistungsaufnahme ähnliches leistet, dann könnte man sich nochmal darüber unterhalten. Aber bis jetzt gab es die höhere Grafikleistung bei AMD nicht grade geschenkt.

 

[gruffi]

Öh: Wie direkt über deinem Post geschrieben klatsch Intel mitnichten "nur CPU und GPU" auf einen DIE. Das haben sie auch noch nie gemacht.

Richtig, bei Clarkdale/Arrandale waren es ja noch zwei Dies. Das mit dem L3 bei Intel ist übrigens nur eine Notlösung und Scheinargument. Oder kannst du mir einen konkreten Vorteil davon nennen? Daten, und das gilt nicht nur für die CPU, sondern auch für die GPU, kommen erstmal aus dem Hauptspeicher. Was ist wohl technisch besser? Wenn diese Daten erstmal den Umweg vom Speichercontroller über den L3 nehmen müssen? Oder wenn diese Daten direkt von einem vereinheitlichten Speichercontroller an die GPU geschickt werden? Die Frage dürftest du dir selbst beantworten können. Caching für schnelleren Zugriff von wiederverwendeten Daten ist übrigens kein Argument. Dafür besitzen GPUs mittlerweile selbst L1 und L2. Mal davon abgesehen ist ein L3 auch viel zu klein für umfangreiches GPU Datencaching. Für das, was AMD vorhat, also die FPU irgendwann durch GPU Shader zu ersetzen, braucht es eine solche Implementierung wie Intel gar nicht. Die Behauptung, Intel hätte eine engere APU Implementierung, ist also komplett falsch. Auch die Behauptung, der L3 Ringbus wäre auf der gleichen Ebene wie ein CPU-Kern, ist falsch. Ebenentechnisch ist der L3 mindestens so weit weg vom Kern wie vom Speichercontroller.

 

[XE85]

Das mit dem L3 bei Intel ist übrigens nur eine Notlösung und Scheinargument. Oder kannst du mir einen konkreten Vorteil davon nennen? Daten, und das gilt nicht nur für die CPU, sondern auch für die GPU, kommen erstmal aus dem Hauptspeicher. Was ist wohl technisch besser? Wenn diese Daten erstmal den Umweg vom Speichercontroller über den L3 nehmen müssen? Oder wenn diese Daten direkt von einem vereinheitlichten Speichercontroller an die GPU geschickt werden?

Wo steht das die Daten über den L3 müssen? Der System Agent mit dem Memory Controller hängt genauso am Ringbus, somit hat die GPU genau den gleichen Zugriffsweg für Daten aus dem Speicher wie ein CPU Kern. Sehe da nichts was da eine Notlösung wäre.

mfg

 

[ruyven_macaran]

Ganz abgesehen davon, dass AMD und Nvidia jetzt iirc schon in der dritten Generation "vergrößerte Caches" im Lastenheft stehen haben
Zugegebenermaßen ist Grafikberechnung davon nicht so abhängig, weil Latenzen gut kaschiert werden können - aber bei einer APU geht es ja eben darum, sich von der strengen Trennung CPU-GPU zu verabschieden. Denn für die bräuchte man quasi gar keine Integration bzw. da war das Niveau von Clarcdale eigentlich optimal: Die GPU hat perfekten Zugang zum Hauptspeicher, die CPU ist schnell genug angehängt, um die Aufgaben zu liefern.
Aber wenn man die massive parallele Rechenpower für nicht-Grafikberechnungen nutzen will, wird Cache extrem wichtig (Das gpGPU-Programm will nunmal irgendwo drin laufen). Wenn man die CPU bei der Grafikberechnung mithelfen lassen will, wird ein gemeinsamer Datenspeicher wichtig (warum soll ich die Modelldetails von der CPU aufwendig in mathematische Formeln fassen und dann in der GPU von einem Tesselator wieder rekonstruieren lassen, wenn ich direkt große Mengen an Polygonkoordinaten rüberschieben kann?).
Davon abgesehen ist es auch einfach eine Frage der Platzeffizienz: 3D-Spiele, die sich mit der Rechenleistung aktueller iGPUs zufrieden geben (insbesondere bei Intel ) lasten sowieso nur einen Bruchteil der CPU-Ressourcen aus. Diese Ressorucen stehen also eh für lau zur Verfügung und sie der GPU zur Verfügung zu stellen rentiert sich somit auch dann, wenn diese nur ein paar % profitiert. AMDs Antwort auf dieses Dilemma besteht, wenn man den eigenen Versprechen glauben darf, bei Trinity darin, die CPU allgemein kleiner zu bauen (so dass man letztlich eher eine kleine CPU in eine doppelt so große GPU integriert hat...). Dann passt zwar unter 3D von der Leistung her, aber in 2D liegen 2/3 des Chips brach und der Rest ackert sich zu Tode.

 

[gruffi]

Wo steht das die Daten über den L3 müssen? Der System Agent mit dem Memory Controller hängt genauso am Ringbus, somit hat die GPU genau den gleichen Zugriffsweg für Daten aus dem Speicher wie ein CPU Kern.

Eben, die Daten müssen erst durch den Ringbus des LLC, um zur GPU zu gelangen. Bei AMD hängt die GPU direkt am Speichercontroller. Da gibt's also keinen Umweg. Und was bei Intel vom L3 gepuffert wird, das wird bei AMD vom L2 der GPU gepuffert. Der einzige Vorteil, der sich bei Intel momentan ergibt, wäre ein Datenaustausch zwischen CPU und GPU. Aber ganz ehrlich, ich wüsste nicht, wozu das sinnvoll sein soll. Mir fällt auch keine Anwendung ein, wo das etwas bringen würde. Partitionierte Aufgaben, und genau das ist der Vorteil von GPUs bei GP Computing, benötigen solch einen Datenaustausch eher selten. Ansonsten sehe ich Intels Lösung momentan eher als nachteilig. Man muss auch bedenken, dass sich CPU und GPU gegenseitig behindern. Schliesslich können nicht beide gleichzeitig in den L3 schreiben. Und auch Lesevorgänge müssen koordiniert werden. Aber gut, das Problem hat man beim Speichercontroller auch. Die Frage ist nur, wo kann man eventuell zusätzliche Latenzen eher in Kauf nehmen. Ich würde sagen, dort, wo die Latenzen eh schon höher sind, also beim Speichercontroller. Höhere Latenzen sind bei Cache schmerzhafter.

aber bei einer APU geht es ja eben darum, sich von der strengen Trennung CPU-GPU zu verabschieden.

Das passiert aber erst auf Kernebene. Und da ist Intel genauso noch nicht angekommen wie AMD. Und nein, der L3 gehört nicht zum Kern. Auch wenn du das vielleicht denkst.

Denn für die bräuchte man quasi gar keine Integration bzw. da war das Niveau von Clarcdale eigentlich optimal

Nicht wirklich. Bei Clarkdale/Arrandale musste Intel ja klare Abstriche beim Speichercontroller bzw dessen Latenz machen.

Aber wenn man die massive parallele Rechenpower für nicht-Grafikberechnungen nutzen will, wird Cache extrem wichtig

Das ist richtig. Aber eben nicht so wie aktuell bei SB. Dafür ist die Trennung von CPU und GPU einfach noch viel zu gross. Wenn CPU und GPU Shader irgendwann richtig verschmolzen sind, dann werden auch die CPU Caches für die GPU Shader wichtig. Aber dafür muss nicht extra "der L3 an die GPU angebunden werden". Man kann die Caches dann so nutzen wie sie jetzt schon sind. Wie gesagt, was Intel da momentan macht, ist überflüssig und für das von AMD angestrebte Ziel für Fusion gar nicht notwendig. Die direkteste und schnellste Anbindung der GPU an das Speicherinterface geht im Moment über den Speichercontroller. Und genau das macht AMD.

AMDs Antwort auf dieses Dilemma besteht, wenn man den eigenen Versprechen glauben darf, bei Trinity darin, die CPU allgemein kleiner zu bauen (so dass man letztlich eher eine kleine CPU in eine doppelt so große GPU integriert hat...). Dann passt zwar unter 3D von der Leistung her, aber in 2D liegen 2/3 des Chips brach und der Rest ackert sich zu Tode.

Eher nicht. AMDs Strategie scheint so zu sein, dass man CPU, GPU und iNB jeweils ein Drittel des Dies zur Verfügung stellt. Das wird sicherlich nicht immer optimal aufgehen. Schliesslich kann man Kerne oder Shader nicht einfach mittendrin abschneiden. Und ob Uncore immer ein Drittel braucht, ist auch nicht gesagt. Das hängt von den verwendeten Interconnects, der Breite des Speicherinterfaces, shared Cache, etc, ab. Grundsätzlich versucht man so aber ein ausgewogenes Design zu schaffen. Und das hat nichts speziell mit Trinity zu tun, das war auch schon bei Llano so. Mal davon abgesehen denke ich, dass es wesentlich sinnvoller ist, ohne Grafiklast nicht genutzte GPU Einheiten für GPGPU zur Verfügung zu stellen. Das gleiche umgekehrt bei CPUs, die bei Nichtauslastung Grafikberechnungen beschleunigen sollen, gilt das nur bedingt bzw nur für Designs, die eine sehr schwache GPU mitbringen. Ansonsten verpufft die CPU nahezu wirkungslos. Ausserdem ist das erste Szenario eher positiv für die Energieeffizienz, während beim letzten Szenario eher das Gegenteil der Fall ist. Ich glaube, es kommt nicht von ungefähr, dass Ivy Bridge prozentual die GPU gegenüber der CPU aufstockt. Hier schaut sich Intel wohl wieder mal einiges von AMD ab und strebt ein ähnlich ausgewogenes Design an.

 

[ruyven_macaran]

Eben, die Daten müssen erst durch den Ringbus des LLC, um zur GPU zu gelangen. Bei AMD hängt die GPU direkt am Speichercontroller.

Nur dummerweise hat der in der aktuellen Generation 30% höhere Latenzen. Dagegen sind die 6 Sprünge = Takte, die man auf dem Ringbus von der IGP zum IMC braucht, nichts.

Man muss auch bedenken, dass sich CPU und GPU gegenseitig behindern. Schliesslich können nicht beide gleichzeitig in den L3 schreiben. Und auch Lesevorgänge müssen koordiniert werden.

Natürlich können sie dass. Jedes Segment des Ringbusses arbeitet unabhängig und auch noch bidirektional. Du hast in einer Quadcore-CPU als 8 Cache-Blöcke, die individuell genutzt werden könnten. Sollte auch kein Aufwand sein, z.B. die letzten komplett für die GPU zu reservieren und die CPU-Last auf die vorderen Kerne zu konzentreiren.

Aber gut, das Problem hat man beim Speichercontroller auch. Die Frage ist nur, wo kann man eventuell zusätzliche Latenzen eher in Kauf nehmen. Ich würde sagen, dort, wo die Latenzen eh schon höher sind, also beim Speichercontroller. Höhere Latenzen sind bei Cache schmerzhafter.

Siehe obiger Link: Zumindest wenn AMDs GPU L2 Cache genauso schnell ist, wie der CPU L2 der Bulldozerkerne, dann ist das nahezu gleich auf mit Intels L3. Somit keine Latenzstrafe, aber deutlich mehr Cache zur Verfügung.

Das passiert aber erst auf Kernebene. Und da ist Intel genauso noch nicht angekommen wie AMD. Und nein, der L3 gehört nicht zum Kern. Auch wenn du das vielleicht denkst.

Da du dich so für mein Denken interessierst, weißt du sicherlich, dass ich denke, dass "Integration" ein Prozess ist und nicht ein Zustand, der schlagartig mit dem letzten Schritt erreicht wird

Nicht wirklich. Bei Clarkdale/Arrandale musste Intel ja klare Abstriche beim Speichercontroller bzw dessen Latenz machen.

Du kennst die GPU->RAM-Latenzen von Clarkdale? Interessant. Her damit.

Das ist richtig. Aber eben nicht so wie aktuell bei SB. Dafür ist die Trennung von CPU und GPU einfach noch viel zu gross.

?
Wenn du meinst...
Nur soviel: Wenn man die GPU auf eine extra Karte setzt, die man in ein extra Board baut, dass in einem extra Gehäuse sitzt (wie einige Tesla-Lösungen), dann ist die Trennung schon klein genug, damit diese Aussage gilt:
gpGPU braucht schnellste Zwischenspeicher. Je mehr. Je besser.

Aber dafür muss nicht extra "der L3 an die GPU angebunden werden". Man kann die Caches dann so nutzen wie sie jetzt schon sind.

Mit Ausnahme von Ivy/Sand-Bridge kann bislang keine einzige GPU den L3 Cache einer CPU nutzen. Und ich wüsste auch nicht, wie das ohne direkte Verbindung möglich sein sollte, denn es existieren aus physikalischen Gründen keine Schnittstellen, die einen derartigen Zugriff ohne direkte Anbindung in voller Geschwindigkeit ermöglichen würden.

Eher nicht. AMDs Strategie scheint so zu sein, dass man CPU, GPU und iNB jeweils ein Drittel des Dies zur Verfügung stellt. Das wird sicherlich nicht immer optimal aufgehen.

Aktuell hat die GPU ~50%. Die nächste Generation bringt, laut AMD eine größere GPU und kleinere CPU-Kerne.
Wie du durch Addition von "1/2" auf "1/3" kommst, ist für mich nicht nachvollziehbar.

Ich glaube, es kommt nicht von ungefähr, dass Ivy Bridge prozentual die GPU gegenüber der CPU aufstockt. Hier schaut sich Intel wohl wieder mal einiges von AMD ab und strebt ein ähnlich ausgewogenes Design an.

Wieso sollte Intel auch viel in einen Bereich investieren, in dem sie >80% Vorsprung haben?
Nach den bisherigen Zahlen wird Ivy Bridge DT eine doppelt so hohe CPU-Leistung haben, wie Llano. Den angekündigten Effizienzzuwächsen von Piledriver zu Folge wird Trinitiy also nicht in der Lage sein, die Ivy Bridge Dualcores zu schlagen. Da kann man entweder kleinere, billigere CPUs oder größere GPUs bauen.
Intel wird bekanntermaßen beides anbieten. (und ich würde stark davon ausgehen, dass sich die kleinen Varianten besser verkaufen)

 

[OctoCore]

Um mal etwas pragmatischer in Sachen GPU zu werden:
Die Zielrichtung von Intels iGPUs ist ja auch etwas anders als bei AMD.
Davon abgesehen, wenn man simple FPS-Zählerei und Effizienzvergleiche außen vorlässt, kann Intel bei der reinen Darstellungsqualität (in Games) wohl immer noch nicht mithalten.
Die "Aufstockung" der Ivy-GPU hat eher weniger mit AMD zu tun, als mit Modellpflege und der Anpassung an aktuelle DirectX-Versionen. Warum werden solche Sachen eigentlich immer gleich als Reaktion darauf gesehen, was irgendwelche anderen Hersteller treiben? Manchmal wird etwas einfach getan, weil es Sinn macht und/oder der Markt das erwartet.

 

[Jan565]

Um mal etwas pragmatischer in Sachen GPU zu werden:
Die Zielrichtung von Intels iGPUs ist ja auch etwas anders als bei AMD.
Davon abgesehen, wenn man simple FPS-Zählerei und Effizienzvergleiche außen vorlässt, kann Intel bei der reinen Darstellungsqualität (in Games) wohl immer noch nicht mithalten.
Die "Aufstockung" der Ivy-GPU hat eher weniger mit AMD zu tun, als mit Modellpflege und der Anpassung an aktuelle DirectX-Versionen. Warum werden solche Sachen eigentlich immer gleich als Reaktion darauf gesehen, was irgendwelche anderen Hersteller treiben? Manchmal wird etwas einfach getan, weil es Sinn macht und/oder der Markt das erwartet.

Weil dann die wahl bei einem HTPC auf Ivy oder Llano bzw Trinity trifft. Die Ivy Bridge GPU mag vielleicht 50% schneller werden als die von SB, aber damit würde die gerade mal aufschließen auf einer APU die schon seit über einem Jahr auf dem Markt ist. Trinity wird in Sachen GPU und CPU wohl noch einen drauf legen.

Für mich hat AMD einfach das bessere Packet aus, Leistung(die mehr als Reicht, denn jedes Programm oder Game ist damit zu Spielen) und Grafikkarte(die für wirklich jedes Spiel bissher ausreicht sogar BF3 wenn man es Zocken möchte).

 

[gruffi]

Nur dummerweise hat der in der aktuellen Generation 30% höhere Latenzen. Dagegen sind die 6 Sprünge = Takte, die man auf dem Ringbus von der IGP zum IMC braucht, nichts.

Und? Das ändert doch an meiner Aussage nichts.

Natürlich können sie dass.

Nein, können sie nicht, wenn auf die gleichen Adressen zugegriffen wird.

Siehe obiger Link: Zumindest wenn AMDs GPU L2 Cache genauso schnell ist, wie der CPU L2 der Bulldozerkerne, dann ist das nahezu gleich auf mit Intels L3. Somit keine Latenzstrafe, aber deutlich mehr Cache zur Verfügung.

Bezug? Worüber redest du bitteschön? Es geht hier nicht um Latenzunterschiede zwischen AMD und Intel. Da die eh unterschiedliche Caches (inklusiv/exklusiv) und Fertigungen nutzen, sind Latenzen auch kaum vergleichbar. Es ging um Latenzunterschiede innerhalb des gleichen Designs.

Da du dich so für mein Denken interessierst, weißt du sicherlich, dass ich denke, dass "Integration" ein Prozess ist und nicht ein Zustand, der schlagartig mit dem letzten Schritt erreicht wird

Ist das so? Na Hauptsache du weisst, dass es "rein definitions-technisch betrachtet bislang nur einen APU-Hersteller gibt". Das ist vor allem deshalb lustig, da du nicht mal eine Definition von APUs gebracht hast.

Du kennst die GPU->RAM-Latenzen von Clarkdale? Interessant. Her damit.

Wie wäre es mit ein bisschen Eigeninitiative? Dass die Speicheranbindung gelitten hat, konntest du in nahezu jedem detaillierteren Review seinerzeit nachlesen, zB hier.

gpGPU braucht schnellste Zwischenspeicher. Je mehr. Je besser.

Aber keine zwischen CPU und GPU, sondern genauso wie bei klassischen CPUs zwischen Hauptspeicher und Prozessorpipeline.

Mit Ausnahme von Ivy/Sand-Bridge kann bislang keine einzige GPU den L3 Cache einer CPU nutzen. Und ich wüsste auch nicht, wie das ohne direkte Verbindung möglich sein sollte, denn es existieren aus physikalischen Gründen keine Schnittstellen, die einen derartigen Zugriff ohne direkte Anbindung in voller Geschwindigkeit ermöglichen würden.

Mit Ausnahme von Ivy/Sandy-Bridge ist auch nirgendwo solche eine für APUs Überflüssige L3 Anbindung integriert. Aber offenbar kennst du nicht wirklich das Ziel von Fusion. Ich hatte ja schon grob gesagt, was das Ziel ist. Ich kann dir daher nur den Tipp geben, dich erstmal einzulesen, bevor du hier weiterdiskutierst. Ansonsten macht das ja keinen Sinn.

Aktuell hat die GPU ~50%.

Nope. Wie wäre es, wenn du langsam mal auf das hörst, was man dir sagt? Und wie ich bereits sagte, aktuell belegen CPU, GPU und NB jeweils etwa ein Drittel.

http://www.abload.de/img/51621_3b4fx93.jpg

Wobei die NB weniger von Bedeutung ist. Ausschlaggebend ist die Ausgewogenheit von CPU und GPU. Allerdings könnte sich das in Zukunft ändern und die GPU mehr Die Budget bekommen. Die CPU wird irgendwo stagnieren, weil Client Anwendungen nichts mit beliebig vielen Kernen anfangen können. Mehr GPU Einheiten werden hingegen auch noch länger bezüglich Performance skalieren.

Wieso sollte Intel auch viel in einen Bereich investieren, in dem sie >80% Vorsprung haben?

Blöd nur, dass sie das nicht haben. Llano ist technisch gesehen der Gegenspieler zum i3. Und das ist Trinity auch, also 2 Kerne/CUs und 4 Threads. Und hier geben sich beide bezüglich CPU fast nichts. Intel hat bis 2 Threads Vorteile, AMD bei mehr als 2 Threads. Intel ist einfach gezwungen, ihre schwache IGP aufzustocken, um nicht den Anschluss an AMDs APUs zu verlieren. Und das machen sie ja auch mit den kommenden Generationen. Blöd nur für Intel, dass die neuen i3 wohl erst in Q4 erscheinen werden. Da könnte AMD mit einem frühen Trinity Launch in Q2 den Markt schon gut abgrasen.

 

[ruyven_macaran]

Und? Das ändert doch an meiner Aussage nichts.

Deine Aussage "AMDs Lösung ist schneller, als Intels" wird nicht durch die Feststellung, dass Intels Lösung selbst im Worst-Case deutlich schneller ist, als AMDs beeinflusst?
Na wenn deine Aussagen derart in Diamant gemeißelt sind, erübrigt sich weitere Diskussion wohl.

Zum Rest deiner Ausführungen bleibt mir auch nur festzustellen, dass sie weder auf meine Ausführungen eingehen und mehrfach den Aussagen aus deinem letzten Post wiedersprechen

 

[PCGH_Marc]

Blöd nur für Intel, dass die neuen i3 wohl erst in Q4 erscheinen werden. Da könnte AMD mit einem frühen Trinity Launch in Q2 den Markt schon gut abgrasen.

Erstens ist Juni (mein Stand) nicht Q4 und zweitens ist Mitte des Jahres mit Q2 äußerst optimistisch - man schaue nur bei Llano, die waren auch erst Wochen nach dem Release ansatzweise verfügbar. So wie es aussieht, ist eher Intel einen Tick früher dran und das mit mehr weitaus mehr SKUs.