AMDs „Kaveri“-APU im Kurzvergleich

Nein, damals hatten wir eine diskussion, dass man bei 512 Shadern ins RAM limit fährt (siehe vergleich 7750 mit DDR3 und GDDR5). Damals haben wir gesagt, dass es theoretisch etwas bringen kann, wenn der Treiber selbständig huma einsetz, und wenn es nur 5% sind, es wäre letztendlich mehr Leistung. fdsonne hat sich aber immer auf "Huma und HSA gibt es nicht und wird es nie geben festgefahren" oder die argumente bis ins kleinste detail zerlegt und auf Kleinigkeiten herumgeritten..... so sachen wie "man erhält mehr Bandbreite für die GPU" -> "nein, die Bandbreite bleibt gleich". Klar war die aussage falsch, aber man konnte erkennen, was gemeint war, hat ihn nicht interessiert.....

Ich weis zwar nicht, warum er mir da jetzt einen strick draus drehen will, einen vergleich zwischen kaveri und einer 7750 mit DDR3 habe ich noch nicht gesehen (gibts da schon was?). Fraglich bleibt auch, ob so etwas mit einem späteren Treiber vielleicht nachgeliefert wird, oder auch nicht, es ging ja nur um die Theorie. Es wurde auch gesagt, dass, falls es was bringen sollte, niemand weiß, wie viel es bringt.

Wie gesagt, es war abzusehen, dass es weniger Leistung als eine 7750GDDR5 wird, die DDR3 version liegt ca. 35% zurück, bei gleichem Takt. So viel Leistungsgewinn hat nie jemand ansatzweise erwähnt. Es standen immer nur maximal 5-10% im raum, wenn überhaupt. Was meiner Meinung nach auch durchaus noch kommen kann, den Crossfire treiber gibts ja auch noch nicht, oder?
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
fdsonne hat sich aber immer auf "Huma und HSA gibt es nicht und wird es nie geben festgefahren" oder die argumente bis ins kleinste detail zerlegt und auf Kleinigkeiten herumgeritten..... so sachen wie "man erhält mehr Bandbreite für die GPU" -> "nein, die Bandbreite bleibt gleich". Klar war die aussage falsch, aber man konnte erkennen, was gemeint war, hat ihn nicht interessiert.....

Das sind aber ziemlich böse Unterstellungen die du hier bringst... Von wegen hUMA gibt es nicht und wird es nie geben stammt nicht aus meiner Feder. Keine Ahnung wo du das her hast.
Ich sagte lediglich, das das HSA Konzept ohne Softwareunterstützung nicht aufgehen kann. Und das hUMA als Feature eben in Games nahezu nichts am Bandbreitenbedarf ändern wird, weil eben der Part, der durch hUMA wegfällt nur einen äußerst geringen Einfluss auf die Spieleleistung hat. Begründet durch den Vergleich einer dedizierten GPU Lösung mit dem Bandbreitenlimit beim PCIe Port. (wo die Daten ja beim Kopiervorgang durch müssen)

PS: und nein, ich will dir da bei weitem keinen Strick draus drehen, sondern viel eher aufzeigen, das man hier bei so einigen Aussagen, gerade pro AMD Argumente äußerst vorsichtig sein sollte. Denn abermals bestätigt sind, das von der schönen Folientheorie und den Postings so mancher Personen hier am Ende nichts über bleibt. Die Bandbreite limitiert genau so wie bei Richland. Tendenziell eher sogar mehr... (weil mehr Rohpower) Man müsste das ganze mal "Leistungsbereinigt" (sprich ähnliche Rohperformance Kaveri vs. Richland) dediziert gegentesten, aber ich behaupte auch dort, wird Kaveri ähnlich stark am RAM nuckeln wie auch ein Richland. hUMA in Games bringt ergo wenig bis nichts. Das Gegenteil wurde hier propagiert im Vorfeld und das war schlicht weg einfach falsch. -> nur war ich damals der Schwarzmaler und AMD Basher -> welche Einschätzung am Ende realistisch war, kann heute jederman selbst einsehen. Vielleicht packen sich ja die Leute hier mal an die eigene Nase :wink: wäre zumindest ein Anfang ;)

Was meiner Meinung nach auch durchaus noch kommen kann, den Crossfire treiber gibts ja auch noch nicht, oder?

