Neue APUs am 15. Mai? AMDs Trinity soll in den Startlöchern stehen

Noch mal: Du kannst eine HD 7970 nicht parallel mit der iGPU einer aktuellen A-Serie-APU betreiben. Und der Synergie-Effekt, die dedizierte Karte zusammen mit der CPU der APU etwa an OCL-Code rechnen zu lassen, geht auch mit anderen AMD-CPUs wie einem FX. Sprich du brauchst hierfür keine APU.

System Requirements & Driver Compatibility
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Hm, y33H@ schrieb doch schon, dass es eben nicht geht mit CF. Hybrid-CF geht wie das normale CF nur mit bestimmten Kombinationen und die 7000er Desktopkarten gehören wohl nicht dazu.
Bzgl. CF hast du übrigens vor einer Weile selbst gesagt:
Von CF habe ich gar nicht gesprochen

Belassen wir es doch dabei, dass man noch nicht weiß, ob es mit Trinity funktionieren wird oder nicht. Daher kann man auch noch nicht über irgendwelche Synergieeffekte diskutieren.
 
Wieso soll es nicht wahrscheinlich sein? Ich sehe auch keinen technischen Grund, warum ZeroCore nicht mit Llano funktionieren soll. Llano + diskrete Radeon ist ein ganz normales CF Setup. Und ZeroCore sollte problemlos mit jedem CF Setup funktionieren. Aber gut, kann sein, dass ZeroCore beidseitig unterstützt werden muss. Da will ich mich nicht festlegen. Wie auch immer, Llano ist hier schlichtweg off-topic. Es geht um Trinity. Und ich sehe keinen Grund, warum Trinity + HD 7000 kein ZeroCore unterstützen soll. Aber gut, warten wir den Launch von Trinity ab. Fakt ist, mit einer diskreten GeForce wird ZeroCore definitiv nicht funktionieren. Mit einer diskreten Radeon besteht eine gute Chance.
Du setzt voraus, dass eine HD 7970 per Crossfire (genauer: Dual Graphics) mit der Trinity-iGPU zusammen arbeitet. Unwahrscheinlich, bei Llano überhaupt nicht möglich ... VLIW4 und GCN als CF? Ich setze dagegen. Zero Core an sich funktioniert natürlich (bei Llano wie Trinity), nur wirst du in dem Fall nicht von der iGPU profitieren, da hier höchstwahrscheinlich kein Dual Graphics supportet wird - wie ich seit Tagen sage.

Im normalen Betrieb sind beide GPUs aktiv, halt über CF. Wenn ZeroCore greift, wird eine GPU abgeschaltet. Sinnigerweise natürlich die diskrete GPU. Die iGPU arbeitet unverdrossen weiter. Was genau soll denn hier switchen?
Du kannst das Display-Signal aktuell nicht durchschleifen, d.h. wenn Zero Core greift, müsstest du das Signal auf die iGPU wechseln und wenn die die HD 7970 nutzen willst, dass gleiche rückwärts.
 
Zitat Zitat von Schaffe89
Wahrscheinlich weil das Konzept noch in den Kinderschuhen steckt und es auf Biegen und Brechen released wurde.

Das würde dann dem widersprechen, weil man sich damit übernommen hat:

Zitat von mr.dude
Ein gewisser grundlegender Entwicklungsaufwand ist sicherlich vorhanden. Den hast du aber sowieso bei einer Neuentwicklung. Ist also kein wirkliches Argument.

Ich denke du solltest beide schon als eigene Individuen verstehen und auch beide Meinungen akzeptieren. Viele Leute hier sind durchaus dazu in der Lage sich ihre eigene Meinung zu bilden (Schaffe zählt da sicher zu) und da ist es zimlich egal was jemand anderer dazu schreibt.
 
Y33h dude redet btw von diskreten Grafikkarten, seid wann ist eine Hd 7970 eine diskrete graka?

Gesendet von meinem GT-I9100 mit der Hardwareluxx App
 
Hm, y33H@ schrieb doch schon, dass es eben nicht geht mit CF.
Was soll nicht mit CF gehen? ZeroCore? Doch, das geht.

Bzgl. CF hast du übrigens vor einer Weile selbst gesagt:
Das war ein anderer Sachverhalt. Dort wollte y33H@ das Thema in Richtung kombinierte Performance beider GPUs lenken. Dazu hatte ich aber nichts gesagt. Das hatte mit ZeroCore nichts zu tun.


