@ZeroZerp
Ich erinnere hier auch gerne an den TW3 Launch und der automatisch eingestellten 64x Tesselation, die man nur üer Treiber reduzieren konnte. Hier war die Antwort von CDPR, dass sie davon nichts wussten, da sich Nvidia um die Optimierung gekümmert hat.
Das ist ein unrühmliches Kapitel, in welchem wir nie erfahren werden, wer da jetzt was gemacht hat. Ich hab das vor einiger Zeit schonmal recherchiert. Da haben sich CDPR, NVIDIA und AMD gegenseitig den schwarzen Peter zugeschoben.
Schon erstaunlich, dass erst nach dem Launch die Firmen draufkamen, dass auf ALLEN Plattformen die Performance mit eingeschalteter Tesselation einknickte. Je nach Generation und Marke mal mehr und mal weniger stark, aber durchweg deutlich spürbar.
Niemand will es bemerkt und niemand will etwas davon gewusst haben. Ich würde mich diesbezüglich nach offizieller Informationslage davor hüten, jemandem jetzt hier alleiniges Versagen oder die alleinige Schuld zuzuschieben.
Ich denke, dass das eine unrühmliche Gemeinschaftsproduktion der drei beteiligten Firmen war.
Aber es geht im Grunde garnicht darum, dass ein Hersteller böswillig benachteiligt wird, sondern nur darum, dass nur für einen optimiert wird.
Wie soll denn so eine Optimierung bei Path- Tracing aussehen? Das läuft über die einfachsten Shader und einfachsten Algorithmen der Welt.
Klar werden die neuen Specials bzw. Beschleunigungsmöglichkeiten der 4xxxer Generation genutzt. Was will man aber optimieren, wenn z.B. die Radeon Karten das nicht können? Soll der Hersteller dann absichtlich das eigene Produkt bremsen oder Beschleunigungsfunktionen ausschalten?
Durch die standardisierte Implementation und den Straight Forward Ansatz von Pathtracing kann da nicht viel gerüttelt werden. Entweder die Karte hat die Leistung oder eben nicht.
Und dass AMD derzeit nicht die hellste Kerze am Pathtracing bzw. Raytracing- Himmel ist, ist doch nun wirklich kein Geheimnis und wird in jedem Test wieder und wieder bestätigt, wenn die dafür notwendigen Einheiten mal richtig unter Dampf gesetzt werden.
Ist ja auch OK- AMD hat einfach auf ein anderes Pferd gesetzt.
Das ist schon seit mindestens 15 Jahren so, dass Enwickler im Partnerprogram von AMD(damals noch ATi), oder eben Nvidia sind und daher die Spiele auch eher für die eine, oder anderen Seite optimiert wird.
Ja- Das war wie bereits erwähnt in den Rasterspielen möglich, da deutlich Performance rauszukitzeln, weil Du eben hunderte Shader hattest/hast, die man auf die eine oder andere Weise auf die Grafikkarte optimieren konnte.
Bei Pathtracing hast Du für die Kernaufgabe aber nur mehr eine Hand voll primitivster Shader, die aktuell noch Brute- Force zwei Beschleunigungsebenen durchlaufen. Da gibts nicht viel zu tricksen....
Böswillig wird das kaum sein, viel besser macht es das aber auch nicht. Wenn selbst die User selbst den Fehler so einfach fixen können sollte es für CDPR doch ein leichtes sein das glatt zu ziehen. Zumal sie sich der Problematik ja grundsätzlich durchaus bewusst sind.
Die Aluhut Keule ist an der Stelle einfach unnötig.
Die Keule hab ich deswegen herausgeholt, weil hier haltlos mit Vermutungen und Unterstellungen um sich geworfen wird, die den Anschein erwecken sollen, dass diese "faktisch" wären.
Und wie gesagt- Es ist bei NVIDIA und AMD völlig normal, dass die den Renderpfad eben auch durch die Dateinamen "intercepten". Sprich, wenn ein Programm erkannt wird, aktivieren und deaktivieren sich in den Treibern der Hersteller allerlei Dinge. Unter Anderem eben auch Fehlerbereinigungen bei Renderfehlern.
Somit- Wer sagt, dass bei AMD durch diesen "Trick" nicht einfach Berechnungen unter den Tisch fallen bzw. sich die Grafikqualität senkt oder es an manchen Stellen Fehler gibt? Muss natürlich nicht sein, ist aber möglich.
Somit besteht da eben schon ein erheblicher Unsicherheitsfaktor.
Für mich, am einzelnen Rechner, macht es ehrlich keinen Unterschied und ist mir (stand jetzt) das Geld als “Early Adopter” nicht wert.
Gleiches kann man von so ziemlich jeder anderen Grafikeinstellung sagen. Wenn Du auf dem Einzelrechner statt Ultra- Details auf mittlere Details zurückgehst, wirst Du ohne Vergleichsmöglichkeit nicht sonderlich viel vermissen.
Und auch, wenn Du nicht genau benennen kannst, was es ist. Nach einer Zeit auf Ultra würdest Du beim direkten Siwtich auf Mittel im Normalfall eben doch bemerken, dass es irgendwie anders aussieht.
Mich würde es nicht wundern , wenn es genauso endet wie PhysX.
Das wäre hervorragend. PhysX ist mit über 700 unterstützten Spielen die erfolgreichste Physikbibliothek in der Geschichte der Computerspiele gewesen.
Most detailed list of games and other applications, which use PhysX SDK physics engine. PhysX News Blog. Comparison video and screenshots.
web.archive.org
Erst eine separate Karte von Ageia , die fast keinen Menschen interessiert hat.
Stimmt
Dann hat Nvidia Adeia aufgekauft und die PhysX-Technik in die eigenen Grafikkarten implementiert und Spiele damit gefördert und plötzlich war es für eine gewisse Gruppe an Spielern der heißeste Scheiß, weil in Batman Arkham City , statt 10, 100 Partikel durch die Gegend geflogen sind.
Stimmt- Das sah schon ziemlich cool aus und hat dem Szenenbild deutlich mehr Dynamik verliehen.
Letztendlich hat es aber kein Mensch gebraucht,
So wie jeder Grafikeffekt letztendlich nicht gebraucht wird.
da sich keine zwei Jahre später die Havok Physik Engine von Valve durchgesetzt hat,
Siehe oben. Havok war bei weitem weniger weit verbreitet als PhysX
Momentan haben wir die RT Cores, die man teuer bezahlen muss, und als Softwarelösung entwickelt sich Lumen in der Unreal Engine immer weiter und macht optisch, im Vergleich zu RT, fast keinen Unterschied mehr.
Es sind nicht die RT Cores, die man teuer bezahlt, sondern R&D in Sachen AI/KI und Raytracing. Nebst explodierender Fertigungspreise und allgemein galoppierender Inflation.
Und ja- Auch ich finde Lumen fortschrittlich. Nur- Auch das nutzt die RT Cores und ist in Teilbereichen auch RT basiert. Nur halt etwas (nicht viel) schneller, dafür aber etwas schlechter.
Schaut Euch doch mal die Performance bzw. die Anforderungen der UE5 Demos bzw. Titel an. Auch allesamt absolute Hardwarekiller.
Die Erstellung und Wartung der Bounding Volume Hierarchy (u. a.) kostet auch Prozessorleistung. Da wir das gerne immer wieder sagen, stellen wir auch Benchmarks zur Untermauerung bereit.
.gif "sm_B-) :-)")
MfG
Raff
Erstens das und zweitens fällt bei RTRT deutlich mehr Szenengeometrie an, da Du grundsätzlich nicht nur die auf das FOV gerichtete Projektionsmatrix zu berechnen hast, sondern die gesamte umgebende Szenerie plötzlich einfluss auf das Ergebnis hat, welches sich vorne, also im Blickfeld abspielt. Du darfst sie also nicht mehr so einfach "cullen".
