AMD Ryzen: Bremsen Nvidia-GPUs die Performance?

Was das Video außerdem nicht berücksichtigt (bzw. nur kurz zu Beginn einmal angeschnitten wurde), ist der Umstand, dass AMD-Karten bei Multi-GPU nach meinem aktuellen Wissensstand (der allerdings einen starken Bedarf nach Auffrischung hätte) unter DX12 sehr gut abschneiden, (ein altes) Ashes of the Singularity nur mal als Beispiel (es gibt noch ein paar andere Benchmarks im Netz, wenn auch nicht viele und nochmal etwas weniger verlässliche). Und ja, das ist ein durchaus zu beachtender Faktor, der selbst in 720p noch einen recht großen Unterschied machen könnte.

Btw.: Nur als Gedankenspiel-Beilage (ich spekuliere in diesem Post generell): Dieses Video ist im Zusammenhang zu dem oben geposteten eventuell auch interessant (ich kann da auch nur vermuten, verlässliche Daten oder ausreichend Hintergrundwissen für eine präzise Aussage stehen mir da auch nicht zur Verfügung):

Doch, das Crossfire-Scaling wird sehr wohl berücksichtigt. Selbst auf Intel-CPUs liegt das Crossfire-Scaling in modernen Spielen meist oberhalb der 90% (teils sprechen wir von fast 100%!), was in etwa dem Leistungsniveau einer GTX1080 entspricht in vielen Spielen. Jim hat mit seiner übertakteten GTX1070 versucht in etwa dasselbe Leistungsniveau zu erreichen, ich denke mehr als 5% liegt er da auch nicht daneben. Die Unterschiede lagen dann aber weit abseits vom Erwarteten. Ich müsste jetzt graben, aber in einem anderen Video wurde auch verdeutlicht, dass der Leistungsgewinn von einer 1070 zu einer 1080Ti (oder war's die Titan X [Pascal]?) unter Ryzen ebenfalls weit unter dem erwarteten lag (wieder Rise of the Tomb Raider).

Das gelinkte Video ist übrigens auch das, was ich ebenfalls als Quelle gelinkt habe. ;)
 
Doch, das Crossfire-Scaling wird sehr wohl berücksichtigt. Selbst auf Intel-CPUs liegt das Crossfire-Scaling in modernen Spielen meist oberhalb der 90% (teils sprechen wir von fast 100%!), was in etwa dem Leistungsniveau einer GTX1080 entspricht in vielen Spielen.

Unter DirectX 12? Auf gleicher Testbasis? AMD-GPUs können unter DX11 oder OpenGL auch zu 100 % ausgelastet sein und trotzdem unter DX12 oder Vulkan 20 Prozent oder teils sogar mehr (Doom, Vulkan vs OpenGL) zulegen. Das ist keine universell verlässliche Angabe! Und darauf bezieht sich auch der Skalierungsfaktor. Das kann zwischen DX11 und DX12 und nochmals DX11 MGPU vs DX12 MGPU und DX11 vs DX12 MGPU und DX11 MGPU vs DX12 variieren. Auf die losen Daten im Netz kann man sich nicht verlassen, die sind zu lückenhaft, zu alt, zu divers, nur auf DX11-Basis oder what-ever. Das ist genau der Faktor, den ich meine.

Er hätte das spezifisch selber für genau dieses Szenario testen müssen, um eine wirklich solide Aussage machen zu können. So ist da noch ein großer Unsicherheitsfaktor drin (MGPU, insbesondere unter DX12, bzw. tatsächliche CPU-Limitierung). Ich kann aber auch vollkommen verstehen, warum er das nicht gemacht hat, weil es eben ein Heidenaufwand ist.

EDIT:
Ich müsste jetzt graben, aber in einem anderen Video wurde auch verdeutlicht, dass der Leistungsgewinn von einer 1070 zu einer 1080Ti (oder war's die Titan X [Pascal]?) unter Ryzen ebenfalls weit unter dem erwarteten lag (wieder Rise of the Tomb Raider).

Das gelinkte Video ist übrigens auch das, was ich ebenfalls als Quelle gelinkt habe.

Das wären als Dreingabe sehr interessante Daten, dann könnte man zumindest eine GPU-Limitierung seitens Nvidia größtenteils ausschließen. Wenn sich das Ganze mit einer GTX 1080 Ti bestätigen ließe, hätte er einen guten Punkt. Besser noch wäre eine Vega-GPU und ein ihr ebenbürtiges Nvidia-Modell (welches auch immer das sein mag ;) )

