Coeckchen schrieb:
Es Fällt schwer Unterschiede festzustellen, vor allem im bewegten Bildablauf.
Wunder mich jetzt nicht, gerade wenn man auch nicht weiß, worauf man achten soll. Weiß man es, fällt es aber schon auf, gerade weil manche Schatten nun natürlicher wirken und auch gewisse Schatten vorhanden sind, die vorher nur angedeutet waren.
muzafferamg58 schrieb:
@kicos018 Bissel schaerfere und bessere Schatten auf Kosten von 50% weniger FPS
Bessere Schatten: Ja. Schärfer Schatten pauschal: Ganz sicher nicht! Gerade weil RayTracing Wege des Lichts besser verfolgt, kommt es auch zu verschwommen Schatten und zwar genau dann, wenn sie verschwommen sein sollen.
FWSWBN schrieb:
Frage mich echt wer auf so ein Detail achtet?
Wenige. Aber wie das mit solchen Details bei einer Grafikengine ist: Sobald sich die Effekte durchgesetzt haben, wird später das Fehlen eher auffallen, als aktuell das Vorhanden sein.
Ex3cuter schrieb:
Turing ist ja erschreckend schneller mit RT.
Ja, Turning ist schneller als Navi, es ist aber nicht erscheckend sondern einfach zu erklären. Nach dem nächsten Zitat mehr!
ZeroZerp schrieb:
Die Turing Architektur ist ja auch unabhängig der dedizierten RT Cores darauf ausgelegt, derlei bandbreitenfressenden Berechnungsszenarien effizienter durchführen zu können.
So wie du es schreibst, vermittelt es den falschen Eindruck. Bandbreite hat sowohl GCN als RDNA genug und auch die Zugriffe sind gerade bei RDNA deutlich geworden und stehen Turning nicht wirklich nach. nVidia hat bei Turning an einer Stellschraube geschraubt, die vorher ein Schwachpunkt von Maxwell als auch Pascal waren und warum zum Beispiel GCN "besser" gealtert ist als Kepler und Maxwell.
Turning hat, was die Möglichkeiten angeht, eigentlich gerade erst zu Vega und Navi aufgeholt. Hier macht sich bemerkbar, dass Turning neben seinen 64 FP32-SALU noch weitere 64 INT32-SALU an Board hat.
Dadurch kann Turning nun - anders als Pascal und Maxwell davor - nun sowohl FP32 als auch INT32 Berechnungen zur gleichen Zeit durchführen. Beispiel:
Kommen 96 Berechnungen an (48 FP32, 48 INT32) so kann Turning durch die zusätzlichen 64INT32 Berechnungen diese 96 Berechnungen in einem Rutch berechnen.
Pascal und Maxwell davor hatten zwar 128 SALU, diese konnten aber entweder FP32-Daten berechnen oder INT32. Für die 96 Befehle benötigte Maxwell also immer 2 Durchläufe. Erst einmal 48 FP32-Daten, dann die 48 INT32-Daten. (Kepler, Maxwell und Pascal sind relativ unflexibel, was die Datentypen angeht.
)
GCN ist intern in einer CU anders aufgebaut als Maxwell, Pascall oder nun Turning. AMD arbeitet bei GCN und nun bei RDNA mit Vektor-ALUs (GCN: Vec16, Navi Vec32). Navi besteht aus 2* SALU (für bestimmte Funktionen) und 2 * VEC32. Diese beiden Vec32-Einheiten können jeweils seperat mit einem Datentyp gefüllt werden.
Mit den 96 Befehlen von oben kann nun Navi (Vega davor auch) nun 1 Vec32-Einheit mit 32 FP32 Daten füllen und die andere mit 32 INT32. Verarbeitet im ersten Durchlauf also 64 Befehle. Es bleiben am Ende 32 Befehle über (16 INT32, 16 FP32). Im zweiten Durchlauf werden also die fehlenden 32 Werte berechnet. Navi als auch Vega brauchen also "2" Durchläufe für die 96 Daten, aber nicht weil sie wenniger flexibel sind oder nicht die "Bandbreite" haben, sondern weil sie weniger Werte auf einmal berechnen können.
TL
R: Turning ist schneller in solche Szenarien, weil Turning 64 * FP32 und 64 * INT32 auf einen Schlag berechnen kann, während Navi für die selbe Menge an Befehlen 2 durchläufe bräuchte, da nur maximal 64 FP32+INT32 Werte zur gleichen Zeit berechnet werden können. Oder noch einfacher: Turning - als GTX hier - hat nicht nur 2340 Shader, sondern eigentlich 4680 Shader, während Navi NUR 2560 (+80 SALU, also 2640) Shader hat.
-- Etwas Auschweifung:
Da bei Grafikberechnungen - FP bleibt "vorherrschend" - immer mehr auch INT-Berechnungen benötigt werden, hat nVidia eine Schwachstelle nun beseitigt, in dem sowohl FP als auch INT Berechnung zur gleichen Zeit ablaufen können. Hat damit aber nur zu den letzten GCN-Generationen aufgeholt. Denoch sind die "Recheneinheiten" bei nVidia recht "unflexibel". Es ist immer noch so, dass ein 64-Block mit dem gleichen Datentyp gefüllt werden müssen. Die 64 FP32-Shader fressen also entweder 64 FP32 Werte, oder 128 FP16. Sie können aber nicht sagen: 32 FP32 + 64 FP16. Das mögen die nicht. Entweder oder.
Vega ist da etwas netter zu befüllen. Aber egal.