Laut CB soll da nur ne äußerst maue Beta? Version vorliegen, die nicht sauber läuft... Auch schreibt CB, das AMD wohl die Empfehlung gibt, aktuell kein derartiges dGPU + APU Setup zu betreiben. Sondern entweder oder...
 
Zuletzt bearbeitet:
laut mr.dude nicht... Denn hUMA sorgt "nur" für den gemeinsamen Adressraum, sprich das Wegfallen der Kopieaktionen zwischen RAM und VRAM fällt weg. hUMA wirkt somit völlig Softwareunabhängig. (lässt sich auch nicht manuel (de)aktiveren) Die GPU legt ihre Daten im RAM ab und der bisherige Zwischenschritt, das eben die APU die Daten aus dem RAM Pool in den als VRAM deklarierten seperaten Bereich umschaufelt ist mit Kaveri hinfällig. Meine Rede war damals, das diese Kopieraktionen wenig bis keine Bandbreite effektiv verschlingen, weil einfach Daten, die einmal im VRAM liegen beim Gamen idR gleich bleiben (Texturdaten beispielsweise, was eine sehr große Masse des gesamten ausmacht) und wenn die Daten einmal umgeschaufelt sind, ist der Effekt gegen Null. Was man spielend mit ner dedizierten GPU (weil kein hUMA) und der Verringerung der PCIe Bandbreite austesten kann... Das wurde aufs äußerste Kritisiert, von wegen unsinnige Vergleiche und Schwarzmaler, Schlechtreder und AMD basher. Heute sehen wir, was hUMA effektiv für Games bringt -> nämlich unterm Strich sogut wie nichts. Richland nuckelt minimal weniger an der Speicherbandbreite, was man ebenso auf die weniger Rohpower zurückführen kann.

Was HSA als solches im Ganzen angeht, speziell in Anwendungen muss sich dann in der Tat zeigen, wie der Softwaremarkt mitzieht. Der Grundstein ist nun gelegt und die Softwareentwickler müssen mitziehen.
 
Hm, so wie ich es verstanden habe ist es richtig das sie beide (CPU/GPU auf dem DIE) auf den selben Adressraum zugreifen können, ohne extra etwas zwischenlagern zu müssen bzw. in den Adressraum des anderen zu kopieren. (Man erinnere sich z.b. an "Shared Memory" - also z.b. 2Gb wurden für die iGPU reserviert, diese waren dann aber für die CPU nicht mehr einsehbar und umgekehrt der Restliche Speicher für die CPU nicht mehr von der GPU - dieser Schritt entfällt).


Wenn die Entwickler es also richtig Programmieren, braucht die CPU nicht mehr von A (Adressraum / Speicher der CPU) nach B (Adressraum / Speicher der GPU) zu kopieren damit die GPU arbeiten kann - sie kann direkt darauf zugreifen, da beides direkt untereinander dynamisch geteilt wird.

Das muss aber eben auch erst so in die Programme implementiert werden... sonst leiten sie die GPU/CPU trotzdem an die entsprechenden Schritte zu unternehmen - auch wenn diese überhaupt nicht mehr notwendig wären.


Ergo: Es dürfte atm überhaupt kein Programm außer vielleicht ner Techdemo geben die das nutzt - wenn einer was hat, bitte her damit. :wink:


fdsonne hat aber insoweit recht das, wie hauptsächlich, Texturdaten im Vram der GPU stecken... also Daten die die CPU reichlich gen 0 interessieren...
 
Zuletzt bearbeitet:
Wenn die Entwickler es also richtig Programmieren, braucht die CPU nicht mehr von A (Adressraum / Speicher der CPU) nach B (Adressraum / Speicher der GPU) zu kopieren damit die GPU arbeiten kann - sie kann direkt darauf zugreifen, da beides direkt untereinander dynamisch geteilt wird.

Damit krankt hUMA allerdings dann an der selben Krankheit wie HSA --> Wer macht sich die Arbeit für etwas zu Programmieren, dass mit Glück 10% Marktanteil (Relevante APUs) hat. ;)
 
Naja, HSA benötigt quasi hUMA... ohne es wäre gar nicht die Basis vorhanden um HSA so durch die Transistoren zu jagen wie AMD das vor hat.

Es bleibt abzuwarten... wie immer.