Damn. Ninja'd. Aber ich hab's schöner gepostet! ;)

Gruß,
Phil
 
Zuletzt bearbeitet:
@Casurin
Hättest du das Video ernsthaft gesehen, wäre dein Post komplett unnütz, GigaThread und Warp-Scheduler werden erwähnt und sind verglichen zum AMD-Konstrukt vergleichsweise simpel aufgebaut, da sie lediglich die Command Queue Batches verarbeiten und verteilen müssen, statt eher den konstant "fließenden" Anweisungen wie bei AMD.
Tja- bitte lies dir zuerst nochmal deinen eigenen Post durch, dann schua dir nochmal das video an und dann lies nochmal meinen post.
Deine Asussage von wegen nvidia hätte keinen Scheduler ist faktisch falsch - daran gibts nichts zu rütteln.



Der InfinityFabric mag ein Flaschenhals für diverse Anwendungsfälle sein, lässt sich aber relativ leicht umgehen (und sollte demnach spürbarer in's Gewicht fallen durch übertakteten Arbeitsspeicher als dies bisher in Tests der Fall war) und ist potenziell nicht das einzige Problem beim nicht optimierten Treiber seitens nVidia. Stichwort Cache-Size-Unterschiede zu Intel und den bestehenden Optimierungen daraufhin, Compiler-Anpassungen die bisher vor allem auf Intel hin optimiert sind.
Man kann das problem umgehen - lustig wie du damit igentlich direkt meinen vorherigen post sogar bestätigst denn man kann ein problem nur umgehen wenn es ein Problem gibt.
Dies hat heir auch ncihts mit der Cache größe zu tun sondern rein dem relativ höheren delay der durch das IF auftritt. und während der sich durch schnellren RAM verkürzen lässt ist er dennoch vorhanden und hinderlich - vorallem da bissher bei den wenigsten boards schneller ram überhaupt läuft - und sich nochweniger dafür den teureren RAM kaufen.
 
Unter DirectX 12? Auf gleicher Testbasis? AMD-GPUs können unter DX11 oder OpenGL auch zu 100 % ausgelastet sein und trotzdem unter DX12 oder Vulkan 20 Prozent oder teils sogar mehr (Doom, Vulkan vs OpenGL) zulegen. Das ist keine universell verlässliche Angabe! Das kann zwischen DX11 und DX12 und nochmals DX11 MGPU vs DX12 MGPU und DX11 vs DX12 MGPU und DX11 MGPU vs DX12 variieren. Auf die losen Daten im Netz kann man sich nicht verlassen, die sind zu alt, zu divers, nur auf DX11-Basis oder what-ever. Das ist genau der Faktor, den ich meine.

Er hätte das spezifisch selber für genau dieses Szenario testen müssen, um eine wirklich solide Aussage machen zu können. So ist da noch ein großer Unsicherheitsfaktor drin (MGPU, bzw. tatsächliche CPU-Limitierung). Ich kann aber auch vollkommen verstehen, warum er das nicht gemacht hat, weil es eben ein Heidenaufwand ist.

Jetzt wo du es sagst, das war noch unter DX11, bisher ist Jims letztes Video das mir einzig bekannte Review, dass den mittlerweile funktionierenden DX12 Crossfire Support in RotTR getestet hat.

Zu DX11 gab es von HardOCP einen Vergleich der sich RotTR vornahm und eine Performance nur leicht unterhalb der GTX1080 bescheinigte: HARDOCP - Introduction - AMD Radeon RX 480 8GB CrossFire Review , leider ist deren anderes RX480 review nicht mit den gleichen Settings

Leider gab es keinerlei Nachtests, seitdem am 8. Juli 2016 anscheinend der DX12 Crossfire Support nachgepatcht wurde.
 
Zuletzt bearbeitet:
Tja- bitte lies dir zuerst nochmal deinen eigenen Post durch, dann schua dir nochmal das video an und dann lies nochmal meinen post.
Deine Asussage von wegen nvidia hätte keinen Scheduler ist faktisch falsch - daran gibts nichts zu rütteln.

Ich habe mich unpräzise bezüglich dem Entfernen des Hardware Schedulers ausgedrückt, Fakt bleibt, dass der Großteil des Schedulings von Hardware zu Software verschoben wurde und genau dies die Vor- und Nachteile der nVidia-Treiber-Performance ziemlich gut erklärt an aktuellen Beispielen.

Man kann das problem umgehen - lustig wie du damit igentlich direkt meinen vorherigen post sogar bestätigst denn man kann ein problem nur umgehen wenn es ein Problem gibt.
Dies hat heir auch ncihts mit der Cache größe zu tun sondern rein dem relativ höheren delay der durch das IF auftritt. und während der sich durch schnellren RAM verkürzen lässt ist er dennoch vorhanden und hinderlich - vorallem da bissher bei den wenigsten boards schneller ram überhaupt läuft - und sich nochweniger dafür den teureren RAM kaufen.

Ich wüsste nicht, dass ich den InfinityFabric nicht als Flaschenhals betitelt hätte, keine Ahnung wo du das daher hernimmst.

Und klar hat die Cache-Größe eine große Auswirkung auf die Performance, bei Ryzen haben wir doppelte Instruction Cache Größen für L1 und auch den doppelten L2 (alles pro Core). Würde man diesen effektiv nutzen, könnte die Performance theoretisch pro Core wesentlich besser aussehen als bei Broadwell-E. Siehe auch Ergebnisse in Cinebench die den Cache gerne ausnutzen und Ryzen sogar Rekorde brechen lassen die vorher vom 6950X gehalten wurden.

Und die Compiler-Anpassungen ignorierst du natürlich auch wieder weg, hauptsache nur versuchen Haare in der Suppe zu finden, gelle? ;)
 
