News FSR 2.0: AMD nennt Details zu Auflösungen, Technik und Aufwand

projectneo schrieb:
FSR 2.0. muss komplett neu implementiert werden. Es wäre aber möglich, dass CDPR dies auch tut.
Cyberpunk wäre ja ein gutes Beispiel für die "<3 Tage" Implementierungszeit, weil es hier schon DLSS 2.x gibt.
Ergänzung ()

Vigilant schrieb:
Hat es auch immer noch, selbst mit 2.4.
Und mir sind sie nicht mal mit der Releaseversion aufgefallen bis ich darüber gelesen und gezielt danach gesucht hab^^ Wie schön, dass ich da scheinbar nicht so empfindlich bin. Wenn es also so aussieht wie DLSS 2.3 ist alles in Ordnung für mich.
 
  • Gefällt mir
Reaktionen: Grundgütiger, jdiv, Wintermute und 3 andere
whyme schrieb:
Das ist das Zauberwort.

Lasst uns erstmal die Digital Foundry Analysen abwarten, die komplett branding agnostisch sind und FSR 2.0 sezieren werden.
Bzw NATÜRLICH die Computerbase Analyse! :)

DANN sehen wir, ob es DLSS 2.x wirklich ersetzen kann.
 
  • Gefällt mir
Reaktionen: Wintermute
Laphonso schrieb:
Lasst uns erstmal die Digital Foundry Analysen abwarten, die komplett branding agnostisch sind und FSR 2.0 sezieren werden.
Du meinst Digital Foundry mit Alex, der keine Gelegenheit auslässt um gegen FSR zu wettern und DLSS in den Himmel zu loben?
Ganz ehrlich, DF wären die letzten die ich mir zum Thema FSR ansehen würde.
 
  • Gefällt mir
Reaktionen: Grundgütiger, Shy Bell, Freiheraus und 5 andere
Taxxor schrieb:
Cyberpunk wäre ja ein gutes Beispiel für die "<3 Tage" Implementierungszeit, weil es hier schon DLSS 2.x gibt.
Wenn DLSS läuft, dann ist der größte Aufwand das in das Settings- Menü zu implementieren.... Als Target für die Buffer gibst Du dann nicht die NVIDIA API an, sondern die von AMD.
AMD hat letztendlich genau das gemacht, was ich hier schon vor einiger Zeit schrieb.

Einfach den eigenen Proxy für die DLSS zur verfügung gestellten Daten bauen.

Ich zitiere mich mal selbst:
.Sentinel. schrieb:
Die Schnittstellen, die DLSS nutzt, sind bereits jetzt auch für alle anderen Hersteller nutzbar.
Aufgrund des modularen Ansatzes von NVIDIA müssten die Hersteller noch nichtmal eigens Änderungen an der Software vornehmen. Sie müssten nur die proxy- Bibliothek der Titel, die DLSS unterstützen austauschen/erweitern.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Dgini
.Sentinel. schrieb:
Wenn DLSS läuft, dann ist der größte Aufwand das in das Settings- Menü zu implementieren....
Was ja, da es auch FSR 1.0 implementiert hat, bereits vorhanden ist^^
 
  • Gefällt mir
Reaktionen: .Sentinel.
Taxxor schrieb:
Du meinst Digital Foundry mit Alex, der keine Gelegenheit auslässt um gegen FSR zu wettern
Ich meine Digital Foundry, die im jüngsten Video größte Hoffnungen auf FSR 2.0 setzen und dem ganzen Block 10 Minuten widmen.


Du solltest weniger selektiv wahrnehmen, Taxxor :P
 
  • Gefällt mir
Reaktionen: Pro_Bro, jdiv und DrFreaK666
@Laphonso hab es erst gesehen, als er es in Zeitlupe vergrößert gezeigt hat. Danach zurückgespult und jetzt sehe ich es überall im Video :D
 
  • Gefällt mir