Du setzt voraus, dass eine HD 7970 per Crossfire (genauer: Dual Graphics) mit der Trinity-iGPU zusammen arbeitet. Unwahrscheinlich
Nee, nicht unwahrscheinlich. Die Kernarchitektur der GPU ist nicht entscheidend für CF. Wichtig für kombinierte Performance ist die Anbindung. Den Rest macht der Treiber. Aber das ist in dem Fall irrelevant. Für ZeroCore müssen die GPUs nicht miteinander rechnen. Daher ist es auch völlig egal, welche Architektur unter der Haube sitzt. Entweder erzählst du seit Tagen Unsinn oder redest absichtlich am Thema vorbei.

Du kannst das Display-Signal aktuell nicht durchschleifen, d.h. wenn Zero Core greift, müsstest du das Signal auf die iGPU wechseln und wenn die die HD 7970 nutzen willst, dass gleiche rückwärts.
Was denn wechseln? Ein Signal liegt standardmässig an der iGPU an. Da muss nichts gewechselt werden, wenn ZeroCore greift. Worauf wolltest du aber nochmal hinaus? Dass mit iGPU das System nicht mehr läuft mit abgeschalteter diskreter Grafikkarte?


Den klassischen Doppelkern kannst du eben schlecht durch ein einzelnes Modul ersetzen, weil dann die Leistung in 'lightly threaded apps' wie z.B. Sysmark 07 noch schlechter ausfällt.
Doch, kannst du wunderbar ersetzen. Denn unterm Strich geht es den Ingenieuren nicht ausschliesslich um Performance, sondern um Effizienz. Also Sachen wie Performance/Watt oder Performance/mm².

Will man nicht noch mehr Boden verlieren, braucht man bei CMT mindestens zwei Kerne / vier logische Prozessoren.
Diese Problematik hast du aber mit jeder Threading Technologie auf Kernebene. Bei SMT ist das sogar noch gravierender aufgrund der geringeren Skalierung. Sollen wir deswegen solche Threading Technologien komplett über Bord werfen und immer nur die gleichen Sachen von vorgestern neu aufwärmen? Ich denke nicht. Performanceansprüche sind degressiv. Und meiner Ansicht nach wird man mit der Zeit auf ein paar Prozent weniger Skalierung von CMT gegenüber CMP problemlos verzichten können, so wie wir mittlerweile auch nicht mehr das letzte bisschen an Takt brauchen. Aber vielleicht gibt's in Zukunft auch noch was besseres als CMT, was noch näher an CMP herankommt. Am grundsätzlichen Gedanken ändert das nicht viel. So viele Redundanzen wie möglich entsorgen und Performance auf so wenig Platz wie möglich unterbringen mit so wenig Energie wie möglich. Letztendlich ist das auch eine natürliche Entwicklung, die der "Fehlentwicklung" zu Beginn der Multicore Ära entgegenwirkt, wo man einfallslos Kerne einfach dupliziert hat, um mehr Performance zu bekommen.
Egal ob CMT, SMT oder was auch immer, unterm Strich muss man einen sinnvollen Kompromiss fürs Design finden, was die Anzahl der Kerne betrifft. Und ich denke ein 2CU/4T Bulldozer ist da eine sehr gute Lösung für den Massenmarkt. Für "lightly threaded apps" hat man immer noch mindestens die Leistungsfähigkeit eines klassischen 2-Kerners. Für mehr kommt man aber auch nahe an einen klassischen 4-Kerner heran.

Der Vorteil von CMT kommt erst dann zum Tragen, wenn statt zwei vier Threads zur Ausführung bereit stehen
Nein. Irgendwie stehst du immer noch im Wald und hast CMT nicht begriffen.

Rechenleistung in Alltagsapplikationen wird absolut gemessen und Bulldozer liegt ca. auf dem Niveau der Intel Pentium Holzklasse. Und der Pentium hat auch einige Bremsen eingebaut und der Nachfolge-Kern (auf Ivy-Basis) wird schneller rechnen - das entschuldigt nur leider AMDs Fehlentwicklung nicht.
Müssen sie auch gar nicht. Schliesslich gibt es keine Fehlentwicklung. Ich weiss ja nicht, was bei dir Pentium Holzklasse sein soll. Aber der grösste Bulldozer liegt deutlich darüber. Wenn ich mir das Gesamtrating von HT4U anschaue, dann liegt der FX4 10% hinter dem i3. Dafür, dass AMD aufgrund der typischen Windows Setups softwareseitig eh immer benachteiligt ist und gerade Bulldozer, als komplett neue Architektur, Support benötigt, ist das völlig iO. Alles weitere wird man mit zukünftigen Verbesserungen sehen.