Stimmt, man sollte besser nichts negatives über AMD produkte sagen egal ob es verdient ist oder nicht. Und nur negativ über Nvidia und Intel berichten.
Aber eben nur noch Positives über AMD, alle unzulänglichkeiten einfach totschweigen.

Du drehst mir die Worte im Mund um. :D
Ich habe nie behauptet es wäre schlecht Kritik zu üben, aber langsam sticht meiner Meinung nach eine unfaire Bewertung heraus.
 
Das wären als Dreingabe sehr interessante Daten, dann könnte man zumindest eine GPU-Limitierung seitens Nvidia größtenteils ausschließen. Wenn sich das Ganze mit einer GTX 1080 Ti bestätigen ließe, hätte er einen guten Punkt. Besser noch wäre eine Vega-GPU und ein ihr ebenbürtiges Nvidia-Modell (welches auch immer das sein mag ;) )

Leider gerade nicht auffindbar und für morgen muss ich auch noch ein Proposal vorbereiten, weshalb ich mich für heute leider ausklinken werde. Was mir aber noch eingefallen war, war der Test aus der C't, in welcher die Fury X unter 720p an der Titan X [Pascal] vorbeigezogen ist, sofern Ryzen als Vergleichsbasis unter DX12 verwendet wird: http://i.imgur.com/OjSIcgM.jpg
 
kobu - nein, der Trieber ordnet nur die Drawcalls - das Scheduling wird noch immer 100% in hardware gemacht - geht auch garnicht anders.
Bitte informiere dich zuerst mal darüber was die Begriffe die du heir zu verwenden veruschst Beschreiben.
Der scheduler wurde verkleinert und vereinfacht - aber er ist noch immer ein vollwertiger Scheduler der nun eben gewisse extras nichtmehr besitzt.
So whatte Fermi noch harware um unterschiedliche Threads ohne konflikte gleichzeitig auf dem selben SM laufen zu lassen und dies in Echtzeit zu regulieren.

Leider gerade nicht auffindbar und für morgen muss ich auch noch ein Proposal vorbereiten, weshalb ich mich für heute leider ausklinken werde. Was mir aber noch eingefallen war, war der Test aus der C't, in welcher die Fury X unter 720p an der Titan X [Pascal] vorbeigezogen ist, sofern Ryzen als Vergleichsbasis unter DX12 verwendet wird: http://i.imgur.com/OjSIcgM.jpg

