.Sentinel. schrieb:
NVIDIA bürdet sich mit ihren Treibern immer schon deutlich mehr auf, als AMD, auch was das Queuing und die Steuerung in Richtung Hardware anbelangt.
Jaein, wenn ich mir die Hardware ansehe und auch die Probleme von DX11 und wie NVIDIA die Hardware anspricht, genau so wenn ich mir die Probleme von GCN ansehe und was sich mit RDNA1 geändert hat, woran AMD mit RDNA beim Treiber gearbeitet hat, aber auch welche Techniken in der letzten Zeit in den Fokus gerückt sind.
NVIDIA hat vor knapp 7 Jahren in ihren Treibern eine Schwachstelle der DX11 API »korrigiert« in dem sie den Treiber, besser, wie der Treiber die Drawcalls und damit verbunden auch die Shader an die Grafikkarte weiterleitet und verarbeitet. Der primäre Vorteil von NVIDIA war damals aber immer, dass eine SM ein »Thread« bearbeiten konnte. Man brauchte damals zwischen 15 - 16 Threads um die Karte perfekt auszulasten. Auch wenn sich NVIDIA hier mehr Arbeit im Treiber gemacht hat, eigentlich ist es jedoch immer noch recht einfach gewesen, weil die Hardware sich einfach ansprechen lässt.
AMD hätte damals auch die »DX11« Probleme per Treiber lösen können. Wir hören immer nur, dass da das »Hardware-Shedulig« Probleme machte, aber sieht man sich die Informationen der Tech-Sheets an, dann war das Hauptproblem: Die Wave64-Befehle, die im Treiber genutzt wurden, wurden nur auf einer Alu ausgeführt und benötigten dafür eben 4 Takte. Um alle 4 ALUs der CU zu nutzen, braucht es eben 4 Befehle, unabhängig ob Wave64, Wave32 oder Wave16.
Kurz jetzt als Einschub, ich denke ich weiß auch langsam warum man bei RDNA1 nicht ins Volle ging und warum man doch RDNA veröffentlichte. In manchen Tech-Papers wird eben angedeutet, dass der »Treiber« bisher mit Wave64 arbeitet und daher die Umstellung auf Vec32 eben bereits »44 % Impact« brachte bei der Leistung (2 Takte pro Vec32 ALU) und ebenso wurde - wie hier ja auch angebracht von einem anderen Mitglied - das man an der Umstellung auf Wave32. Solche Umstellungen sind schwerwiegbend und AMD kann sowas auch nur bis zu einem gewissen Punkt testen und man muss dann springen. Ich denke, AMD hat RDNA1 heraus gebraucht um zu sehen, wie weit sie sind und um dann Probleme zu beseitigen. Ich denke, die massiven Blackscreen-Probleme am Anfang von Navi haben genau auch damit zu tun. Man wollte möglichst viele Probleme und Fehler noch vor »RDNA2« finden und beseitigen.
Und genau diese Umstellung von Wave64 auf Wave32 beim Treiber könnten sich für AMD als Stärke erweisen. Vergiss bitte nicht: RDNA hält in Form der 5700XT mit der 2070 als auch der 2070S bei modernen Titeln durchaus mit. Bei Turing reden wir von 64 + 64 INT, der »INT«-Impact hat also bei Turing keine wirkliche Auswirkung, während eine 5700 XT diese »Einheiten« nicht hat, sondern eben nur die 2 * Vec32 (64). Selbst Turing kann also bei auf »Turing« optimierte Workloads sich trotz nominell 100% mehr ALUs nicht wirklich absetzen.
Warum? Und genau das habe ich dir nun versucht mehrfach zu erklären: Vektoren mit 64 Werte zu füllen ist komplizierter und schwerer als Vektoren mit 32 Werten zu füllen. Ich habe dir einen nächsten Hinweis schon geliefert: Wie viele Werte zusammen kommen hängen von der Szene ab, als Entwickler einer Engine kannst du sicher daran arbeiten, dass man möglichst nur noch FP-Workload hat. Gleichzeitig werden aber heutige Szenen von Spielen immer detaillierter. Früher hattest du in vielen Spielen wesentlich größere Fläche, auf die ein Shader angewendet wurde, entsprechend viele Daten kamen auch an, heute werden die Flächen jedoch immer kleiner, feiner und damit kommen auch pro Shader weniger Werte.
Man kann bei modernen Engine - unabhängig von FP und INT - heute eines sagen: Es werden immer mehr »Shader« (Programme) weil die Details zunehmen, dadurch werden es aber auch weniger werte die pro Shader berechnet werden. Und das ist ein Problem, dem kann NVIDIA nicht wirklich im Treiber begenen und das sind auch Probleme, die man nur bedingt in den »Engines« lösen kann, damit man immer genug Werte zusammen bekommt, um die beiden Threads einer SM perfekt auszulasten.
Also ja, man wird sicher in den Engine als auch im Treiber noch einiges machen können, es wird aber auch Eigenheiten geben, die man weder in der Engine noch im Treiber wird lösen können, sondern es kann einfach sein, dass die Pfade bei Ampere immer etwas »zu breit« bleiben.
Kacha schrieb:
Das hoert sich so an als waere da was in Hardware schief gelaufen.
Das ist meine Vermutung und wird mit den Aussagen in den Tech-Sheets zumindest angedeutet.