Die Thesen zum Aufwand von CMT (Die-Fläche, Energie, Latenz) im Kern teile ich übrigens nicht. Die Cache-Zugriffszeiten und einige Bandbreiten sind eine Katastrophe, insbesondere wenn die Daten zur/von der FPU müssen/kommen. Wer würde schon eine 256 Bit / Takt breite FMAC Einheit in einen Kern einbauen, die nur 128 Bit / Takt /Thread wegschreiben kann.
Es müssen auch nicht in jedem Takt Ergebnisse in den Speicher zurückgeschrieben werden. Meistens wird ja mit Registern gerechnet. Und zum Cache, wie gesagt, das hat nichts mit CMT zu tun, sondern vor allem mit Grösse, Ex-/Inklusivität, Assoziativität und Fertigung. Mal abgesehen davon sind Latenzen zur FPU nicht so dramatisch. Da FP Instruktionen eh in der Minderheit sind, kann man Latenzen gut durch OoO Ausführung kaschieren. Hast du dir mal die Ausführungen von Agner Fog angeschaut? Der teilt deine Ansichten auch in keinster Weise.
 
Zuletzt bearbeitet:
y33H@ schrieb:
Wie soll die iGPU ohne Wechsel (switchen) alles weitere übernehmen, hmmm? Aber was rede ich, selbst wenn man dich zitiert - es ist witzlos.

Du solltest einfach aufhören ständig alles mit deinen angeblichen "Fakten" zu zerreden. Die Diskussion ist genauso episch wie zwischen uns bei Computerbase, einfach nen Kaffee und n paar Plätzerl. :d

boxleitnerb schrieb:
on CF habe ich gar nicht gesprochen
Belassen wir es doch dabei, dass man noch nicht weiß, ob es mit Trinity funktionieren wird oder nicht. Daher kann man auch noch nicht über irgendwelche Synergieeffekte diskutieren.

Du verstehst die y33H@ Masche nicht.
Er versucht schon zuvor die Diskussion in für sich passende Wege zu leiten. Deswegen das vorherige Drängen auf CF.
Und jetzt weil über CF gesprochen wird, tappst du auch in die Falle und zitierst einen anderen Sachverhalt von vorhin.
Bleibt die leidige Frage ob es nun ein Synergie Effekt zwischen IGPU und dedizierter GPU wird oder nicht.
Wenn man von einem Trinity System als Grundlage ausgeht, wohl doch eher schon. Und das war die ursprüngliche Aussage, die eigentlich korrekt ist um die man sich jetzt fetzt. Schon erstaunlich. ^^
 
Zuletzt bearbeitet:
Die Kernarchitektur der GPU ist nicht entscheidend für CF.
Ach so, deswegen gibt's seit jeher KEIN Crossfire zwischen unterschiedlichen Architekturen :fresse:

http://sites.amd.com/PublishingImag.../WebBannerJPEG/AMD_CrossfireX_Chart_1618W.jpg

Was denn wechseln? Ein Signal liegt standardmässig an der iGPU an. Da muss nichts gewechselt werden, wenn ZeroCore greift. Worauf wolltest du aber nochmal hinaus? Dass mit iGPU das System nicht mehr läuft mit abgeschalteter diskreter Grafikkarte?
Wenn das Signal an der iGPU einer aktuellen APU (Llano) anliegt, kannst du die HD 7970 nicht nutzen - wozu also erst einbauen.
 
Na ja, auch wenn die Liste klar ist, dürfte CF dennoch ohne Murren zwischen VLIW4 und VLIW5 GPUs laufen. Es ist ja weiterhin AFR und bei AFR ist die Architektur im Prinzip egal, es zählen nur die herausgerotzten Bilder. GCN sollte allerdings tatsächlich nicht mit VLIW kombiniert werden, da die abwechselnden Bilder in ihrer Qualität zu stark voneinander abweichen können. Zwischen VLIW4 und 5 dürfte das ziemlich gleichwertig sein und damit keine Rolle spielen.
 
