Diskussion zu: Ein erster Überblick zur RayTracing-Performance

[Leonidas]

Link zum Artikel:
https://www.3dcenter.org/artikel/ein-erster-ueberblick-zur-raytracing-performance

[Gast]

Danke für die Index Erstellung!
Im Balkendiagramm zum WQHD Index hat sich bei Ampere ein Fehler eingeschlichen. Bei der 3060 und der 3060ti

[OpenVMSwartoll]

Der Artikel ist für mich ein Sahneschnittchen. Danke für die Arbeit.

Interessant, weil die Entwicklung bei Nvidia gut ablesbar ist und der Stand der Dinge bei AMD.

[bloodflash]

Danke!
Eine sehr schöne Bestandsaufnahme.

Interessant auch die ersten Erkentnisse bzgl. Speichermenge. Lustig zu sehen, wie sich nV und AMD da gegenseitig die Butter vom Brot nehmen und am Ende keiner klar gewinnen kann.

[Gaston]

Nice Bestandsaufnahme. :up:

Hättest aber eigentlich auch nur die Pcgh hernehmen können die erläutern das alles so schön in dem von dir gelinkten Artikel, benchen 4 Auflösungen und zeigen damit den anderen wo der Frosch die Locken hat.

mfg

[Morgenlicht]

Hier ist 3DCenter :love: und nicht PCGH. Es gibt immer irgendwo wen der etwas ähnliches macht ob privat oder veröffentlicht.

[Iscaran]

Sehr schöne Zusammenstellung! Als Beginn eines neuen RT-Indexratings eine gute Basis :-).

[Leonidas]

Im Balkendiagramm zum WQHD Index hat sich bei Ampere ein Fehler eingeschlichen. Bei der 3060 und der 3060ti

Fehler rein im angezeigten Wert der 3060 (Balkenlänge ist korrekt). Selber Fehler bei der 3070Ti im 4K-Diagramm. Dummer C&P-Fehler. Beides gefixt.



Hättest aber eigentlich auch nur die Pcgh hernehmen können die erläutern das alles so schön in dem von dir gelinkten Artikel, benchen 4 Auflösungen und zeigen damit den anderen wo der Frosch die Locken hat.

Anfänglich war dieser Artikel auch nur als kurze News geplant, welcher auf diesen PCGH-Artikel hinweist. Bis ich dann gesehen habe, das von Le Comptoir eine ähnlich umfangreiche Datenbasis vorliegt. Danach wurde die Auswertung immer größer und größer ;)

[Gast Ritis]

Also die MinecraftRTX Ergebnisse muss man rausrechnen solange das ein allein Nvidia entwickeltes RTX Marketing Produkt bleibt.
Bei Metro Exodus ist der Marketing Case auch gegeben, das wurde auch afaik fertig entwickelt bevor AMD RT verfügbar war und nicht weiter angepasst.

Man muss aufpassen dass das am Ende nicht so ne Farce wie die Tesselation Benchmarks werden.

Besser wäre schon mal man stellt nur auf Test von Titeln ab, die nach der Einführung von RDNA2 veröffentlicht wurden. Dann gibts wenigstens die Chance dass die Entwickler für beide Plattformen Anpassungen bzw. Kompromisse gemacht und nicht nur das Nvidia HowTo BVH Acceleration umgesetzt haben.

[Gast]

Selbiger Index wird die reine RayTracing-Performance betrachten, gänzlich ohne Performance-Booster á DLSS & FSR – jene sind sowieso nicht durchgängig verfügbar, weisen aber vor allem ihre ganz eigene Performance-Charakteristik auf.

Es gibt wesentlich mehr Raytracing-Titel mit DLSS Support als ohne, da sind eher letztere die Ausnahme.

Vor allem angesichts der Tatsache, dass DLSS in vielen Titeln sogar eine visuell höhere Qualität aufweist als deren Default AA-Lösung kann man das nur schwer ignorieren.

Man hätte DLSS zumindest als zusätzliche Datenpunkte mit einarbeiten sollen, also z.B. Performance-Index 4k + DLSS, WQHD + DLSS und FullHD + DLSS.

Um es komplett zu ignorieren ist DLSS einfach viel zu gut, und in Raytracing-Titeln wie erwähnt auch ausreichend verfügbar.

Nebenbei entschärft dies auch die Speicherbelastung.

[Leonidas]

Also die MinecraftRTX Ergebnisse muss man rausrechnen ...
Bei Metro Exodus ist der Marketing Case auch gegeben ...

All dies sind Unstimmigkeiten, welche man sicherlich in der Zukunft besser lösen kann. Ich bin auch nicht glücklich über jede Entscheidung der Hardwaretester. Aber derzeit gibt es schlicht zu wenig Auswahl an entsprechenden Tests.

[Gast]

Also die MinecraftRTX Ergebnisse muss man rausrechnen solange das ein allein Nvidia entwickeltes RTX Marketing Produkt bleibt.

Bei Metro Exodus ist der Marketing Case auch gegeben, das wurde auch afaik fertig entwickelt bevor AMD RT verfügbar war und nicht weiter angepasst.



Entwickelt wird gegen DXR, es ist nicht Aufgabe der Softwareentwickler, die Software an die Hardware anzupassen, deshalb programmiert man ja gegen eine einheitliche API. Die Aufgabe diese API möglichst effizient auf Hardwareseite zu implementieren ist Aufgabe der Hardwareentwickler bzw. hauptsächlich deren Treiberentwickler.


Besser wäre schon mal man stellt nur auf Test von Titeln ab, die nach der Einführung von RDNA2 veröffentlicht wurden. Dann gibts wenigstens die Chance dass die Entwickler für beide Plattformen Anpassungen bzw. Kompromisse gemacht und nicht nur das Nvidia HowTo BVH Acceleration umgesetzt haben.

Es kann nicht sein, dass Softwareentwickler für jeden Hardwareentwickler eigene Anpassungen vornehmen muss, genau dafür wurden APIs entwickelt um das eben nicht zu müssen. Wie soll das denn weitergehen, wenn auch noch Intel kommt, soll dann jeder Softwareentwickler für AMD, Intel und Nvidia eigene Versionen entwickeln.
Das ist doch viel zu ineffizient.

[Gaston]

All dies sind Unstimmigkeiten, welche man sicherlich in der Zukunft besser lösen kann. Ich bin auch nicht glücklich über jede Entscheidung der Hardwaretester. Aber derzeit gibt es schlicht zu wenig Auswahl an entsprechenden Tests.

Das sind keine 'Unstimmigkeiten' sondern reale Usecases, da echte Spiele. Nur weil AMD bei hartem Ray Tracing saugt soll man das weglassen? Minecraft Rtx ist eines der eindrücklichsten RT Spiele bisher. Man sieht u.a. am Artmark dass RDNA nicht besonders gut ist, wenn man die Effektdichte hochzieht: https://www.pcgameshardware.de/Raytracing-Hardware-255905/Specials/ART-Mark-Raytracing-Benchmarks-1371125/

mfg

[Leonidas]

Ich hab auch nicht gesagt, dass man es weglassen soll. Die Unstimmigkeit ist, dass es derzeit keine Auswahl an Benchmarks gibt, sondern nur weniges benutzbares Material. Kommt eine umfangreichere Auswahl, kann man selektieren, was man reinnimmt und was nicht. Was überhaupt nicht bedeutet, dass man deswegen solche Fälle wie Minecraft per se ausschließt. Insbesondere bei umfangreichen Benchmark-Feldern stört es überhaupt nicht, so einen Farbtupfer dabeizuhaben.

Im gesamten wollte ich sagen: Wir befinden uns hiermit noch in der Findungsphase und ich nehme alle Anregungen hierzu auf.

[Gaston]

Einverstanden. :) Ich bin auch sehr gespannt wie das weitergeht (auch auf die neuen Benchmark Sets 2022).

mfg

[Gast Ritis]

Entwickelt wird gegen DXR, es ist nicht Aufgabe der Softwareentwickler, die Software an die Hardware anzupassen, deshalb programmiert man ja gegen eine einheitliche API. Die Aufgabe diese API möglichst effizient auf Hardwareseite zu implementieren ist Aufgabe der Hardwareentwickler bzw. hauptsächlich deren Treiberentwickler.

Es kann nicht sein, dass Softwareentwickler für jeden Hardwareentwickler eigene Anpassungen vornehmen muss, genau dafür wurden APIs entwickelt um das eben nicht zu müssen. Wie soll das denn weitergehen, wenn auch noch Intel kommt, soll dann jeder Softwareentwickler für AMD, Intel und Nvidia eigene Versionen entwickeln.
Das ist doch viel zu ineffizient.

Nein, das ist überhaupt nicht ineffizient. Das ist die Regel. Allein deshalb gibt es in DirectX die Möglichkeit die Hardware und die darauf unterstützten Features abzufragen um dann jeweils in unterschiedlichen Code-Pfaden das Optimum herauszuholen.

Hier gehts auch nicht um einen POC für ne Semesterarbeit sondern um kommerzielle Produkte.

Hättest Du Dir mal die DXR API durchgelesen wäre Dir vielleicht sogar aufgefallen, dass es bestimmte Flags gibt um auf die Eigenheiten einzugehen.
Wenn ich zum beispiel eine GPU habe mit der das Erstellen von BVH relativ schneller als das Tracing geht, dann kann man einen optimierten BVH erstellen lassen, vice versa. Man kann auch dynamische BVH anlegen, die nicht jeden Frame komplett neu berechnet werden, wenn die HW damit umgehen kann (RDNA2). Wenn ein BVH zu gross wird muss man den in den bottom Level teilen und im top Level Instancen. Man kann auch BVHs bauen, die kleiner sind und nicht so viel VRAM benötigen (Nvidia). Über die Speicherallozierung kann man steuern ob es noch im Cache liegt oder doch nur im VRAM. Jeder Parameter kann vom Treiber abgefragt werden wie gross das Speicherobjekt wird. Das dient nur dazu die BVH Erstellungen auf die jeweilige HW dynamisch anzupassen. Wenn da Murks gemacht wirds läuft es, aber nicht performant.

Heieiei das Ding heisst Minecraft RTX und nicht Minecraft DXR. Das muss man doch verstehen können auch wenn man sonst von DirectX Programmierung keine Ahnung hat.
Es ist doch hoffentlich keiner so blauäugig zu glauben Minecraft RTX wäre nicht auf Nvidia BVH optimiert.

[Platos]

Super Test. Die Tabellem bei der du noch den Perfomance-Index dazu nimmst, ist auch ganz interessant. Da sieht man, dass z.B die 3080 im Vergleich zur 2080 mehr an RT Perfomance zunimmt, als sonst im Perf.-Index. Allerdings hätte ich gedacht, dass es mehr ist. Jetzt sieht man das aber mal genauer.

Diese Art von Tabelle könntest du von mir aus auch in zukünftigen Launchanalysen bringen (wenn es dazu genügend Tests gibt) :biggrin:

Also wie man (wieder einmal) sieht, ist 8GB unter 4k einfach nur noch ein Witz. Mit RT bestätigt sich das aber hier nochmals deutlicher. Was ohne RT heute "erst" in manchen Spielen Probleme verursacht, ist bei RT anscheinend heute schon ein absolutes NO-GO. 10GB wird sich sicherlich auch bald verabschieden.

Aber auch unter 1440p zeigt sich bei 8GB jetzt schon einen spürbaren Perfomanceverlust. Bei der 6600XT verliert man unter 1440p ca. 10% und die 2070s verliert ca. 6%. Also sollte man auch unter 1440p keine 8GB Karte mehr für RT und für eine lange Lebensdauer empfehlen.

Andererseits haben natürlich gerade AMD Karten unterhalb der 6800XT ne ziemlich miese RT Perfomance. Also ist das sowieso noch nicht so wirklich nutzbar. Denn für 4K wird es sowieso nicht so wirklich reichen und Leute, die sich für niedrigere Auflösungen so ne Karte kaufen, wollen vermutlich ne hohe Framerate haben und dann schalten sie vermutlich sicher kein RT ein.

Also gerade bei AMD ist RT immer noch ein sehr theoretischer Faktor. So richtig brauchbar wird RT aus meiner Sicht erst mit Lovelace und (jenachdem wie gut AMD ist) mit RDNA3.

[Gast Ritis]

Das sind keine 'Unstimmigkeiten' sondern reale Usecases, da echte Spiele. Nur weil AMD bei hartem Ray Tracing saugt soll man das weglassen? Minecraft Rtx ist eines der eindrücklichsten RT Spiele bisher. Man sieht u.a. am Artmark dass RDNA nicht besonders gut ist, wenn man die Effektdichte hochzieht: https://www.pcgameshardware.de/Raytracing-Hardware-255905/Specials/ART-Mark-Raytracing-Benchmarks-1371125/

mfg

ART-Mark ist nen zusammengeklicker Bench auf Basis von Unreal Engine 4, als die rudimentären RT-Support hatte.

Keine Ahnung, wer das ernst nehmen will, aber man sollte sich bei Benchmarks immer auch schlau machen was das überhaupt misst.

Das letzte mal wurde im Juni was dran gebastelt, war schon instabil. Das erste entscheidende Unreal-4 Update nach dem first Release vom Dezember kam im August mit 4.27

Wartet doch mal ab, bis das wenigstens auf UE5 nachgebastelt wurde und die Treiber-Teams RT für die aktuelle UE Engine optimieren konnten.
Problematisch bleibt am Ende aber, da wird scheinbar nur RT in extrem gemessen, ist nicht mit Performance typischer Hybrid-Renderer vergleichbar.

[Lehdro]

Es gibt wesentlich mehr Raytracing-Titel mit DLSS Support als ohne, da sind eher letztere die Ausnahme.

Vor allem angesichts der Tatsache, dass DLSS in vielen Titeln sogar eine visuell höhere Qualität aufweist als deren Default AA-Lösung kann man das nur schwer ignorieren.

Man hätte DLSS zumindest als zusätzliche Datenpunkte mit einarbeiten sollen, also z.B. Performance-Index 4k + DLSS, WQHD + DLSS und FullHD + DLSS.

Um es komplett zu ignorieren ist DLSS einfach viel zu gut, und in Raytracing-Titeln wie erwähnt auch ausreichend verfügbar.

Nebenbei entschärft dies auch die Speicherbelastung.
Das Ganze ist aber ein RT Performancevergleich, kein RT+DLSS vs. RT Performancevergleich. Denn darauf würde es hinauslaufen, wenn solche Werte im selben Diagramm auftauchen.

Zudem: Solange die Qualität von DLSS so schwankend ist sollte man damit sowieso vorsichtig sein, denn eine Gleichsetzung von DLSS 1.0 und 2.x ergibt sich automatisch durch Verwendung der Vereinfachung "DLSS". Die Suppe hat sich NV selber eingebrockt, rein marketingtechnisch gehört das deutlicher abgetrennt. Denn technisch ist es eben so: Massiv besser in allen Belangen und eben nicht nur "ein bisschen". Du machst in deinem Text auch keinerlei Unterscheidung zwischen den unterschiedlichen DLSS Revisionen - von daher ist das ganze sowieso nicht wirklich ernstzunehmen, weil in einem Diagramm ohne ausführlichen Kommentar zur jeweiligen Quali pro Game nicht darstellbar. In einem Index schon einmal komplett unmöglich, da nicht quantifizierbar abseits der reinen Leistung. Absurd wenn man bedenkt dass es doch gerade bei RT um Optik geht und dann bei einem DLSS Wert eben dieser, durchaus fluktuierende Faktor, komplett vernachlässigt werden würde.

[WedgeAntilles]

Nein, das ist überhaupt nicht ineffizient. Das ist die Regel. Allein deshalb gibt es in DirectX die Möglichkeit die Hardware und die darauf unterstützten Features abzufragen um dann jeweils in unterschiedlichen Code-Pfaden das Optimum herauszuholen.

Hier gehts auch nicht um einen POC für ne Semesterarbeit sondern um kommerzielle Produkte.

Hättest Du Dir mal die DXR API durchgelesen wäre Dir vielleicht sogar aufgefallen, dass es bestimmte Flags gibt um auf die Eigenheiten einzugehen.
Wenn ich zum beispiel eine GPU habe mit der das Erstellen von BVH relativ schneller als das Tracing geht, dann kann man einen optimierten BVH erstellen lassen, vice versa. Man kann auch dynamische BVH anlegen, die nicht jeden Frame komplett neu berechnet werden, wenn die HW damit umgehen kann (RDNA2). Wenn ein BVH zu gross wird muss man den in den bottom Level teilen und im top Level Instancen. Man kann auch BVHs bauen, die kleiner sind und nicht so viel VRAM benötigen (Nvidia). Über die Speicherallozierung kann man steuern ob es noch im Cache liegt oder doch nur im VRAM. Jeder Parameter kann vom Treiber abgefragt werden wie gross das Speicherobjekt wird. Das dient nur dazu die BVH Erstellungen auf die jeweilige HW dynamisch anzupassen. Wenn da Murks gemacht wirds läuft es, aber nicht performant.

Heieiei das Ding heisst Minecraft RTX und nicht Minecraft DXR. Das muss man doch verstehen können auch wenn man sonst von DirectX Programmierung keine Ahnung hat.
Es ist doch hoffentlich keiner so blauäugig zu glauben Minecraft RTX wäre nicht auf Nvidia BVH optimiert.

Der Punkt ist halt: Wenn AMD will, dass die Entwickler AMD GPUs wichtig nehmen sollte man halt mal einen signifikanten Marktanteil bekommen.
Warum soll ich mich bei nem PC Spiel bei RT an AMD orientieren? Die 0,01% Marktanteil die RDNA2 hat, sind doch völlig uninteressant.

Und die RT Performance kann man bei den AMD GPUs ja sowieso vergessen, weshalb also einen Gedanken an AMD verschwenden? Jedenfalls wenn mein Titel PC only ist.

Da braucht sich AMD doch nicht wundern, wenn manche Entwickler sich nicht weiter dafür interessieren wie es auf AMD GraKas läuft.

[Gast Ritis]

Da braucht sich AMD doch nicht wundern, wenn manche Entwickler sich nicht weiter dafür interessieren wie es auf AMD GraKas läuft.

Nur weil AMD die Henne-Ei Problematik hat sollte man halt einen Index nicht mit Nvidia co-entwickelten RT Titel schmücken. Das verzerrt unnötig.

Schaut euch mal die krasse Liste von AMD und Nvidia an. https://forum.planet3dnow.de/index.php?threads/amd-fidelityfx-fsr-adaption-redux.447106/#post-5354961
Nvidia hat jede Menge RT-Titel am Start, die nicht so alt oder speziell sind. Ganze 12 ohne DLSS, da kann man dann sicher sein, dass es nicht gesponsert ist.
Bei der Liste sieht man aber auch, dass da Titel ganz unterm Mainstream-Radar mit DLSS daherkommen, die Finanzierung darf man dann schon hinterfragen. AMD hat nach 6 Monaten auch nicht zu wenige Softwarepartner für das OSS Modell die auch DLSS anbieten. Es gibt eigentlich genug Auswahl für einen ausgewogenen Index. Die Bechnmarks müssen halt gemacht werden. Dazu müssten die Tester den Marketing-Rucksack ablegen.

[OpenVMSwartoll]

[...]
Und die RT Performance kann man bei den AMD GPUs ja sowieso vergessen, weshalb also einen Gedanken an AMD verschwenden? Jedenfalls wenn mein Titel PC only ist.

Da braucht sich AMD doch nicht wundern, wenn manche Entwickler sich nicht weiter dafür interessieren wie es auf AMD GraKas läuft.

Gerade nach dem gestrigen Artikel erscheint diese Aussage in ihrer Pauschalität seltsam. Ergo kann man die RT-Leistung der 3070 und 3070 Ti auch vergessen?

[Gast]

Um die RT-Leistung besser zu vergleichen, könnte man noch die MRays/s der GPUs angeben:
https://wccftech.com/first-nvidia-rtx-2080-ti-2080-dxr-raytracing-benchmark/

Daraus wird z.B. ersichtlich, wann man auf Hybridrendering verzichten kann. Laut IMG benötigt man für 1080p@60fps über 3 GRays/s (10-fache Performance einer PowerVR 6500 GPU):
https://www.youtube.com/watch?v=tOdaU0u9c3U&t=28m

[Gipsel]

Um die RT-Leistung besser zu vergleichen, könnte man noch die MRays/s der GPUs angeben:
https://wccftech.com/first-nvidia-rtx-2080-ti-2080-dxr-raytracing-benchmark/

Daraus wird z.B. ersichtlich, wann man auf Hybridrendering verzichten kann. Laut IMG benötigt man für 1080p@60fps über 3 GRays/s (10-fache Performance einer PowerVR 6500 GPU):
https://www.youtube.com/watch?v=tOdaU0u9c3U&t=28m
Die maximale Anzahl der pro Sekunde getraceten Rays alleine sagt allerdings auch sehr wenig aus. Zur RT-Performance gehört dann doch noch etwas mehr (wie viele Intersections/s können ausgeworfen werden, was ist der Overhead für einen Shaderaufruf bei einem Hit und all sowas).

[WedgeAntilles]

Gerade nach dem gestrigen Artikel erscheint diese Aussage in ihrer Pauschalität seltsam. Ergo kann man die RT-Leistung der 3070 und 3070 Ti auch vergessen?
Fast jedes RT Game bietet DLSS.
Das aktiviert man bei Nvidia und hat dann auch auf schwächeren Karten gute Frames. So wie es vermutlich 95% aller Spieler mit Nvidia-GraKa tun. Nur hat AMD das ja eben auch nicht.

Es tut mir leid, dass AMD bei diesem Thema so miserabel ist, aber Nvidia ist eben Lichtjahre überlegen bei diesem Bereich.

Dafür ist die Ramausstattung der 3070 und 3080 miserabel.

[Gast]

Die maximale Anzahl der pro Sekunde getraceten Rays alleine sagt allerdings auch sehr wenig aus. Zur RT-Performance gehört dann doch noch etwas mehr (wie viele Intersections/s können ausgeworfen werden, was ist der Overhead für einen Shaderaufruf bei einem Hit und all sowas).

Das ist doch bei den üblichen Angaben zu Speicherbandbreite und Rechenleistung nicht anders. Es wäre eine zusätzliche Information, um die GPUs bei einem Überblick zur RayTracing-Performance besser vergleichen zu können. Man könnte dann zum Beispiel einschätzen, wer diese RT-Leistung in der Praxis besser in hohe FPS umsetzt. Je mehr Informationen dazu vorhanden sind desto besser.

[Gast]

Heieiei das Ding heisst Minecraft RTX und nicht Minecraft DXR. Das muss man doch verstehen können auch wenn man sonst von DirectX Programmierung keine Ahnung hat.
Es ist doch hoffentlich keiner so blauäugig zu glauben Minecraft RTX wäre nicht auf Nvidia BVH optimiert.

Das behauptet auch keiner. Nur kann es nicht die Aufgabe des Softwareentwicklers sein nur weil plötzlich eine neue Hardware kommt das ganze nochmal komplett umzuschreiben.

Es ist die Aufgabe von AMD einen Treiber zu entwickeln, der damit gut klarkommt. Das gilt insbesondere da man überhaupt erst eine Generation später mit DXR-Hardware auf den Markt gekommen ist, wenn die Konkurrenz so viel zeitlichen Vorsprung hat muss man darauf achten mit der Software klarzukommen die bereits am Markt vorhanden ist, und logischerweise auf Konkurrenzhardware entwickelt wurde weil man selbst gar keine anbieten konnte.

Und ja ich verstehe was von Programmierung, damit verdiene ich mein Geld, und ich kann dir sagen, nein wir entwickeln nicht verschiedene Versionen der selben Software nur weil Hardware A mit Version A und Hardware B mit Version B besser klarkommt, das führt langfristig nämlich zu unwartbarer Software und ist niemals eine Gute Idee. Jeder weitere Codepfad verdoppelt die Chancen Fehler einzubauen, und das gilt insbesondere bei der Weiterentwicklung von Software, wenn spätere Änderungen plötzlich in den Unterschiedlichen Codepfaden zu unterschiedlichen Ergebnissen führen können.

[Gast Ritis]

Und ja ich verstehe was von Programmierung, damit verdiene ich mein Geld, und ich kann dir sagen, nein wir entwickeln nicht verschiedene Versionen der selben Software nur weil Hardware A mit Version A und Hardware B mit Version B besser klarkommt, das führt langfristig nämlich zu unwartbarer Software und ist niemals eine Gute Idee. Jeder weitere Codepfad verdoppelt die Chancen Fehler einzubauen, und das gilt insbesondere bei der Weiterentwicklung von Software, wenn spätere Änderungen plötzlich in den Unterschiedlichen Codepfaden zu unterschiedlichen Ergebnissen führen können.

Das ist halt der Unterschied. Entweder ich hole die Performance aus der HW raus und optimiere z.B. selbst innerhalb X86 ISA für einzelne Features wie Cache-Grössen, MMX, FMA4, SSSE oder ähnliches, oder ich ignorier das einfach und helfe im Zweifel Monopole zu betonieren.
Diese Arroganz geht halt auch nur gut solange man die Schuld auf zu langsame CPUs schieben kann und einfach abwartet bis egal zu welchem Preis neue CPUs verfügbar werden.

Bei Handy-Games hat man teils hunderte von Versionen für jegliche Kombi von OS-Version und CPU. Es geht ums Geld bei Massenprodukten. Da kann man dem Kunden nicht ne zertifizierte HW vorschreiben so wie SAP das tut.

Von sich auf andere schliessen ist bei DirectX und DXR und Programmierung kommerzieller Games der falsche Weg. Wer nicht bereit ist seinen Code an die Eigenheiten von HW anzupassen hat aufgegeben bevor er angefangen hat. Solche Leute landen dann unweigerlich bei den Wirtschaftsinformatikern. ;D

[Gast]

Bei Handy-Games hat man teils hunderte von Versionen für jegliche Kombi von OS-Version und CPU. Es geht ums Geld bei Massenprodukten.


Du glaubst wohl nicht ernsthaft, dass Handygames für jeden SoC oder gar jedes potentielle Handy eine eigene Version ausliefern. 🤦*♂️

[Lehdro]

Das behauptet auch keiner. Nur kann es nicht die Aufgabe des Softwareentwicklers sein nur weil plötzlich eine neue Hardware kommt das ganze nochmal komplett umzuschreiben.
Ganz aktuell möchten Intel und Microsoft mit dir sprechen: Die sehen das bei Win11 und ADL gaaaanz anders und daran werden noch viele Programmierer denken müssen, auch so Leute mit deiner Einstellung. Was du dann wohl dazu sagst? Oder ist das dann ok wenn es ein Branchenprimus macht, sonst aber Teufelszeug? Schöne Innovationsbremse bist du, könnte ja sein das ein anderer Weg als eben der Deine die schnellste und beste Lösung darstellt, aber wenn man das nicht einmal probieren will, weil hat man ja schon immer so gemacht, na dann gute Nacht. Sag bitte für wen du arbeitest, vielleicht kann ich Softwareprodukte dieser Firma (falls deine Einstellung auch die der Firma ist) irgendwie vermeiden.

Software heißt zudem nicht ohne Grund Software. Denk mal drüber nach.

[Gast]

Ganz aktuell möchten Intel und Microsoft mit dir sprechen: Die sehen das bei Win11 und ADL gaaaanz anders und daran werden noch viele Programmierer denken müssen, auch so Leute mit deiner Einstellung.


Klar, das ist aber auch Betriebssystementwicklung und keine Anwendungsentwicklung.

Das sind 2 völlig unterschiedliche paar Schuhe, in der Betriebssystementwicklung gibt es selbstverständlich immer noch hardwarespezifische Anpassungen, und ja sogar Assembler wir auf dieser Ebene noch verwendet.

Compilerbau ist auch so ein Anwendungsgebiet, in dem für spezifische Hardware entwickelt wird.

Das hat aber alles nichts mit Anwendungsentwicklung zu tun, in denen du 100% in einer Hochsprache entwickelst, hier erlaubt es die Sprache in der Regel nicht mal einen derartig tiefen Zugriff auf die Hardware.

Genau deshalb gibt es auch Betriebssysteme und APIs, damit der direkte Hardwarezugriff an möglichst wenigen stellen passiert und jeder andere nur über definierte Schnittstellen darauf zugreift.

Ansonsten bräuchten wir das ganze Zeugs gar nicht, und jeder programmiert einfach für sich munter drauf los wie er es am effizientesten hält.

[OpenVMSwartoll]

Das behauptet auch keiner. Nur kann es nicht die Aufgabe des Softwareentwicklers sein nur weil plötzlich eine neue Hardware kommt das ganze nochmal komplett umzuschreiben

Mich würde interessieren, was für Software Du entwickelst. Ich kenne das Konzept der Wartungsverträge auch für SW.

"Aber ich stricke meine Software nicht um, weil sie auf nem Pentium nicht läuft. Sollen die Leute doch die 486er weiter betreiben?"

[Gast]

"Aber ich stricke meine Software nicht um, weil sie auf nem Pentium nicht läuft. Sollen die Leute doch die 486er weiter betreiben?"

Es gibt keinen Grund warum sie nicht laufen sollte.

Ich entwickle gegen eine Hochsprache sollte tatsächlich der unwahrscheinliche Fall eintreten dass die Software plötzlich auf einer x86 neuen CPU nicht laufen sollte braucht es einen neuen Compiler und der selbe Quellcode wird eben durch jenen gejagt.

Vor allem ist das ja auch nicht der Fall, besagte Software ist auf den Radeons, wenn ich mich recht erinnere wurden auch einige APIs von NVs spezifischen APIs auf generische DXR bzw. Vulkan-APIs umgebaut. Mehr kann man auch nicht verlangen, die Software ist überall lauffähig, und dass sie auf AMD schneller laufen könnte kann man zwar nicht ausschließen, ist aber reine Spekulation für die aktuell kaum etwas spricht.

[OpenVMSwartoll]

[...]

Vor allem ist das ja auch nicht der Fall, besagte Software ist auf den Radeons, wenn ich mich recht erinnere wurden auch einige APIs von NVs spezifischen APIs auf generische DXR bzw. Vulkan-APIs umgebaut. Mehr kann man auch nicht verlangen, die Software ist überall lauffähig, und dass sie auf AMD schneller laufen könnte kann man zwar nicht ausschließen, ist aber reine Spekulation für die aktuell kaum etwas spricht.

Also nicht sehr hardwarenah.

[Gast]

Das behauptet auch keiner. Nur kann es nicht die Aufgabe des Softwareentwicklers sein nur weil plötzlich eine neue Hardware kommt das ganze nochmal komplett umzuschreiben.
Aber es sollte die Aufgabe eines Software Entwicklers sein, sich an seinen Kunden zu orientieren. Und da ist RDNA2 dank der Konsolen von Sony und MS eben nicht 0,01% Marktanteil, wie einige hier sich das schön reden, sondern vermutlich deutlich verbreiteter als Ampere. Und da Ampere und Turing auch unterschiedlich im RT sind, ist vermutlich für alle aktuellen Neubauten die logische Ausgangsbasis eben RDNA2, da größter Kundenkreis für Games, die auch auf Konsole kommen. Für PC Only games, ist es vielleicht Turing oder Ampere, aber die meisten Games kommen halt auch auf Konsolen.

[MiamiNice]

Ich empfinde den Überblick als absolut nichts sagend. Im privaten Umfeld, das diese Seite adressiert, kann niemand etwas mit der reinen RT Performance anfangen. Zum einen haben die Karten idr. nicht genug Power, zum anderen wird überall DLSS dazu geschaltet.
Beim normalen Performanceindex sieht man sofort welche Karte schneller ist, bei RT Index muss der User selbst wissen das DLSS XX% mehr FPS liefert.
Der Index war, meiner Erachtens, auch immer dazu da, eine Kaufentscheidung zu treffen. Ohne das man DLSS einrechnet ist der RT Index dafür allerdings nicht zu benutzen.
Mir würde es gefallen wenn bei NV DLSS in der höchsten Stufe eingerechnet wird und bei AMD deren Pendant. Wobei das für NV ziemlich unfair wäre da FSR optisch maximal saugt vs. DLSS. Aber es wären dann wenigstens praxisnahe Werte die auch in der freien Wildbahn erreicht werden.

[Lehdro]

Ich empfinde den Überblick als absolut nichts sagend. Im privaten Umfeld, das diese Seite adressiert, kann niemand etwas mit der reinen RT Performance anfangen. Zum einen haben die Karten idr. nicht genug Power, zum anderen wird überall DLSS dazu geschaltet.
Beim normalen Performanceindex sieht man sofort welche Karte schneller ist, bei RT Index muss der User selbst wissen das DLSS XX% mehr FPS liefert.
Der Index war, meiner Erachtens, auch immer dazu da, eine Kaufentscheidung zu treffen. Ohne das man DLSS einrechnet ist der RT Index dafür allerdings nicht zu benutzen.
Mir würde es gefallen wenn bei NV DLSS in der höchsten Stufe eingerechnet wird und bei AMD deren Pendant. Wobei das für NV ziemlich unfair wäre da FSR optisch maximal saugt vs. DLSS. Aber es wären dann wenigstens praxisnahe Werte die auch in der freien Wildbahn erreicht werden.
Solange nicht ausnahmslos jedes RT Game auch DLSS/FSR bietet ist auch diese Herangehensweise von dir nur eine Krücke, geht aber am eigentlichen Problem vorbei: Mit DLSS und vorallem FSR ist die Bildqualität nicht mehr vergleichbar. Da kommen wir dann wieder bei Äpfeln und Birnen an...

[Platos]

Ne, das wäre schliesslich nur die Abbildung der Relaität. DLSS wird wohl so ziemlich fast jeder unter RT aktivieren, wenn nicht 60 FPS erreicht werden (und falls die Optik dann zu schlecht ist, wird RT erst gar nicht aktiviert).

Für einen Index ist es trotzdem Kacke, da ein Index immer ein Durchschnittswert bildet und somit die Resultate (FPS) in der Praxis sehr unterschiedlich ausfallen könnte und zumindest bei AMD dann überhaupt nicht der Realität entspricht (bei nvidia gibts bei den meisten RT Spielen auch DLSS und ist somit da kein Problem)

[Gast Ritis]

Du glaubst wohl nicht ernsthaft, dass Handygames für jeden SoC oder gar jedes potentielle Handy eine eigene Version ausliefern. 🤦*♂️
Wenn man es erst meint und nicht nur TicTacToe anbietet muss man das. Dazu gabs zum Beispiel von Google Play die APKs mindestens je ABI und genutzte APIs in Versionierung über die Android Versionen.
Das wird durch AAB auch nur im Rollout verbessert, aber der per Device Support Aufwand im Coding bleibt erst mal der gleiche bis sich ne HAL wie Vulkan ordentlich durchgesetzt hat.
Am Ende werden dann aber die Anpassungen auch nur in einem Global-Binary untergebracht und nicht per Device als separates APK ausgerollt.
Viel spass beim einlesen :) https://developer.android.com/google/play/publishing/multiple-apks

[OpenVMSwartoll]

Ne, das wäre schliesslich nur die Abbildung der Relaität. DLSS wird wohl so ziemlich fast jeder unter RT aktivieren, wenn nicht 60 FPS erreicht werden (und falls die Optik dann zu schlecht ist, wird RT erst gar nicht aktiviert).

Für einen Index ist es trotzdem Kacke, da ein Index immer ein Durchschnittswert bildet und somit die Resultate (FPS) in der Praxis sehr unterschiedlich ausfallen könnte und zumindest bei AMD dann überhaupt nicht der Realität entspricht (bei nvidia gibts bei den meisten RT Spielen auch DLSS und ist somit da kein Problem)

Im Gegenteil ist die Betrachtung sehr ehrlich. Es geht um die Leistung der jeweiligen Architektur unter RT. Ohne Schnickschnack, nur die reine RT-Leistung. DLSS und FSR verändern die erzeugten FPS und auch das Bild.

Dass es DLSS noch zusätzlich gibt und NV hier einen Mehrwert bietet, steht dabei doch außer Frage und ist jedem Interessierten bewusst.

[Platos]

Im Gegenteil ist die Betrachtung sehr ehrlich. Es geht um die Leistung der jeweiligen Architektur unter RT. Ohne Schnickschnack, nur die reine RT-Leistung. DLSS und FSR verändern die erzeugten FPS und auch das Bild.

Dass es DLSS noch zusätzlich gibt und NV hier einen Mehrwert bietet, steht dabei doch außer Frage und ist jedem Interessierten bewusst.

Es ist schon richtig, dass man die RT Leistung ohne DLSS misst, aber es bildet dann eben in diesem speziellen Fall überhaupt nicht die Realität ab, da die meisten RT Spiele DLSS unterstützen, aber nicht FSR. Deshalb sollte man beides mittesten, wie eben die PCGH. Zumindest in diesem Fall.

in 1-2 Jahren ist das vlt. nicht mehr nötig. Wobei DLSS unter Umständen unter RT nicht das selbe Plus gibt, wie ohne RT. Also im Idealfall testet man immer beides mit.

Trotzdem ist es etwas mühsam. Früher musste man nur einfach die Gamingleistung anschauen. Heute muss man immer noch die DLSS/FSR als Faktor miteinbeziehen.

Gibt es eig. grossflächige Tests bezüglich Leistungsfähigkeit in DLSS Games?

Das wäre doch auch mal ein Artikel wert, Leonidas :D Eine Auswertung von DLSS Benches. Quasi Durchschnittswerte der DLSS Perfomance in den versch. Modis.

[Leonidas]

Ja, wäre interessant. Vorhandene Datenbasis: Noch geringer als bei RT.

[Gast]

Ja, wäre interessant. Vorhandene Datenbasis: Noch geringer als bei RT.

Höchstens geringfügig, 90% der RT-Spiele bieten DLSS und wenn es verfügbar ist wir es logischerweise auch mitgetestet.

Auch wenn die pure Raytracingleistung technisch sehr interessant ist, und der reine Apples to Apples Vergleich keinesfalls fehlen darf, ist die Praxis nunmal dass man bei Nvidia in aller Regel DLSS mit Raytracing verwenden wird.

Daher wäre es auf jeden Fall gut wenn man jenes zusätzlich mit aufnehmen könnte, zumindest ein DLSS-Q Index in jeder Auflösung wäre auf jeden Fall wünschenswert, wenn man noch mehr Einstellungen dazu nimmt wird es denke ich zu Aufwändig und auch unübersichtlich.

Dann könnte jeder darauf schauen was er möchte, die "nur native Pixel sind echte Pixel" Fraktion hätte einen Index, und es gäbe auch einen Index der den tatsächlichen praktischen Unterschied anzeigt.

[Leonidas]

Spiele bieten es, aber ich redete davon, wieviele Tests hierzu vorliegen. Und das ist deutlich weniger als RT. DLSS wird gern nur exemplarisch getestet - weit zu gering für eine Index-Erstellung.

[Gast]

Spiele bieten es, aber ich redete davon, wieviele Tests hierzu vorliegen. Und das ist deutlich weniger als RT. DLSS wird gern nur exemplarisch getestet - weit zu gering für eine Index-Erstellung.

Also ich kann bei so ziemlich jedem Spieletest mit einem RT-Spiel und DLSS Unterstützung auch entsprechende Benchmarks finden.

Die fehlen höchstens bei Spielen die DLSS erst nach dem Launch per Patch nachgereicht bekommen.

[Leonidas]

Jein, das ist nicht gemeint. Gemeint sind zusammenhängende Benchmark-Felder derselben Quelle (auf selbem System) mit jeweils extensiver Grafikkarten-Auswahl. Alles andere kommt für eine solide Performance-Auswertung kaum in Frage.

[Platos]

Spiele bieten es, aber ich redete davon, wieviele Tests hierzu vorliegen. Und das ist deutlich weniger als RT. DLSS wird gern nur exemplarisch getestet - weit zu gering für eine Index-Erstellung.

Das habe ich bisher auch so erlebt, aber ich habe gehofft, dass ich nur nocht genug gesucht habe.

[Leonidas]

Kommt mit der Zeit.