Computex 2013: AMD zeigt "Kaveri" in Aktion

[fdsonne]

Reduzier die Bandbreite noch weiter. PCIe 2.0 8x hat 4GB/s Lass es 2GB/s sein, die am ende mehr zur Verfügung stehen.

Wenn man Computerbase glauben darf, schaufelt Richland 13GB/s aus dem RAM, das wären dann grob 20%. Natürlich ist das eine rein theoretische Überlegung, aber man könnte so ein wenig mehr Bandbreite herausholen und eine stärkere GPU in Kaverie einbauen, bis DDR4/GDDR5 kommt.

Moment... Darum gings doch nicht.
Mir ging es um den Aspekt, der oben genannt wurde. Eben, das der Transfer von Daten zwischen RAM (CPU) und VRAM (GPU) wegfällt. Und man somit die Bandbreite effektiver bzw. besser nutzen kann für die GPU. Soweit, sogut. Nur ich sehe daran eben keinen performance Vorteil. Da dieser Transfer der Daten in aktueller Umsetzung scheinbar kein Nachteil ist.

Darauf hin gab ich als Beispiel, das eine aktuelle HighEnd Grafikkarte nur via PCIe mit dem RAM sprechen kann, bzw. das System nur via PCIe mit der Grafikkarte (und dessen VRAM). So ein Modell hat die x Fache Leistung von den aktuellen APUs, was den GPU Teil anbelangt. Dennoch kommt diese mit nem Bruchteil an effektiv nutzbarer Bandbreite aus, ohne überhaupt in der Performance einzuknicken. Das Reduzieren der Bandbreite von PCIe auf ein viertel kostet effektiv vielleicht 2-5% Performance, wenn überhaupt.

Meine Schlussfolgerung ist nun, bei ner HighEnd GPU werden so wenig Daten über den "Bus" übertragen bzw. diese Datenmengen sind so gering, das durch Bandbreitenreduzierung sogut wie keine Performance verloren geht.
Bei ner deutlich langsameren GPU Lösung einer APU kann dieses Verhalten nur analog dazu von statten gehen.
Killt man nun diesen Transfer durch den gemeinsamen Speicherbereich, so kann man unterm Strich effektiv fast gar nix gewinnen.
Denn wo ein künstlich erzeugter Flaschenhals keine Performance bringt, kann durch Umgehung dieses Flaschenhalses auch keine nennenswerte Performance gewonnen werden. Denn wäre die Transferleistuung zwischen RAM und VRAM bzw. umgekehrt das Problem, so müsste eine dedizierte GPU bei deutlicher Bandbreitenverknappung auch deutlich einbrechen...

Hier wiedersprichst du dir doch grad selber. Auf der einen Seite bringt mehr Bandbreite nichts, aber auf der anderen Seite schnellerer RAM schon, also was denn jetzt?

Wo habe ich das gesagt?
Der GPU Teil benötigt Bandbreite zum Arbeiten. Das hat niemand angezweifelt. Der CPU Teil ebenso, aber scheinbar weit weniger, als der GPU Teil.
Erhöht man den Speicherdurchsatz im gesamten, so profiziert der GPU Teil recht anständig davon.

Mein Zweifel liegt aber nach wie vor darin, das dieses Verhalten durch genannte Techniken von AMD anders ausfallen wird. Denn die Bandbreite bleibt unverändert. Es mag der Transfer der Daten zwischen CPU RAM Bereich und VRAM Bereich der GPU wegfallen. Aber dieser Transfer von Daten kostet scheinbar aktuell keine Leistung, wie mein Beispiel oben mit der dedizierten Lösung von Grafikkarte aufzeigt.

 

[why_me]

Ich kann es nur nocheinmal sagen, reduzier den PCIe Bus weiter.

Dein Vergleich bedeutet nur, wir benötigen aktuell weniger als 4GB/s an Daten, die in den GPU RAM geschrieben werden müssen. Ob diese Daten bei kleineren GPUs wesentlich kleiner sind? Solannge die Einstellungen gleich sind, werden die gleichen Daten als Rechengrundlage genutzt.

Hier mal ein Test mit kleineren Bandbreiten:
Benchmark-Ergebnisse - Wer braucht PCI Express? Test bei x16, x8, 4x, x1

Zwar nur PCIe 1.0, aber man sieht einen deutlichen Unterschied. Hinzu kommt, für die iGPU muss aus dem RAM gelesen und wieder in den RAM geschrieben werden -> doppelte Bandbreite.

Gehen wir einfach mal von 2GB/s aus, dann sind das von den 13GB/s die laut Computerbase möglich sind (link) 15%. Die verloren gehen. Und genau diese könnte man evtl. durch Huma wieder "gewinnen". Schnellerer RAM bringt natürlich auch mehr, aber bei 2133 ist schluss, mehr gibt es bei DDR3 offiziel nicht (JEDEC).

 

[mr.dude]

Ich ging damit auf deine Aussage von oben ein, nämlich: "Transfers zwischen RAM und VRAM fallen weg, da CPU und GPU auf einen gemeinsamen Adressraum zugreifen"
Und ich brachte einen Vergleich zu einer dedizierten GPU Lösung, wo genau so das selbe Verhalten gezeigt wird. Nämlich "Transfer zwischen RAM und VRAM". Im Vergleich sagte ich, verringert man die PCIe Bandbreite, um einen Flaschenhals zu erzeugen, ändert sich an der Performance sogut wie nix.

Nochmal zum mitmeisseln:

dGPU: HDD/SDD <--(CPU)--> RAM --(PCIe)--> VRAM ----> dGPU
iGPU: HDD/SDD <--(CPU)--> RAM ----> iGPU

Du schriebst, dass es "am Zusammenspiel von GPU und CPU" quasi keinen Unterschied gäbe. Es gibt aber sehr wohl einen Unterschied, wie du sehen kannst. Es bringt dir nichts, auf einzelne Teile zu schauen. Du musst das Gesamtkonstrukt betrachten. Es wird auch kein Flaschenhals erzeugt. Den Flaschenhals gibt's jetzt schon und heisst RAM/IMC. Und momentan geht ein Teil dieser Bandbreite dafür drauf, um Daten entweder an die iGPU oder dGPU (PCIe) zu schicken. Und genau diese Transfers fallen dann weg, weil die iGPU auf den gleichen Adressraum wie die CPU zugreifen kann. Ob hUMA im Endeffekt was bringt, und ob es hilft, den Bandbreitenhunger einzudämmen, werden wir sehen. Dies aber von vornherein kategorisch auszuschliessen, halte ich für falsch.

Wäre der Transfer zwischen RAM und VRAM eine Performancebremse ...

Darum geht's doch gar nicht. Hast du die Diskussion überhaupt mitverfolgt? Es ging um die Bedenken, dass wahrscheinlich weiterhin Dual-Channel DDR3 zum Einsatz kommt und dass dadurch die vorhandene Rechenkapazität womöglich zu stark von der Speicherbandbreite limitiert wird. Das Thema heisst also RAM -> GPU und nicht RAM -> VRAM.

Aber fragen wir mal anders, welchen Effekt würde diese Technik denn bringen, wenn die Daten schon im "VRAM" Bereich der APU drin sind?

Diese Frage ist auch nicht Gegenstand der Diskussion. Nochmal, die Frage lautete, ob die Bandbreite bei Dual-Channel DDR3 zum Flaschenhals werden kann. Wenn die Daten eh schon im Speicher sind, dann stellt sich die Frage logischerweise gar nicht.

Bleibt unterm Strich also das Spielen. Und dafür halte ich die APUs für zu langsam

Also das ist nun wirklich Quatsch. Man sollte nicht von sich oder von Hardcore-Gamern auf den gesamten Markt schliessen. Ich behaupte einfach mal, dass für weit mehr als die Hälfte des Gamer-Marktes APUs perfekt sind. Nicht jeder spielt mit irrwitzig hohen Auflösungen und irgendwelchen AA/AF Spielereien. Wie viele Millionen MMO-Spieler gibt es mittlerweile? Oder schau dir mal an, mit welchen GPUs die aktuellen Konsolen immer noch rumgurken. Und selbst die Next-Gen Konsolen sind keine Rechenmonster im Vergleich zu aktuellen Top-dGPUs. Ich habe zB eine HD 5750, die mir im Moment immer noch völlig ausreicht. Und Kaveris iGPU wird da schon sehr nahe an die theoretische Rechenleistung rankommen. Dank GCN sollte diese aber besser genutzt werden können. Fragt sich halt nur, ob die Speicherbandbreite mitspielt.

 

[fdsonne]

Es geht hier doch um die allgemeine Abschätzung welchen Vorteil hUMA bringen könnte. Und da bin ich nach wie vor der Meinung, dass man da einfach mal abwarten muss.

Also darfst du, und ein paar andere hier, die Meinung abgeben, ich aber nicht? Sorry, aber was soll das?

Ich kann es nur nocheinmal sagen, reduzier den PCIe Bus weiter.

Dein Vergleich bedeutet nur, wir benötigen aktuell weniger als 4GB/s an Daten, die in den GPU RAM geschrieben werden müssen. Ob diese Daten bei kleineren GPUs wesentlich kleiner sind? Solannge die Einstellungen gleich sind, werden die gleichen Daten als Rechengrundlage genutzt.