wenn wir das so zusammenfassen.
RyZen hat mehr Kerne, mehr insgesammte Rechenleistung, größeren Cache - und dennoch sacken die FPS gewaltig ab wenn eine Anwendung auf schnelle kommunikation zwischen den kernen angewiesen ist.
Ergo - nicht die schuld von irgendwem anderen sondern AMD.

Wenn mann mit vielen Kernen wirbt aber diese dann zum Problem werden ist das nicht schuld der Anwendungen sondern der Hardware.
Die ursache ist AMDs Architektur. AMD propagiert doch immer das viele Kerne besser sind (Grundsätzlich ja auch richtig) und das diese auch genützt werden sollen. nur sieht man hier eben das dies bei synchronisations-kritischen Anwendungen zu gehörigen Problemen führen kann. unter Dx11 hat Nvidia hervorangende Treiber die die hardware gut zu nutzen wissen. Wenn dann aber die hardware slebst einen Strich durch die Rechnung macht gibts eben Probleme.
Man sieht dies auch deutlich daran das dieses Problem mit anderen CPU-Architekturen nicht auftritt. Weder bei Broadwell-E noch bei der AMD-FX-Serie - was wiederum klar aufzeigt das es ein Problem der Zen-Architektur ist.
 
kobu - nein, der Trieber ordnet nur die Drawcalls - das Scheduling wird noch immer 100% in hardware gemacht - geht auch garnicht anders.
Bitte informiere dich zuerst mal darüber was die Begriffe die du heir zu verwenden veruschst Beschreiben.
Der scheduler wurde verkleinert und vereinfacht - aber er ist noch immer ein vollwertiger Scheduler der nun eben gewisse extras nichtmehr besitzt.
So whatte Fermi noch harware um unterschiedliche Threads ohne konflikte gleichzeitig auf dem selben SM laufen zu lassen und dies in Echtzeit zu regulieren.

Denke wir haben hier in der Abstraktion etwas aneinander vorbei geredet. Was du jetzt gerade erwähnst ist natürlich vollkommen korrekt.

wenn wir das so zusammenfassen.
RyZen hat mehr Kerne, mehr insgesammte Rechenleistung, größeren Cache - und dennoch sacken die FPS gewaltig ab wenn eine Anwendung auf schnelle kommunikation zwischen den kernen angewiesen ist.
Ergo - nicht die schuld von irgendwem anderen sondern AMD.

Sehe ich nicht so, da das Problem hauptsächlich unter DX12 mit nVidia Treiber bei bestimmten Anwendungen zu sehen ist. Unter DirectX11 liegt die Performance angesichts der IPC und Taktung der Prozessoren ja zumeist im erwarteten Bereich oder lediglich minimal drunter.
Mal davon ab muss der größere Cache teils auch erst angesprochen werden, je nachdem wie kompiliert wurde. Ich denke das ganze Thema wird über die nächsten Monate noch ein paar Überraschungen für uns haben.

Jetzt bin ich zeitlich aber wirklich am Limit, das Proposal schreibt sich leider nicht von alleine, also gute Nacht!
 
Leider gerade nicht auffindbar und für morgen muss ich auch noch ein Proposal vorbereiten, weshalb ich mich für heute leider ausklinken werde. Was mir aber noch eingefallen war, war der Test aus der C't, in welcher die Fury X unter 720p an der Titan X [Pascal] vorbeigezogen ist, sofern Ryzen als Vergleichsbasis unter DX12 verwendet wird: http://i.imgur.com/OjSIcgM.jpg

Sowas ähnliches hab ich (teilweise, es gibt auch da noch ein paar Abweichungen) auch schon mit einem i7-6900K unter DX12 messen können (Print). Unter anderem in Forza Horizon und Gears of War 4. Und in der darauffolgenden Ausgabe auch in Battelfield 1. Da kann sich im (bei 720p und 25 % Auflösungsskalierung wirklich ziemlich voll greifenden) CPU-Limit eine R9 Fury X Stock auch gegen eine GTX 1080 OC behaupten aka diese teilweise schlagen.

