Baal Netbeck schrieb:
Darüber, dass ich es trotz (hoffentlich) verbesserter (Spiele)IPC, für unrealistisch halte, dass AMD mal eben die Leistung einer 5700XT verdoppelt....und das ohne eine 400W Karte daraus zu machen.
Kommt darauf an, wovon wir genau sprechen und welche Parameter man anlegt. Es ist nicht unrealistisch, dass AMD mit BigNavi die Leistung verdoppelt, es kommt aber auf die Szenarios an und da gibt es welche, bei denen es eher zutreffen kann und es gibt Szenarios wo es nicht zu treffen kann.
Man muss hier beachten, dass ein Workload nicht nur von der Engine als ganzes abhängt oder dem Treiber, sondern dass auch andere Faktoren wie Auflösung, Detailfülle und Co mit reinspielen und darüber auch bestimmen wie viele Daten wie anfallen.
Ob sich die »Leistung« verdoppelt - dank Takt, mehr CU und IPC-Steigerung - hängt von vielen Faktoren ab und es wird sich von Spiel zu Spiel unterscheiden und genau das ist hier mit ein Problem bei vielen Mutmaßungen, auch auf Twitter und Co.
Baal Netbeck schrieb:
Aber Rechenleistung muss irgendwo her kommen....und da sehe ich das Ziel(Erwartung der meisten Kommentare hier) die RTX 3080 zu schlagen nur als möglich an, wenn wirklich alles super läuft für AMD:
Du solltest dich in dem Fall nicht zu sehr auf die Rechenleistung »fixieren«. Theoretisch müsste eine RTX 3080 um die RTX 2080 Ti Kreise ziehen, wenn man nur nackt auf die Rechenleistung schaut, tut sie aber nicht.
Warum habe ich bereits ein paar mal, auch hier bereits erläutert und das hat nicht nur etwas damit zu tun, dass Ampere bei »Turing-Workloads« sich nicht wirklich absetzten kann, sondern auch damit, dass man selbst in FP lastigen Workloads seine SM nicht so ausgelastet bekommt, wie man denkt. Man siehe sich hier die Benchmarks von Doom: Eternal an, dass als FP »lastig« gilt. Thereotisch müsste hier die 3080 statt im Mittel 20 - 30% vor der 2080 Ti ganze 100 % liegen, tut sie aber nicht und warum? Genug »Threads« kommen auf der SM an, dass man die beiden 64er Blöcke »nutzt«, aber es kommen nicht genug Daten pro Block an. Die Daten, die pro Block ankommen, hängen vom eigentlichen Bild und dessen Auflösung ab und in welchen Bereichen welche Shader gefordert werden. Es kommen eben - selbst bei FP lastigen Workloads - nicht immer pro Block 64 Werte zusammen, sondern immer eine Summe 1 - 64. Früher bei Kepler kamen auch nicht immer 192 Werte pro »SM« zusammen und bei Maxwell nicht 128 Werte pro SM. Deswegen hat ja Maxwell trotz nominell weniger Shader mit Kepler den Boden gewischt. Immer dran denken: Je breiter ich pro »Befehl« werten muss, um so komplizierte wird es den Befehl wirklich auszulasten.
Mich würde es ehrlich gesagt nicht wundern, wenn wir bei NVIDIA in der nächsten Generation entweder eine etwas feinere Granulierung der Cuda Cores innerhalb der SM sehen, sprich statt 2 * 64 eben 4 * 32 oder kleinere SM mit 2 * 32 und dafür mehr SM.
Baal Netbeck schrieb:
Da ich nicht glaube, dass AMD alles hinbekommt, wird entweder die Leistung nur mit der 3070 konkurrieren oder es gibt andere Gründe, warum es nicht das erträumte "Super-Angebot" sein wird.
Auch hier kommt es drauf an. Die 3070 ist alleine von Anzahl der ALUs her für AMD kein wirkliches Problem. Hier stehen 4888 gegenüber 5120. Beide Grafikkarten brauchen für eine »optimale« Auslastung 2 Befehle pro SM/CU, da sind wir bei gleichen Bedienungen.
Aber ja, es wird Spiele geben, bei denen die 3070 mit BigNavi durchaus den Boden wischt, die gab es aber schon immer, im Großen und Ganzen ist die 3070 jedoch kein wirklicher Gegner für Big Navi.
pipip schrieb:
Ich kann dich verstehen. Langsam schaukelt sich die Erwartung einiger Richtung 3090.
Was aber auch primär durch die Community hier erfolgt, oder irgendwelche Hardware-Youtuber, die nicht wirklich Ahnung haben.
Das realistische Ziel für BigNavi ist die RTX 3080. Die 6900 XT wird zwischen der 3070 und der 3080 landen und je nach Spiel und Auflösung mal näher bei der 3070 und mal näher bei der 3080. Es wird dabei Ausreißer nach Oben geben und nach unten.
pipip schrieb:
Mein Tipp, durch die DualCu wird die Auslastung besser als bei GCN und auch Treiber soll es ja dann die Umstellung auf RDNA geben (32 thread Wavefront). Aber ja Erfahrungswerte mit RDNA1 fehlen.
Die DualCU oder "Working Group Processor" WGP ist ein Puzzleteil der Auslastung, das andere Puzzelteil ist die Umstellung auf Vec32 gewesen, sodass man nur noch zwei unabhängige Befehle pro CU hat.
Ich hab letztens mit Polaris als auch Vega gespielt in OpenCL und mir die
Wave16
, 4 Befehle pro CU,
Wave32
, 2 Befehle pro CU und die
Wave64
, 1 Befehl pro CU, noch mal gesehen und weder Polaris noch Vega mögen die
Wave32
noch die
Wave64
wirklich, es scheint so, dass diese Befehle immer nur auf einer der Vec16-Alus ausgeführt werden, statt auf allen 4, wie man vermuten könnte. Ich hab da den Verdacht - auch in der »Gerüchteküche« zu finden - dass da auch die »Hardware« ein »Knacks« hat, da die größeren Befehle immer länger brauchten, als wenn ich die Daten auf den 16er-Befehl verteilt haben.
Geht man über die »Wave16«, braucht man massig »Befehle« für die CU und das wird ja auch überall beschrieben, dass man für eine optimale Auslastung bei Vega mit 64 CU eben 256 Threads brauchte um sie wirklich auszulasten. Bei RDNA sind es dank der Vec32 nur noch 2 Befehle und damit »2« Threads. Müsste auch malö schauen, ob Wave64 bei RDNA nun wie erwartet auf beiden Vec32 ausgeführt wird, oder der Knacks immer noch da ist.
Mit der WGP muss ich auch mal genauer schauen, wie die sich auswirkt. Ah wieder soviel experimentieren und sowenig Zeit.
pipip schrieb:
Trotzdem meine ich dass dir RDNA2 GPU im Mittel weniger Schwankungen in den Titeln haben wird, als es aktuell bei Ampere der Fall ist und sich mehr wie Turning verhält.
Wird auch so sein, da man nur 32 Werte pro Befehl pro CU als auch WGP zusammen bekommen muss und RDNA2 damit auch wesentlich flexibler auf gemischte Workloads reagieren kann.
Nehmen wir mal jetzt die WGP und die SM - beide 128 ALUs - dann ergibt sich bei einer 3/4 FP-Berechnung und 1/4 INT-Berechnung bei der WGP der Vorteil, dass man hier threotisch in einem »Takt« alle Werte abgeknuspert bekommt, während Ampere hier 2 Takte braucht, weil sich das 1/4 INT-Berechnung 50 % der ALUs schnappt.
Ansonsten gilt auch hier: Pro Befehl 32 Werte zusammenzubekommen ist einfacher als 64 Werte.
pipip schrieb:
Am Ende bedeutet das, in einigen Titel erreicht man die 3080 nicht, in anderen aber schon.
Realistische Einschätzung, wobei ich denke, dass es auch von der Auflösung abhängen wird.
pipip schrieb:
Bei der 3070 halte ich eine bessere Auslastung der Shader für möglich. Wer weiß vllt ist sie in worst Case Szenario gegenüber der 3080 nicht wesentlich langsame.
Man muss hier etwas unterscheiden. AMD hatte mit GCN das Problem genug Befehle für die CUs zusammen zu bekommen, es waren aber genug Werte da. NVIDIA hat bei Ampere genau das andere Problem: Es kommen zwar genug Befehle, aber nicht genug Werte zusammen.
pipip schrieb:
Die 3070 könnte am Ende sogar die beste Ampere GPU werden.
Da stimme ich dir aber absolut zu.