Das der Vergleich nur eine Tendenz aufzeigt, ist mir durchaus bewusst.
Dennoch habe ich absichtlich von HighEnd GPUs gesprochen im Vergleich, die ein vielfaches der Rechenleistung der APUs haben...
Und hier erzeugt bei gleichen Settings mehr Hardwareleistung auch mehr FPS.
Nur weil die Settings gleich sind, bleibt der Bandbreitenbedarf nicht gleich.
Wenn die APU sagen wir 30 FPS schafft, die dedizierte GPU aber 120 (4x kommen da sicher zusammen), heist das auch, sie benötigt in Größenordnungen mehr Bandbreite... Weil die Zugriffe auf den Speicher eben in diesem Beispiel auch viermal mehr in der selben Zeit erfolgen. Nur das ist alles nicht Thema, weil die Daten ja im VRAM (bzw. im VRAM Bereich der APU) liegen.
Dieser Part skaliert recht gut mit steigender Bandbreit.
Da ich mich aber auf die Aussage von mr.dude beziehe!, wie schon angesprochen, bezweifle ich nach wie vor, dass es hier zu Engpässen kommt, was den Transfer der Daten zwischen RAM und VRAM angeht. Da einfach diese von ihm erwähnen Transfers scheinbar nicht ins Gewicht fallen. Und da selbst bei HighEnd GPUs, die deutlich schneller sind, die geringe PCIe Bandbreite (selbst bei Verringerung) nicht nennenswert an der FPS Leistung dreht.
Zumal sich die Daten, auf die die GPU zugreift, nicht ständig signifikant ändern. Denn wäre dies der Fall, würde eine PCIe Grafikkarte deutlich mehr Performance einbüßen bei verringerter PCIe Bandbreite. Macht sie aber nicht. Das Konstrukt lebt ja quasi davon, das die GPU ihre Daten, die sie benötigt, im Zugriff hat. UNd das auch bei ner APU, ja selbst mit hUMA. Wie die Daten dort hin kommen, scheint aus meiner Sicht der Betrachtung wenig Performancekritisch zu sein. Auch reden wir hier nicht von x hundert GB an Menge. Sondern von teils wenigen hundert MB, wenn überhaupt.

Ich würde uneingeschränkt zustimmen, wenn sich der Datenpool exorbitant schnell ändern würde. Dann kann dies folglich enorm von Vorteil sein. Im Gegenwertigen Konstrukt scheint aber das wenn man so will einmalige "reinschieben" der Daten in den VRAM Bereich zu genügen, und die GPU greift immer wieder auf die gleiche Basis zu. Ändert sich an der Basis was, gibts hier und dort nen kleinen Nachschub an Daten. Ggf. auch nen Nachladeruckler, wenn die Engine nicht schnell genug im Vorfeld erkennen kann, was für Daten benötigt werden.
Überspitzt ausgedrückt, hätte der Nutzer einer dedizierten GPU beim Spielstart ein paar wenige Sekunden mit mauen FPS zu kämpfen, wärend die APU mit hUMA dies nicht hätte (weil der Transfer der Daten wegfällt)... Ich meine aber auch hier, das wäre verschmerzbar und zählt aus meiner Sicht nicht zu einem generellen Vorteil...

Und momentan geht ein Teil dieser Bandbreite dafür drauf, um Daten entweder an die iGPU oder dGPU (PCIe) zu schicken. Und genau diese Transfers fallen dann weg, weil die iGPU auf den gleichen Adressraum wie die CPU zugreifen kann. Ob hUMA im Endeffekt was bringt, und ob es hilft, den Bandbreitenhunger einzudämmen, werden wir sehen. Dies aber von vornherein kategorisch auszuschliessen, halte ich für falsch.

Zum ersten bezog ich mich im allgemeinen auf APUs... Wie sie heute zu sehen sind, oder siehst du irgendwo, das ich explizit von der noch nicht erhältlichen Umsetzung mit hUMA sprach?
Und zum zweiten, "Nochmal zum mitmeisseln"
Es ist in der Theorie gut und schön, nur was nutzt die beste Theorie, wenn in der Praxis daraus kein (wirklicher) Vorteil entsteht?
Wie nun schon x mal erwähnt, halte ich den Bandbreitenbedarf für diese von dir angesprochenen Transfers für so gering, das diese nahezu gar nicht ins Gewicht fallen. Speziell genau dann, wenn die Daten einmal im Speicherbereich angesiedelt sind, wo die GPU Zugriff drauf hat. Und das müssen sie sein. Sonst hat die GPU Lösung (ob nun i oder d, egal) keine Performance. Nennt man auch Nachladeruckler im GPU chargon... Nämlich wenn die GPU auf Daten zugreift, die nicht in ihrem zugewiesenen VRAM Bereich angesiedelt sind, und diese umständlich und langsam über den PCIe Slot, bzw. bei der APU über irgend nen Connect aus dem RAM Bereich geholt werden müssen.

Mal ne blöde Frage, aber meinst du, es gibt Personen, die so permanent spielen? Ich glaube nicht daran...
Denn umgeht man das ganze durch treffend gewählte Settings, so tritt genau das ein, was du weiter unten selbst schreibst. "Wenn die Daten eh schon im Speicher sind, dann stellt sich die Frage logischerweise gar nicht."
Und wenn man eine HighEnd GPU, welche Bandbreitenbedarf für ihren Speicher von mehreren 100 GB/sec hat, mit nem PCIe Flaschenhals von wenigen hundert MB/sec versorgen kann, so dürfte doch klar ersichtlich sein, das eine APU Lösung, die von Haus aus schon einiges weniger an Performance liefert, dort nicht auf einmal zum Performancewunder wird, wenn da die Daten nicht erst verschoben werden müssen in den Bereich, wo der GPU Teil Zugriff hat.

Darum geht's doch gar nicht. Hast du die Diskussion überhaupt mitverfolgt? Es ging um die Bedenken, dass wahrscheinlich weiterhin Dual-Channel DDR3 zum Einsatz kommt und dass dadurch die vorhandene Rechenkapazität womöglich zu stark von der Speicherbandbreite limitiert wird. Das Thema heisst also RAM -> GPU und nicht RAM -> VRAM.
Ich schon... Kleiner Exkurs. Post #11/#13, Schaffe stellt die Frage, du antwortest. Und ich fragte, was das Effektiv bringen soll...

Also das ist nun wirklich Quatsch. Man sollte nicht von sich oder von Hardcore-Gamern auf den gesamten Markt schliessen. Ich behaupte einfach mal, dass für weit mehr als die Hälfte des Gamer-Marktes APUs perfekt sind. Nicht jeder spielt mit irrwitzig hohen Auflösungen und irgendwelchen AA/AF Spielereien.

Das kleine Wörtchen "ich" scheint wohl untergegangen zu sein, in meinem Kommentar zur Leistung.
Wenn du anderer Meinung bist, gut und schön, ist das deswegen auch Quatsch?

 

[WC_Ente]

@fdsonne

was jammerst du hier eigentlich rum?

du versuchst dich permanent irgendwie herauszureden,
denn das beste Beispiel ist das thema gpu/cpu ram/vram pcie Anbindung.

da kannst du es drehen und wenden wie du willst man muss das gesamt Konstrukt nehmen,
und nicht 1zelne teile heraus zu picken.

wenn du das in einem HW Forum nicht kannst , sry aber dann ist dein posten als MOD ein fail

 

[fdsonne]

Auch wenn ich es drehe und wende, wie es die Anderen möchten, sehe ich kein "Problem" durch den von mr.dude angesprochenen Datentransfer zwischen RAM und VRAM, wie im Post #13 erwähnt.
Und ja natürlich betrachte ich dabei das Gesamtkonstrukt. Wie soll man sonst die Leistung abschätzen. Nur spielt eben das Ändern eines Teilparts die gewichtigere Rolle in dieser Diskusion. Und ich bezweifle schlicht, dass durch dieses Feature da an der Performance arg was verbessert wird, weil scheinbar der dann wegfallende Transfer nicht nennenswert auf die Performancebremse drückt bzw. die Performance aktuell nicht nennenswert beeinflusst wird, weil aktuell noch Daten dort umgeschoben werden.


Im übrigen wäre ich dir sehr dankbar, diese haltlosen Unterstellungen sein zu lassen und bitte dich hiermit einmalig und höflich um die Beweise für "permanent irgendwie herauszureden"!!

 

[WC_Ente]

1. das es derzeit keiner Performance kostet liegt daran, das es so ein huma sys im x86 praktisch noch nicht gibt,
somit kann man auch wenig über Performance gewinn sagen, da wir nach wie vor beim alten System sind.

2. lese einfach die seite nr.2 hier durch.

 

[fdsonne]

1. das es derzeit keiner Performance kostet liegt daran, das es so ein huma sys im x86 praktisch noch nicht gibt,
somit kann man auch wenig über Performance gewinn sagen, da wir nach wie vor beim alten System sind.

Was ist das denn für ne Schlussfolgerung?
Wenn man ein küstliches Limit erzeugt, sich am ganzen aber nix trivial ändert, scheint kein Problem vorzuliegen in diesem Bereich...
Man kann aber sehr wohl abschätzen, was es bringen wird, wenn man in Betracht zieht, was aktuell an Vorgängen ablaufen und was in der hUMA Umsetzung dann damit passiert.
Und dort wo besagte Datentransfers keine Leistung kosten, kann auch hUMA nichts an Performance bringen. (hier waren wir übrigens schonmal... mr.dude stimmte sogar zu)
Und dort wo besagte Datentransfers eben Leistung kosten, wird auch hUMA ansich die Performance erhöhen können. -> nur scheinen das eben keine Spiele zu sein, denn hier trifft scheinbar erstes zu.