Ich stelle es mir allerdings nicht schwer vor diesen Copy Schritt wegzulassen - sollte einfacher gehen als ihn zu schreiben. Ist ja immerhin nen Schritt weniger und beides greift auf exakt denselben Adressraum zu ---> einfacher gehts nicht.
 
was hUMA effektiv für Games bringt -> nämlich unterm Strich sogut wie nichts.

Mich würde interessieren, ob sich hUMA womöglich positiv auf die Framelatenzen von Kaveri gegenüber Richland ausgewirkt hat oder dies an der GCN Architektur liegt? Bei Techreport sind die Latenzen zum Vorgänger verbessert.

Im 3DCenter Post 140 gibts ein Preview, wie HSA funktioniert. Auch der Link in dem Post ist interessant. Es wird bei Golem gezeigt wie die Leistung von Kaveri bei höheren Taktraten zu verpuffen scheint.
 
Zuletzt bearbeitet:
Wann reicht denn HWLuxx nun endlich einen vollwertigen Test ein ?
 
Ruhig Blut. :wink:

Lg Marti (gesendet von unterwegs)
 
Hm, so wie ich es verstanden habe ist es richtig das sie beide (CPU/GPU auf dem DIE) auf den selben Adressraum zugreifen können, ohne extra etwas zwischenlagern zu müssen bzw. in den Adressraum des anderen zu kopieren. (Man erinnere sich z.b. an "Shared Memory" - also z.b. 2Gb wurden für die iGPU reserviert, diese waren dann aber für die CPU nicht mehr einsehbar und umgekehrt der Restliche Speicher für die CPU nicht mehr von der GPU - dieser Schritt entfällt).

Aktuell ist es ja so, das die Daten eben Wandern müssen... Was bei der APU reichlich sinnfrei ist, weil eben der Speicher der gleiche bleibt. Mit hUMA ändert sich das Konstrukt unter der Decke. Für die Programme selbst sieht das Konstrukt aber immernoch identisch aus. Da gibt dann vereinfach gesagt das Programm dann den "Wink" an die Hardware (über den Treiber), wo gesagt wird, lass mal bitte Daten xyz von RAM in VRAM wandern -> Kaveri macht hier keinen Kopiervorgang draus, sondern dreht nur simpel Zeiger um. Die Dauer des Ganzen schrumpft sozusagen gegen Null, wo Richland und älter, sowie alle dedizierte Karten eben Zeit benötigen.
Nur sind halt die Spiele, die hier die Bandbreite der APUs massiv überfordern ein Teil von Software, die idR Initial die Daten von RAM zu VRAM übertragen... -> einmal drin und gut ist. Das heist, die Nachladeruckler beim Start des Games dürften nun gegen Null schrumpfen (sofern man diese überhaupt allein messen kann). Nur das, was der APU fehlt wärend der Spielzeit, nämlich die Bandbreite wird weder mehr noch weniger. -> einzig in Szenen, wo nachgeladen werden muss (Kontextwechsel bei einem Spiel), also wo beispielsweise größere Datenmengen von beispielsweise Texturen neu in den VRAM geschrieben werden, profitiert hier Kaveri von hUMA. Und das völlig unabhängig jeglicher Anpassungen des Codes der Games. Eben genau den Punkt, den ich seinerzeit schon ansprach. hUMA bringt dort was, wo wirklich exesiv Bandbreite für die Kopiervorgänge drauf geht. Simples Beispiel: wenn ein Tool sowohl GPU als auch CPU für die Berechnung ranzieht und die Daten immer wieder je nach Berechnung von RAM in VRAM und zurück geschoben werden. Nur gehören Games da idR nicht dazu...

Was aber beispielsweise denkbar wäre, wenn Spiele in Zukunft vermehrt auf GPGPU setzen um einfach Aufgaben von der CPU auf die teilweise deutlich schnelleren GPU Einheiten zu übergeben -> hier setzt HSA und hUMA dann an und kann auch massiv punkten. Für mich persönlich ist das aber ein zweischneidiges Schwert. Wenn ich so oder so schon nur "wenig" GPU Performance habe (gegen die HighEnd dGPUs), ist es für mich auch ein absolutes NoGo diese GPU Performance noch weiter mit nicht "3D Berechnungen" zu quälen um den CPU Part zu entlasten. Das ist identisch mit PhysX, was NV ja immernoch fabriziert. PhysX per GPU auf ner Einsteiger/Mittelklasse kostet teils stark Performance in Form von FPS. Entlastet zwar die CPU ein Stück weit -> kostet unterm Strich aber mehr bei der 3D Berechnung, als es aus meiner Sicht bringt...
 
