squadric schrieb:
Konsolen sind ganz anders optimiert, sieht man zB. sehr gut an Uncharted 4 oder Lost Legacy. Ist schon krass was man so aus der relativ alten PS4 Pro zB. "rausquetschen" kann.
Versuche es erst gar nicht hier zu erklären. Das ist verlorene Zeit. Hier denken - genau so wie auf GameStar und da sogar noch schlimmer die Redakteure - weil nun x86-Hardware in der Konsole steckt, wäre ja alles so viel einfacher und besser zu portieren und die Optimierungen kommen auch auf den PC und es ist sowieso nicht verständlich.
Das heute die Software-Ebene weit mehr Auswirkung hat als die Hardware-Ebene, wird da gerne vergessen oder unterschlagen.
MaverickM schrieb:
Tesselation ist dann auch erst einmal wieder verschwunden, bis es als Standard wiederbelebt wurde.
Falsch. Tessellation ist nach dem Start von DX11 nie verschwunden, nur die Implementierung erfolgte mit der Zeit immer anders.
Während man Tessellation am Anfang gezielt aktivieren musste und die Effekte auch übertrieben eingesetzt wurden, hat sich relativ schnell heraus kristallisiert, dass der eigentliche optische Mehrwert von Tessellation nicht in seiner übertriebenen Anwendung liegt, sondern es subtiler einen viel höheren Mehrwert bietet. Statt also gezielt auf wenige Objekte mit übertriebenen Faktoren zu gehen, haben die Entwickler gelernt Tessellation über viele Ebenen hinweg mit kleineren Faktoren zu nutzen.
KuroSamurai117 schrieb:
Doch, auf PCGH hat Raff eine Vermutung:
Das hat bereits
@ZeroZerp hier bereits vor Beiträgen als Vermutung geäußert und ich habe dazu auch meinen Beitrag geschrieben.
Im übrigen ist GCN als auch RDNA in ihren Shadern schon wesentlich flexibler gewesen, so dass man je nach Notwendigkeit die einzelnen Vektoreinheiten für die eine oder die andere Aufgabe gleichzeitig nutzen kann, während Kepler, Maxwell und Pascal mit ihren 64-FP32-Shadern immer nur entweder das eine oder das andere machen konnten.
Ich kann dir sogar genau erklären, warum RDNA nun einige % zu ihren eigentlichen Gegenspielern verliert und auch in DX12 zum Beispiel stärker verliert als Vega: RDNA kann zwar eine der Vec32 auf die INT32-Befehle los lassen und eine Vec32 auf die FP32, das wirkt sich aber am Ende so aus, als würden nur noch 32Shader die FP32-Befehle bearbeiten und 32 Shader die INT32-Befehle.
Turning wiederum wächst in so einem Fall auf 128Shader an. 64 rechnen an den FP-Befehlen, 64 an den INT-Befehle.
Wenn man es so will, hat nvidia zwischen Pascal und Turning 64 FP-Shader durch 64 INT-Shader setzt und gleichzeitig die Shaderblöcke hoch geschraubt, damit man am Ende auf die alte Zahl der FP-Shader kommt.
Nimmt man nun die GeForce RTX 2070 Super und die Radeon RX 5700XT, dann haben nach außen hin beide erst mal "2560"-Shader, das stimmt aber nur auf den ersten Blick. Nimmt man es genau, dann hat die RTX 2070 Super nämlich 5120 Shader als ganzes, während die RX 5700XT weiterhin nur ihre 2560 Shader hat.
Und um hier das etwas mit einen Beispiel zu veranschaulichen:
Müssen 512 Rechnungen vorgenommen werden, wovon 1/4 INT32 sind, dann kann ein Shader-Cluster bei der RTX das in 6 Happen machen. 512 Rechnungen - 128 INT32 = 384 FP32. Durch 64 FP32 sind eben 6. Die 128 INT32 werden bei den ersten beiden Happen mit genommen.
RDNA kann nun 32 FP32 Berechnungen und 32Int32-Berechnungen in 4 Happen machen (eine Vec32 auf Int, eine Vec32 FP), bleiben am Ende nach 4 Berechnungen 256 über und braucht für die auch noch mal 4 Happen, kommt also auf 8 Happen.
Deswegen hat AMD auch bei RDNA die Workgroups eingeführt, die am Ende aus 4 Vec32-Einheiten besteht, damit man auch hier wieder effektiver Verteilen kann. Dann wären wir bei 128 Shadern, die zu je 32 organisiert werden. von 128 Shadern könnte man dann ein Viertel für INT32 zur Verfügung stellen und drei Viertel für FP32.
Aber das geht jetzt dann zu weit in die Materie hinein. Zeigt aber gut, warum Vega bei DX12 sogar eher zu legen kann, während Navi in dem Spiel sogar verliert.
Neronomicon schrieb:
Dieses Spiel und deren Umsetzung zeigt einmal mehr meine Befürchtung bestätigt. Egal wie man zum NV RTX steht, die Entwickler können oder wollen nicht die non Rtx Version richtig umsetzen.
Das hat nichts mit Können zu tun und auch nur bedingt etwas mit Wollen.
Es hat viel eher damit etwas zu tun, dass sämtliche Effekte, die hier nun per DXR implementiert wurden, in einem Rasterizer nicht ohne hohen Kostenaufwand - Zeit sowohl beim Programmieren, als auch im Zeit im Programm selbst - implementiert werden können.
Back-Face-Reflections und Screen-Space-Reflections sind zwar technisch möglich und die Screen-Space-Reflections sind sogar implementiert - es spiegeln ja einige Oberflächen, benötigen aber bei einer ähnlichen Qualität und der gleichen Menge viel mehr Ressourcen als schöndes DXR, denn sollte man die gleiche Qualität haben wollen und die selbe Intensität, müsste man für jede Spiegelung ein einen neuen "Render Space" öffnen, der die Szene aus dem Blick der Spiegelung (Back-Face-Reflections) erneut berechnet in einer gewissen Auflösung.
Alles möglich, keine Frage, aber eben nicht mehr wirklich effizient. Selbst wenn man die Spiegelungen über diese Technik nur noch mit halber Auflösung berechnet, würden sehr viele solcher Berechnungen benötigt werden und der Leistungsabfall wäre sogar deutlich höher als es jetzt mit RTX der Fall ist.
Deswegen lässt man bei Back-Face-Reflections auch eine viel Zahl von Aspekten weg und berechnet sie nur recht grob und vermeidet zum Beispiel jeglich Akteure darin oder Explosionen und Co.
Mit Screen-Space-Reflections braucht man zwar weniger Ressourcne als mit den Back-Face-Reflections, aber auch die Kosten je nach Menge stark an Leistung und können eben nicht an jeder Oberfläche angewendet, weil die Spiegelungen nur das Spiegeln, was im Render-Space zu sehen ist und selbst dann müssen wieder Tricks angewendet werden, weil man verworfene Polygone plötzlich doch braucht.
ZeroZerp schrieb:
Soso- Was macht denn DLSS GENAU? Wie arbeiten die Tensor- Cores?
Also wie Tensor-Cores arbeiten ist hier aber echt die billige Frage: Tensor-Cores lösten Tensor-Vektoren/Matrizen:
https://de.wikipedia.org/wiki/Tensor
Nur - und jetzt fängt es an: Was DLSS genau macht, kann keiner sagen, denn DeepLearning hat einen kleinen Nachteil: Was das "neurale" Netzt am Ende wirklich macht, ist selbst denen, die diese Netze entwerfen am Ende nicht mehr wirklich klar und führt immer wieder zu sehr ... sagen wir mal erstaunten Kommentaren von so manchem Entwickler.
Wir verstehen die Grundlagen, wir wissen wie diese Netze arbeiten, aber warum sie zu einem gewissen Ergebnis kommen, können wir nur versuchen nachzuvollziehen, am Ende ist das Neuralenetzwerk aber immer eine Blackbox, die wir mit Daten füttern und der wir beim lernen sagen, was am Ende heraus kommen soll. Was dazwischen passiert? Das ist ein "Rätsel".
Und wer es mir nicht glaubt:
https://www.bigdata-insider.de/deep-learning-und-wie-ein-neuronales-netz-entscheidet-a-820294/
ZeroZerp schrieb:
Wenn DLSS nur Hokuspokus ist, hätte ich gern von Dir gewusst, wie GENAU es arbeitet.
Wenn wir genau sein wollen und ein bisschen böse: Er hat damit nicht unrecht. Eben weil wir nicht genau verstehen, warum ein neurales Netzwerk sich wie entscheidet, kann man hier durchaus von Hokuspokus sprechen.
Wir können versuchen nachzuvollziehen, warum eine Entscheidung getroffen wurde, aber am Ende haben wir nur Anhaltspunkte, wie diese Entscheidung wirklich zu Stande gekommen ist, können wir eben nicht mit absoluter Sicherheit sagen.
.