Simples Beispiel, du fährst in den Urlaub und setzt die Kinder hinten ins Auto. Kind A auf Sitz A und Kind B auf Sitz B.
In der aktuellen Umsetzung musst du vor dem Start Kind A auf Sitz B und Kind B auf Sitz A umziehen, weil es sonst nicht geht.
In der neuen Umsetzung kannst du dir dieses sparen.
Theoretisch scheint die Einsparung des Arbeitsschrittes freilich gut. In der Praxis werden dich aber diese paar Sekunden Arbeit nicht stören, wenn du ne 10h Autofahrt vor dir hast. Denn in beiden Fällen (ob alt oder neu) hast du als Fahrer Zugriff auf die Kinder hinten und kannst mit diesen "Reden"
Vielleicht versteht man jetzt, worauf ich hinaus will

2. lese einfach die seite nr.2 hier durch.

Ich warte nach wie vor auf Belege für diese Behauptung!

 

[Mick_Foley]

Vielleicht versteht man jetzt, worauf ich hinaus will

Nicht verstehen und nicht sehen wollen sind leider zwei komplett unterschiedliche Paar Schuhe. Finde dich damit ab, eine negative Prognose für AMD-Technologien in AMD-Threads führt grundsätzlich zur Erschießung durch den Revolutionsrat...

 

[OT71]

Nicht verstehen und nicht sehen wollen sind leider zwei komplett unterschiedliche Paar Schuhe. Finde dich damit ab, eine negative Prognose für AMD-Technologien in AMD-Threads führt grundsätzlich zur Erschießung durch den Revolutionsrat...

und du kannst auch nix anderes als in AMD threads zu sticheln

 

[fdsonne]

Es sollte ja nicht generel negativ sein. Das war bestimmt nicht meine Absicht...
Sondern viel eher bezweifle ich, das es damit eben signifikant positive Effekte gibt. Schlechter werden wird es durch dieses Feature wohl keinesfalls
Wohl dem, der die Augen aufmachen kann und auch mal in Teilbereiche einsehen möchte um zu schauen, wo kommt die Performance nun her...

Das was an mehr Leistung bei rum kommt, kommt wohl viel eher durch mehr Takt und/oder bessere Technik unterm Deckel sowohl bei CPU als auch bei GPU Teil.
Aber eventuell bin ich auch schlicht nicht in der Lage einfach das Gesamtbild zu betrachten und mich so vom warscheinlich etwas besserem Ergebnis im Vergleich zum direkten Vorgänger blenden zu lassen
Das ist wie mit PhysX per GPU bei NV. Der Mythos, das es Performance bringt anstatt kostet geht ja nach wie vor durch die Köpfe, die nur das Gesamtbild betrachten und den Vergleich zur reinen CPU Berechnung sehen

 

[Mick_Foley]

und du kannst auch nix anderes als in AMD threads zu sticheln

Doch ich kann auch in Intel und Nvidia-threads sticheln wenn ich Blödsinn lese. Diese Rudelbildung hier ist doch schon wieder total affig, als wenn fdsonnes Ansatz kompletter Schwachsinn wäre. Wenn die, die ihn hier anpampen und für Ahnunglos erklären nur halb so offen mit Sichtweise umgehen würden, wie sie es für gewöhnlich von anderen verlangen, hätte sie gesagt:"Kann sein, dass hUMA kurzfristig nichts bringt". aber nein es wird auf seiner Meinung rum gedroschen weil die nicht passt.

 

[Mondrial]

Also darfst du, und ein paar andere hier, die Meinung abgeben, ich aber nicht? Sorry, aber was soll das?

Du unterstellst mir, ich würde deine Meinung nicht akzeptieren? Kannst du diese Unterstellung belegen(wenn du das schon von anderen Usern forderst)?

Ich habe dich lediglich darauf hingewiesen, dass deine Sichtweise altbacken sein könnte und ein Abschätzen des Vorteils von hUMA dadurch schwierig wird. Aktuell kann außer Programmierern niemand wirklich abschätzen was hUMA letztendlich bringt und was nötig ist, damit AMD überhaupt davon profitiert.

 

[why_me]

@fsdonne: Es erwartet doch auch niemand die Leistung einer 7770 oder höher von einer APU (außer anscheinend du), es ging doch von Anfang an darum, wie die Leistung der iGPU von Kaveri erhöht werden kann, ohne das der RAM limitiert. Den Ramtakt noch weiter erhöhen kann man nicht und DDR4/GDDR5 gibt es noch nicht.

Was bleibt also übrig um den Flaschenhals RAM zu beseitigen?
Einen weiteren Speicherkanal: vlt. ist das die Änderung von FM2+? wobei dann die Frage bleibt, ob die Pins der CPU dafür überhaupt ausreichen und wie es mit FM2 CPUs aussieht, die ja kompatibel sein sollen.

Und die andere Möglichkeit ist eben Huma und damit weniger auf dem RAM zugreifen zu müssen. Das dabei keine tausendprozentige Leistungssteigerung herauskommt ist doch von vorneherein klar. Vlt bringt es auch überhaupt nichts. Wer kann das aktuell überhaupt sagen?
Aber lassen wir es 15% sein und dazu noch das komplette ausreizen von DDR3 2133, dann kann die iGPU nochmal ein gutes Stückchen drauf legen und so die Zeit bis DDR4/GDDR5 im Desktop angekommen ist überbrücken und den Abstand zu Intel ausbauen.

Bringt es überhaupt keine Leistung, wird die iGPU von Kaverie auch kaum schneller ausfallen als die des 6800k (zumindest bei Spielen), da der Flaschenhals RAM die Leistung limitiert. Evlt ist GCN etwas effizienter, aber an den Ramzugriffen sollte das eher wenig ändern.

Naja, in ein Paar Monaten wissen wir ja mehr

 

[fdsonne]

Du unterstellst mir, ich würde deine Meinung nicht akzeptieren? Kannst du diese Unterstellung belegen(wenn du das schon von anderen Usern forderst)?

Ich habe dich lediglich darauf hingewiesen, dass deine Sichtweise altbacken sein könnte und ein Abschätzen des Vorteils von hUMA dadurch schwierig wird. Aktuell kann außer Programmierern niemand wirklich abschätzen was hUMA letztendlich bringt und was nötig ist, damit AMD überhaupt davon profitiert.

Das hab ich ein klein wenig anders aufgefasst. Denn wenn ich mit einer Frage nach dem Resultat die Diskusion erweitere, aber nur ein simples, "Meinst du nicht, dass man da einfach abwarten muss?" zu lesen bekomme, ohne das überhaupt auf die Einführung meiner Zweifel eingegangen wird, stellt sich mehr doch ernsthaft die Frage nach der Akzeptanz

Aber wieso altbacken? Wie ich schon schrieb, sehe ich AMD nicht in der Marktlage, an der Art und Weise der Softwareindustrie signifikant und vor allem schnell was zu ändern. Also entweder das Feature taugt und bringt effektiv Punkte, oder es bewirkt im Endeffekt fast nix... In beiden Fällen macht wohl die Softwareindustrie weiter wie bisher. Ein Indiz dafür könnte sein, das der allgemeine Support, was GPUs generell angeht, außer bei Games und einiger Profisoftware eher mau ausschaut. Allgemeine Browser/Flash oder auch Videobeschleunigung gabs auch vorher schon...
Aller Vermutung nach schaut es also vollends danach aus, das die Software weiter macht, wie bisher und altbacken wohl auf einige Zeit noch top Aktuell sein wird.

@fsdonne: Es erwartet doch auch niemand die Leistung einer 7770 oder höher von einer APU (außer anscheinend du), es ging doch von Anfang an darum, wie die Leistung der iGPU von Kaveri erhöht werden kann, ohne das der RAM limitiert. Den Ramtakt noch weiter erhöhen kann man nicht und DDR4/GDDR5 gibt es noch nicht.

Wo erwarte ich das?
Leistung erhöhst du generell wie so oft am einfachsten mit mehr Takt und/oder mehr Ausführungseinheiten. Die Bandbreite selbst ist wichtig, keine Frage, aber nun auch nicht sooo exorbitant stark limitierend, das die nahestehendste Leistungssteigerung gar nix bewirken würde. Denn bei gleicher Bandbreite scheinen die APUs dennoch recht gut auf OC zu reagieren.
Also das Kaveri schneller wird, als die aktuellen Umsetzungen, dürfte mit oder auch ohne hUMA vollkommen außer Frage stehen... Wie schnell genau? Spielt (für diese Diskusion) keine Rolle.

Was bleibt also übrig um den Flaschenhals RAM zu beseitigen?
Einen weiteren Speicherkanal: vlt. ist das die Änderung von FM2+? wobei dann die Frage bleibt, ob die Pins der CPU dafür überhaupt ausreichen und wie es mit FM2 CPUs aussieht, die ja kompatibel sein sollen.

Und die andere Möglichkeit ist eben Huma und damit weniger auf dem RAM zugreifen zu müssen. Das dabei keine tausendprozentige Leistungssteigerung herauskommt ist doch von vorneherein klar. Vlt bringt es auch überhaupt nichts. Wer kann das aktuell überhaupt sagen?
Aber lassen wir es 15% sein und dazu noch das komplette ausreizen von DDR3 2133, dann kann die iGPU nochmal ein gutes Stückchen drauf legen und so die Zeit bis DDR4/GDDR5 im Desktop angekommen ist überbrücken und den Abstand zu Intel ausbauen.