Jup, volle Zustimmung.

Quadchannel wäre da z.b. ne Idee um dem Bandbreitenproblem effektiv entgegen zu treten - aber dafür wären wieder 4 Ramslots und somit mehr Platz notwendig...

Was man auch machen könnte wäre, wenn man bspw. die igpu völlig die gpgpu Aufgaben erledigen lassen könnte während eine dezidierte GPU sich um die Grafik selbst kümmert.

(Edit: Analog dazu wie nVidia einem die Wahl bei SL! Systemen via Treiber überlässt. - für die Grafiksparte würde dann in kleinen Systemen schon eine moderate dez
GPU reichen wie bspw. Eine 260/260X die mittlerweile eigentlich auch ohne Probleme in ein LP Format gepackt werden könnte. )

Damit könnte man das ganze vertiefen.

Lg Marti (gesendet von unterwegs)
 
Zuletzt bearbeitet:
Jup, volle Zustimmung.

Quadchannel wäre da z.b. ne Idee um dem Bandbreitenproblem effektiv entgegen zu treten - aber dafür wären wieder 4 Ramslots und somit mehr Platz notwendig...

Was man auch machen könnte wäre, wenn man bspw. die igpu völlig die gpgpu Aufgaben erledigen lassen könnte während eine dezidierte GPU sich um die Grafik selbst kümmert.

(Edit: Analog dazu wie nVidia einem die Wahl bei SL! Systemen via Treiber überlässt. - für die Grafiksparte würde dann in kleinen Systemen schon eine moderate dez
GPU reichen wie bspw. Eine 260/260X die mittlerweile eigentlich auch ohne Probleme in ein LP Format gepackt werden könnte. )

Damit könnte man das ganze vertiefen.

Lg Marti (gesendet von unterwegs)

Gerüchten zur Folge, besitzt Kaveri einen Quadchannel MC
 
Joa, ich hab mal nen DIE Shot bearbeitet, da ich bisher noch nichts dazu gelesen hatte und nicht wusste ob das nur nen Hirngespinst bzw Wunschdenken ist...


amd-kaveri-die-shot10jix7.jpg



- das sieht im Vergleich zu nem Trinity DIE Shot nämlich sehr stark danach aus.



Hier nochmal nen Trinity DIE Shot im Vergleich:


amd-trinity-apu-die-scmrd9.jpg
 
Zuletzt bearbeitet:
Bist du dir sicher dass du die Striche richtig gezogen hast? Falls man die Controller mit nem horizontalen Strich teilt bleibt man bei 2 Controllern, nur sind die von Kaveri ein wenig größer da Kaveri aka "Berlin" im Server dann ECC können wird und sonst auch mit DC-DDR3 kommen wird.....Ich sehe einfach keinen Grund wieso Amd da für teuer Geld was einbauen soll und es dann nie aktiviert - klar gibts da etliche Knallköpfe wenn man sich die letzten Prozessoren so ansieht aber so verrückt kann doch keiner sein?
 
Ziemlich sicher, die beiden Kanäle sind bei Richland ebenfalls über einen Bus verbunden, bei Kaveri sind es 2 davon - sprich einer im oberen Bereich und einer im unteren.

Desweiteren ist er fast doppelt so groß - bei ECC Unterstützung wäre eine Fehlerkorrektur von nöten, nicht aber gleich nen doppelt so großer IMC. Korrigiert mich bitte wenn ich falsch liege... bin auch bloß nen Hardwaresüchtiger Laie. :fresse2:


€dit: Jetzt nach nochmaligem Hinsehen weiß ich was du meinst - könnte natürlich sein, aber somit wäre der IMC immernoch doppelt so groß, was die ECC Kontrolle eigentlich nicht benötigt.
 
Zuletzt bearbeitet:
Aus P3DNow

