Test F1 22 mit Patch 1.17 im Test: AMD FSR 2.2, FSR 1, Nvidia DLSS 2.4 & 3 fahren um die Wette

Das ist es auf jeden Fall, aber man kann eben Beispiele finden, wie meins mit der Brücke, wo die Technik eben etwas braucht, um Strukturen korrekt darzustellen. Es ist ein nach wie vor ein verlustbehaftetes Verfahren weil ein geringer aufgelöstes Bild den Input bildet. Da beißt die Maus keinen Faden ab, und in sofern kann es nie 100% bugfrei sein. Das war mein Punkt. Wohlwissend, dass diese Technik es in den meisten Fällen schafft, ein besseres Bild als das native zu erzeugen. Gerade Control fand ich ungeheuer beeindruckend. Ich bin echt Fan von der Technik. Aber die Limitierungen kann man nicht einfach leugnen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: MountWalker
Taxxor schrieb:
Es werden keine Strukturen erkannt und geschätzt wie sie aussehen müssten, das war der allererste Ansatz von DLSS 1.0
...
Der "KI"-Part bei DLSS2 betrifft einfach nur die Art, wie der dafür verwendete Algorithmus entstanden ist und weiterentwickelt wird. Während man DLSS mit der GPU nutzt, ist keine KI am Werk.
Das stimmt aber nicht, ansonsten würde es keinen Sinn ergeben, wieso sich das native und das DLSS 2 Bild in Metro Exodus so unterscheiden:
Nativ: https://images.cgames.de/images/gam...-4k-rt-ultra-dlss-aus-400-prozent_6137185.jpg
DLSS: https://images.cgames.de/images/gam...t-ultra-dlss-qualität-400-prozent_6137184.jpg

DLSS erkennt hier eine Brücke und entfernt deswegen die Gebäude und Barrikaden im inneren.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: MountWalker, JohnWickzer und Grimba
Ich vermute mal, dass es etwas mit der LoD Distanz oder anderen Settings zu tun hat, die hier bei der DLSS Implementierung verkackt wurde und die Sachen deshalb auf dieser Entfernung einfach nicht dargestellt werden.

Da wurde keine Brücke von einer KI rekonstruiert anhand von Annahmen wie eine Brücke aussehen müsste.
Dann müsste sich das Bild ja auch ständig unter enormen Bildfehlern verändern, je näher man ran geht weil es ja irgendwann nicht mehr zu leugnen wäre, dass da noch mehr ist als nur eine Brücke.

Wenn es an den Settings liegt, würden die Sachen hingegen ab einer gewissen Entfernung einfach plötzlich aufploppen, kann ja gerne jemand Testen der das Spiel hat^^
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Wintermute, msv, incurable und 3 andere
Ich würde eher vermuten, dass nach wie vor KI oder vielmehr neuronale Netze am Werk sind, zusätzlich zu den neuen vektorbasierten Verfahren. Sowas schmeißt man doch nicht weg. Da man es hier sowieso grundsätzlich mit einem Fall zu tun hat, wo am Ende zwangsläufig Schätzwerte herauskommen müssen, bietet sich sowas doch geradezu an. Jetzt mal unabhängig von Heisenbergs Brückenbeispiel.
 
  • Gefällt mir
Reaktionen: MountWalker
DLSS2.x macht im Grunde rein gar nichts anders als was FSR2.x auch macht, der Algorithmus ist festgelegt, daher kann man ihn ja auch in beiden Fällen durch Austausch der dll Datei verbessern, wenn es neue Versionen gibt.

Und diese neuen Versionen werden bei DLSS eben durch KI Unterstützung erzeugt, bei FSR von Hand.
Der DLSS Algorithmus ist aber insgesamt aufwendiger und dürfte auch mehr Samples nutzen als FSR, wodurch der Performancegewinn geringer ausfallen würde, wenn man es rein auf den Shadern laufen lässt.
Dadurch, dass die Tensor Kerne ihn beschleunigen können, ist man dann aber am Ende trotzdem ca gleich schnell wie FSR
 
  • Gefällt mir
Reaktionen: Wintermute und .Sentinel.
Taxxor schrieb:
Algorithmus ist festgelegt, daher kann man ihn ja auch in beiden Fällen durch Austausch der dll Datei verbessern
Das hat nichts damit zu tun, ob KI oder NN oder nichts. Die Austauschbarkeit der DLL alleine ist kein hinreichendes Kriterium für eventuelle Abwesenheit von KI/NN oder die Festgelegtheit des Algorithmus. Den könntest du theoretisch mit jeder neuen DLL komplett austauschen solange du die Schnittstelle nicht brichst.
 