Reaktionen: Laphonso
Rikimaru schrieb:
@Laphonso hab es erst gesehen, als er es in Zeitlupe vergrößert gezeigt hat. Danach zurückgespult und jetzt sehe ich es überall im Video :D
SORRY Bro :D 😂

Ja, wenn man nicht drauf achtet, ist es unkritisch.

FSR und DLSS haben das Ghosting und diese Artefakte letztlich als größte "Baustelle" im Rahmen der temporalen Vektoren/Komponenten.

Wenn dieser Endboss gelegt wird, haben wir echt einen Durchbruch.
 
  • Gefällt mir
Reaktionen: Rikimaru und .Sentinel.
Laphonso schrieb:
Ich meine Digital Foundry, die im jüngsten Video größte Hoffnungen auf FSR 2.0 setzen und dem ganzen Block 10 Minuten widmen.

Ich bin auch froh, wenn wir endlich von diesem nativen Bruteforce- Rendering wegkommen. Das kann keiner, der sich ein wenig mit der Materie beschäftigt schlecht finden, was da gerade für eine Transformation stattfindet...
 
  • Gefällt mir
Reaktionen: Zer0Strat, random12345 und Laphonso
Was viele nicht verstehen, ein temporales UpScaling braucht nicht notwendiger Weise ein Tensorflow Model, um gute Ergebnisse zu produzieren. Das Model, welches NVidia einsetzt ist ja auch ein generisches Model, also für alle Spiele gleich. Es hat also keinen Vorteil gegenüber einem statischem Algorithmus.

Das Zuweisen von Upscaling Mechaniken auf die Motion Vectors, kann genauso gut ein handgeschriebener Algorithmus übernehmen. Der Unterschied ist: NVidia kann in Rechenzentren sein Tensorflow Model optimieren lassen, während AMD Algorithmen manuell anpassen muss. Hört sich nach einem großen Vorteil an, aber jeder der schon mal mit ML gearbeitet hat, weiß dass das validieren der Daten um das Tensorflow Training effizient zu gestalten, sehr komplex werden kann. Auch kann man mit einem handgeschrieben Algorithmus bestimmt Opimierungen einbauen, die ein generiertes Model nicht unbedingt enthält.

Meiner Meinung nach: Solange NVidia keine optimierten Modelle pro Spiel ausliefert, ist es nicht wirklich ein technischer Vorteil. Für die Spielehersteller eher ein Vendor Lock, den ich vermeiden möchte.

https://community.amd.com/t5/gaming...d-fidelityfx-super-resolution-2-0/ba-p/516395
 
  • Gefällt mir
Reaktionen: Schinken42, Grundgütiger, Shy Bell und 4 andere
DevPandi schrieb:
Verringerst du die Auflösung im 50 %, dann meint man damit in der Regel, dass die Auflösungen der Achsen um 50 % verringert wird, hier also 3860 auf 1980 und 2160 auf 1080. Damit ist die Auflösung um 50 % verringert, die Pixelmenge hat man geviertelt.

Wenn du die Auflösung als Anzahl der absoluten Anzahl an Pixel verstehst, dann hast du wiederum recht, dann sind es nur noch 25 %.
Nein 50% ist falsch. Da es im Zusammenhang mit verringertem Rechenaufwand steht. FullHD ist 25% von UHD. Der Computer berechnet Pixel.
mibbio schrieb:
Die 50% beziehen sich wohl einfach darauf, dass die Werte (3840 & 2160) jeweils halbiert wurden und nicht auf die Menge der Pixel.
50% ist falsch. Siehe oben.
 
.Sentinel. schrieb:
Danke an NVIDIA, dass die das Ganze überhaupt erst ins Rollen gebracht haben, den Vorreiter gespielt haben und für AMD kostenlos die Basis geschaffen haben, bei vielen Titeln nun ihr eigenes Verfahren einbringen bzw. nachrüsten zu können.