Bringt es überhaupt keine Leistung, wird die iGPU von Kaverie auch kaum schneller ausfallen als die des 6800k (zumindest bei Spielen), da der Flaschenhals RAM die Leistung limitiert. Evlt ist GCN etwas effizienter, aber an den Ramzugriffen sollte das eher wenig ändern.

Wie schon gesagt wurde, erhöht sich ja nicht die Bandbreite selbst. Sondern es bleibt unterm Strich etwas mehr Bandbreite für die GPU nutzbar. Aber auch nur dann, wenn diese Technik eben quasi unnötig verschenkte Bandbreite aufgrund von unnötig umgeschobenen Daten frei machen kann. Und hier setzt meine Argumentation an. Wenn nix zum freimachen da ist, kann auch nix freigemacht werden. Auch mit hUMA wird die APU Lösung ganz ordentlich an der Bandbreite hängen. Was aber im allgemeinen Bandbreitenbedarf liegt, nicht weil man heute Daten umkopiert, und dies dann nicht mehr machen muss. Und A) geht im Schnitt scheinbar nur ein Bruchteil der Bandbreite für diese Transfers drauf, B) scheinen diese Transfers auch eher initial aufzutreten (Spielstart, Mapwechsel usw.) sowie C) haben auch aktuelle APU Lösungen die gleiche Bandbreite nutzbar, wenn die Daten einmal im VRAM Bereich drin sind. -> was den Performanceeffekt gegen Null rutschen lässt. -> bleibt unterm Strich nur das übrig, was GCN bringt und was der womöglich höhere Takt rausholt. Sowie ggf. noch ein Stück weit die womöglich bessere CPU Leistung.


Nach aller Theorie nun, was soll da am Ende nun groß bei rum kommen?
Das frage ich mich echt ernsthaft.

 

[Mondrial]

Ein Indiz dafür könnte sein, das der allgemeine Support, was GPUs generell angeht, außer bei Games und einiger Profisoftware eher mau ausschaut.

Und genau das meine ich mit altbacken

AMD will u.A. mit hUMA die Nutzung der GPU vereinfachen, so dass der der Programmierer nicht mehr darüber nachdenken muss wie er die GPU nun einbindet und wie er die Daten dahin bekommt. Was das bringen kann, kann aktuell nur ein Programmierer abschätzen...von daher abwarten.

 

[mr.dude]

Zum ersten bezog ich mich im allgemeinen auf APUs... Wie sie heute zu sehen sind, oder siehst du irgendwo, das ich explizit von der noch nicht erhältlichen Umsetzung mit hUMA sprach?

Und warum zitierst du mich dann? Ich sprach explizit von hUMA in Kaveri.

Es ist in der Theorie gut und schön, nur was nutzt die beste Theorie, wenn in der Praxis daraus kein (wirklicher) Vorteil entsteht?

Siehst du denn irgendwo, wie es in der Praxis ausschaut? Also ich sehe noch nichts davon. Und es würde mich doch stark wundern, wenn du mehr siehst.

Wie nun schon x mal erwähnt, halte ich den Bandbreitenbedarf für diese von dir angesprochenen Transfers für so gering, das diese nahezu gar nicht ins Gewicht fallen.

Und da denke ich liegst du einfach falsch. Soll ich dir mal verraten, warum sich Spieleentwickler wie Mark Cerny so begeistert über die PS4 geäussert haben? Genau, wegen dem gemeinsamen Adressraum für CPU und GPU. Gerade für Texturen bringt das ordentliche Vorteile.

"Game developers and other 3D rendering programs have wanted to use extremely large textures for a number of years and they’ve had to go through a lot of tricks to pack pieces of textures into smaller textures, or split the textures into smaller textures, because of problems with the legacy memory model… Today, a whole texture has to be locked down in physical memory before the GPU is allowed to touch any part of it. If the GPU is only going to touch a small part of it, you’d like to only bring those pages into physical memory and therefore be able to accommodate other large textures.

With a hUMA approach to 3D rendering, applications will be able to code much more naturally with large textures and yet not run out of physical memory, because only the real working set will be brought into physical memory."

Zur Veranschaulichung nochmal die Folien zu hUMA:

Post #11/#13, Schaffe stellt die Frage, du antwortest. Und ich fragte, was das Effektiv bringen soll...

Ich kann dir da trotzdem nicht weiterhelfen, wenn du zu anderen Sachverhalten abdriftest. Und PCIe hatte nun mal nichts mit dem Thema zu tun.

Das kleine Wörtchen "ich" scheint wohl untergegangen zu sein, in meinem Kommentar zur Leistung.

Das habe ich schon mitbekommen. Du lieferst aber keine nachvollziehbare Erklärung. Insofern halte ich einen so provozierend hingeworfenen Brocken einfach für Quatsch. Nicht jeder braucht Top-dGPUs, um vernünftig spielen zu können.

Wenn die, die ihn hier anpampen und für Ahnunglos erklären nur halb so offen mit Sichtweise umgehen würden, wie sie es für gewöhnlich von anderen verlangen, hätte sie gesagt:"Kann sein, dass hUMA kurzfristig nichts bringt".

Da sieht man wieder mal, wie voreingenommen und Anti-AMD(-User) du bist. OT71 hat es schon sehr gut auf den Punkt gebracht. Da brauchst du dich gar nicht bei fdsonne einzuschleimen. Niemand hat fdsonne als ahnungslos oder hUMA als definitiv erklärt. hUMA kann sich aber positiv auswirken. Mehr hat gar niemand gesagt. Und die Erklärungen dazu wurden nachvollziehbar aufgezeigt. Also wenn du schon so argumentierst, dann wäre es eher an fdsonne gelegen, einfach mal zu sagen, "kann sein, dass hUMA was bringt". Und nicht umgekehrt. Denn das Gegenteil hat gar niemand ausgeschlossen.

 

[fdsonne]

Und genau das meine ich mit altbacken

OK, dann vielleicht altbacken, aber dennoch noch top aktuell...
Aber warte halt ab... Ich denke, daran wird sich auf absehbare Zeit nicht viel ändern...
Gerade bei AMD Umsetzungen waren wie gesagt schon einige andere Sachen als "Vorteil" ersichtlich... Nur wurden diese Vorteile nicht ausgenutzt, auch nicht mit der Zeit...
Ich erinnere mich noch an die seinerzeit hochgelobte Anbindung der Speicher vom A64 im Vergleich zu Netburst oder auch Core2.
Oder an die nativen Quadcores von Phenom I im Vergleich zum Dual DIE Package des Core2Quad.
Oder an die VLIW5 Einheiten von R600 als Grafikkarte usw.
Beispiele gibts da noch ganz paar mehr... In keinem Fall scheint aber am Standpunkt die Zeit selbst was verbessert zu haben. Sondern wenn dann Weiterentwicklungen der Hardware auf schnellere Ausführungen

Und da denke ich liegst du einfach falsch. Soll ich dir mal verraten, warum sich Spieleentwickler wie Mark Cerny so begeistert über die PS4 geäussert haben? Genau, wegen dem gemeinsamen Adressraum für CPU und GPU. Gerade für Texturen bringt das ordentliche Vorteile.


Zur Veranschaulichung nochmal die Folien zu hUMA:

http://abload.de/img/small_hsa-slide-3m5uys.jpg

http://abload.de/img/small_hsa-slide-47yujq.jpg

Es bestreitet doch auch niemand, das der gemeinsame Speicherbereich irgendwie schlecht sein soll. Im Gegenteil...
Aber mir scheint der Performancevorteil, der hier mehrfach angesprochen wurde, nicht klar ersichtlich. Denn der bringt aus meiner Sicht nur dort etwas, wo eben ein Limit in der aktuellen Umsetzung zu sehen ist. Ebenso kann außer pauschaler Kritik niemand auch nur ansatzweise nachvollziehbare Argumente vorweisen.
Ein "Limit" in der aktuellen Umsetzung scheint wohl klar die Bandbreite... Nur bekommt man aus meiner Sicht eben nicht essentiel viel mehr Bandbreite frei, das dies ein merklicher (Leistungs)Vorteil werden könnte.
Und warum ich dies so sehe, zeigt mein anschauliches Beispiel mit viel schnellerer dedizierter GPU Hardware über nen künstlich erzeugten Flaschenhals in Form von weniger PCIe Bandbreite... Sowie meine Ausführungen zum Thema VRAM Speicherbelegung und deren Änderungsraten usw.

Fragen wir mal andersrum, kannst du konkrete Tests bennenen, wo man sieht, das das von dir angesprochene Transferieren von Daten aus dem RAM Bereich der CPU in den VRAM Bereich der GPU zu konkret benennbaren Nachteilen führt oder basiert deine Aussage nur auf theoretischer Natur?

Ich kann dir da trotzdem nicht weiterhelfen, wenn du zu anderen Sachverhalten abdriftest. Und PCIe hatte nun mal nichts mit dem Thema zu tun.

Das habe ich schon mitbekommen. Du lieferst aber keine nachvollziehbare Erklärung. Insofern halte ich einen so provozierend hingeworfenen Brocken einfach für Quatsch. Nicht jeder braucht Top-dGPUs, um vernünftig spielen zu können.

Wieso abdriften? PCIe ist der Bandbreitenflaschenhals einer dedizierten GPU Lösung, die sich exakt identisch einer aktuellen! APU Umsetzung ihre Daten über den System RAM bezieht.
Währe das von dir angesprochene Transferieren von Daten ein Problem, sollte sich doch eine deutlich schnellere dedizierte GPU Lösung bei weiterer Verknappung des Flaschenhalses wenigstens ansatzweise durch weniger Leistung bemerkbar machen. -> macht sie aber scheinbar nicht. Denn selbst bei 2x PCIe 3.0 (also ~1GB/sec Durchsatz) machen aktuelle HighEnd GPUs im Schnitt noch keine großen Performancesprünge nach unten.
Außer dieses Argument als "PCIe hatte nun mal nichts mit dem Thema zu tun" abzustempeln, kannst du es ja nichtmal ansatzweise sachlich entkräften. Beharrst aber dennoch auf dem Bandbreitenflaschenhals, der scheinbar essentiel durch Datentransfer von RAM und VRAM bei aktuellen APU Lösungen zum Problem sein soll. Warum auch immer, denn es ist ein leicher Widerspruch

 

[mr.dude]

Es bestreitet doch auch niemand, das der gemeinsame Speicherbereich irgendwie schlecht sein soll. Im Gegenteil...
Aber mir scheint der Performancevorteil, der hier mehrfach angesprochen wurde, nicht klar ersichtlich.

Welcher Performancevorteil? Wo hat jemand was von Performancevorteil gesagt? Nochmal, es ging um eventuelle Bandbreitenlimitierung durch Dual-Channel DDR3. Und dass hUMA helfen kann, dies zu entschärfen. Weil eben nicht ständig Daten vom CPU-Speicherbereich in den GPU-Speicherbereich kopiert werden müssen. Was im Moment viel Bandbreite des IMC/RAM kostet. Sondern es werden quasi nur Zeiger auf die jeweiligen Daten übergeben. Verrate mir doch mal, was im Moment so viel Bandbreite bei den iGPUs kostet, wenn es sich nicht um Texturdaten usw handeln soll. Was wird da die ganze Zeit transferiert?

Und warum ich dies so sehe, zeigt mein anschauliches Beispiel mit viel schnellerer dedizierter GPU Hardware über nen künstlich erzeugten Flaschenhals in Form von weniger PCIe Bandbreite...

Nein, das sagt uns überhaupt nichts. Denn erstens ist wie gesagt PCIe belanglos für die iGPU. Und zweitens besitzt VRAM <-> dGPU aktuell eine viel höhere Bandbreite als RAM <-> iGPU. Da sind die Grenzen für Limitierungen logischerweise auch ganz andere. Nur mal zum Vergleich, eine HD 7750 mit 512 GCN SPs besitzt eine Speicherbandbreite von 72 GB/s. Das ist mehr als das doppelte von Dual-Channel DDR3-2133 und fast das dreifache von dem, was ich momentan im Rechner habe, Dual-Channel DDR3-1600.

Fragen wir mal andersrum, kannst du konkrete Tests bennenen, wo man sieht, das das von dir angesprochene Transferieren von Daten aus dem RAM Bereich der CPU in den VRAM Bereich der GPU zu konkret benennbaren Nachteilen führt oder basiert deine Aussage nur auf theoretischer Natur?

Du kannst doch selbst mal eine Anwendung schreiben, wo du einen grösseren Speicherbereich erst kopierst oder nur einen Zeiger auf den Speicherbereich übergibst. Dann wirst du schon sehen, wo die Nachteile sind. In der Programmierung nennt man diese Parameterübergabe übrigens by-value vs by-reference. Einfach mal danach googeln. Da wirst du sicherlich bessere und ausführlichere Erklärungen finden, als ich das jetzt hier könnte. Vereinfacht ausgedrückt, ersteres kostet O(4) bzw O(8), je nachdem, ob 32-bit oder 64-bit System. Letzteres kostet O(N), wobei N für die Grösse des Speicherbereiches steht. Also eine Textur von zB 512x512 kostet bei 32-bit Farbtiefe O(1048576). Jetzt verständlicher, welcher "kleine" Unterschied mit und ohne hUMA existiert? Kurzum, hUMA kann Bandbreite (und damit auch Zeit) sparen und die Speichermenge reduzieren.

Wieso abdriften? PCIe ist der Bandbreitenflaschenhals einer dedizierten GPU Lösung

Wir reden aber nun mal nicht über dGPUs. Wir reden von Kaveri, also APUs bzw CPU+iGPU. Und bisher konnten CPU und iGPU zwar auf den gleichen physikalischen Speicher zugreifen, hatten trotzdem ihre eigenen Speicherbereiche, zwischen denen hin und her kopiert werden musste. Mit hUMA muss es das nun nicht mehr. Und das alles hat mit PCIe überhaupt nichts zu tun.

Sry, aber ich denke du befindest dich momentan auf dem Holzweg. Wenn du mir schon nicht glauben willst, dann lass zumindest PCIe mal komplett aussen vor und denke dann nochmal über den Sachverhalt nach.

 

[Powerplay]

bei uniform memory hatte ich was von mehr als 30% leistungsplus gelesen. Das war im bezug auf die PS4

 

[fdsonne]

Welcher Performancevorteil? Wo hat jemand was von Performancevorteil gesagt? Nochmal, es ging um eventuelle Bandbreitenlimitierung durch Dual-Channel DDR3. Und dass hUMA helfen kann, dies zu entschärfen. Weil eben nicht ständig Daten vom CPU-Speicherbereich in den GPU-Speicherbereich kopiert werden müssen. Was im Moment viel Bandbreite des IMC/RAM kostet. Sondern es werden quasi nur Zeiger auf die jeweiligen Daten übergeben. Verrate mir doch mal, was im Moment so viel Bandbreite bei den iGPUs kostet, wenn es sich nicht um Texturdaten usw handeln soll. Was wird da die ganze Zeit transferiert?

Welchen Performancevorteil? Na den, den du benannt hast!
http://www.hardwareluxx.de/communit...-zeigt-kaveri-aktion-962331.html#post20716550
Schau dir die Aussage nochmal an...
Auf die Frage, wie! hUMA die Leistung steigern kann, schreibst du, es kommt zum Wegfall des Datentransfers. Ergo entsteht ein (Performance)Vorteil. Oder etwa nicht?

Aber auch hier wieder die Frage, woher stammt die Aussage: "Weil eben nicht ständig Daten vom CPU-Speicherbereich in den GPU-Speicherbereich kopiert werden müssen. Was im Moment viel Bandbreite des IMC/RAM kostet."?
Auf welche konkreten Werte bezieht diese sich?
Wieviel ist "viel"?

Es macht für mich den Eindruck, als vermischt du hier zwei paar Schuhe... Es besteht ein himmelweiter Unterschied zwischen dem Bandbreitenbedarf der GPU beim Zugriff auf den Speicher wärend des Spielebetriebs (Ablegen von Bilddaten, Zugriff auf Texturen, ...) und dem Bandbreitenbedarf dediziert durch den von dir angesprochenen Transfer von Daten zwischen RAM und VRAM Bereich.
Denn ersteres ist fortwährend und immerdar, wärend das Spiel läuft. Letzteres kommt aber nur dann zum Vorschein, wenn auch Daten zum Transferieren vorhanden sind. Daten, die einmal transferiert wurden, sind abgehandelt und erzeugen an der Stelle auch keine Last mehr. Erst wenn "neue" Daten transferiert werden müssen, wird hier Bandbreite benötigt.
Diesen Unterschied scheinst du scheinbar vollkommen auszuklammern in deiner Argumentation... hUMA kann aber an der Stelle nur beim letzten Teil überhaupt ansetzen. Am Verhalten des ersten Punktes wird hUMA absolut gar nichts ändern können. Wenn ohne hUMA 10GB/sec dediziert für ersteren Part benötigt werden, werden diese 10GB/sec auch mit hUMA benötigt. Letzteres fällt zweifelsfrei raus. Aber letzteres tritt wie angesprochen eben nicht ständig und permanent auf. Deswegen ist ein Zusammenwürfeln dieser beiden Umstände in einem Topf auch nicht machbar. -> Und deswegen trenne ich hier.

Nein, das sagt uns überhaupt nichts. Denn erstens ist wie gesagt PCIe belanglos für die iGPU. Und zweitens besitzt VRAM <-> dGPU aktuell eine viel höhere Bandbreite als RAM <-> iGPU. Da sind die Grenzen für Limitierungen logischerweise auch ganz andere. Nur mal zum Vergleich, eine HD 7750 mit 512 GCN SPs besitzt eine Speicherbandbreite von 72 GB/s. Das ist mehr als das doppelte von Dual-Channel DDR3-2133 und fast das dreifache von dem, was ich momentan im Rechner habe, Dual-Channel DDR3-1600.

Ich spreche auch nicht von PCIe bei ner iGPU. Sondern von PCIe als Flaschenhals bei ner dGPU um eben aufzuzeigen, das sehr geringe Bandbreiten für den Transfer von Daten benötigt werden und das bei deutlich schnellerer Hardware!
Schau doch weiter oben, du hast es selbst aufgezeigt, welchen Weg die Daten nehmen...
1) dGPU: HDD/SDD <--(CPU)--> RAM --(PCIe)--> VRAM <----> dGPU
2) iGPU heute: HDD/SDD <--(CPU)--> RAM --> VRAM <----> iGPU"
3) iGPU morgen: HDD/SDD <--(CPU)--> RAM <----> iGPU
Ich habe die entsprechenden Stellen markiert. Am Verfahren, wo die Daten aktuell! lang wandern, gibt es keinen Unterschied ob nun APU oder dedizierte GPU.
1) Also werden bei der dedizierten GPU die Daten aus dem RAM, über den künstlich verängten PCIe Slot in den VRAM übertragen.
2) Wärend eine aktuelle APU die Daten aus dem RAM, in einen seperaten Bereich des selben Speichers überträgt.
3) Was schlussendlich bei der hUMA Umsetzung wegfallen wird.
Und ich habe dazu grün markiert, was aktuell die Speicherbandbreite wegfrisst. Sowohl bei dGPU, iGPU aktuell und auch in Zukunft!
Wie man schön sieht, grün ist in allen drei Szenarien vorhanden. Wärend rot im dritten folgerichtig rausfällt.

Du kannst doch selbst mal eine Anwendung schreiben, wo du einen grösseren Speicherbereich erst kopierst oder nur einen Zeiger auf den Speicherbereich übergibst. Dann wirst du schon sehen, wo die Nachteile sind. In der Programmierung nennt man diese Parameterübergabe übrigens by-value vs by-reference. Einfach mal danach googeln. Da wirst du sicherlich bessere und ausführlichere Erklärungen finden, als ich das jetzt hier könnte. Vereinfacht ausgedrückt, ersteres kostet O(4) bzw O(8), je nachdem, ob 32-bit oder 64-bit System. Letzteres kostet O(N), wobei N für die Grösse des Speicherbereiches steht. Also eine Textur von zB 512x512 kostet bei 32-bit Farbtiefe O(1048576). Jetzt verständlicher, welcher "kleine" Unterschied mit und ohne hUMA existiert? Kurzum, hUMA kann Bandbreite (und damit auch Zeit) sparen und die Speichermenge reduzieren.

Wofür brauchen wir künstlich geschönte Werte?
Ich denke wir sprechen vom Gesamtergebnis?
Das ist wie, wenn ich die Bandbreite von SATAI vs. SATAIII messen würde und im Fazit die Aussage bringt, letzteres ist perse deutlich schneller. Theoretisch ja, praktisch?

Wir reden aber nun mal nicht über dGPUs. Wir reden von Kaveri, also APUs bzw CPU+iGPU. Und bisher konnten CPU und iGPU zwar auf den gleichen physikalischen Speicher zugreifen, hatten trotzdem ihre eigenen Speicherbereiche, zwischen denen hin und her kopiert werden musste. Mit hUMA muss es das nun nicht mehr. Und das alles hat mit PCIe überhaupt nichts zu tun.

Das was bei der aktuellen APU Umsetzung im selben Speicher zwischen RAM und VRAM Bereich übertragen wird, wird bei der dGPU Lösung über den PCIe Bus übertragen... Da wir keine Möglichkeit haben, diese Datenübertragung bei aktuellen APUs mit Werten zu belegen, bleibt also nur das Messen an dedizierten GPUs. Und dort ist eben PCIe der Flaschenhals. Da wir aber hier eben den Flaschenhals veringern können, können wir auch Rückschlüsse über die benötigte Bandbreite ziehen. Warum versuchst du dies gekonnt auszublenden?

 

[why_me]

Hast du einen Link zu dem Test mit PCIe 2x?

 

[unl34shed]

Wofür brauchen wir künstlich geschönte Werte?
Ich denke wir sprechen vom Gesamtergebnis?
Das ist wie, wenn ich die Bandbreite von SATAI vs. SATAIII messen würde und im Fazit die Aussage bringt, letzteres ist perse deutlich schneller. Theoretisch ja, praktisch?

Welche Praxis? Huma gibt es offiziell noch nicht

Das was bei der aktuellen APU Umsetzung im selben Speicher zwischen RAM und VRAM Bereich übertragen wird, wird bei der dGPU Lösung über den PCIe Bus übertragen... Da wir keine Möglichkeit haben, diese Datenübertragung bei aktuellen APUs mit Werten zu belegen, bleibt also nur das Messen an dedizierten GPUs. Und dort ist eben PCIe der Flaschenhals. Da wir aber hier eben den Flaschenhals veringern können, können wir auch Rückschlüsse über die benötigte Bandbreite ziehen. Warum versuchst du dies gekonnt auszublenden?

Zu deinem Flaschenhals:
AMD Radeon HD 5870 PCI-Express Scaling Review | techPowerUp
Sehr Spieleabhängig, aber meist reicht PCIe2.0 1x nicht mehr Sprich es werden zwischen 1 und 2 GB/s gebraucht.
Oder mit anderen Worten gut. 10% der Bandbreite von Richland dürfte flöten gehen.
Oder sind es 20%, muss ja gelesen und geschrieben werden...

 

[mr.dude]

Welchen Performancevorteil? Na den, den du benannt hast!
http://www.hardwareluxx.de/communit...-zeigt-kaveri-aktion-962331.html#post20716550
Schau dir die Aussage nochmal an...
Auf die Frage, wie! hUMA die Leistung steigern kann, schreibst du, es kommt zum Wegfall des Datentransfers. Ergo entsteht ein (Performance)Vorteil. Oder etwa nicht?

Lies dir bitte die Diskussion von Beginn an durch. Schaffe sprach die Limitierung durch den Speicher an. Und natürlich kann es Leistungsunterschiede zwischen Limitierung und Nichtlimitierung geben. Es hat aber keiner gesagt, dass durch hUMA grundsätzlich ein Performancevorteil entsteht. Die theoretisch mögliche Performance wird immer noch von der Architektur und deren Recheneinheiten bestimmt. Mal davon abgesehen verstehe ich nicht, worauf du mit dieser Wortklauberei hinaus willst.

Aber auch hier wieder die Frage, woher stammt die Aussage: "Weil eben nicht ständig Daten vom CPU-Speicherbereich in den GPU-Speicherbereich kopiert werden müssen. Was im Moment viel Bandbreite des IMC/RAM kostet."?
Auf welche konkreten Werte bezieht diese sich?
Wieviel ist "viel"?

Viel ist so viel, dass Dual-Channel DDR3 bei Kaveri womöglich zum limitierenden Faktor wird. Beantworte erst mal meine Frage, dann können wir über deine reden.

Es macht für mich den Eindruck, als vermischt du hier zwei paar Schuhe... Es besteht ein himmelweiter Unterschied zwischen dem Bandbreitenbedarf der GPU beim Zugriff auf den Speicher wärend des Spielebetriebs (Ablegen von Bilddaten, Zugriff auf Texturen, ...) und dem Bandbreitenbedarf dediziert durch den von dir angesprochenen Transfer von Daten zwischen RAM und VRAM Bereich.

Nein, jetzt vermischst du wieder zwei Sachen. Was die GPU mit den Daten letztendlich macht, darüber habe ich gar nichts gesagt. Das ändert ja auch nichts daran, dass ein Bandbreitenbedarf von CPU-Speicher zu GPU-Speicher momentan vorhanden ist. Wie viel es konkret ausmacht, lässt sich natürlich schlecht bei APUs ermitteln. Wegreden kann man es aber nicht.

Denn ersteres ist fortwährend und immerdar, wärend das Spiel läuft. Letzteres kommt aber nur dann zum Vorschein, wenn auch Daten zum Transferieren vorhanden sind. Daten, die einmal transferiert wurden, sind abgehandelt und erzeugen an der Stelle auch keine Last mehr. Erst wenn "neue" Daten transferiert werden müssen, wird hier Bandbreite benötigt.

Ja, und das geschieht öfter, als dir anscheinend bewusst ist. Oder glaubst, da wird nur alle halbe Stunde mal was nachgeladen, wenn man im nächsten Level ist?

Diesen Unterschied scheinst du scheinbar vollkommen auszuklammern in deiner Argumentation...

Nein. Oder habe ich gesagt, dass hUMA den Bandbreitenbedarf auf Null reduziert?

Ich spreche auch nicht von PCIe bei ner iGPU. Sondern von PCIe als Flaschenhals bei ner dGPU ...

Nochmal, was soll uns das konkret zeigen? Bezogen auf Trinity/Richland vs Kaveri herzlich wenig. Eine APU besitzt eine andere Infrastruktur. Insofern halte ich solche Vergleiche nicht für zielführend. Irgendwie habe ich das Gefühl, dass du völlig am Thema vorbeiredest. Du hörst dich so an, als willst du mit allen Mitteln beweisen, dass der Bandbreitenbedarf auf GPU-Seite höher ist als auf CPU-Seite. Wo ich mich frage, hat denn jemand etwas Gegenteiliges behauptet? Ich wüsste nicht wo. Nochmal, das Thema ist, ob Dual-Channel DDR3 zum Flaschenhals für Kaveri werden kann. Und selbst wenn hUMA nur 10-20% Entlastung bringt, dann wäre schon einiges gewonnen bei 33% mehr SPs.

 

[fdsonne]

@why_me
AnandTech | The Radeon HD 7970 Reprise: PCIe Bandwidth, Overclocking, & The State Of Anti-Aliasing

Welche Praxis? Huma gibt es offiziell noch nicht

...

Zu deinem Flaschenhals:
AMD Radeon HD 5870 PCI-Express Scaling Review | techPowerUp
Sehr Spieleabhängig, aber meist reicht PCIe2.0 1x nicht mehr Sprich es werden zwischen 1 und 2 GB/s gebraucht.
Oder mit anderen Worten gut. 10% der Bandbreite von Richland dürfte flöten gehen.
Oder sind es 20%, muss ja gelesen und geschrieben werden...

Darum gehts ja, klar gibt es diesen noch nicht. Dennoch wird hier spekuliert, wie so ziemlich vor jedem Release von irgendwelcher neuen Hardware
Ich denke, der Vergleich zu SATA bringts da ziemlich genau. Denn dort tritt das gleiche Verhalten in Kraft. Auf dem Papier ein Vorteil. In der Praxis natürlich auch ein Stück weit. Nur nutzt einem das nix. Den Transfer zwischen HDD und wem auch immer, wird nur unwesentlich beschleunigt.

Zum anderen, wie oben verlinkt. Spieleabhänigig in der Tat, aber im Mittel reichen PCIe 3.0 2x bei ner aktuellen HighEnd GPU. Effektiv also 4x 2.0 oder 8x 1.x mit ~2GB/sec.
Da dies aber HighEnd GPUs sind, die APU Umsetzung aber nur nen Bruchteil deren Leistung bietet, bleibt weiterhin die Frage, ob nicht auch abermals weniger Bandbreite benötigt wird.
Aus meiner Sicht kommt also der Umstand des Datentransfers eher wenig(er) stark zum Tragen, als ihn hier mr.dude sehen möchte...
Dazu kommt, das die GPU nur über PCIe angebunden ist. Wärend dies bei der APU eben nicht so ist. Auf diesen Umstand pocht mr.dude ja ebenso Heist also, es ist dazu noch unklar, was darüber hinaus im Datenstrom durch den PCIe Slot noch durch anderweitige Kommunikation verbrannt wird, der bei ner APU Umsetzung aber anders läuft.
Also in Summe minimum zwei Fakten, die über den PCIe Slot bei ner dGPU laufen, bei ner APU aber nicht. Und dennoch ist der Bandbreitenbedarf vergleichsweise gering...

Lies dir bitte die Diskussion von Beginn an durch. Schaffe sprach die Limitierung durch den Speicher an. Und natürlich kann es Leistungsunterschiede zwischen Limitierung und Nichtlimitierung geben. Es hat aber keiner gesagt, dass durch hUMA grundsätzlich ein Performancevorteil entsteht. Die theoretisch mögliche Performance wird immer noch von der Architektur und deren Recheneinheiten bestimmt. Mal davon abgesehen verstehe ich nicht, worauf du mit dieser Wortklauberei hinaus willst.

Viel ist so viel, dass Dual-Channel DDR3 bei Kaveri womöglich zum limitierenden Faktor wird. Beantworte erst mal meine Frage, dann können wir über deine reden.

Habe ich getan. Ändert aber an der Aussage nichts... Weder an Schaffes, noch an deiner sowie an meiner.
Und welche Frage?

Warum betreibe ich eigentlich "Wortklauberei"? Was sollen diese Vorwürfte schon wieder? Bleib doch einfach sachlich.
Du allein sprachst auf die Frage, wie die Performance gesteigert werden soll in Spielen von hUMA. Gesteigerte Performance ist ein Vorteil. Oder willst du jetzt hier ne neue Definition erfinden um dich rauszureden?
Die Sachlichkeit sinkt leider abermals enorm...

Nein, jetzt vermischst du wieder zwei Sachen. Was die GPU mit den Daten letztendlich macht, darüber habe ich gar nichts gesagt. Das ändert ja auch nichts daran, dass ein Bandbreitenbedarf von CPU-Speicher zu GPU-Speicher momentan vorhanden ist. Wie viel es konkret ausmacht, lässt sich natürlich schlecht bei APUs ermitteln. Wegreden kann man es aber nicht.

Ja, und das geschieht öfter, als dir anscheinend bewusst ist. Oder glaubst, da wird nur alle halbe Stunde mal was nachgeladen, wenn man im nächsten Level ist?

Auch hier, warum schon wieder rausreden?
Du sprachst mehrfach den Bandbreitenbedarf an und bringt im selben Absatz den Vorteil von hUMA ins Gespräch, weil wegfall des Datentransfers. Soweit klar...
Es geht doch nur darum, wieviel das effektiv ausmachen kann bzw. wird.
Und wenn es doch so schlecht bei APUs ermittelbar ist, wie stark der Umstand zum Tragen kommt, warum streubst du dich dann so sehr gegen den Vergleich mit dedizierter GPU Hardware? Das macht den Eindruck "Augen zu, wird schon werden"... Hilft der Spekulation aber sogar nicht weiter

Und ja, was ist öfters?
Was ich glaube, spielt doch keine Rolle für diese Spekulation. Sondern ich versuche mit Benchmarks unter möglichst realen Bedingen aufzuzeigen, wie hoch der Bedarf an Bandbreite für diese Vorgänge wirklich ist.
Ich hätte ja definitiv kein Problem damit, wenn du mir unter Berücksichtigung der Sachlichkeit erklären kannst, was an meinem Ansatz falsch ist. Aber hier bringst du außer deiner gegenteiligen Behauptung gegen meinen Ansatz nichts, was verwertbar ist. Dennoch brinst du keine Werte, keine belegbaren Aussagen, nichts außer pure leere Behauptungen mit scheinbar pauschal erstmal dem Gegenteil. Aber ich sag mal so, ich behaupte das Gegenteil Vielleicht nicht alle halbe Stunde... Aber definitiv nicht mehrfach pro Sekunde in enormen Mengen. Sonst müsste man das im der VRAM Belegung (absolute Menge wärend der Spielzeit) sehen. Nur schwankt diese nahezu gar nicht. Erhöht sich wenn dann Schrittweise... Und das nachweislich auch Szenenabhängig. Schnapp dir den Afterburner, pack diesen auf nen zweiten Monitor und beobachte wärend des Spielens das Diagramm. Und ja, das klappt sowohl mit APU als auch mit dGPU

Nein. Oder habe ich gesagt, dass hUMA den Bandbreitenbedarf auf Null reduziert?

Bandbreitenbedarf für den Datentransfer? Ja, das sagtest du... Oder was sollte der Rat mir ein eigenes Programm zu schreiben?

Nochmal, was soll uns das konkret zeigen? Bezogen auf Trinity/Richland vs Kaveri herzlich wenig. Eine APU besitzt eine andere Infrastruktur. Insofern halte ich solche Vergleiche nicht für zielführend. Irgendwie habe ich das Gefühl, dass du völlig am Thema vorbeiredest. Du hörst dich so an, als willst du mit allen Mitteln beweisen, dass der Bandbreitenbedarf auf GPU-Seite höher ist als auf CPU-Seite. Wo ich mich frage, hat denn jemand etwas Gegenteiliges behauptet? Ich wüsste nicht wo. Nochmal, das Thema ist, ob Dual-Channel DDR3 zum Flaschenhals für Kaveri werden kann. Und selbst wenn hUMA nur 10-20% Entlastung bringt, dann wäre schon einiges gewonnen bei 33% mehr SPs.

Du interpretierst zu viel...
Mir ist das doch vollkommen egal, wie hoch da wessen Anteil an Bandbreitenbedarf ist.
Es ging im Vergleich um das Aufzeigen der möglicherweise real benötigten Bandbreite für den von dir angesprochenen Transfer (und das bei deutlich schnellerer Hardware)
Da kannst du noch so oft wiederholen, das ne APU ne andere Infrastruktur aufzeigt. Das bestreitet niemand und ist auch so. Dennoch ist der Weg der Daten zwischen der dGPU und ner APU Lösung bei aktueller Umsetzung identisch. Siehe oben in Bund aufgezeigt. Also kann man auch am PCIe ansetzen und Messungen vornehmen... Zumindest was die aktuelle APU Lösung anbelangt. Aus diesen Werten kann man dann Rückschlüsse ziehen, was an Vorteil enstehen kann. Denn wo nix übertragen wird, kann auch nix eingespart werden. Und wo viel übertragen wird, bringt es effektiv auch viel.
Wie man also sieht, ist mir der Umstand durchaus bewusst. Es geht nur noch um das mögliche Endresultat in der Praxis...

 

[why_me]

Jetzt bleibt nur die Frage, in wie weit sich die 3GB der 7970 auf die Daten auswirken, die über PCIe geschaufelt werden müssen. Hier könnte es mit weniger VRAM schneller zu einem Flaschenhals kommen.

Und ob eine schnelle GPU viel daran ändert, wieviel daten über den PCIe Bus gesendet werden? Bei gleichen Einstellungen dürfte sich da nicht viel ändern, klar die GPU muss diese auch mit vernünftigen FPS darstellen können, aber hohe Texturqualität ist hohe Texturqualität.

Ein Bandbreitentest mit einer 7750 mit 1GB GDDR5(damit der RAM kein Flaschenhals bildet) wäre mal interessant und würde wohl auch eher den Bandbreitenbedarf wiederspiegeln, als solche VRAM Monster.

 

[Mick_Foley]

Die RAM-Größe dürft da nicht viel ausmachen: Ivy Bridge PCI-Express Scaling with HD 7970 and GTX 680 Review | techPowerUp Im Endeffekt dürfte der momentane Bandbreiten-Bedarf bei um die 5 GB/s liegen, wenn man sich die Leistung der beiden GPUs bei Pcie1.1 anguckt.

Und das Daten-Volumen dürfte mit großen GPUs größer werden, ansonsten würde eine potentere CPU ja nicht die FPS erhöhen

 

[fdsonne]

Jetzt bleibt nur die Frage, in wie weit sich die 3GB der 7970 auf die Daten auswirken, die über PCIe geschaufelt werden müssen. Hier könnte es mit weniger VRAM schneller zu einem Flaschenhals kommen.

Und ob eine schnelle GPU viel daran ändert, wieviel daten über den PCIe Bus gesendet werden? Bei gleichen Einstellungen dürfte sich da nicht viel ändern, klar die GPU muss diese auch mit vernünftigen FPS darstellen können, aber hohe Texturqualität ist hohe Texturqualität.

Die Menge dürfte wohl wenig(er) ausschlaggebend sein. Denke ich.
Sinnvollerweise sollte ein Vergleich natürlich ohne anliegendes VRAM Limit (absolute Größe) stattfinden. Schon aus dem Grund, dass ein Spielen im VRAM Limit so oder so nicht möglich ist...
Aber hier kommt eben der Punkt zum Tragen, den ich ansprach. Es werden nicht permantent riesige Datenmengen ständig hin und her geschaufelt. Sondern, das was bei ner aktuellen APU (oder auch dedizierten GPU) einmal im VRAM Bereich abgelegt ist, ist drin und findet Verwendung. Erst wenn sich die Szene ändert, müssen Daten nachgeschoben werden, eben die, die noch fehlen. Bis zu dem Punkt, das alle wichtigen Daten platz finden... Dieser Umstand fällt dann mit hUMA zweifelsfrei weg.
Praktischerweise sind mir persönlich nur ganz wenige Spiele bekannt, die hier riegeros bei einem Szenenwechsel auch den VRAM Datenbestand komplett umkrempeln. Allen Vorran ist Anno 1701 zu nennen. Schaut man auf eine Insel, werden die Daten in den VRAM geladen, schaut man auf eine andere Insel mit anderer Klimazone, gibt es nen Nachladeruckler und der Datenbestand ändert sich einmalig scheinbar vollständig. Schaut man wieder zurück auf die andere, ändert sich der Datenbestand abermals usw.
Das sind aber eher scheinbar ganz wenige Ausnahmetitel, die sowas veranschlagen. Normal ist es meiner Erfahrung nach eher so, das der Datenbestand möglichst lange im VRAM gehalten wird. Heist also, es kommt eher nur was hinzu... Aber rellativ zeitnah hat man den VRAM Bereich mit allen relevanten Daten gefüllt und es spielt sich Nachladerucklerfrei, ohne das der Bestand weiter und stark ansteigt. Und das auch beim nochmaligen Besuchen von Szenen, die man ewig vorher das letzte mal betrachtet hat (bei OpenWorld Rollenspielen ist das sehr gut zu beobachten!), gibt es keine Nachladeruckler, die auf einem großen Schub an neu zu transferierenden Daten schließen lassen würde.

Thema Texturen, ja, das stimmt wohl...
Die Texturen selbst sollten normal immer gleich groß sein... Der "Nachteil" der schnelleren Hardware ist aber, das diese eben durch mehr FPS auch mehr Zugriffe auf diesen Speicher tätigt. Bei gleichbleibender Texturgröße, aber mehr FPS (weil mehr Leistung) steigt folglich der Bandbreitenbedarf. -> Nur bekommt man diesen Umstand in keinster Weise mit hUMA irgendwie verbessert. Denn der Zugriff auf den Speicher bleibt exakt identisch.
Milchmädchenrechnung: 30 FPS = 30 Zugriffe, 60 FPS = 60 Zugriffe = doppelte Anzahl an Zugriffen = fast doppelter Bandbreitenbedarf.
Dennoch bleibt laut meiner Ansicht und Erfahrung nach der reine Bedarf für den Datentransfer zwischen RAM und VRAM Teil eben gleich (niedrig)... Denn bei der selben Szene greift man sowohl bei 30 FPS wie auch bei 60 FPS auf den gleichen Datenbestand zurück. Der nur einmalig für diese Szene vorhanden sein muss.


@Mick
interessante Zusammenfassung...
Heist also bei steigender Auflösung und somit steigender Anforderung an die GPU, sinkt der Bandbreitenbedarf des Slots...
Was also gleichsam auch heist, mit steigender Anforderung an die GPU werden immer weniger Daten über den Slot übertragen. (trotz gleichem Content auf dem Schirm)
-> passt 1A in meine These Denn scheinbar wird bei steigendem GPU Limit die Rechenzeit so lang, das die Zeit des Datentransfers über den Slot immer weniger ins Gewicht fällt. Bei deutlich langsamer Hardware dürfte/sollte dies somit noch deutlich weniger Stark ins Gewicht fallen!

 

[mr.dude]

Warum betreibe ich eigentlich "Wortklauberei"?
...
Du allein sprachst auf die Frage, wie die Performance gesteigert werden soll in Spielen von hUMA. Gesteigerte Performance ist ein Vorteil.

Siehst du, genau das ist Wortklauberei. Keiner hat "Performancevorteil" in den Mund genommen. Von "gesteigerter Performance" habe ich ebenso nichts gesagt. Woher soll ich wissen, was du damit bezwecken willst? Gib entweder die getätigten Aussagen korrekt wieder. Oder komm zum Punkt und erkläre uns, worauf du hinaus willst. Die Grundlage der Diskussion war jedenfalls, dass die Kaveri iGPU ihre theoretische Performance eventuell nicht ausspielen kann, weil sie zu stark vom Speicher gebremst wird. Es geht also nicht um einen Vorteil, sondern um einen eventuellen Nachteil bzw eine Limitierung, bedingt durch Dual-Channel DDR3.

Du sprachst mehrfach den Bandbreitenbedarf an und bringt im selben Absatz den Vorteil von hUMA ins Gespräch, weil wegfall des Datentransfers. Soweit klar...
Es geht doch nur darum, wieviel das effektiv ausmachen kann bzw. wird.

Nein, nicht für mich. Es ging erst mal nur darum, dass diese Funktionalität existiert. Nicht mehr und nicht weniger. Alles weitere hat ja bereits Mondrial gesagt. Das Rumreiten darauf, wie viel es nun ausmacht, kommt nur von dir. Was du gerne machen darfst. Nur frage ich mich dann, was du von mir willst? Und seltsam ist es obendrein, da du uns bisher in keinster Weise beantworten konntest, wie viel es denn nun ausmacht. Nenne doch mal ein paar Zahlen. Ich habe noch keine von dir gesehen.

Bandbreitenbedarf für den Datentransfer? Ja, das sagtest du... Oder was sollte der Rat mir ein eigenes Programm zu schreiben?

Nein, sagte ich nicht. Es ging darum, dass Leser verstehen, wie hUMA letztendlich funktioniert und was es bewirkt. Wenn du dort irgendwo liest, dass ich behauptet hätte, hUMA würde sämtlichen Bandbreitenbedarf auf Null reduzieren, dann hast du zu viel Phantasie. Sry, aber du bist jetzt unsachlich, nicht ich.

Dennoch ist der Weg der Daten zwischen der dGPU und ner APU Lösung bei aktueller Umsetzung identisch.

Zum x-ten mal, das halte ich trotzdem nicht zielführend für Kaveri. Und identisch ist es auch nicht. Wie gesagt, die Anbindung ist eine andere.

Es besteht ein himmelweiter Unterschied zwischen dem Bandbreitenbedarf der GPU beim Zugriff auf den Speicher wärend des Spielebetriebs (Ablegen von Bilddaten, Zugriff auf Texturen, ...) und dem Bandbreitenbedarf dediziert durch den von dir angesprochenen Transfer von Daten zwischen RAM und VRAM Bereich.
...
Mir ist das doch vollkommen egal, wie hoch da wessen Anteil an Bandbreitenbedarf ist.

Schon klar. Wenn es dir egal wäre, wieso fängst du dann überhaupt mit der GPU an, anstatt lediglich den CPU-Anteil zu betrachten und mal ein paar Werte zu bringen? Mittlerweile kann ich deine Aussagen nicht mehr nachvollziehen. Du redest zu wirr. Du hast dich von Anfang an in etwas reingesteigert und versuchst nun, dir alles irgendwie zurecht zu biegen. Denn das hUMA NICHTS bringt, konntest du bisher nirgends erklären oder gar belegen. Und genau das müsstest du, um meinen Einwand zu entkräften.

Heist also bei steigender Auflösung und somit steigender Anforderung an die GPU, sinkt der Bandbreitenbedarf des Slots...
Was also gleichsam auch heist, mit steigender Anforderung an die GPU werden immer weniger Daten über den Slot übertragen. (trotz gleichem Content auf dem Schirm)

Ergibt Null Sinn und geht aus den Diagrammen auch gar nicht hervor. Schliesslich zeigen die Diagramme keine Datenvolumen, sondern Performance (FPS). Mehr FPS bedeutet definitiv nicht, dass weniger Daten pro Sekunde über PCIe wandern. Sie bleiben entweder gleich oder steigen. Und bei deutlich langsamerer GPU wandert das Verhältnis logischerweise mehr Richtung CPU.

 

[fdsonne]

ach ich gebs auf... Denk halt was du willst. Sachliche Gegenargumente bringst du ja doch nicht.