Zuletzt bearbeitet:
Grimba schrieb:
Das hat nichts damit zu tun, ob KI oder NN oder nichts .... Den könntest du theoretisch mit jeder neuen DLL komplett austauschen solange du die Schnittstelle nicht brichst.
Korrekt- Jedoch ist Taxxors Gedanke dahinter (und das ist glaube ich der springende Punkt), dass das "neuronale Netz für die Gewichtung", bzw. der Algorithmus der bei DLSS für das Pixel- Clamping zuständig ist, feststehend ist.
Es ist also nicht so, dass die AI dort laufend analysiert, lernt und an irgendwelchen Strukturen rumpfuscht, sondern dass es nach einem antrainierten Muster eben wiederum andere Muster auflöst.
Ergänzung ()

Grimba schrieb:
Das ist es auf jeden Fall, aber man kann eben Beispiele finden, wie meins mit der Brücke, wo die Technik eben etwas braucht, um Strukturen korrekt darzustellen. Es ist ein nach wie vor ein verlustbehaftetes Verfahren weil ein geringer aufgelöstes Bild den Input bildet.
Das ist bei Frame 1 bei einem harten Schnitt wie z.B. einem Szenenwechsel der Fall. Erst ab Frame 3 der Bildausgabe bewegt man sich sampletechnisch im Schnitt überhalb der nativen Zielauflösung.

Ihr müsst mal wegkommen von Auflösung bzw. dem Pixeldenken. Das existiert in den vektorbasierten Szenendaten nämlich so nicht. Rastern macht ja nichts anderes als ein punktuelles Samplen der Szene und Farbwertsanpassung in entsprechender Matrix, die der Auflösung entspricht. Da liegt der Sample aber oft genug auch ungünstig bzw. produziert einen fehlerhaften Output, wenn die Gewichtung nicht passt.

Supersampling, wie es DLSS und FSR temporal betreiben nehmen für einen Pixel dann nicht einen Sample, um den Farbwert zu bestimmen, sondern mehrere Samples aus den Szenendaten darauffolgender Bilder, weswegen eben Strukturen "plötzlich" erscheinen können, die vorher in der Bestimmung des Farbwertes für das Pixel innerhalb des Auflösungsrasters untergegangen wären. Um auch Standbilder in den Genuss der supersampling- Auflösung zu bringen, wird die Sampleposition pro Frame zudem gejittert (halton sequence).
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Wintermute und Zer0Strat
.Sentinel. schrieb:
Es ist also nicht so, dass die AI dort laufend analysiert, lernt und an irgendwelchen Strukturen rumpfuscht, sondern dass es nach einem antrainierten Muster eben wiederum andere Muster auflöst.
Natürlich braucht man ein fertig trainiertes NN für solche Zwecke. Das Anlernen eines solchen zur Laufzeit wäre vermutlich aus zeitkritischen Gründen unmöglich. Aber die Aussage war ja, dass das nur bei 1.0 war und später gar nicht mehr stattfindet. Der Meinung bin ich nicht. Ich hatte ja gesagt, es wird versucht Muster zu erkennen. Ich meinte im Sinne von bekannte Muster erkennen, also etwas, was schon erlernt ist. Wir meinen hier also dasselbe.
 
kaka11 schrieb:

Es kann dir schlichtweg egal sein, wenn es weniger echte Frames sind, aber die Latenz trotzdem besser ist. Was zählt ist, wie schnell eingaben umgesetzt werden und wie flüssig es wirkt. Das sind die einzigen zwei Parameter auf denen bisher die Framerate auswirkungen hatte. Und beides profitiert hier durch FG.


Klar könnte man jetzt argumentieren, dass mit deaktiviertem FG jedoch aktiviertem Reflex die Latenz noch niedriger wird, allerdings muss man festhalten, dass Reflex bisher fast ausschließlich bei kompetitiven Games integriert wurde. Bei Singleplayer Games kam das bisher kaum zum Einsatz. Das wird sich mit DLSS3 schnell ändern, da Reflex pflicht ist.

Ich verstehe Deine Argumentation nicht. Da durch die Zwischenbildberechnung in allen bekannten praktischen Szenarien die CPU-Frames sinken erhöht sich zwangsläufig die Latenz gegenüber DLSS 2.x (welches ich gerne nutze).

Wenn nun Reflex nur noch exklusiv mit DLSS 3 implementiert wird, um es latenzseitig gegenüber DLSS 2 besser dastehen zu lassen, wäre das aus meiner Sicht wieder mal ein typischer nVidia Move 🧐
 
Zuletzt bearbeitet:
Wolfgang schrieb:
Denn, "ich habe 100 FPS mit FG" und "ich habe 100 FPS mit DLSS 2" (zum Beispiel) sind eben nicht dasselbe in der Performance.
Man hat aber mehr FPS mit FG. Verlgeiche mit identischer Bildrate machen wenig Sinn meiner Meinung nach. Man hat eine geringere Latenz dank Reflex und die Vorteile einer höheren Bildrate, höhere Schärfe, besseres Sampling bei schneller Bewegung und flüssigere Animationen.

Als ich The Witcher 3 NextGen auf dem 5800X3D gespielt hatte, da hat FG zur einem flüssigen Spieleerlebnis geführt, während es sich ohne FG ziemlich hackelig angefühlt hat. Seit dem verwende ich den Begriff Killerfeature. ^^
 
Taxxor schrieb:
Das stimmt zwar, aber wie gesagt, wen die Latenz von Nativ bereits nicht stört, dem wird es auch nicht störend auffallen, wenn es mit FG nur 10ms und mit DLSS2 Quality dann 30ms weniger sind.

Es wird ja oftmals so dargestellt, als würde man mit FG zwar mehr FPS als Nativ bekommen, aber es würde quasi gar nichts bringen bzw. sich sogar schlechter anfühlen, weil die Latenz gleichzeitig nach oben geht.
Das ist zwar richtig, aber es fühlt sich eben nicht gleich an.
Wenn die Latenz ohne Reflex nicht stört, dann stört sie auch mit FG + Reflex nicht ist ein anderes Thema als 100 FPS DLSS 2 sind wie 100 FPS DLSS 3. Und das liegt dann eben doch an der Latenz, die mit FG eben schlechter ist als ohne FG Auch ohne Reflex bei DLSS 2 sind die latenzen bei der FG oft schlechter.

Zer0Strat schrieb:
Als ich The Witcher 3 NextGen auf dem 5800X3D gespielt hatte, da hat FG zur einem flüssigen Spieleerlebnis geführt, während es sich ohne FG ziemlich hackelig angefühlt hat. Seit dem verwende ich den Begriff Killerfeature. ^^
The Witcher 3 ist aber halt auch völlig kaputt aktuell. Das sollte man nun nicht großartig bei einer generellen mit ein beziehen. Das was du beschreibst, ist in The Witcher 3 zwar richtig, liegt aber quasi nicht an FG, sondern schlicht an einem krassen Bug im Spiel.
 
  • Gefällt mir
Reaktionen: Wintermute
Wolfgang schrieb:
Und das liegt dann eben doch an der Latenz, die mit FG eben schlechter ist als ohne FG Auch ohne Reflex bei DLSS 2 sind die latenzen bei der FG oft schlechter.
In dem Fall hier bringt SR Quality ja sogar mehr FPS als FG, was ich auch schon komisch finde. Deshalb ist die Latenz auch niedriger als mit FG.
Ich schätze mal, wenn SR Quality auf die gleichen FPS wie FG kommen würde, also 85 statt 95, dann läge dessen Latenz auch irgendwo bei ~50-55ms(grob geschätzt anhand des Latenz-Unterschieds zwischen DLSS Quality und DLSS Performance sowie Nativ und DLSS Quality).

Das sind zwar immer noch ~15-20ms weniger als Nativ+FG, dafür erhält man je nach DLSS Implementierung evtl ein besseres Bild, umgeht ein potenzielles CPU Limit und hat auch generell weniger CPU Verbrauch.

Und ich glaube persönlich wie gesagt nicht, dass so arg vielen Leuten ein Unterschied zwischen 55ms und 70ms Latenz auffallen würde und selbst wenn dann nur im direkten Vergleich, bei dem man sich dann innerhalb weniger Minuten an das eine oder das andere gewöhnt hat.

Aber es gibt ja eigentlich keinen Grund, nicht generell beides zu nutzen, wenn man kann, das wäre dann hier nur noch ein Latenzunterschied von gerade mal ~8ms ggü reinem SR Quality bei dafür flüssigerem Bild.

Ich habe, wenn das Spiel FG bietet, immer beides an, SR Quality und FG, aber eben auch einen FPS Limiter, somit verringert bei mir DLSS2 auch meist nur den Stromverbrauch aber nicht die Latenz.
 
Zuletzt bearbeitet:
Wolfgang schrieb:
The Witcher 3 ist aber halt auch völlig kaputt aktuell. Das sollte man nun nicht großartig bei einer generellen mit ein beziehen. Das was du beschreibst, ist in The Witcher 3 zwar richtig, liegt aber quasi nicht an FG, sondern schlicht an einem krassen Bug im Spiel.
Krasser Bug?! The Witcher 3 NextGen verwendet halt einen DX11ToDX12 Wrapper und ist daher ziemlich stark CPU-limitiert. FG hilft schlicht dabei, das Problem zu lösen.

Dann nimm Spider-Man stattdessen. Das fühlt sich mit einem 3700X auch hackelig an, mit FG dagegen nicht mehr.
 
Das sollte aber nicht Sinn und Zweck von FSR 2 sein, dass FSR 1 kaum schlechter oder sogar gleichwertig ist. Hier haben die Spieleentwickler wohl eine schlechte Arbeit abgeliefert.
 
Frame Generator in F1 22 finde ich Katastrophe. Gerade in den Kurven, wenn sich im Hintergrund die Landschaft mit Bäume sich seitlich bewegt, entstehen hässliche Klötzchenbildungen/Fehlberechnungen. Mit DLSS ohne Framegenerator ist es flüssiger und besser. Da muss Nvidia noch einiges verbessern.
 
Zurück
Oben