Zuletzt bearbeitet:
Ich sehe nur, es ging bisher nicht mal bei VLIV und es bei GCN ist was völlig anderes. Trinity ist VLIW4, da gibt's nur die HD 69x0.
 
Ich sehe nur, es ging bisher nicht mal bei VLIV und es bei GCN ist was völlig anderes. Trinity ist VLIW4, da gibt's nur die HD 69x0.

"Es ging nicht" aus Performancesicht. Bei Trinity wirst mMn mit den umbenannten 40nm-VLIW5-Chips sehen, dass es sehr wohl geht. Solange das aber nicht erwiesen ist, können wir uns unendlich weiterstreiten, wir werden sehen, wie das läuft. Ich halte es eben für extrem unwahrscheinlich, dass man "DualGraphics", wie schwachsinnig diese AFR-Lösung auch immer sein mag, fallen lässt und rein technisch gesehen spricht überhaupt nichts gegen diese Lösung.


Und CMT ist mMn nicht "zum Scheitern verurteilt". Das ist erst der Anfang! MMn liegt die Zukunft eindeutig in Threadintegration, also CMT über 3 oder 4 Threads in einem Modul. Das Optimum wäre dann, dass das Modul die Ressourcen auch bei nur einem Thread optimal nutzen kann.
Sicher ist BD noch unglaublich weit davon entfernt, aber man muss einen Anfang machen. Nur weil BD nicht optimal ist, heißt das nicht, dass die Technologie schlecht ist. Denkansatz super, Erstumsetzung mangelhaft (wie überraschend).
 
Zuletzt bearbeitet:
Den klassischen Doppelkern kannst du eben schlecht durch ein einzelnes Modul ersetzen, weil dann die Leistung in 'lightly threaded apps' wie z.B. Sysmark 07 noch schlechter ausfällt.
Doch, kannst du wunderbar ersetzen. Denn unterm Strich geht es den Ingenieuren nicht ausschliesslich um Performance, sondern um Effizienz. Also Sachen wie Performance/Watt oder Performance/mm².
Dann viel Spaß mit deiner neuen Traummaschine, selbst ein hypothetischer 45 nm Atom 8-Kerner wäre wahnsinnig effizient, in 22 nm wird das toll:
Exclusive: Intel 8-core server Atom gets a name and date | SemiAccurate
Wenn Geschwindigkeit für dich keine Priorität hat, dann ist die Diskussion müßig. Über Geschmack kann man nicht streiten.

@k3im: Sorry - hast eigentlich recht. War nicht fein.

Wegen CMT:
Und CMT ist mMn nicht "zum Scheitern verurteilt". Das ist erst der Anfang! MMn liegt die Zukunft eindeutig in Threadintegration, also CMT über 3 oder 4 Threads in einem Modul. Das Optimum wäre dann, dass das Modul die Ressourcen auch bei nur einem Thread optimal nutzen kann.
Wenn man die Resourcen der zwei Integer-Kerne in einem logischen Kern bündeln könnte, würde das ausreichen mehr als vier Integer-Instruktionen pro Takt zu verarbeiten (ein Integerkern hat zwei ALUs + zwei AGUs). Das hieße, dass man dann auch vier + X Instruktionen pro Takt im Frontend dekodieren muss.

Kann man aus der Tatsache, dass ein Bulldozermodul im Dual-Thread-Betrieb 60-70 % mehr Instruktionen verarbeitet als im Single-Thread-Betrieb, darauf schließen, dass das dekodierende Frontend noch Reserven besitzt und die Bremse irgendwo hinten im Kern sitzt?
 
[...]
Wegen CMT:

Wenn man die Resourcen der zwei Integer-Kerne in einem logischen Kern bündeln könnte, würde das ausreichen mehr als vier Integer-Instruktionen pro Takt zu verarbeiten (ein Integerkern hat zwei ALUs + zwei AGUs). Das hieße, dass man dann auch vier + X Instruktionen pro Takt im Frontend dekodieren muss.

Kann man aus der Tatsache, dass ein Bulldozermodul im Dual-Thread-Betrieb 60-70 % mehr Instruktionen verarbeitet als im Single-Thread-Betrieb, darauf schließen, dass das dekodierende Frontend noch Reserven besitzt und die Bremse irgendwo hinten im Kern sitzt?