Für mich persönlich ist das gute Abschneiden einer AMD-GPU unter DX12 mit einem Octocore(+) gegenüber einer Nvidia daher auch nicht vollkommen überraschend, wenngleich ich nicht den Grund dafür belegbar präzisieren kann. Von diesem Standpunkt aus ist MGPU unter DX12 aber nochmals ein Faktor, den ich einfach nicht konkret einschätzen kann, das Teufelszeugs (;) ) ist schon unter DX11 unberechenbar genug... Ich werd versuchen, da in Zukunft mal ein etwas mehr Aufmerksamkeit drauf zu legen, aber Multi-GPU ist grad zum Launch von Titeln eigentlich ein No-Go, weil reichlich fehleranfällig und aus Tester-Perspektive die sprichwörtliche Box der Pandora. Damit bürgt man sich selbst eine weitere Lage Komplexität auf, moderne Spiele sind da eh schon sehr vielschichtig, vorsichtig formuliert...

Aber ich hab schon ein paar mal geschrieben, dass ich das Thema auf dem Radar habe und in näherer Zukunft gern mal in einem (Print-)Artikel aufgreifen würde... vielleicht bietet sich eine Gelegenheit, wenn Vega erschienen und ein bisschen gereift ist, dann dürfte auch Ryzen die Kinderkrankheiten abgelegt haben. Das wäre sicher mal interessant und auch eine lohnenswerte Aufgabe für einen Tester – sucht mal nach einem umfassenden und aussagekräftigen, aktuellen sowie unabhängigen Artikel. Gibt's meines Wissens (noch) nicht – zumindest nicht im Netz.

Gruß,
Phil
 
Sehe ich nicht so, da das Problem hauptsächlich unter DX12 mit nVidia Treiber bei bestimmten Anwendungen zu sehen ist. Unter DirectX11 liegt die Performance angesichts der IPC und Taktung der Prozessoren ja zumeist im erwarteten Bereich oder lediglich minimal drunter.
Bei Dx11 und gtx 0180Ti/Titan X kann die GPU_Auslastung durchaus auf unter 70% fallen wie am beispiel Tombraider gut zu sehen ist - das mit Dx12 einwandfrei läuft.


Gute.
 
Gebt mal nicht soviel auf Benchmarks, seht euch identisch Aufgebaut laufende Systeme an mit evtl. schwächeren Gpu Leistung im Vergleich zu Nvidia und siehe da die AMD Leistung ist dennoch mindestens ebenbürtig. Beweis sind auch hier in Foren veröffentlichte, jedoch nicht von pcgames hardware durchgeführe tests.

Es lebe AMD, wer dennoch Intel kauft hat einfach nur die Werbe Pille geschluckt und könnte für einen viertel des Preises ein vergleichbares AMD System nutzen. Selbst schuld Leute, könnt aber dennoch stolzer Intel User sein, bei dem Preis würde ich mir das auch einreden.

Danke ans pc games Haus für die neuesten Berichte jeglicher Art

AMD Ryzen: X390-Chipsatz angeblich für 16-Kerner Snowy Owl
 
Zuletzt bearbeitet:
Es lebe AMD, wer dennoch Intel kauft hat einfach nur die Werbe Pille geschluckt und könnte für einen viertel des Preises ein vergleichbares AMD System nutzen. Selbst schuld Leute, könnt aber dennoch stolzer Intel User sein, bei dem Preis würde ich mir das auch einreden.

Es lebe die unabgeschlossenheit macher leute. :D
Es lebe eben nicht AMD, es lebe auch nicht Intel. Aber dafür sind leute ja zu engstirnig.

Aber nach deiner Aussage sind Leute die sich Intel Kaufen anscheinend nur zu blöd es besser zu wissen..

Aber huch!? Was ist das!?
Ja genau, es gibt genug Anwendungsfälle wo der AMD Ryzen absolute grütze ist, genauso wie es Anwendungsfälle gibt wo der Intel absolute grütze ist. Gibt sogar beispiele wo man AMD und Intel beide in die tonne treten kann.

Aber das es unterschiedliche Anwendungsfälle bei Nutzern geben kann kann ja mal sowas von nicht sein! Ahne halt, *******, gibt ja keine unterschiedlichen Anwendungsfälle, läuft bei jedem immer das selbe.

Und morgen werfe ich auch mein Smartphone weg, weil da ist ja ARM grütze drin, und nicht der super tolle Ryzen. Weil taugt ja nur AMD, alles andre ist nur in meiner vorstellung toll wegen der Werbepille die ich geschluckt habe. :wall:
 
Zurück