Dass AMD Größeres vor hat, lassen auch die vier Speicherkontroller vermuten, die im BKDG explizit erwähnt werden und somit Quad-Channel DDR3 ermöglichen würden. Aus Enthusiastensicht bleibt also zu hoffen, dass AMD nächstes Jahr mit Carrizo diese Option(en) wahrnimmt. Attraktiv genug sind die neuen Steamroller-Kerne allemal, weswegen man für „unmodernen” x86-Code, der die GPU-Kerne nicht nutzen kann, gerne etwas mehr hätte. Entsprechende Hex-Core-Chips würde sich auch noch etwas besser von den Jaguar-SoCs abgrenzen.
 
Wie gesagt, der IMC sieht komisch aus... nur bin ich darin nicht sehr bewandert.

Kann durchaus sein das meine Linien falsch gezogen sind, nur erscheint es mir so logisch.

Fakt ist das Kaveri interessant ist, nur warte ich erstmal ab. Zu dem momentanen Preis isses mir für ne Backup GPU zu teuer.

Evtl wirds bei mir auch nur nen 7770k - reicht an für sich für den E-Fall.

Lg Marti (gesendet von unterwegs)
 
Zuletzt bearbeitet:
Warum Backup? Ich würde mal die Crossfire treiber abwarten, evtl. läuft ja auch ein crossfire mit R280.

Mit Mantle sollen solche gespanne möglich sein, da man einfach nur noch sagt GPU mach, welche ist dann laut AMD egal.
 
Evtl wirds bei mir auch nur nen 7770k - reicht an für sich für den E-Fall.

Ich finde den A8 7600 am interessantesten, quasi der 5800k in gut mit fast der gleichen iGPU-Leistung wie der A10 7850k mit relativ niedrigen Verbrauch. :d Da würde mich auch mal Dual Graphic zu interessieren, hab Benchmarks von einer 240 mit dem A10 gesehen die 40 FPS auf Medium in bioshock lieferten. Nur so ein Balken sagt leider nichts übers Spielgefühl dabei aus.
 
Joa, der müsste dann 65W TDP haben oder? Da Gigabyte das cTDP Feature wieder aus F3 genommen hat ist mir ne 95W TDP CPU lieber, lieber mehr haben und nicht brauchen als permanent ins TDP Limit bei OC zu rennen.

Meinte übrigens nen 7700k :fresse:

Dual Graphics... hab ich ehrlich gesagt keine Meinung zu. Habe mit mühe noch ne HD 7870 mit originalem AMD PCB und Referenz kühler ergattert. Die wird solange verwendet bis sie es net mehr packt, dann landet sie an der Wand (aufgehängt, net geworfen. :shot: )

Lg Marti (gesendet von unterwegs)
 
Zuletzt bearbeitet:
Jo der mit 65w TDP. Mir geht OC inzwischen am aller Wertesten vorbei... :fresse2: Aber der A8 sieht, wie gesagt, ganz interessant aus, wenn man mal den Blick durch die Reviews schweifen lässt.
 
Eigentlich haste Recht, OC lohnt sich imo atm nur bei der NB.

Teste trotzdem gerne rum. Habe bisher aber echt außer WoT kein Spiel gefunden was nicht sehr gut auf dem 760k @Stock + HD7870 läuft. Nach wie vor beeindruckend für ne 60€ CPU. Nen Pentium (Edit: G 2120) + HD7870 kommt da net mit (Getestet haben wir Metro: LL und Anno 2070)

Lg Marti (gesendet von unterwegs)
 
Zuletzt bearbeitet:
Naja man kann ja auch untervolten, erfüllt auch den Spieltrieb und ist ja Quasi OC anders herum. :d Dass der Athlon da teilweise besser läuft glaube ich wohl, ist ja quasi auf i3 Level und der würde den Pentium auch in die Ecke stellen. :d Aber der Athlon gewinnt halt über den Preis. ;)

Mal gucken was kommt, warten hat zumindest den Vorteil, dass die Preise sinken werden und falls ich Kaveri ausprobieren will die Boards dann wahrscheinlicher schon das passende Bios haben. :d
 
Wenn nich und ich dann schon meinen Kaveri hab schreibst du mich einfach an, da schick ich dir leihweise den 760k mal rum. :wink:

Lg Marti (gesendet von unterwegs)
 
Die wird solange verwendet bis sie es net mehr packt, dann landet sie an der Wand (aufgehängt, net geworfen. :shot: )

Wie barbarisch :eek: ... zivilisierte Menschen hängen nur Mainboards an die Wand. :banana:
 
Zuletzt bearbeitet:
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