Bei BD dürfte weder die integer-cluster noch das frontend optimal sein. Piledriver scheint sowas wie BD reloaded zu sein und Steamroller bringt dann offenbar double-stage-decoder und bessere int-cluster mit. BD ist ganz klar nicht in der Lage Nutzen aus seinem CMT ggü. Sandy zu ziehen bei ähnlicher Fertigung, das heißt aber nicht, dass das so bleiben muss in Zukunft.

Ach ja, VLIW4 + VLIW5 CF:
http://www.computerbase.de/news/2012-04/amd-trinity-details-fuers-notebook-sickern-durch/
 
Zuletzt bearbeitet:
Das kann man verschieden ansehen.
Wenn es bei Trinity zusammen mit einer GCN Karte funktioniert, kann man das als Synergie sehen, da die IGPU ansprpingt, wenn GCN in den Zero Core Mous geschaltet wird.
Ob dies später so funktionieren wird oder nicht, bleibt abzuwarten.

Das würde auch mit anderen IGPUs (auch auf dem Motherboard) funktionieren, wenn es den funktionieren würde ;)
Aber lassen wir das, wenn sie es mal schaffen sollten sowas in den Treiber zu integrieren, wird sicher die Hardware mit ausgelesen und auf bestimmte Hardware begrenzt.
 
Weiß jemand wann die Desktopvarianten kommen sollen? Bei dem ganzen Geschreibsel geht das schnell unter.
 
Bisheriger Gerüchtestand ist der 15. Mai - Desktop wie Mobile. Die Verfügbarkeit gilt es abzuwarten.

EDIT
Siehe Thread-Name ^^
 
Zuletzt bearbeitet:
Bisheriger Gerüchtestand ist der 15. Mai - Desktop wie Mobile. Die Verfügbarkeit gilt es abzuwarten.

EDIT
Siehe Thread-Name ^^
Offizieller Stand ist 15. Mai Mobile und Desktop im Juni.... da wurde doch glatt schon beim zitieren eine 15 aus deiner 10. ;)

*edit* Offiziell bestätigt ist bisher nur der 15. Mai für die Notebookchips, für die Desktopvariante gilt noch 'mid 2012'. Also könnte Juni auch zu optimistisch sein.
 
Zuletzt bearbeitet:
Bisheriger Gerüchtestand ist der 15. Mai - Desktop wie Mobile. Die Verfügbarkeit gilt es abzuwarten.

EDIT
Siehe Thread-Name ^^

Wäre fast unmöglich dass Trinity für Desktop am 15. Mai kommt; hast du schon irgendetwas zu FM2 MoBos gelesen, geschweige denn finale Boards gesehen? Wenn sogar ihr als Hardwareredaktion nein dazu sagt, dann wäre der 15. Mai ein wenig knapp dafür.....in einem Interview wurde "back to school"-Zeitpunkt genannt, was September wäre (leider). Der link zu dem Interview wurde hier bereits gepostet, da dieser Thread jedoch, wie jeder andere bezüglich AMDs CPUs übrigens, in einen Kleinkrieg mr.dude vs. irgendeinen anderen User ausartet, geht so etwas wirklich schnell verloren
 
Naja könnte ja ein Paperlaunch geben bei dem sozusagen die komplette Plattform gelauchnt wird.
 
Also mich würden vor allem die Verbrauchswerte interessieren, da so eine APU in einem Ultrabook mir schon gefallen könnte^^
 
A6 4400M Benchmarks:

Trinity A6-4400m + A10-4600m Benchmarks

Nur ein Modul, eine deftige Verschlechterung gegenüber den A6-Llanos falls das stimmt. Der Cinebench-Score eines alten A6-3420M ist mal eben 70 Prozent höher, Singlethreaded läuft es laut SuperPi wohl auf einen Gleichstand hinaus. Womöglich ein Anzeigefehler und es handelt sich nur um einen A4, da würden die Leistungsdaten besser passen - wäre CPU-seitig aber trotzdem praktisch Stillstand gegenüber Llano.
 
Sind die A6 nciht die neue "holzklasse" der Trinitys ? ... also A6, A8 und A10 ?
 
A4 soll es wohl weiterhin geben. Zumindest ist ein A4-5300 bisher durchgesickert.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh