Zwiebelsoße schrieb:
AMD erzeugt in der Pipeline bei weniger Rays deutlich weniger Overhead.
Nicht wirklich, weil Du im Inline- Raytracing immer auf uber- Shader setzen solltest.
Die Flexibilität, die Du durch eine höhere Kontrolle der Ray- Stages erzielst, verlierst Du an anderer Stelle wieder.
Zudem sind die zweite Generation RT Cores von NVIDIA auch flexibler geworden.
Du musst nicht mehr zwangsweise durch die gesamte Blackbox.
Zwiebelsoße schrieb:
Zudem haben sie Vorteile bei divergenten Lichtbündeln.
Divergente Rays shreddern den last level Cache von RDNA 2.
Da musst Du auch auf "durchzug" stellen, soll noch ein wenig Leistung erhalten bleiben.
Das heisst, dass Du die Sortierroutine vorher schon ansetzt.
Die meisten Bündelungs-/Ray- Sorting- Algorithmen laufen auf der CPU und nicht auf der GPU.
Zwiebelsoße schrieb:
Nvidias Lösung ist unflexibel
Im Gegenteil- AMD zwingt mich dazu meine Shader nicht so gestalten zu können, bzw. Dispatches daraus zu erzeugen, wie ich will, wenn ich nicht durch das Tal der Performancetränen schreiten will.
Zwiebelsoße schrieb:
und wird aufgrund der Konsolenlastigkeit der RT Implementierungen wohl vorerst nicht wirklich schneller sein.
Die Praxis zeigt derzeit ein anderes Bild.
Zwiebelsoße schrieb:
Zu sehen ist das bei Crysis Remastered
...welches quasi alle Last (auch des Raytracings) von den Karten nimmt und die CPUs damit tötet...
Zwiebelsoße schrieb:
Welchem man, wenn man den Code untersucht, fast schon unterstellen könnte, NVIDIA gezielt schlecht dastehen zu lassen (Witcher 3 Hairworks lässt grüßen) - Stichwort INT/FP.
Zwiebelsoße schrieb:
, Metro Exodus bei niedrigeren Settings, natürlich vorrausgesetzt, das AMD nicht schummelt.
...das ist ein weiterer Punkt. Die ersten Tests der AMD Karten in Watchdogs unter RT waren eine Farce, da die hälfte der Effekte nicht berechnet wurde.
Kann man sich auf die Messungen auch ob der Treiberschweinereien wirklich verlassen?
Zwiebelsoße schrieb:
Custom Traversal, Ray-Caching, funktioniert auf Nvidia Karten zum Beispiel nicht.
Custom traversal macht bei der Ray- Engine von NVIDIA seltenst Sinn (und bei immer weiter voranschreitendem Ray- reuse noch weniger), da dort im Gegensatz zu RDNA2 kein Flaschenhals auszumachen ist.
...zudem dachte ich, dass besagtes ray- caching, welches immer wieder in den Medien rumschwirrt Konsolen exklusiv sei, da vom unified Speichermanagement abhängig?
Zwiebelsoße schrieb:
DXR 1.1 hat das RT Feld für Nvidia so ein wenig vermint.
Im Gegenteil- Ampere wurde wie RDNA2 im Hinblick auf 1.1 optimiert.
Zwiebelsoße schrieb:
Ich weiß jetzt nicht mehr wo ichs gelesen habe, aber es erscheint zumindest logisch, schließlich geht Nvida den weg über die RT Cores, welche nunmal in der SM weiter weg sind als AMD´s Textureinheiten.
Nicht wirklich - Du kannst concurrent inzwischen auf die Traversal Einheiten zugreifen, wie es beliebt und das auch Renderstage- Unabhängig.
Hier nicht Turing mit Ampere verwechseln.
Zwiebelsoße schrieb:
Aber mittlerweile denke ich, dass da noch einiges an Optimierungspotenziual brach liegt.
Meine Rede - Wir werden hier auf Seiten der Software noch einiges erwarten dürfen.
Wir kommen von Demos, die auf Turing mit 1080P und 30FPS präsentiert wurden (mit einem RT Grafikeffekt).
Und innerhalb von 2,5 Jahren sehen wir mit Minecraft RTX einen Titel, der FULL PATHTRACED auf der 3090 über 90FPS auf 4K drückt.
Zwiebelsoße schrieb:
Mit DXR 1.1 kann man den Overhead deutlich reduzieren.
Die Kommandos zum Bauen vom BVH Trees kommen nicht mehr alleine von der CPU, es läuft nun über den GPU Compute Kernel.
Das wäre vorher auch schon gegangen. Dazu brauchts kein 1.1
Die BVH Trees sind im Übrigen nichts fix hinterlegtes. Du kannst nach belieben jede andere Beschleunigungsstruktur dahinterklemmen, weil es eben kein fixer Bestandteil einer Spezifikation ist.