Da merkt man mal wieder, dass proprietäre Software einfach oftmals der Innovationstreiber bleibt.
Einmal das, und das Tolle auf der anderen Seite ist, dass nun wieder Nvidia - dank AMD und sofern FSR 2.0 mit DLSS 2.x gleichzieht - nachlegen (bzw. dann wieder vorlegen) muss mit einer "DLSS 3.0 Lösung", um die Premiumpreise und die Tensorarchitektur zu rechtfertigen
 
whyme schrieb:
Vorausgesetzt FRS2.0 bietet eine ähnliche Qualität/Performance wie DLSS, wäre es dann schlimm, wenn DLSS nicht mehr verwendet werden würde? Der einzige Vorteil den DLSS aktuell noch bietet ist das alleinstellungsmerkmal, zu kosten des Vendor locks.

Grundsätzlich wäre das natürlich denkbar. Knackpunkt ist wirklich, dass es qualitativ gleichwertig und gleich schnell sein muss.
Dann würde NVIDIA natürlich wohl gerne einen Teil der FSR2.0 Berechnungen wie bei DLSS auch auf die Tensor- Cores umlagern, die entsprechende Aufgabe schneller erledigen.

Und da sehe ich ein Problem. Wie AMD mit der Veröffentlichung anderer APIs gezeigt hat, ist der open source modus nicht als "zuarbeitbar bzw. weiterentwickelbar" zu verstehen, sondern muss für jede Implementation von 0 auf beim Entwickler wieder vom Original angepasst werden. An der Basis des Codes der verteilt wird, durfte bis jetzt keiner rumpfuschen.

Insofern ist das "open source" des ganzen nicht so open, wie man sich das wünschen würde.
 
Zuletzt bearbeitet:
Taxxor schrieb:
Und mir sind sie nicht mal mit der Releaseversion aufgefallen bis ich darüber gelesen und gezielt danach gesucht hab^^ Wie schön, dass ich da scheinbar nicht so empfindlich bin. Wenn es also so aussieht wie DLSS 2.3 ist alles in Ordnung für mich.
Problem bei Ghosting, what has been seen cannot be unseen^^
Bei WoT ist mir Anfangs das Ghosting von TAA auch nicht aufgefallen. Irgendwann hattte ich bemerkt, das Bäume umfahren starkes Ghosting hervorruft, aber da war es Omnipräsent
ABER Ghosting lieber als Aliasing
Ergänzung ()

Laphonso schrieb:
Lasst uns erstmal die Digital Foundry Analysen abwarten, die komplett branding agnostisch sind und FSR 2.0 sezieren werden.
Das war Sarkasmus oder?
 
  • Gefällt mir
Reaktionen: Schinken42, Shy Bell, eXe777 und eine weitere Person
random12345 schrieb:
Nein 50% ist falsch. Da es im Zusammenhang mit verringertem Rechenaufwand steht. FullHD ist 25% von UHD. Der Computer berechnet Pixel.
... ich würde ja mal an der Stelle empfehlen dir zu lesen, was ich geschrieben habe, dann wäre dir vielleicht aufgefallen, dass ich auf den Umstand eingegangne bin, über denn du nun meinst mich und eben so Mibbio zu belehren.

Deine Ausführung ist nicht falsch, sie ist aber auch nicht richtig. Ebenso sind die 50 %, von denen hier gesprochen wird genauso wenig richtig oder falsch und die 25 % sind auch nicht richtig oder falsch, sondern es kommt auf den Bezugspunkt an und was man nun mit Auflösung wirklich meint und je nach dem, was man nimmt, sind beide Zahlen richtig.

Man kann nun mit der Auflösung entweder das Produkt aus x * y meinen, also die Pixelmenge die berechnet wird, oder man sieht x * y als einen Vektor an [x,y] der die Dimensionen beschreibt.

Umgangssprachlich meint man mit Auflösung in der Regel die Dimensionen, der die Anzahl der Pixel in der X und Y Achse angibt. Halbiere ich die Auflösung, dann halbiere ich nicht das Produkt aus x * y, sondern ich halbiere den Raum sowohl in der X und Y Achse. Also 0,5 * [x,y].

Halbiere ich die Dimensionen [3840, 2160], dann kommt [1920,1080] bei raus. Die Menge der zu berechnenden Pixel viertelt sich in dem Fall - also deine 25 %.

Das heißt, die 50 % sind auf die Dimensionen der Auflösung absolut richtig, die 25 % sind auf das Produkt bezogen richtig und damit kommen wir zur ursprünlichen Aussage:

Es kommt darauf an, was gemeint ist. Meint @Wolfgang oder AMD die Dimensionen der Auflösung, dann sind die 50 % richtig, würden sie die Menge der Pixel als Auflösung meinen, dann sind die 50 % falsch und eure 25 % sind richtig.

Statt also jedes mal zu meinen, man wäre die einzige Person, die Ahnung hat und man muss alle andere belehren: Mal nach fragen und etwas nachdenken! Danke!
 
  • Gefällt mir
Reaktionen: Schinken42, Pro_Bro, Poati und eine weitere Person
Laphonso schrieb:
Das ist ja durchaus eine gewisse Ironie: "Am einfachsten zu integrieren soll FSR 2.0 sein, wenn ein Spiel schon DLSS 2.0 unterstützt".
:D

FSR 2.0 als Motor für die DLSS Implementation?
Unglaublich, AMD profitiert von einer pRoPRietÄRen Lösung! :D

.Sentinel. schrieb:
Danke an NVIDIA, dass die das Ganze überhaupt erst ins Rollen gebracht haben, den Vorreiter gespielt haben und für AMD kostenlos die Basis geschaffen haben, bei vielen Titeln nun ihr eigenes Verfahren einbringen bzw. nachrüsten zu können.
...und für Intel. ^^
 
Zuletzt bearbeitet von einem Moderator:
  • Gefällt mir
Reaktionen: foo_1337 und ThePlayer
DevPandi schrieb:
Mal nach fragen und etwas nachdenken! Danke!
Dan les dir nochmals die Kommentare durch, danke. Die Renderauflösung ist eben nicht 50% sondern 25%. Dem Computer ist egal ob die die X oder Y Achse halbierst, er muss so oder so alle Pixel berechnen deswegen stimmen auch nur die 25%.
 
Vigilant schrieb:
Hat es auch immer noch, selbst mit 2.4.
2.4 gibt's noch nicht. Das Ghosting Problem wurde kürzlich mit der 2.3.9 weitestgehend behoben.

1648121150538.png
 
Zuletzt bearbeitet von einem Moderator:
  • Gefällt mir
Reaktionen: foo_1337 und Vigilant
bad_sign schrieb:
Das war Sarkasmus oder?
Nein, einfach das Video von gestern anschauen.

Dass DLSS 2.x der FSR 1 Matsche überlegen ist, legen einige ernsthaft den FD Analysen (die das damit ebenso wie HU oder sogar Computerbase illustrieren) gegenüber als "contra AMD" aus, während sogar das AMD Subreddit, also die Hochburg der AMD Fanboys, das ebenso sieht (FSR 1 = fail, DLSS 2 = Maßstab)
 
  • Gefällt mir
Reaktionen: fairlane24 und Pro_Bro
Laphonso schrieb:
Dass DLSS 2.x der FSR 1 Matsche überlegen ist, legen einige ernsthaft den FD Analysen (die das damit ebenso wie HU oder sogar Computerbase illustrieren) gegenüber als "contra AMD" aus, während sogar das AMD Subreddit, also die Hochburg der AMD Fanboys, das ebenso sieht (FSR 1 = fail, DLSS 2 = Maßstab)

Wobei man dazu sagen muss, dass AMD selbst FSR 1 nie als direkten Gegenspieler zu DLSS gestellt hat.
Die User haben das nur immer unterstellt, dass es der Gegenpart wäre.
Ist also eher mal wieder ein hausgemachtes Problem der Fanbase.

FSR 1 funktioniert technisch betrachtet sogar erstaunlich gut und ist alles andere als ein Fail.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Schinken42, Shy Bell, Peacemaker1337 und 4 andere
Zurück
Oben