AMDs FidelityFX Super Resolution 2.0/3.0/4.0 (FSR 2.0, FSR 3.0, FSR 4.0)

[Relex]

Zu Mantle kennen wir die internen Details nicht, aber Mantle wurde Ende 2013 vorgestellt und DX12 anfang 2014.

Da DX Änderungen mit allen Herstellern Jahre im Voraus abgesprochen werden, wussten ja alle Hersteller längst bescheid.

Laut Wikipedia war es ein Frostbite Entwickler, der sich schon seit 2008 für eine Low Level Schnittstelle eingesetzt hat und dann mit AMD einen partner gefunden hat, der das frühzeitig umsetzen wollte.

Aber offensichtlich war bei diesen Bestrebungen auch Microsoft mit im Boot. Schließlich haben die Frostbite Entwickler auch bei DX11.1 mitgewirkt, was in BF4 damals deutliche Performancevorteile gegenüber DX11 brachte und teilweise wenn ich mich recht erinnere gleich schnell mit Mantle war? Gab dazu ja mal PCGH Benchmarks, aber ich finde sie nicht mehr.


Sieht also ziemlich klar danach aus, als wäre Mantle und DX12 quasi von den selben Leuten , also hauptsächlich wohl dem Frostbite Team initiiert worden. AMD hat mit Mantle halt versucht dem Markt zuvor zu kommen bzw. wahrscheinlich früher mit den arbeiten begonnen, bevor Microsoft, Nvidia und intel sich bewegt haben.


Natürlich ist schwer zu sagen, wer da jetzt den größten Anteil dran hatte. Dass AMD mit Mantle früher kam kann man ihnen hoch anrechnen. Immerhin haben sie den Bedarf nach Anfrage von DICE früher erkannt. Aber da DX12 eh schon in den Startlöchern stand und offensichtlich längst beschlossene Sache war könnte man Mantle auch als simplen Frühstart abtun. Wenngleich mit Vulkan dann ein wichtiger plattformübergreifender Standard daraus wurde.

AMD hat da natürlich alles richtig gemacht, aber dass DX12 so kurz danach kam hinterlässt irgendwie schon nen leicht trübenden Eindruck.


Das wirkt halt auf mich als wenn man in ner Vorstandsrunde ne Entscheidung diskutiert und ausplant und einer sich dann selbstständig macht und es vor allen anderen umsetzt. :freak:

Na ja, wer weiß schon was es da damals an Unstimmigkeiten und Reibereien gab... Ich stell es mir jedenfalls nicht ganz einfach vor, alle GPU Hersteller an einen Tisch zu bringen und künftige Standards auszuarbeiten.

[Oranje7]

Mantle ist 2013 erschienen in Battlefield und DirectX 12 wurde 14 angekündigt und erste spiele waren so 2016

Bitte nicht würfeln...

[horn 12]

Ja, etwas später mit Thief 4 - der Meisterdieb!
War eines der Ersten, wenn nicht gar das Erste Game mit Mantle Support!

https://www.google.com/search?q=Thief+4&sca_esv=aef7960d6ac611d8&source=hp&ei=YkMjabTBDP-6i-gP1smu0QY&iflsig=AOw8s4IAAAAAaSNRcn1xgPZSKQ5ATVK-xw-04atJVQHA&ved=0ahUKEwi0-sSX5YiRAxV_3QIHHdakK2oQ4dUDCA4&uact=5&oq=Thief+4&gs_lp=Egdnd3Mtd2l6IgdUaGllZiA0MgUQLhiABDIFEAAYgAQyBRAAGIAEMgUQABiABDIFEAAYgAQyBh AAGBYYHjIGEAAYFhgeMgYQABgWGB4yBhAAGBYYHjIGEAAYFhgeSPVGUABYyThwBXgAkAEAmAF7oAGDCa oBAzcuNbgBA8gBAPgBAZgCEKACpAmoAgDCAgsQLhiABBjRAxjHAcICChAuGIAEGEMYigXCAgoQABiABB hDGIoFwgIQEC4YgAQY0QMYQxjHARiKBcICCRAAGIAEGAoYC8ICBxAAGIAEGArCAhAQLhiABBjRAxjHAR jJAxgKwgIOEAAYgAQYkgMYuAQYigXCAgsQABiABBiSAxiKBcICCRAuGIAEGAoYC8ICBxAAGIAEGA3CAg cQLhiABBgNwgIOEC4YgAQYxwEYjgUYrwHCAgsQLhiABBjHARivAZgDAPEFdzeCem6tVMmSBwQxMS41oA fHtwGyBwM3LjW4B5wJwgcGMC4xNS4xyAcb&sclient=gws-wiz#fpstate=ive&imgdii=Rzjcj5kM3ArfsM&imgrc=MuZY4j5nKQp8aM&vld=cid:e29cae24,vid:82_SC107sQ8,st:0

[Ex3cut3r]

Das erste Game mit Mantle war damals BF4! Allerdings hatte Nvidia den DX11 Wundertreiber rausgebracht und war Mantle damit ebenbürtig. Siehe auch Video von der PCGH damals. Mit BF Hardline.

Ab 5:30 Min. wird interessant.

7AzeNjSgfNQ

[TheAntitheist]

und Mantle war nicht gut und wird jetzt gerade erst mit Vulkan akzeptabel. Heißt aber nicht das D3D12 gut ist. Dennoch hinkt Vulkan schon teilweise krass hinterher weil sich nicht alle einigen können. ist halt auch nicht geil

[robbitop]

Ohne Mantle kein Vulkan und ohne Vulkan kein Proton. Und ohne Proton kein Linuxgaming und SteamOS wie wir es heute kennen.

Ob Vulkan praxisrelevant hinterherläuft ist IMO auch die Frage. Doom Dar Ages sieht phantastisch aus und läuft phantastisch und hat auch moderne features. Das nutzt Vulkan.

[Ganon]

Vulkan hat das gleiche Problem wie OpenGL -> Design by Committee.

Ansonsten hat Vulkan kaum Gaming-Relevanz. Die Vulkan-Treiber der Hersteller sind in der Regel Müll, sodass an den meisten Stellen, wo Vulkan breitflächig zum Einsatz kommt, nicht die Hersteller-Treiber eingesetzt werden. Und selbst wenn man Dinge wie Proton da hervorheben will: Da sind wir aktuell bei ~3% des Gaming-Markts. Die einzige Konsole, die Vulkan unterstützt, ist die Nintendo Switch und die hat aber natürlich noch effizientere, eigene APIs.

Das FSR4 SDK hat auch noch kein Vulkan-Support.

Vulkan ist toll als Ersatz für praktisch noch viel schlimmere OpenGL. Aber das war es auch schon.

[robbitop]

Ja allerdings sieht es stark danach aus, dass Proton mehr Relevanz bekommen wird. Die 3rd Party PC Handhelds migrieren auch nach und nach zu SteamOS und wer weiß, was die Steam Machines jetzt lostreten.
Aber ja wenn man rein nach der aktuellen Bedeutung angeht, ist es limitiert. Aber es ist eine tolle Innovation, dass Linux sich jetzt immer mehr Leuten öffnet und es kann (aber nicht muss) sein, dass es auch an Bedeutung zunimmt.

Zumindest hat Mantel sicherlich einige andere Dinge losgetreten, die sonst ggf erst später/langsamer passiert wären. Der Trend zu LL API. Und wer weiß, ob Mantle -> Vulkan/D3D12 nicht auch auch bei Apple rein vom Trend Metal getrieben hat. Kann schon eine Kausalkette sein am Ende (wissen wir natürlich nicht mit Gewissheit).

[OgrEGT]

Ohne Mantle kein Vulkan und ohne Vulkan kein Proton. Und ohne Proton kein Linuxgaming und SteamOS wie wir es heute kennen.
(...)
So ist es... da sollte sich NV mal ein Beispiel daran nehmen...

[aufkrawall]

Die Konkurrenz zu Windows bei Handhelds ist nett, muss man jetzt aber auch nicht überbewerten. Unreal wird sowieso auf Mobile optimiert. Für die Industrie im größeren Maßstab spielt das alles nur Nebenrollen.

[robbitop]

Ja die Bedeutung ist (noch?) relativ klein. Ggf. bleibt sie es auch. Aber es ist trotzdem irgendwie cool, dass es das gibt mit SteamOS und dass Linux Gaming immer zugänglicher wird. Mehr Optionen = mehr geil ^^

[][immy]

Ja allerdings sieht es stark danach aus, dass Proton mehr Relevanz bekommen wird. Die 3rd Party PC Handhelds migrieren auch nach und nach zu SteamOS und wer weiß, was die Steam Machines jetzt lostreten.
Aber ja wenn man rein nach der aktuellen Bedeutung angeht, ist es limitiert. Aber es ist eine tolle Innovation, dass Linux sich jetzt immer mehr Leuten öffnet und es kann (aber nicht muss) sein, dass es auch an Bedeutung zunimmt.

Zumindest hat Mantel sicherlich einige andere Dinge losgetreten, die sonst ggf erst später/langsamer passiert wären. Der Trend zu LL API. Und wer weiß, ob Mantle -> Vulkan/D3D12 nicht auch auch bei Apple rein vom Trend Metal getrieben hat. Kann schon eine Kausalkette sein am Ende (wissen wir natürlich nicht mit Gewissheit).
Vor allem hat Steam den perfekten Zeitpunkt erwischt (oder darauf gewartet). MS ist aktuell unbeliebter den je und das Support-ende von Windows 10 ist da eine große Chance. Besonders wo man die Leute zusätzlich mit KI Themen auf den eigenen Rechner nervt und teils z.b. bitlocker automatisch aktiviert. Und dann noch das Xbox Debakel...
Nen besseren Zeitpunkt könnte Valve nicht erwischen.
Also ja. Denke auch das Vulkan in Zukunft deutlich mehr vertreten sein wird und einige Hersteller nachziehen werden.

Nvidia ist auch gerade dabei den gaming Markt quasi zu verlassen, ist ja inzwischen für die nur noch ärgerlich das man die Produkte dich in anderen Bereichen teurer verkaufen könnte.

Btw, das day one Windows Spiele unter Linux Lauffähig sind ist schon echt erstaunlich. Die Steam Box könnte so AMD deutlich im PC Sektor helfen ihre Technologien auch wirklich durch zu setzen.

[Gast]

Ohne Mantle kein Vulkan und ohne Vulkan kein Proton. Und ohne Proton kein Linuxgaming und SteamOS wie wir es heute kennen.


Dass eine hat mit dem anderen wenig zu tun, dann hätte man eben eine andere Schnittstelle genommen oder eine entwickelt.

[The_Invisible]

[immy;13844452']
Nvidia ist auch gerade dabei den gaming Markt quasi zu verlassen, ist ja inzwischen für die nur noch ärgerlich das man die Produkte dich in anderen Bereichen teurer verkaufen könnte.


Klar deswegen tritt man gerade voll auf Holiday Season Marketingschiene und veranstaltet sowas wie die Geforce Gamer Festival in Seaul wo sogar Jensen anwesend war. Was macht AMD schnell?

[DrFreaK666]

Noch 4x schlafen :D

[DrFreaK666]

Erscheint es dann morgen mit einem neuen Treiber?
Und wieso gibt es keine Uhrzeit?

[horn 12]

15 Uhr laut Igor

https://www.igorslab.de/von-markham-in-die-zukunft-die-wahre-geschichte-hinter-ati-und-der-geburt-von-radeon/

[dargo]

Also wie immer oder? :tongue:

[Raff]

Also wie immer oder? :tongue:

Yep. =) Los geht's!

FSR Redstone: Die Feature-Bombe für Radeon-Nutzer - KI-Frame-Generation im Praxistest (https://www.pcgameshardware.de/AMD-Radeon-Grafikkarte-255597/Specials/FSR-Redstone-Release-Test-AMD-RDNA-2-3-vs-DLSS-4-1488644/)

48AdBkf9ZFg

MfG
Raff

[Lurtz]

Lol, weder gibt es eine neue FSR Super Resolution/Upscaling-Version, noch kommt FSR FG mit Multi Frame Generation :udown: RX 7000, was ist das?

Immerhin gibts das SDK ab sofort und das AI FSR FG funktioniert in allen FSR-3.1.4-Spielen.

Da kann nVidia sich Zeit lassen mit der nächsten DLSS-Version...

[Relex]

Oh man. Das war mal wieder viel Hype um nichts.

KI Frame Generation schön und gut, aber hat man auch endlich mal am Framepacing geschraubt?
Die Performance von FSR3 FG dürfte mit dem KI Algo bei FSR4 FG eher schwer zu halten sein. Aber vielleicht gibts ja da noch ne positive Überraschung.

EDIT: Okay, bei PCGH gibts performance werte. Also nur minimal langsamer. Immerhin.
EDIT2: Leider nur 1080p und 1440p Werte. In 4K wärs interessant gewesen. Da kostet FG generell am meisten Performance. Aber ist ja kein Wunschkonzert :D

[DrFreaK666]

Wie langweilig...

Und was ist mit Vulkan?? :rolleyes:

[Lurtz]

Und was ist mit Vulkan?? :rolleyes:
Vulkan ist einfach zu unbedeutend, die Unterstützung kann sich eine kleine Garagenfirma wie AMD einfach nicht leisten :ugly:

[aufkrawall]

Hat AMD mit "enhanced ML model" auf den Redstone Ankündigungsfolien mal wieder dreist gelogen:
https://pics.computerbase.de/1/1/7/5/9/4-112f5cb5d386cfd8/4-2160.5b2301f0.png

Dazu noch Ray Reg. nur RR-Light, kein Vulkan, kein RDNA3, keine Anti-Lag 2-Pflicht. Die Firma ist so unfassbar furchtbar geworden, von dem sympathischen ATi-Geist als Innovator ist absolut null und gar nichts mehr da...

[Raff]

Aber ist ja kein Wunschkonzert :D

Treiber und Begleitmaterial wurden erst am vergangenen Freitag bereitgestellt. Da Gerüchten zufolge sogar Vollzeitnerds zwischendurch schlafen, essen und andere Nichtsnutzigkeiten erledigen müssen, müssen es 16-Stunden-Schichten richten, die am Ende doch nicht ohne Triage gehen. Nachschlag kommt. :)

MfG
Raff

[dildo4u]

LpAZF_-qsI8

[DrFreaK666]

QnatMyP5gto

[Lurtz]

https://youtu.be/LpAZF_-qsI8
Autsch. Da nehme ich lieber zwei Monate lang Blackscreens mit nVidia als jahrelanges kaputtes Framepacing mit FSR... :facepalm:

[dargo]

Bei CB sieht das eher wie eine Vorschau aktuell aus.
https://www.computerbase.de/news/gaming/fsr-redstone-fuer-rx-9000-das-steckt-hinter-fsr-upscaling-frame-generation-und-co.95398/

btw.
Auf Radiance Caching bin ich gespannt ob das spürbar die RT-Frametime senkt (was bitter nötig ist) oder nur ein Tropfen auf den heißen Stein ist.

[Raff]

Bei CB sieht das eher wie eine Vorschau aktuell aus.
https://www.computerbase.de/news/gaming/fsr-redstone-fuer-rx-9000-das-steckt-hinter-fsr-upscaling-frame-generation-und-co.95398/

Wie gesagt, viel Zeit war nicht zwischen Bereitstellung und Fall des Embargos, das ging nur mit Crunch.

MfG
Raff

[aufkrawall]

Autsch. Da nehme ich lieber zwei Monate lang Blackscreens mit nVidia als jahrelanges kaputtes Framepacing mit FSR... :facepalm:
Hatte ja schon vor Monaten gesagt, als ich die Radeon gegen die GeForce getauscht hatte, dass das Pacing mit RDNA4 spätestens mit FG im GPU-Limit ständig völliger Schrott gegen DLSS 4 ist. 7 Monate später, und es ist noch exakt genauso kaputt. Alles richtig gemacht. :uclap:
Wobei du da vielleicht noch den etwas besseren Riecher hattest, direkt vom Widerrufsrecht Gebrauch gemacht zu haben. :freak:

[dargo]

Wie gesagt, viel Zeit war nicht zwischen Bereitstellung und Fall des Embargos, das ging nur mit Crunch.

Alles gut... sollte auch keine Kritik sein. Wenns mehr Zeit braucht ist es halt so. :) Habe gerade erfahren, dass FSR Restone Framegen nun in den Treiber gewandert ist. Wie darf ich das nun verstehen? Ist ML-FG jetzt von der Spielengine entkoppelt? :uconf2:

btw.
Stark wieder dieses mimimi aus dem grünen Lager. ;D

[Lurtz]

Stark wieder dieses mimimi aus dem grünen Lager. ;D
Nichts verglichen damit, dass man sich jetzt ein weiteres Jahr aus dem roten Lager anhören darf, wie unbrauchbar Fake Frames und Co sind, weil AMD es einfach nicht gebacken kriegt ;D

Der Geforce-Aufpreis ist schon gut investiertes Geld.

[Raff]

Alles gut... sollte auch keine Kritik sein. Wenns mehr Zeit braucht ist es halt so. :) Habe gerade erfahren, dass FSR Restone Framegen nun in den Treiber gewandert ist. Wie darf ich das nun verstehen? Ist ML-FG jetzt von der Spielengine entkoppelt? :uconf2:

Lies dir einfach den PCGH-Artikel aufmerksam durch und schieb das Video nach. Falls du dann noch Fragen hast, stehe ich bereit. :)

MfG
Raff

[The_Invisible]

Also viel Hype um nichts wieder, AMD doing AMD things, hauptsache man kündigt es schon ein 3/4 Jahr vorher an ;D

[Daredevil]

Nichtsdestotrotz wird das Paket RDNA4 ein immer runderes, zumindest aus P/L Sicht.
Das war es jetzt schon, jedes weitere Feature welches Sachen von Nvidia auch nur zu 70-90% nachahmt ist ein enormer Gewinn für AMD und den Marktanteil.

"Der Geforce-Aufpreis ist schon gut investiertes Geld." könnte man auch benennen wie "Die Technik von Morgen, schon heute" mit entsprechendem Aufpreis. Kann man machen, muss man aber nicht, jeder hat die Wahl. :)
Wenn etwas fehlt, ist der Traum nach dem "AMD macht es so gut wie Nvidia für weniger Geld" Sparbrötchen natürlich immer enorm groß. Ich habe mich auch früher gefreut, dass meine TnT2 eine Geforce 3 Demo abgespielt hat, damit hatte ich aber immer noch keine GeForce 3. :D

Die Erwartung kann aber nur so groß sein, weil AMD in letzter Zeit halt auch ganz gut geliefert hat. Schade, das manche enttäuscht sind theoretisch. Die bereits getätigten Käufer kann es nur freuen.

[Lurtz]

Nichtsdestotrotz wird das Paket RDNA4 ein immer runderes, zumindest aus P/L Sicht.
Das war es jetzt schon, jedes weitere Feature welches Sachen von Nvidia auch nur zu 70-90% nachahmt ist ein enormer Gewinn für AMD und den Marktanteil.

"Der Geforce-Aufpreis ist schon gut investiertes Geld." könnte man auch benennen wie "Die Technik von Morgen, schon heute" mit entsprechendem Aufpreis. Kann man machen, muss man aber nicht, jeder hat die Wahl. :)
Ich weiß nicht ob man drei Jahre nach Einführung von DLSS FG noch von "Technik von morgen" sprechen kann. DLSS FG hatte zu Beginn ja auch einige Probleme, die wurden aber relativ schnell gefixt.

AMD dagegen macht da gefühlt nur Seitwärtsschritte, keine konsistenten Fortschritte. Und ja, wer mal mit konstanten MFG FPS am Refresh Rate-Limit eines High Refresh Displays gespielt hat, wird kaum mehr zurückwollen. It just works... Während FSR FG so genau keinen Einsatzzweck hat, weil das Framepacing mit höherer Refresh Rate nur auffälliger wird.

[dargo]

https://youtu.be/QnatMyP5gto
Das finde ich lustig. AMD empfiehlt Vsync mit der neuen Framegen zu aktivieren. Nur blöderweise ist es in manchen Games wie zb. ARC Raider ausgegraut Ingame sobald FG verwendet wird. :ulol: Ergebnis ist dann natürlich eine kaputte Frameausgabe mit FG. In Avatar kann man Vsync mit FG aktivieren und dort scheint es zumindest laut Ancient sehr gut zu funktionieren. Ich selbst habe Avatar, werde das also überprüfen können. :)

Lies dir einfach den PCGH-Artikel aufmerksam durch und schieb das Video nach. Falls du dann noch Fragen hast, stehe ich bereit. :)

Habs schon mitbekommen... das neuere FG wertet das "alte" über den Treiber auf.

[dildo4u]

Gut für Sony das sie sich nicht zu 100% auf AMD verlassen diese halbfertigen Lösungen braucht keiner für Konsolen wo man die Features im schlimmsten Fall nicht abschalten kann.

[HOT]

Framegen find ich sowieso total uninteressant, der Rest wird schon brauchbar sein und ich gehe immer noch davon aus, dass das upscaling auch für RDNA3 offiziell kommen wird. Wenn man das neue upscaling nur noch fsr upscaling nennt wird das vllt. sogar für alle kommen.

[The_Invisible]

Gut für Sony das sie sich nicht zu 100% auf AMD verlassen diese halbfertigen Lösungen braucht keiner für Konsolen wo man die Features im schlimmsten Fall nicht abschalten kann.

Ich hoffe Intel & Nvidia bekomen bis zur PS7 einen gemeinsamen SoC gebacken :D

[Spring]

Also viel Hype um nichts wieder, AMD doing AMD things, hauptsache man kündigt es schon ein 3/4 Jahr vorher an ;D

Ah wieder das gleiche unqualifizierte Gequatsche wie immer.

Gut das man auch was zum Thema erfährt anstatt wieder rumgepopel von den üblichen Verdächtigen wg AMD vs NV. Zum Kotzen

[aufkrawall]

Ich hoffe Intel & Nvidia bekomen bis zur PS7 einen gemeinsamen SoC gebacken :D
Dafür braucht es nicht erst Nvidia (oder Intel, wtf :freak: ). Qualcomm hat schon jetzt bzw. bald selbst SER für RT in Mobile-SoCs, während AMD das nicht mal in ihren größten Chips hat. Oder TCs in Mobile-SoCs...

[DrFreaK666]

Das finde ich lustig. AMD empfiehlt Vsync mit der neuen Framegen zu aktivieren..

Und Tim von HWU testet ohne VSync

[aufkrawall]

Nö. Er hat gesagt, Vsync on/off macht keinen Unterschied. Jetzt mal nicht lächerlich an noch die dünnsten Strohhalme klammern...
Vsync an macht eher noch mehr Ruckler, wenn durch das miese Pacing ansonsten das Tearing noch deutlicher wäre.

[Lurtz]

Und Tim von HWU testet ohne VSync
Unsinn, er hat beides getestet, konnte in den kaputten Fällen aber keine relevanten Unterschiede auf VRR Displays ausmachen.

Wäre ja auch eine Idee VSync einfach global über den Treiber erzwingen zu können. Auch so eine Sache, die AMD seit Jahrzehnten nicht hinbekommt.

[aufkrawall]

Wäre ja auch eine Idee VSync einfach global über den Treiber erzwingen zu können. Auch so eine Sache, die AMD seit Jahrzehnten nicht hinbekommt.
Doch, das geht. Nur die Profilverwaltung ist bei AMD chronisch unzuverlässig (wie alles an diesem Treiber-UI).

[DrFreaK666]

Nö. Er hat gesagt, Vsync on/off macht keinen Unterschied. Jetzt mal nicht lächerlich an noch die dünnsten Strohhalme klammern...
Vsync an macht eher noch mehr Ruckler, wenn durch das miese Pacing ansonsten das Tearing noch deutlicher wäre.

Erkläre das Ubisoft, denn die empfehlen VSync wenn man FG nutzt.

[aufkrawall]

Erkläre das Ubisoft, denn die empfehlen VSync wenn man FG nutzt.
Weiß nur nicht, wie ausgerechnet die das wissen wollen, bei der Katastrophen-Implementierung in Avatar, wo es bei den Patches ein einziges hin und her mit wechselnden Regressions gab (und sicherlich bis heute gibt). :freak:
Dafür müsste man ja mal irgendwann mit einem Technikstand testen, der nicht fundamental kaputt ist...

[dildo4u]

Framegen find ich sowieso total uninteressant, der Rest wird schon brauchbar sein und ich gehe immer noch davon aus, dass das upscaling auch für RDNA3 offiziell kommen wird. Wenn man das neue upscaling nur noch fsr upscaling nennt wird das vllt. sogar für alle kommen.
Es gibt Mittlerweile 240 Hz OLED für 500€ dafür brauchst du FG in AAA Games.

https://geizhals.de/lg-ultragear-oled-27gx704a-b-a3625896.html?hloc=de


Gerade Unreal Engine 5 Games haben unterirdische CPU Performance mit Nanite das Limitiert dich oft auf 100fps.

[Spring]

Spiele ja ARC Raiders problemlos mit AFMF + FSR 4 in 4K (das ingame FG ist kaputt, jetzt weiss ich warum).
Teste jetzt den neuen Treiber damit.

[dargo]

Nichts verglichen damit, dass man sich jetzt ein weiteres Jahr aus dem roten Lager anhören darf, wie unbrauchbar Fake Frames und Co sind, weil AMD es einfach nicht gebacken kriegt ;D

An höheren Latenzen mit FG ändert sich rein gar nichts. :rolleyes: Du bist schon ganz schön tief abgedriftet.

Ah wieder das gleiche unqualifizierte Gequatsche wie immer.

Ich hatte nichts anderes erwartet. Es gibt halt paar Grüne die nach Aufmerksamkeit in falschen Threads suchen. ;)

[HOT]

Es gibt Mittlerweile 240 Hz OLED für 500€ dafür brauchst du FG in AAA Games.

https://geizhals.de/lg-ultragear-oled-27gx704a-b-a3625896.html?hloc=de


Gerade Unreal Engine 5 Games haben unterirdische CPU Performance mit Nanite das Limitiert dich oft auf 100fps.

Bei dem krassen VRR-geflicker, was diese derzeitigen OLEDs von sich geben ist 240hz VRR eh völlig unbrauchbar. Da macht man lieber RTSS mit 100hz stabil und hat keine Probleme mit flackern.

[Lurtz]

An höheren Latenzen mit FG ändert sich rein gar nichts. :rolleyes: Du bist schon ganz schön tief abgedriftet.
Latenzen haben rein gar nichts damit zu tun, dass AMD das Framepacing nicht hinbekommt.

Und die weiterhin fehlende AntiLag 2-Pflicht ist natürlich wahnsinnig förderlich für die Latenzen.
Bei dem krassen VRR-geflicker, was diese derzeitigen OLEDs von sich geben ist 240hz VRR eh völlig unbrauchbar.
Ich habe ingame kein einziges Mal Geflicker mit VRR + MFG gesehen.

[Troyan]

Meint AMD wirklich V-Sync?! Das ist absolut irre. Wir reden hier von mindesten zwei Frames Buffer - also fast schon Triple-Buffering Latenz.

Das hatte nVidia auch vor drei Jahren bei Lovelace. Seitdem kann man FG nur noch mit Reflex bei V-Sync On benutzen.

[HOT]

[...]

Ich habe ingame kein einziges Mal Geflicker mit VRR + MFG gesehen.
Das ist komplett unerträglich für mich, daher hab ich den einzigen VA der wirklich flickerfree ist und immer noch keinen OLED, obwohl ich mir schon zig angeschaut habe - das ist es einfach nicht wert auf VRR zu verzichten wegen dem scheiss Geflacker in der Dunkelheit.

[dargo]

Bei dem krassen VRR-geflicker, was diese derzeitigen OLEDs von sich geben ist 240hz VRR eh völlig unbrauchbar.
Was ist das wieder für ein unqualifizierter Dünnschiss? :crazy: Ja... ein OLED kann unter bestimmten Bedingungen mit VRR flackern, dafür gibt es aber Workarounds damit es eben nicht passiert. Wer damit nicht leben kann kaufst sich halt keinen OLED und lebt mit viel schlimmeren Einschränkungen bezüglich Bildqualität.


Und die weiterhin fehlende AntiLag 2-Pflicht ist natürlich wahnsinnig förderlich für die Latenzen.

Zwar unschön, dafür gibt es aber den OptiScaler der in allen SP-Games Abhilfe schafft. Ergo kein Drama.


Ich habe ingame kein einziges Mal Geflicker mit VRR + MFG gesehen.
Troyan schon.

[HOT]

Was ist das wieder für ein unqualifizierter Dünnschiss? :crazy: Ja... ein OLED kann unter bestimmten Bedingungen mit VRR flackern, dafür gibt es aber Workarounds damit es eben nicht passiert. Wer damit nicht leben kann kaufst sich halt keinen OLED und lebt mit viel schlimmeren Einschränkungen bezüglich Bildqualität.

Nein, es gibt nichts schlimmeres als flackern für mich. Nenn es persönliche Präferenz, aber das ertrag ich schlichtweg nicht. Und deine Workarounds sind noch schlimmer, weil man dann effektiv auf VRR verzichtet.

[dargo]

Nein, es gibt nichts schlimmeres als flackern für mich.
Ich hatte dir gerade geschrieben, dass dann nichts flackert. :rolleyes: Kannst du mir überhaupt folgen? :freak: Ein Flackern ist nur das Resultat von schnellen und stärkeren Frequenzsprüngen am Bildschirm. Wenn das passiert ist was kaputt.

Es gibt Mittlerweile 240 Hz OLED für 500€ dafür brauchst du FG in AAA Games.

https://geizhals.de/lg-ultragear-oled-27gx704a-b-a3625896.html?hloc=de

Interessante Story Bro. Erstens werden hier in der Praxis hauptsächlich 960p als Input beim Upscaling verwendet womit die GPU-Last stark gesenkt wird und FG kein Zwang ist. Und zweitens muss ich es verpasst haben, dass man immer die volle Bildschirmfrequenz ausfahren muss. :freak:

https://youtu.be/LpAZF_-qsI8
Jetzt muss ich schon ein wenig schmunzeln. Das ist ja genau das Problem was ich hier bemängelt hatte.
https://www.forum-3dcenter.org/vbulletin/showthread.php?t=622619

Wieso kommt HWU mit der Kritik jetzt erst um die Ecke (natürlich besser jetzt als nie) und nicht schon im März 2025? :freak: Und was ist mit der anderen "Fachpresse"? :ulol:

[Raff]

btw.
Auf Radiance Caching bin ich gespannt ob das spürbar die RT-Frametime senkt (was bitter nötig ist) oder nur ein Tropfen auf den heißen Stein ist.

AMD listet es bewusst als eine von vier Maßnahmen (https://www.pcgameshardware.de/AMD-Radeon-Grafikkarte-255597/Specials/FSR-Redstone-Release-Test-AMD-RDNA-2-3-vs-DLSS-4-1488644/galerie/4049237/?fullsize). Das ist ein weiteres Werkzeug im KI-Köfferchen, um anstelle von stupider, roher Gewalt leichter zum Ziel zu kommen. :)

___

Dass das Ghosting bzw. Falschbilder gegenüber FSR 3 FG massiv reduziert wurden, ist unstrittig und kann daher gefeiert werden. Denn alles, was spatiotemporales Daten-Recycling so gut macht, dass es als "echt" bzw. "nativ" durchgeht, hilft. Hier sieht man klare Vorteile:

nNUsFfIEjJw

MfG
Raff

[robbitop]

Ich frage mich was Vsync bewirken soll mit FSR FG. Zumindest wenn man innerhalb der VRR Range greift VSync gar nicht mach meinem Verständnis. Frage mich was das am Framepacing machen soll. Hat das jemand verstanden? :)

[Ex3cut3r]

HWU hat auch ein Video zum Frame Pacing gemacht.
Schade, dass das weiterhin drin ist, der Sinn von FG ist es das Bild flüssiger darstellen zu lassen, wenn dann aber die Frameausgabe kaputt ist, macht das überhaupt keinen Sinn.

MFG von Nvidia ist einfach ein Biest. Kann damit meinen QD-OLED in den meisten "neuen" AAA Spielen einfach ausmaxxen.

[aufkrawall]

Ich frage mich was Vsync bewirken soll mit FSR FG. Zumindest wenn man innerhalb der VRR Range greift VSync gar nicht mach meinem Verständnis.

Doch. Wenn das reale on-screen Frame Pacing Scheiße ist, wandert das Tearing trotz VRR weiter in die Bildmitte. Mit Vsync kann man das dann gegen Ruckler eintauschen. Im Arsch ist beides, nur anders.


Frage mich was das am Framepacing machen soll. Hat das jemand verstanden? :)
Da lässt sich langsam hinterfragen, ob AMD das eigentlich selbst weiß.

[robbitop]

Meinst du wenn das frame pacing so scheisse ist dass eine frametime eines einzelnen frames so aus dem Rahmen fällt (nach oben oder unten) dass es aus der vrr range fliegt und dann teart? Sorry stehe auf der Leitung :)

[Spring]

Also ich habe es gerade getestet in Arc Raiders:

Sieht besser aus in Bewegung, aber es "laggt" eben mit ingame FG aktivierten randomly manchmal. Vsync wird automatisch auf off umgestellt von Arc Raiders und ein Framelimit kann man auch nicht mehr anpassen, alle Fenstermodi + Vollbild getestet = keine Abhilfe.

also wieder ingame FG aus und auf AFMF gewechselt = Butterweich ohne issues.
:ugly:

[aufkrawall]

Meinst du wenn das frame pacing so scheisse ist dass eine frametime eines einzelnen frames so aus dem Rahmen fällt (nach oben oder unten) dass es aus der vrr range fliegt und dann teart? Sorry stehe auf der Leitung :)
Es kann ohne Vsync mit VRR immer Tearing geben, auch mit guten Frame Times. Es kann aber auch einfach nach Tearing-frei aussehen, wenn das Tearing etwa nur ein paar der untersten Zeilen betrifft. Nur mit Vsync gibt es die Garantie, dass jedes Frame komplett ohne Tearing über den Scan-Out geht. Dass das anders wäre, ist einfach nur ein Mythos.
Sagt der Blurbusters-Typ übrigens auch.

[Troyan]

Problem mit V-Sync ohne Reflex-ähnliches Verfahren ist das Buffern von den Frames. Und wahrscheinlich werden dann 3x Frames gespeichert, weil das ganze nicht anders funktioniert. Darüber hat ja auch DigitalFoundry vor drei Jahren berichtet: https://youtu.be/92ZqYaPXxas?t=1742

[robbitop]

Es kann ohne Vsync mit VRR immer Tearing geben, auch mit guten Frame Times. Es kann aber auch einfach nach Tearing-frei aussehen, wenn das Tearing etwa nur ein paar der untersten Zeilen betrifft. Nur mit Vsync gibt es die Garantie, dass jedes Frame komplett ohne Tearing über den Scan-Out geht. Dass das anders wäre, ist einfach nur ein Mythos.
Sagt der Blurbusters-Typ übrigens auch.

Hab es bei BB gefunden

Wait, why should I enable V-SYNC with G-SYNC again? And why am I still seeing tearing with G-SYNC enabled and V-SYNC disabled? Isn’t G-SYNC suppose to fix that?
(LAST UPDATED: 05/02/2019)
The answer is frametime variances.

“Frametime” denotes how long a single frame takes to render. “Framerate” is the totaled average of each frame’s render time within a one second period.

At 144Hz, a single frame takes 6.9ms to display (the number of which depends on the max refresh rate of the display, see here), so if the framerate is 144 per second, then the average frametime of 144 FPS is 6.9ms per frame.

In reality, however, frametime from frame to frame varies, so just because an average framerate of 144 per second has an average frametime of 6.9ms per frame, doesn’t mean all 144 of those frames in each second amount to an exact 6.9ms per; one frame could render in 10ms, the next could render in 6ms, but at the end of each second, enough will hit the 6.9ms render target to average 144 FPS per.

So what happens when just one of those 144 frames renders in, say, 6.8ms (146 FPS average) instead of 6.9ms (144 FPS average) at 144Hz? The affected frame becomes ready too early, and begins to scan itself into the current “scanout” cycle (the process that physically draws each frame, pixel by pixel, left to right, top to bottom on-screen) before the previous frame has a chance to fully display (a.k.a. tearing).

G-SYNC + V-SYNC “Off” allows these instances to occur, even within the G-SYNC range, whereas G-SYNC + V-SYNC “On” (what I call “frametime compensation” in this article) allows the module (with average framerates within the G-SYNC range) to time delivery of the affected frames to the start of the next scanout cycle, which lets the previous frame finish in the existing cycle, and thus prevents tearing in all instances.

And since G-SYNC + V-SYNC “On” only holds onto the affected frames for whatever time it takes the previous frame to complete its display, virtually no input lag is added; the only input lag advantage G-SYNC + V-SYNC “Off” has over G-SYNC + V-SYNC “On” is literally the tearing seen, nothing more.

For further explanations on this subject see part 1 “Control Panel,” part 4 “Range,” and part 6 “G-SYNC vs. V-SYNC OFF w/FPS Limit” of this article, or read the excerpts below…


https://blurbusters.com/gsync/gsync101-input-lag-tests-and-settings/15/

Problem mit V-Sync ohne Reflex-ähnliches Verfahren ist das Buffern von den Frames. Und wahrscheinlich werden dann 3x Frames gespeichert, weil das ganze nicht anders funktioniert. Darüber hat ja auch DigitalFoundry vor drei Jahren berichtet: https://youtu.be/92ZqYaPXxas?t=1742
Deshalb hatte IIRC BB zusätzlich einen framelimiter knapp unterhalb der refreshrate des Monitors empfohlen iirc.

[dargo]

Also ich habe es gerade getestet in Arc Raiders:

Sieht besser aus in Bewegung, aber es "laggt" eben mit ingame FG aktivierten randomly manchmal. Vsync wird automatisch auf off umgestellt von Arc Raiders und ein Framelimit kann man auch nicht mehr anpassen, alle Fenstermodi + Vollbild getestet = keine Abhilfe.

Der Treiber Framelimiter funktioniert überall bestens.

[DrFreaK666]

ERswhgYRr0w

[Oranje7]

Deshalb hatte IIRC BB zusätzlich einen framelimiter knapp unterhalb der refreshrate des Monitors empfohlen iirc.

Also das sollte nach all den Jahren doch bitte jedem bewusst sein ;(

[Eadzon64]

https://youtu.be/ERswhgYRr0w

erst mal den Zottel kürzen

[robbitop]

Wobei es irrelevant ist wenn man deutlich unter der dem oberen ende der VRR range unterwegs ist. Dank 240-360 Hz Monitoren kommt das schon mittlerweile recht oft vor dass man da deutlich drunter liegt.

[Eadzon64]

Wobei es irrelevant ist wenn man deutlich unter der dem oberen ende der VRR range unterwegs ist. Dank 240-360 Hz Monitoren kommt das schon mittlerweile recht oft vor dass man da deutlich drunter liegt.

finde VRR etc. eh übel weils zu stark auf die Latenz geht

halte mich da an bewährte Methoden, ohne VSync, Framelimiter richtig setzen un Gut

[raffa]

Also das sollte nach all den Jahren doch bitte jedem bewusst sein ;(

Man sollte den Puffer aber imho in ms oder prozent denken und nicht in fps.
57/60 wären 1,2ms oder 5%
228/240 wären auch 5%
190/240 wären auch 1,2ms

Bisschen Topic noch: Das schlechte Pacing von FSR3.1 FG ist ein großes Manko. Wenn das nicht deutlich besser wird mit Redstone ML FG, dann müssen die da auf jedenfall nochmal beigehen.

[Oranje7]

Man sollte den Puffer aber imho in ms oder prozent denken und nicht in fps.
Das wäre dann die Königsdisziplin, oberers drittel damit es blos keinem Kopfzebrechen verursacht


Edit: wie dein edit sagt nur komplizierter^^

[Relex]

Ich kapier nicht, warum AMD das Framepacing nicht gebacken bekommt. Ja, das ist sicher ein hochkomplexes Problem. Aber trotzdem... Die blöße sollte sich AMD nicht geben müssen.

Ich glaube ja immernoch, dass das Framepacing was ich mit FSR FG auf meiner GeForce sehe wahrscheinlich 1:1 dem entspricht, was man auch auf ner AMD Karte bekommt. Aber gut, wissen kann mans nicht und überprüfen kann ichs auch nicht. (Warum testet das niemand?) Aber wenn man sich solche Videos ansieht scheint es zumindest naheliegend, dass die Framepacing Probleme mit FSR FG auf AMD und Nvidia Karten gleichermaßen auftreten...

Jedenfalls halte ich das, was ich da auf Nvidia zu sehen bekomme für absolut unbrauchbar. In Avatar fühlt es sich selbst mit dem neuesten Patch nicht flüssiger an, wenn man FSR FG aktiviert, sondern eben genauso wie ohne FG, nur dass sich die FPS laut Zähler fast verdoppeln und die Latenz ansteigt.

Aber egal ob das verhalten auf der GeForce repräsentativ ist oder nicht, es wirft ein sehr schlechtes Licht auf die Technik, wenn man sich so auf Konkurrenzhardware präsentiert. Warum sollte ich zu AMD greifen, wenn ich auf meiner Nvidia Karte sehe, wie DLSS FG gut funktioniert, aber FSR FG in vielen Fällen praktisch überhaupt nicht oder nur schlecht. Selbst technisch weniger versierte Spieler würden dann doch lieber bei Nvidia bleiben, da das eher abschreckende Wirkung hat.

AMD tut sich damit echt keinen Gefallen. Ich hätte schon gehofft, dass sie mit Redstone jetzt mal alles glatt ziehen. Nochmal besseres Super Resolution, vielleicht ein RayRegeneration in Version 1.0 statt 0.9, was nicht nur ein Denoiser ist, sondern auch upsampling/rekonstruktion von RT effekten macht, wie Nvidias RR eben auch und ein Frame Generation oder Multi Frame Generation mit gefixtem Framepacing + AntiLag2.

Aber nichts davon hat AMD geliefert, obwohl sie für heute den großen Redstone Launch angekündigt haben.

Bei der Frame Generation scheint AMD jetzt zwei Generationen hinten zu liegen.
Man bekommt kein AntiLag2, man bekommt selbst mit 2x FG kein vernünftiges Framepacing, während Nvidia einfach Reflex + 4x MFG mit sauberem Framepacing anbietet und sogar das Framepacing mit dem neuen Algo für Ada Gefixed hat. Gut, selbst DLSS3 war da schon durchweg um welten besser als FSR 3 FG in den spielen wo es auf Nvidia Probleme macht, aber halt nicht optimal. Mit DLSS4 FG ist Nvidia schon so ziemlich am Optimum bzgl. Framepacing.



Und ja, AMD Bashing, blablabla, immer schön drauf. Aber mich ärgert das. Ich hab heut punkt 15:00 Uhr die Berichte gelesen, weil ich wirklich dachte, AMD haut einen raus. Ich hätte es gefeiert. Ich will dass AMD und Nvidia abliefern. Aber das war halt mal wieder nix. Schade :(


PS: Bin gespannt, was Nvidia jetzt macht oder ob sie sich überhaupt genötigt fühlen, was zu machen.
Wenn die im Januar Reflex 2 mit FG kompatibilität raushauen wäre das ein ziemlicher gamechanger. Ich glaub zwar nicht dran, aber die "gefahr" ist auf jeden Fall da, dass AMD mit Redstone jetzt eher ne Nullnummer macht, während Nvidia nochmal richtig einen draufsetzen könnte.
Mal sehen. Ich hoffe einfach, dass es interessanter wird als Redstone...

[Eadzon64]

Aber nichts davon hat AMD geliefert, obwohl sie für heute den großen Redstone Launch angekündigt haben.
:(

Gut Ding will Weile haben und wer nicht warten wil, kann ja weiter NV heizen

jetzt braucht es nur noch jemand fähigen, der eine int8 Variante mit dem neuesten Source kompiliert
soweit bin ich leider nicht
aber wird passieren!

[raffa]

Wenn man das Video vom AMD Jesus anschaut, siehts nicht so schlecht aus mit der nutzbarkeit der FSR REDSTONE FG (warum nicht einfach FSR4.x? mäh)

duFlnVDQ7vY

[Raff]

Jedenfalls halte ich das, was ich da auf Nvidia zu sehen bekomme für absolut unbrauchbar. In Avatar fühlt es sich selbst mit dem neuesten Patch nicht flüssiger an, wenn man FSR FG aktiviert, sondern eben genauso wie ohne FG, nur dass sich die FPS laut Zähler fast verdoppeln und die Latenz ansteigt.

Ich hatte die Tage, bei den Redstone-FG-Tests, ein ganz anderes Gefühl. Da wurde alles optisch wesentlich flüssiger, ganz ohne Frage. Sogar an einem 60-Hz-Display. Nur die Latenz ist so 'ne Sache ...

Wenn man das Video vom AMD Jesus anschaut, siehts nicht so schlecht aus mit der nutzbarkeit der FSR REDSTONE FG (warum nicht einfach FSR4.x? mäh)

Geht es nach AMD, heißt das Feature nun einfach "FSR Frame Generation". Ohne Zahl. Wie das alte Zeugs, das es weiter geben wird (muss), dann heißt? Das sagte niemand. :ugly:

MfG
Raff

[The_Invisible]

Ich hatte die Tage, bei den Redstone-FG-Tests, ein ganz anderes Gefühl. Da wurde alles optisch wesentlich flüssiger, ganz ohne Frage. Sogar an einem 60-Hz-Display. Nur die Latenz ist so 'ne Sache ...


Das man FSR-ML nicht zwingend mit AL2 kombiniert hat war wieder eine vergeudete Chance. Da FSR-ML eh nicht mehr auf anderen GPUs läuft hätte man auch gleich hier den Sack zu machen können.

[Raff]

Das man FSR-ML nicht zwingend mit AL2 kombiniert hat war wieder eine vergeudete Chance. Da FSR-ML eh nicht mehr auf anderen GPUs läuft hätte man auch gleich hier den Sack zu machen können.

Man hätte es von Anfang an wie Nvidia machen sollen. Dort hat man vorab richtig erkannt, dass die Latenz vielen sauer aufstoßen würde, daher ist Reflex ein zwingender Bestandteil. Warum AMD es weiter so "weich" lässt? Vermutlich in diesem Fall, da man ansonsten nicht mit 31 Spielen zum Start hätte werben können. Im Treiber kann man ja Anti-Lag (1) anmachen, für Anti-Lag 2 braucht's aber Spiel-Integration (https://www.amd.com/de/products/software/adrenalin/radeon-software-anti-lag.html).

MfG
Raff

[Relex]

Gut Ding will Weile haben und wer nicht warten wil, kann ja weiter NV heizen



Nö, das Problem ist, AMD nimmt sich "weile" aber liefert trotzdem kein "gut ding". :freak:

OK FSR4 Upscaling ist ein Achtungserfolg. Kann man lassen. Aber ansonsten ist das einfach zu wenig, zu spät.

[raffa]

Geht es nach AMD, heißt das Feature nun einfach "FSR Frame Generation". Ohne Zahl. Wie das alte Zeugs, das es weiter geben wird (muss), dann heißt? Das sagte niemand. :ugly:

MfG
Raff

https://github.com/GPUOpen-LibrariesAndSDKs/FidelityFX-SDK
Danach heisst das Ding: FSR™ Frame Generation (ML) 4.0.0 :D

[Raff]

Gut, dann werden die Versionsnummern sicher auch wieder in den Spielen erscheinen, denn ohne wär's echt albern.

Btw, Radiance Cache führt da zu einem 404. :ugly:

MfG
Raff

[Daredevil]

Ich weiß nicht ob man drei Jahre nach Einführung von DLSS FG noch von "Technik von morgen" sprechen kann. DLSS FG hatte zu Beginn ja auch einige Probleme, die wurden aber relativ schnell gefixt.

AMD dagegen macht da gefühlt nur Seitwärtsschritte, keine konsistenten Fortschritte. Und ja, wer mal mit konstanten MFG FPS am Refresh Rate-Limit eines High Refresh Displays gespielt hat, wird kaum mehr zurückwollen. It just works... Während FSR FG so genau keinen Einsatzzweck hat, weil das Framepacing mit höherer Refresh Rate nur auffälliger wird.
Fairer Punkt, man muss aber letztendlich auch mit beachten, das Nvidia halt seit 2018 Tensor Cores verbaut, welche einen enormen Unterschied bei der Berechnung dieser Dinge machen kann. Die wurden zu Turing Zeiten noch hämisch belächelt, im Nachhinein ist das aber nun einmal die "Technik von Morgen schon heute". Deswegen gibts auf ner Turing Kiste halt DLSS4.

Das AMD überhaupt in irgendeiner Form ähnliche Features anbieten kann ohne sich den Stress mit extra Matrix Einheiten zu machen und den damit verbundenen Kosten, ist eine ziemliche Aufgabe. Das meine ich wirklich ernst. Es ist nicht so leicht, aus einem Technologievorteil rauszukommen, schon gar nicht wenn die direkte Konkurrenz 90% Marktanteil hat und mehr Wert ist als die halbe Erdkugel. AMD macht gerade dafür einen guten Job imho.

[Prinzenrolle]

Geht es nach AMD, heißt das Feature nun einfach "FSR Frame Generation". Ohne Zahl. Wie das alte Zeugs, das es weiter geben wird (muss), dann heißt? Das sagte niemand.

Vielleicht bereitet AMD ja den Legacy Mode für RDNA3 vor.:D

[Eadzon64]

und das schönste dran ist doch wir haben den Source und können damit unseren Spass haben,
un richtig was mit anstellen
was man bei Nvidia wohl ganz vergessen hat, was sowas bewirken kann
ich will Spass, ich will Spass:tongue:

[dargo]

Öhm... hat denn jemand einen guten Überblick welche Spiele nun seit gestern das neue FG verwenden können? Ich sehe hier zwar diese Liste.
https://www.pcgameshardware.de/FidelityFX-Super-Resolution-Software-277617/News/Spiele-mit-FSR-Redstone-1488754/galerie/4100835/?fullsize

Aber diese scheint lückenhaft zu sein. :D
94836

Witzigerweise fehlt das Game auch beim neuen Upscaling.
https://www.hardwareluxx.de/index.php/artikel/software/spiele/67675-fsr-redstone-ein-blick-auf-amds-ml-unterst%C3%BCtzte-upscaling-und-frame-generationen-funktionen.html

Edit:
Das neuere FSR 4.0.3 und FSR-FG 4.0.0 kann man jetzt überall mit dem OptiScaler haben. Astreine Community. :up:
https://www.forum-3dcenter.org/vbulletin/showpost.php?p=13851689&postcount=418

btw.
Autsch... sah das bei FSR 3.1 tatsächlich so übel bei 1080p aus oder ist das nur Marketinggeblubber hier? Ich kann das nicht beurteilen da ich schon seit >11 Jahren keinen 1080p Bildschirm habe. :tongue: Wobei 540p als Input schon wirklich extrem wenig ist.
https://i.postimg.cc/NKXgkLd6/Zwischenablage-12-11-2025-01.jpg (https://postimg.cc/NKXgkLd6)

Das native Bild im Vergleich sieht mir auch irgendwie überschärft aus.

Quelle:
AKkhhh4E37Y

Achja... noch was. Am neuen FG hat sich nichts @RDNA4 geändert. Absolut saubere Frameausgabe bekommt man weiterhin mit dem Treiberlimiter. Und dann flackert auch nichts am OLED mit VRR. Was auch logisch ist da die Frequenz nicht mehr so wild am Bildschirm rumspringt.

[DrFreaK666]

FSR Radiance Caching Requires Further Development and Optimization and Is Not Currently Planned for Release in Darktide
:ugly:
https://wccftech.com/fsr-radiance-caching-requires-further-development-optimization-is-not-currently-planned-release-darktide/

[The_Invisible]

und das schönste dran ist doch wir haben den Source und können damit unseren Spass haben,
un richtig was mit anstellen
was man bei Nvidia wohl ganz vergessen hat, was sowas bewirken kann
ich will Spass, ich will Spass:tongue:

Welcher Source, das ganze neue Redstone Zeug ist closed und läuft nur auf RDNA4. DLLs benutzen kann man bei Nvidia auch.

Das es dann noch auf "GPUOpen" gehostet wird macht es noch absurder

[Taigatrommel]

Ohne Vulkan-Support ist das eher noch mehr closed als DLSS, der Name ist nur noch eine richtige Mogelpackung. Ja, der deprecated-Kram bleibt weiterhin open. Zu gütig, zu gütig...
Die fehlende Unterstützung für Vulkan stört mich ebenfalls. Ist denn bekannt, ob zumindest dran gearbeitet wird oder lässt man das stillschweigend sein?

[dargo]

Ohne Vulkan-Support...
Das hier ist wesentlich wichtiger erstmal um 99,9x% der Games abzudecken.

DirectX® 12
Unreal® Engine 5.2 bis UE 5.7

https://gpuopen.com/amd-fsr-upscaling/

Der Markt wird ja hauptsächlich eh mit UE5.x Games demnächst geflutet.


https://github.com/HansKristian-Work/vkd3d-proton.git
un was ist mit VKD3D:biggrin:

was isch los
Er meint den nativen Vulkan-Support. Zb. beim letzten Doom oder Indiana Jones.

[Exxtreme]

Die fehlende Unterstützung für Vulkan stört mich ebenfalls. Ist denn bekannt, ob zumindest dran gearbeitet wird oder lässt man das stillschweigend sein?

AMD unterstützt Vulkan nur sehr spärlich. Schon FSR3 bekam den Vulkan-Support sehr viel später.

[MadManniMan]

Yep. =) Los geht's!

FSR Redstone: Die Feature-Bombe für Radeon-Nutzer - KI-Frame-Generation im Praxistest (https://www.pcgameshardware.de/AMD-Radeon-Grafikkarte-255597/Specials/FSR-Redstone-Release-Test-AMD-RDNA-2-3-vs-DLSS-4-1488644/)

https://youtu.be/48AdBkf9ZFg

MfG
Raff

Hm ... Ich habe jetzt nichts zum Frame Pacing gefunden - konntet ihr dazu nichts feststellen?

[DrFreaK666]

Hm ... Ich habe jetzt nichts zum Frame Pacing gefunden - konntet ihr dazu nichts feststellen?

Ohne VSync wohl schlecht, mit VSync und Frame-Limit gut

[Eadzon64]

Wenn man das Video vom AMD Jesus anschaut, siehts nicht so schlecht aus mit der nutzbarkeit der FSR REDSTONE FG (warum nicht einfach FSR4.x? mäh)

https://youtu.be/duFlnVDQ7vY

wer bis jetz noch Zweifel hatte

Jesus lebt!

und Er arbeitet mit AMD zusammen:eek:

aalso, ihr elendigen Sünder, noch ist Zeit umzukehren, Buße zu tun

un euch ne AMD zu kaufen

[Lurtz]

if your display or your refresh rate is set to something absurdly high
if the display is running at 120 Hz and VSSync is on

Was für ein bescheuertes Gaslighting, klar, alles über 120 FG FPS sind natürlich "absurdly high", obwohl das die Mindestgrenze ist, ab dem FG überhaupt Sinn ergibt ;D

[DrFreaK666]

if your display or your refresh rate is set to something absurdly high
if the display is running at 120 Hz and VSSync is on

Was für ein bescheuertes Gaslighting, klar, alles über 120 FG FPS sind natürlich "absurdly high", obwohl das die Mindestgrenze ist, ab dem FG überhaupt Sinn ergibt ;D

Er sprach davor von 480Hz, was die Wenigsten hier haben werden.
Und sind 480 dann nicht absurd hoch? Dass schafft man höchstens mit einer 5090 und MFG

[Gast]

https://youtu.be/AKkhhh4E37Y?si=cTIwCrM4FhWOVEmE

Scheint also Probleme zu haben mit hohen Hertz-Zahlen.
Aber mit VSync und frame limit -> Besser

Genau das ist das Problem, du willst kein VSYNC, schon gar nicht mit FG

[DrFreaK666]

Nein. Ich habe behauptet, die fps nach starren Limits ausrichten zu müssen ist Steinzeit...

Man muss Limits setzen um die maximale Hertz-Zahl des Monitors nicht zu überschreiten. Keine Ahnung was das mit Steinzeit zu tun hat.

Sieht bestimmt super aus, wenn die FPS-Zahl die 144Hz deines Monitors überschreitet und das tearen beginnt. Hauptsache keine "Steinzeit"

[robbitop]

Wenn es die GPU Last ist die das frame pacing kaputt macht müsste AL2 nicht helfen? Der reduziert die ja ein wenig.

[Exxtreme]

Das ist schon ziemlich interessant, dass das Framepacing mit FG so schlecht wird wenn VRR aktiv ist und man unter der maximalen Bildwiederholfrequenz des Monitors bleibt. Eigentlich müsste das sehr einfach zu implementieren sein. Man muss nur die Zeit zwischen den echten Bildern messen und das generierte Bild zeitlich genau dazwischen platzieren. Dass das trotzdem nicht funktioniert könnte eigentlich nur daran liegen, dass die GPU nicht in der Lage ist diese Zeit (exakt) zu messen. Die generierten Bilder existieren ja nur in der GPU, weder der Treiber noch das Spiel wissen was davon. Also ist das auch kein Treiberproblem. Und dass man das fixen kann indem man einen Framelimiter einsetzt ist auch ein Indikator, dass es an der Messung scheitert. Mit einem niedrig gesetzten Framelimiter muss nämlich nichts gemessen werden. Man nimmt einfach die Latenz, die sich aus den maximalen echten fps ergibt und halbiert sie. Dann hat man automatisch die Mitte zwischen den echten Bildern.

Ist nur zu hoffen, dass die offenbar fehlende Möglichkeit die Zeit zwischen den Bildern exakt zu messen nicht an der Hardware scheitert.

[aufkrawall]

Wenn es die GPU Last ist die das frame pacing kaputt macht müsste AL2 nicht helfen? Der reduziert die ja ein wenig.
Hatte in Talos mit der 9070 nichts gebracht.

Das ist schon ziemlich interessant, dass das Framepacing mit FG so schlecht wird wenn VRR aktiv ist und man unter der maximalen Bildwiederholfrequenz des Monitors bleibt. Eigentlich müsste das sehr einfach zu implementieren sein.
Es hatte auf RDNA3 auch schon in diversen Spielen wesentlich besser funktioniert, insbesondere mit Mods. In Witcher 3 Res. konnte ich bei deutlicher Power-Drosselung auf der 7800 XT die Kamera drehen und es war butterweich. Aber ist halt classic AMD, dass da einfach kein Verlass drauf ist. Immer das Gleiche, alle Jahre/Monate wieder...

[Eadzon64]

Das ist schon ziemlich interessant, dass das Framepacing mit FG so schlecht wird wenn VRR aktiv ist und man unter der maximalen Bildwiederholfrequenz des Monitors bleibt. Eigentlich müsste das sehr einfach zu implementieren sein. Man muss nur die Zeit zwischen den echten Bildern messen und das generierte Bild zeitlich genau dazwischen platzieren. Dass das trotzdem nicht funktioniert könnte eigentlich nur daran liegen, dass die GPU nicht in der Lage ist diese Zeit (exakt) zu messen. Die generierten Bilder existieren ja nur in der GPU, weder der Treiber noch das Spiel wissen was davon. Also ist das auch kein Treiberproblem. Und dass man das fixen kann indem man einen Framelimiter einsetzt ist auch ein Indikator, dass es an der Messung scheitert. Mit einem niedrig gesetzten Framelimiter muss nämlich nichts gemessen werden. Man nimmt einfach die Latenz, die sich aus den maximalen echten fps ergibt und halbiert sie. Dann hat man automatisch die Mitte zwischen den echten Bildern.

Ist nur zu hoffen, dass die offenbar fehlende Möglichkeit die Zeit zwischen den Bildern exakt zu messen nicht an der Hardware scheitert.

was heißt nur in der GPU, ja weiss schon wird generiert, aber ab da ist es real und das bleibt es auch wenns von unserem Hirn bewertet wird.
und auch die fake Frames müssen ja gesynced werden, damit wir keine Schlieren sehn.
Die Annahme das da eine grobe Mittellung ausreicht, steht jedenfalls zur Debatte...

[Hakim]

Merkwürdig ist halt schon das bei HWU das Frame Pacing so offensichtlich ist, man sieht es ja selber, dieses konstante Delay nach jedem zweiten Frame und CB sagt das es bei denen nicht aufgefallen ist.

[Exxtreme]

was heißt nur in der GPU, ja weiss schon wird generiert, aber ab da ist es real und das bleibt es auch wenns von unserem Hirn bewertet wird.

Ja richtig. Mir ging es aber eher darum, dass der Treiber da in diesen Prozess nicht wirklich eingreifen kann. Der Treiber schickt nur die echten Bilder an die Grafikkarte. Was dann passiert, das weiss er nicht. Deswegen glaube ich auch nicht so wirklich, dass das Problem so ohne Weiteres fixbar ist da das schwer nach einer Hardware-Sache riecht.

[Eadzon64]

Ja richtig. Mir ging es aber eher darum, dass der Treiber da in diesen Prozess nicht wirklich eingreifen kann. Der Treiber schickt nur die echten Bilder an die Grafikkarte. Was dann passiert, das weiss er nicht. Deswegen glaube ich auch nicht so wirklich, dass das Problem so ohne Weiteres fixbar ist da das schwer nach einer Hardware-Sache riecht.


denke schon das es Fortschritte geben wird und auch da ist wieder der klare Vorteil, der Code ist gut verfügbar kann für eigene Projekte verwandt werden und viele Cracks haben Interesse an dem Thema.
Ob es Prorität hat waage ich zu bezweifeln, da es noch genug andere interessante Baustellen gibt.
aber dieses "freihe Ökosystem an sich vermag schon gutes

[Prinzenrolle]

Merkwürdig ist halt schon das bei HWU das Frame Pacing so offensichtlich ist, man sieht es ja selber, dieses konstante Delay nach jedem zweiten Frame und CB sagt das es bei denen nicht aufgefallen ist.

Hier wird gerne überdramatisiert und Kirschen gepickt. So schlecht ist das auch wieder nicht, aber definitiv anfälliger als DLSS, dafür drückt es mehr FPS raus.

[dildo4u]

FSR4 Support in Clair Obscur: Expedition 33 - hatte bisher gar kein FSR

https://store.steampowered.com/news/app/1903340/view/491585297311596633

[Spring]

Mit Frame Cap auf z.B. 144 fps im Treiber und ingame FG ohne AFMF = läuft, wie Dargo erwähnt hatte. Da muss AMD nochmal ran. Solange tuts AFMF auch, aber wäre schön wenn das in den nächsten Wochen / Monaten auch ohne fps cap geht (ingame FG).

[DevilX]

Framecap auf die refresh rate des Monitors oder etwas unterhalb von den FPS die man im Spiel hat?
Dann kann ich vsync aus lassen?

[DrFreaK666]

Es lässt sich aber sehr gut erkennen, dass FSR Frame Generation dazu in der Lage ist, ein gleichmäßiges Frame Pacing zu betreiben, die Bilder werden also in beiden Spielen mit einem möglichst gleichen Zeitabstand ausgegeben. Das hat ein gutes Spielgefühl zur Folge und bestätigt die gefühlten Eindrücke der Redaktion. Das bedeutet nicht, dass dies in jedem Spiel der Fall sein muss und es kann auch Unterschiede zwischen verschiedenen Systemen geben. An sich funktioniert das Frame Pacing von FSR FG aber gut.
https://www.computerbase.de/artikel/grafikkarten/amd-fsr-redstone-frame-generation.95385/#update-2025-12-12T08:47

[dildo4u]

Wäre mal interresant mit was gestestet wurde Hardware Unboxed könnte z.b OLED testen und CB LCDs.

Wenn AMD nur mit LCD testet könnte ihnen die Problematik gar nicht auffallen.

[basix]

Btw, Radiance Cache führt da zu einem 404. :ugly:

AMD at its best: Broken links, Schreibfehler, ....
Alle Links auf github führen zu einem 404 :D Sogar der von FSR4 SR, obwohl es das alles ja schon in besser gäbe, auch für das neue FG, RR und NRC:
https://gpuopen.com/manuals/fsr_sdk/

Inkl. Beschreibung des Algorithmus, Performance Angaben, Speicherverbrauch usw. ;)
Falls es jemanden interessiert und man mit FSR4 vergleichen will: Hier die DLSS Doku, wo man ebenfalls Performance und Speicherverbrauch Angaben erhält: https://github.com/NVIDIA/DLSS/tree/main/doc

FSR4 RR ist ziemlich heavy, 3...4x schwerer als Nvidias RR auf einer vergleichbaren GPU (z.B. 4080 vs. 9070 XT). Es benötigt auch 2.5...4x mehr Speicher.
FSR RR hat 3x Modi und ist auf einer vergleichbaren GPU (z.B. 4080 vs. 9070 XT) in etwa gleich heavy wie DLSS4 RR. Mich haben die Performance-Angaben am Anfang das ein wenig verwirrt, weil DLSS wird mit DLSS4-RR bei Outputauflösung im Performance Mode angegeben und bei FSR4 RR die Renderauflösung.
Insgesamt wird DLSS4 RR wohl etwas schneller sein, da das ein Joint Denoiser + Upscaler ist und bei FSR4 ist er decoupled, das heisst nach FSR4 RR muss man noch die SR Kosten dazurechnen.
FG ist schneller als DLSS und benötigt weniger Speicher.

Hier auf der GPUOpen Hauptseite gibt es ebenfalls eine Übersicht. Etwas oberflächlicher als die Doku oben, aber mit Bildvergleichen:
https://gpuopen.com/
https://gpuopen.com/amd-fsr-framegeneration/
https://gpuopen.com/amd-fsr-rayregeneration/
https://gpuopen.com/amd-fsr-radiancecaching/

[Exxtreme]

Wäre mal interresant mit was gestestet wurde Hardware Unboxed könnte z.b OLED testen und CB LCDs.

Wenn AMD nur mit LCD testet könnte ihnen die Problematik gar nicht auffallen.

Ich glaube nicht, dass das am Bildschirmtyp liegt. Und AMD wird schon wissen wann diese Problematik auftritt da sie ja auch die Implementierung kennen. Ist aber interessant, dass CB und PCGH zu so unterschiedlichen Ergebnissen kommen was dieses Framepacing angeht.

[Troyan]

FG ist schneller als DLSS und benötigt weniger Speicher.


Laut Computerbase ist DLSS-FG schneller als FG in CoD und Black Myth. Arc Raiders ist wohl kaum korrekt bei Computerbase für die 5070TI.

[DrFreaK666]

Arc Raiders ist wohl kaum korrekt bei Computerbase für die 5070TI.
Wieso nicht? Weil AMD FG dort besser abschneidet? Grandiose Logik :freak:

[dildo4u]

Arc kommt vermutlich an die 144hz des Monitors?(Nur 50% Skalierung)
Die anderen Games bleiben um 110hz und sklairen um 70%.

[DrFreaK666]

Arc kommt vermutlich an die 144hz des Monitors?(Nur 50% Skalierung)

Das glaube allerdings nicht. Wolfgang sagte, dass er VSync off empfiehlt. Der Test ist daher ohne VSync gemacht worden (was auch Sinn macht, wenn man Performance vergleichen will).

Meine Empfehlung bei Frame Generation ist: VRR An, VSync Off, in allen Lebenslagen.
https://www.computerbase.de/forum/threads/amd-fsr-redstone-im-test-ai-frame-generation-auf-fps-bildqualitaet-latenz-untersucht.2260440/post-31152419

[aufkrawall]

Tja, hat auch nicht verstanden, dass VRR auch mit Limiter keine Garantie gegen Tearing ist...

[Relex]

Das Fazit von CB ist zwar grundsätzlich richtig, aber die Testmethodik ist mal wieder Unsinn.

Frame Generation hat fixe Frametime kosten. Ja, die schwanken von Spiel zu Spiel, aber grundsätzlich sind sie im gleichen Spiel, mit gleicher GPU und gleicher Auflösung fix.

Wenn jetzt die FPS aber bereits höher sind, dann wirken sich die Frametimekosten anteilig an der Gesamtframetime deutlich stärker aus als wenn die base Framerate niedriger ist.


Hab ich z.B. bereits 100 FPS (also 10ms Rendertime) und muss zusätzlich 5 ms für das Berechnen von Frame Generation aufwennden, dann steigt die Renderzeit auf 15 ms an (= 66 FPS) bevor sie dann auf 133 FPS verdoppelt wird. Hier hab ich also nur 33% FPS Gewinn mit aktiver FG.


Liegt die Base Framerate aber bei nur 50 FPS (also 20 ms Rendertime) und schlage 5 ms für Frame Gen drauf, lande ich bei 25 ms Rendertime, also 40 FPS, welche dann auf 80 FPS verdoppelt werden.
Von 50 auf 80 FPS hab ich aber einen FPS Gewinn von 60%.


Heißt also in beiden Beispielen war Frame Generation gleich teuer und somit gleich performant.
Nur hab ich im ersten beispiel +33% mehr FPS bekommen und im zweiten +60% und das nur weil im zweiten beispiel die FPS niedriger waren.


Das zeigt ganz gut, dass das hervorheben der Prozentwerte wie es computerbase macht von wegen "Technik X kann die FPS um mehr Prozentpunkte steigern als Technik Y" einfach grundlegend falsch ist, da die Karte, die ohne Frame Generation WENIGER FPS erzielt (also die langsamere Karte) bei dieser Betrachtung immer im Vorteil wäre.

Es macht daher überhaupt keinen Sinn, die FPS Steigerung zu betrachten, da sie stark abhängig von der bereits erreichten Frametime ist.


Ich hab mal alle Werte durchgerechnet. Zufälligerweise stimmt zumindest die Richtung. Sprich wenn FSR oder DLSS FG jeweils mehr Prozentpunkte an FPS Gewinn ermöglichen, war auch die Renderzeit für FG meistens geringer. Trotzdem weichen die Zahlen und Unterschiede wenn man die Renderzeit ermittelt stark von den Prozentwerten ab die CB ermittelt hat. Das Fazit hätte daher auch völlig anders lauten können.


Meine 5 ms hab ich übrigens nur zur Vereinfachung genutzt. Praktisch liegt die Renderzeit von DLSS FG und FSR FG zwischen 2 und 3 ms. Aber mal ist FSR schneller, mal DLSS.
Würde sagen, die sind vergleichbar, auch wenn nur drei getestete Spiele zu wenige samples sind...

[The_Invisible]

Das glaube allerdings nicht. Wolfgang sagte, dass er VSync off empfiehlt. Der Test ist daher ohne VSync gemacht worden (was auch Sinn macht, wenn man Performance vergleichen will).


https://www.computerbase.de/forum/threads/amd-fsr-redstone-im-test-ai-frame-generation-auf-fps-bildqualitaet-latenz-untersucht.2260440/post-31152419

Bei nvidia jedenfalls VRR an, Vsync im Treiber an und im Spiel aus, deswegen ist seine Aussage schon mal falsch. Und was über die Refreshrate hinausgeht ist eh uninteressant

[DrFreaK666]

Bei nvidia jedenfalls VRR an, Vsync im Treiber an und im Spiel aus, deswegen ist seine Aussage schon mal falsch. Und was über die Refreshrate hinausgeht ist eh uninteressant

Gibt es dazu überhaupt offizielle Angaben? Konnte nichts finden

[aufkrawall]

Du willst wohl eher nichts finden. Der Blurbusters-Typ wurde hier schon zitiert...

[DrFreaK666]

Du willst wohl eher nichts finden. Der Blurbusters-Typ wurde hier schon zitiert...

Das Wort "offiziell" hast wahrscheinlich wieder unbeabsichtigt übersehen :rolleyes:
Wenn es bei Nvidia so nicht steht, dann ist es nicht offiziell.
Und wie viele Nvidia-User kennen den Test von 2017? 4%
Wer sagt, dass sich das Verhalten nach acht Jahren nicht verändert hat? Hast dazu auch eine Quelle?

[aufkrawall]

Brauchst du auch offiziell die Bestätigung, dass Wasser nass ist?
Es gibt Tearing ohne Vsync, Punkt. Wer das anders sieht, hat falsch getestet.

[Flusher]

AMD unterstützt Vulkan nur sehr spärlich. Schon FSR3 bekam den Vulkan-Support sehr viel später.

Schon absurd, wenn man daran denkt dass AMD mit Mantle den Geburtshelfer von Vulkan gespielt hat.

[robbitop]

Brauchst du auch offiziell die Bestätigung, dass Wasser nass ist?
Es gibt Tearing ohne Vsync, Punkt. Wer das anders sieht, hat falsch getestet.
Um dein Punkt für andere aufzugreifen und zu verstärken:
Und die Erklärung warum das so ist macht auch Sinn. (für alle die sie nochmal sehen wollen: die ist von 2019 und hatte die vor 1-2 Seiten hier gepostet).

[Troyan]

Bei nvidia jedenfalls VRR an, Vsync im Treiber an und im Spiel aus, deswegen ist seine Aussage schon mal falsch. Und was über die Refreshrate hinausgeht ist eh uninteressant

Jap, das ist absolut irre. V-Sync Off heißt Tearing - immer. Dann muss man auch kein VRR mehr nutzen, da sowieso nie garantiert ist, dass das nächste Frame im Bildschirmintervall vorkommt.

Einzig akzeptabel wäre es bei Bildschirmen mit wirklich hoher Hz - also die 480Hz+ OLED Monitore. Und da ja sowieso wegen VRR Flimmern. :freak:

[basix]

Laut Computerbase ist DLSS-FG schneller als FG in CoD und Black Myth. Arc Raiders ist wohl kaum korrekt bei Computerbase für die 5070TI.

Bei 4K etwa 2.8ms auf einer 5080 vs. 2.2ms auf einer 9070 XT. Was ist schneller? ;)
Wir reden hier vom isolierten FG Algorithmus.

Bei HWUB sieht es anders aus als bei CB, FSR FG skaliert typischerweise besser als DLSS FG.

Wie immer:
Spieleskalierung kommt auf Spiel / Engine, Testszene, Framerate und konkret getestete GPU an.

[Troyan]

Bei 4K etwa 2.8ms auf einer 5080 vs. 2.2ms auf einer 9070 XT. Was ist schneller? ;)
Wir reden hier vom isolierten FG Algorithmus.

Bei HWUB sieht es anders aus als bei CB, FSR FG skaliert typischerweise besser als DLSS FG.

Wie immer:
Spieleskalierung kommt auf Spiel / Engine, Testszene, Framerate und konkret getestete GPU an.

Und bei Computerbase ist DLSS-FG in CoD schneller - nämlich ca. 1,8ms.

Offensichtlich sind höhere Ausgangsframes ein Nachteil, um die "effizienz" zu messen. Wobei bei Computerbase FG immer ca. 70% Mehrleistung liefert und DLSS-FG bei 71% und 79% liegt. Arc Raiders mit 51% ist da kaum relevant.

[dargo]

Wäre mal interresant mit was gestestet wurde Hardware Unboxed könnte z.b OLED testen und CB LCDs.

Wenn AMD nur mit LCD testet könnte ihnen die Problematik gar nicht auffallen.
Du kommst hier mit merkwürdigen Sachen manchmal. :freak: Was kommt als nächstes? Unterschiedliches Framepacing für verschiedene Paneltechniken? :ulol:

Ich glaube nicht, dass das am Bildschirmtyp liegt. Und AMD wird schon wissen wann diese Problematik auftritt da sie ja auch die Implementierung kennen. Ist aber interessant, dass CB und PCGH zu so unterschiedlichen Ergebnissen kommen was dieses Framepacing angeht.
Könntest du freundlicherweise die Games auflisten die CB und PCGH untersucht haben? Falls ich die habe könnte ich mir speziell diese anschauen.

Tja, hat auch nicht verstanden, dass VRR auch mit Limiter keine Garantie gegen Tearing ist...
Warum sehe ich dann kein Tearing mit dem Treiberlimiter, VRR und Vsync Off? Zumindest nicht in den Games die ich getestet habe.

[Exxtreme]

Bei CB war es Arc Raiders und Blackmyth:Wukong:
https://www.computerbase.de/artikel/grafikkarten/amd-fsr-redstone-frame-generation.95385/seite-3#abschnitt_fsr_frame_generation_und_das_spielgefuehl_update

Bei PCGH war es Cyberpunk 2077.


Warum sehe ich dann kein Tearing mit dem Treiberlimiter, VRR und Vsync Off? Zumindest nicht in den Games die ich getestet habe.

Es kann sein, es Tearing zufälligerweise nicht oder sehr selten auftritt mit ausgeschaltetem VSync. Man muss VSync aber einschalten wenn man garantiert kein Tearing haben will.

[dargo]

Es kann sein, es Tearing zufälligerweise nicht oder sehr selten auftritt mit ausgeschaltetem VSync. Man muss VSync aber einschalten wenn man garantiert kein Tearing haben will.
Das kriegst du aber nicht hin da bei vielen Games Ingame Vsync ausgegraut ist sobald FG aktiviert wird. Bei Avatar zb. ist es anders, dort kann man mit FG auch Vsync aktivieren. Das ist aber eher Ausnahme als die Regel. Möglich aber auch, dass viele DEVs es falsch in ihre Spiele implementieren.

[aufkrawall]

Das geht bei AMD genauso wie bei Nvidia über den Treiber.

[dargo]

Seit wann denn das? Ich habe schon ewig im Hinterkopf, dass Vsync im Treiber gar keine Auswirkung hat. Ok... dann muss ich das mal auch testen. Dennoch finde ich es seltsam, dass die Games so unterschiedlich ausgeliefert werden. Normalerweise müsste doch im SDK stehen, dass das Spiel auch Vsync bei FG erlauben muss. Der eine DEV macht es dann richtig, der andere wiederum falsch.

[aufkrawall]

Seit schon ewig unter Windows 11, wenn das Treiber-Panel von AMD bei den Profilen nicht rumbugt (was es ständig tut, ebenfalls seit Menschengedenken).

[Exxtreme]

Das kriegst du aber nicht hin da bei vielen Games Ingame Vsync ausgegraut ist sobald FG aktiviert wird. Bei Avatar zb. ist es anders, dort kann man mit FG auch Vsync aktivieren. Das ist aber eher Ausnahme als die Regel. Möglich aber auch, dass viele DEVs es falsch in ihre Spiele implementieren.

Normal geht das über den Treiber. Du kannst auch den MSI Afterburner dazu nutzen.

[aufkrawall]

Kannst kein Vsync per AB oder RTSS erzwingen.

[Exxtreme]

Upss, haste recht. Habe das grad mit einem Framelimiter verwechselt.

[dargo]

Seit schon ewig unter Windows 11...
Ok... Win11 habe ich noch nicht so lange drauf. Habs jetzt mit 120Hz bei CP77 probiert und tatsächlich greift Vsync On. Allerdings muss ich "immer ein" im Spielprofil aktivieren, nur global "immer ein" funzt nicht.

[aufkrawall]

Nach ein paar Mal Profil löschen, neu erkennen lassen oder manuell hinzufügen geht es dann ggf. irgendwann auch per Profil.

[dargo]

Bei CB war es Arc Raiders und Blackmyth:Wukong:
https://www.computerbase.de/artikel/grafikkarten/amd-fsr-redstone-frame-generation.95385/seite-3#abschnitt_fsr_frame_generation_und_das_spielgefuehl_update

Bei PCGH war es Cyberpunk 2077.

Danke.

Und bei der PCGH soll alles mit dem FG sauber gewesen sein? Kann ich nicht nachvollziehen. Gerade CP77 mit nur 120Hz Vsync On und 4k + Quality Upscaling und FG mit RT Ultra probiert damit die Frames unter 120 bleiben. Lagen bei ~100fps und die Stutter sind absolut vorhanden, hier sogar noch stärker als die Mikroruckler die ich mit freinen Frames so kenne da die Framerate natürlich viel zu niedrig ist. Die Frequenzen am OLED springen auch ständig wild zwischen 9xHz und 120Hz. Normalerweise wenn ich was mit freien Frames + FG teste lande ich bei 150+fps @max 240Hz. Da fällt das Stuttering schon spürbar geringer fürs Auge aus. Natürlich trotzdem nicht schön. Absolut sauber wirds nur mit Treiber-Framelimit.

[Eadzon64]

schön finde ich bei Redstone auch, das FSR3 wieder ein kleines aber feines Update erhalten hat.
spele damit auf meinem Strix Point @15-25W, GTAV enhanced in 1080p und
FSR3 Quality, mit maximalen Einstellungen und Raytracing Ulltra+ ,ausser Umgebunggsverdeckung, weils ohne Denoiser dann zu grainy wird, mit durchgehend über 30FPS. Finde das eine beachtliche Leistung für so ein Spielzeug!
Auf meinem alten Panasonic Plasma sieht das dann richtig gut aus.

finde auch, das wir ja sehr verwöhnt sind heutzutage, ich meine was war denn vor upscaling, da hat gutes AA, extrem viel Leistung gekostet, oder hat dann mit fortschrittlichen Shadern ab DX9 aufwärts oft gar nicht, oder nur mit Tricks gegriffen.
Artefakte hatte man eigentlich sogut wie immer und da schaut ein gut gemachtes FSR3 schon mal um Welten besser aus!
Auch V-Sync ist ja kein neues Thema, was war denn damals zur guten alten Zeit?
Nehmen wir zum Beispiel das Originale Unreal von 98.
Klar konnte ich da mit meiner Voodoo 2, 8GB, mit V-Sync in 512x384 mit 60FPS zocken, aber sah halt in 800x600 soviel besser aus und daher war V-Sync aus und Porno an. Aliasing war aber trotzdem stark zu sehen, so what.

[dargo]

Bitte jetzt nicht in Nostalgie hier verfallen. ;)

[Eadzon64]

Bitte jetzt nicht in Nostalgie hier verfallen. ;)

keine Zukunft ohne Vergangenheit

[dargo]

Also ich habe ehrlich gesagt keine Ahnung was CB und die PCGH da getestet haben. Auch ARC Raiders läuft hier mit freien Frames meilenweit weg von sauber mit max. 120Hz am OLED, 4k + Native AA + FG und Vsync On um die Frames zu drücken. Ich stehe still, bekomme 87fps und der OLED springt regelmäßig zwischen 86Hz und 120Hz. Vielleicht verrät uns CB oder die PCGH welche Voodoo Settings die verwendet haben. :) Bei mir sind freie Frames mit FG definitiv kaputt, also exakt wie schon vor Redstone.

[robbitop]

schön finde ich bei Redstone auch, das FSR3 wieder ein kleines aber feines Update erhalten hat.

Gab es für FSR 3.1 denn eine neue Version/dll? Die bis dato neuste war ja 3.1.5(?). Wusste gar nicht, dass daran noch entwickelt wird von AMD.

[aufkrawall]

Gerade CP77 mit nur 120Hz Vsync On und 4k + Quality Upscaling und FG mit RT Ultra probiert damit die Frames unter 120 bleiben. Lagen bei ~100fps und die Stutter sind absolut vorhanden,
Die native Implementierung ist wohl immer noch eindeutig kaputt, das Spiel würd ich sowieso ausklammern. Außer per Mod. Wobei das seit dem letzten Patch auch ohne FG schon nicht mehr optimale Frame Times hat.

Vielleicht verrät uns CB oder die PCGH welche Voodoo Settings die verwendet haben. :) Bei mir sind freie Frames mit FG definitiv kaputt, also exakt wie schon vor Redstone.
Imho ist das sich Verlassen auf LDAT bei ComputerBase eine komplett fehlerhafte Testmethodik, da ist auch bei den Latenzen ständig alles komisch.
Da ist der VRR Refresh Rate Counter zigmal aussagekräftiger, wenn er nicht zu schnell oder zu langsam aktualisiert wird. Und genau das hat HWUB-Tim (offenbar als Einziger) gemacht.

[dargo]

Gab es für FSR 3.1 denn eine neue Version/dll? Die bis dato neuste war ja 3.1.5(?). Wusste gar nicht, dass daran noch entwickelt wird von AMD.
Ja... FSR 3.1.6. Afaik hatte AMD auch offiziell bestätigt, dass FSR 3.x weiter entwickelt wird.

Die native Implementierung ist wohl immer noch eindeutig kaputt, das Spiel würd ich sowieso ausklammern. Außer per Mod. Wobei das seit dem letzten Patch auch ohne FG schon nicht mehr optimale Frame Times hat.

Aber die Stutter bei Kameraschwenks müssen die doch bei FG <=100fps auch so sehen? Sonst falle ich hier vom Glauben ab. :freak: Oder haben beide mit 240-360Hz getestet und extrem hohen FG-Frames? Da kann ich es mir schon vorstellen, dass der eine oder andere Spieler da keine Probleme sieht. Aber von solchen Redaktionen erwarte ich schon mehr. Natürlich dann auch mit entsprechenden Meldungen an AMD direkt.

[dargo]

del

[aufkrawall]

Aber die Stutter bei Kameraschwenks müssen die doch bei FG <=100fps auch so sehen? Sonst falle ich hier vom Glauben ab. :freak:

Ja, ist offensichtlich kaputt. Relex hatte das mal etwas ausgeführt, dass selbst die interpolierten Bilder an sich irgendwie kaputt sind und komische Tearing-Artefakte o.ä. haben, was in anderen Spielen nicht der Fall ist. Weiß auch nicht, wie man das nicht bemerken kann.

HWUB-Tim hatte übrigens auch die Vermutung, dass die Implementierung in dem Spiel (besonders) kaputt ist.

[Eadzon64]

aalso,
Test mit Ghost of Tsushima, mein letzter Oscaler +Redstone standard
sowohl mit DLSS und auch FSR3 inputs
streamline auf RDNA3, max FSR 3.1.6 Framegen möglich
teste jetzt noch mal mit der gemoddeten INT8 FSR4 .dll kann sein das was hilft...

auch mit INT8 mod, leider kein Erfolg, bleibt bei max FSR3.1.6 Framegen und RDNA3

[Eadzon64]

auf Cyberpunk darfst als AMD Nutzer sowieso an Scheiß geben
da hatten Projekt Red et NV, so tief ihre Marketing Griffel drinne, das es echt nich mehr schön ist
aber so gut ist das Spiel zum Glück ja nicht, total unfertig etc.

hatte ja schon mein Strix Point und GTA5 volles Ulltra Raytracing angeführt
sobal ich aber in CP auch nur einen Raytracing Schalter auf normal schalte,
bricht der kleine auf unspielbare 5 FPS ein. Ich spreche vom normalen Raytracing!
und dass kann nur an Manipulation liegen.

[TheGood]

https://www.computerbase.de/artikel/grafikkarten/amd-fsr-redstone-frame-generation.95385/#update-2025-12-12T08:47

Computerbase hat auch klar geschrieben, dass das wohl Hardwarekonfigurationsabhängig ist, da es einer hat und der andere nicht. DAs ist natürlich nicht besonders geschickt und sollte wirklich schnell gelöst werden.

Leider hat AMD hier mehr versprochen als sie geliefert haben. Wenigestens ein neues Upscaling Version hatten doch alle erwartet. Vermutlich ist es halt nicht fertig geworden und man wollte irgendwie den Termin einhalten. Echt schade... Aber der WEg ist das Ziel und es geht vorran, auch wenn die ERbsenzähler hier mit aller gewalt alles madig reden wollen.

[DrFreaK666]

Text

Genau genommen gibt es mit FSR4.0.3 eine neue Version.

AMD FSR™ Upscaling “Redstone” (4.0.3) release (as part of the AMD FSR SDK 2.1 release):

Latest ML-based upscaling improvements.
Continued quality enhancements.
https://gpuopen.com/amd-fsr-upscaling/

[robbitop]

Der kleine Sprung in der Revisionsnummer impliziert allerdings nur kleine Änderungen. Redstone wirkte bei so einer langfristigen Ankündigung ja eher nach einem major release (oder zumindest nach ein wenig mehr).

[aufkrawall]

Da wurd laut Changelog maximal ein einzelner Bug gefixt, plus eine Verbesserung für die Zukunft:
AMD FSR™ Upscaling 4.0.3
* Fixed a rendering error when surface dimensions are not multiples of 8.
* API changes:
- Added ffxCreateContextDescUpscaleVersion which must be linked to ffxCreateContextDescUpscale when creating a context to ensure correct behavior with future updates.
https://github.com/GPUOpen-LibrariesAndSDKs/FidelityFX-SDK/blob/main/Kits/FidelityFX/docs/whats-new/index.md

Auf gpuopen scheint typischer ungenauer PR-Quatsch zu stehen...

[DrFreaK666]

Der kleine Sprung in der Revisionsnummer impliziert allerdings nur kleine Änderungen. Redstone wirkte bei so einer langfristigen Ankündigung ja eher nach einem major release (oder zumindest nach ein wenig mehr).

AMD hat das falsch kommuniziert

[Achill]

Der kleine Sprung in der Revisionsnummer impliziert allerdings nur kleine Änderungen. Redstone wirkte bei so einer langfristigen Ankündigung ja eher nach einem major release (oder zumindest nach ein wenig mehr).

Nicht wenn es sich um eine technische Version (https://semver.org/spec/v2.0.0.html) handelt, was bei einer DLL sinn macht. Die Erhöhung der ersten Nummer die major version, ist ein Bruch der API oder Prozesse, es Bedarf einer Änderung im Code wo die DLL verwendet wird. Die zweite Nummer ist die minor version, API und Prozesse sind erweitert worden, bleiben aber kompatibel. Die letzte Nummer ist die Build und Bugfix version, wenn sich nichts an der API oder Prozessen ändert, so wird diese erhöht.

Eine Verbesserung des ML-Models ohne Änderung oder Erweiterung der Input, was ein API Change wäre, ist also mit der Erhöhung der letzten Nummer völlig ausreichend. Und man kann keine generelle Ableitungen machen. Das Marketing kann es FSR 15 nennen und intern ist die DLL weiter eine 4.x.y ...

---
Edit: Das ist natürlich Mist.


API changes:
- Added ffxCreateContextDescUpscaleVersion which must be linked to ffxCreateContextDescUpscale when creating a context to ensure correct behavior with future updates.

[dargo]

Ich habe das "alte" Ghost of Tsushima wieder angeschmissen und verstehe langsam nichts mehr. Habe das neueste FSR 4.0.3 über den OptiScaler aktiviert. Framegeneration noch nicht über den OptiScaler aktiviert sondern über die Ingameoption. Das ganze läuft mit freien Frames. Ich drehe mich ständig mit der Maus im Kreis und sehe kein Mikrostutter. Normalerweise erkenne ich sowas direkt. Dann rufe ich das OSD vom OLED auf und auch hier sehe ich keine wilden Frequenzsprünge wie das bei vielen (eher den meisten) Spielen der Fall mit FG ist. Wie kann sowas sein?

Als weiteres habe ich getestet was passiert wenn ich mich nicht bewege. Der Framecounter zeigt mir 165-166fps an. Das OSD vom OLED zeigt mir aber in diesem Szenario 154-157Hz an. Wie kann die Bildausgabe bei dieser Differenz sauber sein? Kann mir mal einer das technisch, verständlich erklären? Ich verstehe es einfach nicht. Übrigens greift hier noch nicht das neue FSR-FG von Redstone ein. Zumindest sagt das der Treiber, dass ein entsprechendes Upgrade fehlt. Aber darum gehts mir hier nicht. Ich verstehe einfach nicht wie die Bildausgabe bei einem Spiel mit FG und freien Frames sauber sein kann und bei anderen Spielen nicht. Und auch nicht wie die Bildausgabe absolut sauber sein kann wenn die Frequenzen am Bildschirm nicht zu den Frameraten passen.

Fairerweise muss ich dabei sagen, dass ich keinen Controller habe um einen schön gleichmäßigen Kameraschwenk auszuführen, das wäre noch besser für eine Beurteilung. Aber normalerweise merke ich das auch mit der Maus immer sobald was mikroruckelt.

Edit:
Habe jetzt die Maussteuerung Ingame von 10 auf Null reduziert. Damit lässt sich eine gleichmäßige Bewegung noch besser ausführen. Auch hier sieht das für meine Augen alles sauber aus. Und jetzt wird es noch bekloppter. Andere Szene, ich bewege die Kamera ständig von links nach rechts und wieder zurück. Der Framecounter bewegt sich zwischen ca. 175fps und 185fps. Die Frequenz am OLED bleibt aber fest bei 240Hz und die Bildausgabe ist trotzdem immer noch sauber. WTF? X-D Das widerspricht doch jeglicher Logik. :freak:

[robbitop]

Ich gebe hier mal meine zwei Halbwissens Pfennige:

Frametimes scheinen wenn es schief geht (siehe das letzte DF Video zu fsr fg redstone) hoch dynamisch zu sein. Also wirklich hohe Gradienten frame by frame. Wenn man bspw grob 100 fps hat ergibt sich alle 10 ms ein neues Ergebnis einer Frametime. Die meisten fps Anzeigen dürften eine wesentlich grobere Abtastrate haben und ggf auch eine Art moving average so dass man hoch dynamische Frametimes sofern sich der Mittelwert / oder moving avg nicht ändert nicht auffallen könnten. Entsprechend macht ggf ein frametimegraph mit sehr feiner Abtastrate da schon Sinn um das zu detektieren. Ich fand auch die Idee nicht verkehrt mit dem Smartphone ein high refreshrate video zu drehen und dann frame per frame zu schauen ob die Bewegung (bei festem Camera pan input) konstant ist.

Aber ich denke auch dass man das auch subjektiv merken wird wenn man ein Händchen dafür hat. :)

Anscheinend ist das Ergebnis der Frametimevariabilität sehr variabel - nicht nur vin Spiel zu Spiel sondern auch von HW Konfiguration zu HW Konfiguration.

Ansonsten und unabhängig gilt: FPS und Frametimes sind auch dynamisch abhängig von der Dynamik der Last der jeweiligen Spielszene. Und bei FG wird die Dynamik bzw die Amplituden auch verstärkt.

[dargo]

Wenn ich mich nicht bewege und sich entsprechend am Bildinhalt auch nichts ändert gibt es praktisch keine Lastdynamik. Zudem passen die Frequenzen vom Bildschirm ohne FG immer zu den angezeigten Frameraten. Nur bei FG On löst sich die Logik hier auf. :D

btw.
Ist das bei deinem System auch so, dass die Frequenzen am Bildschirm nicht mehr zu den Frameraten passen sobald FG aktiviert ist? Einfach im beliebigen Spiel sich irgendwo hinstellen, nicht bewegen und beides abgleichen. Und ich meine jetzt hier nicht mickrige Unterschiede von 1-2Hz.

Edit:
https://store.steampowered.com/news/app/2215430/view/560265191314424856?l=german

Werden doch einige Spiele nachgepatcht. (y)

[robbitop]

Das habe ich tatsächlich noch gar nicht untersucht. Anti flicker ist bei dir aber aus oder? Kann mir vorstellen, dass wenn durch FG die die Dynamik/Amplituden der Frametime verdoppelt werden, greift das stärker ein und/oder (unabhängig davon) macht das die Spreizung zwischen niedrig abgetasteten fps rates und höher abgetasteten fps rates und/oder anders verrechneter fps rates größer. (also bspw Monitor OSD vs Afterburner oder Treiber OSD. Monitor OSD vermute ich tastet viel langsamer ab und dann kommen eben andere Werte raus - gerade wenn ein moving average gemacht wird).

[dargo]

Das habe ich tatsächlich noch gar nicht untersucht.

Dann schau dir das bitte an damit ich einen Vergleich habe.


Anti flicker ist bei dir aber aus oder?

Logisch, den Quatsch in den OLEDs braucht kein Mensch.


Kann mir vorstellen, dass wenn durch FG die die Dynamik/Amplituden der Frametime verdoppelt werden, greift das stärker ein und/oder (unabhängig davon) macht das die Spreizung zwischen niedrig abgetasteten fps rates und höher abgetasteten fps rates und/oder anders verrechneter fps rates größer. (also bspw Monitor OSD vs Afterburner oder Treiber OSD. Monitor OSD vermute ich tastet viel langsamer ab und dann kommen eben andere Werte raus - gerade wenn ein moving average gemacht wird).
Nee... das OSD vom Asus OLED bei den Frequenzen sieht mir vom Gefühl nach 250ms aus, allerhöchstens 500ms. Frameraten werden in der Regel alle 1000ms aktualisiert wenn man es nicht manuell ändert.

[robbitop]

Mache ich bei Gelegenheit- bin aber eine Weile erstmal nicht in Reichweite von meinem PC ^^

Die hohen Abtastraten machen deine Beobachtungen jedenfalls erstmal schlüssig zu dem was man in dem Zusammenhang erwarten könnte.

[Lurtz]

FSR was non-driver level FG, unlike DLSS, so interfacing with the graphics API in a way for it to be seamless-enough for devs.
Obviously cant speak for the FSR team any more- but when I stood up at GDC and said that frame pacing was the hardest part of FSR 3, I was not joking! It's all about tradeoffs, and it's not perfect.
The solution to this? Put all pacing in the driver or API extensions. That was against the FidelityFX cross-platform and open ecosystem goals at the time. Doesn't seem like that's an issue now?
https://bsky.app/profile/domipheus.bsky.social/post/3ma3qii7g2c2f

[Relex]

Interessant, dass er bestätigt, dass sie mit Framepacing Probleme hatten und es ein sehr schwieriges Problem ist.

Machts nur umso beeindruckender, dass Nvidia das so gut im Griff hat (auch auf Ada mit DLSS4 FG) und mit MFG und Hardware Flip metering nur nochmal nachgelegt hat.

Ich hätte als die Technik aufkam nicht gedacht, dass gerade das das schwierigste Problem ist.
Was sich AMD halt trotzdem an Kritik gefallen lassen muss ist, dass es selbst Intel wohl gut hinbekommt (läuft auch auf allen GPUs). Wobei ich das aber auch nicht viel getestet habe.

[DrFreaK666]

Machts nur umso beeindruckender, dass Nvidia das so gut im Griff hat (auch auf Ada mit DLSS4 FG)

nein, da du folgenden Punkt übersehen hast:
That was against the FidelityFX cross-platform and open ecosystem goals

[The_Invisible]

"Schuld" war ja anscheinend der OpenSource Ansatz da man es entkoppeln wollte oder musste vom Treiber. Scheint aber wohl nicht so gut zu gehen.

Da FSR4/Redstone aber sowieso Closed ist nochmal unverständlicher warum man es jetzt nicht gemacht hat

[robbitop]

nein, da du folgenden Punkt übersehen hast:
Er hat aber auch gesagt bei Intel funktioniert es. Und die haben Crossplattform.

IMO ist es potentiell einfacher sicherzustellen, dass alles gut läuft, wenn man den Code in der eigenen Hand hat. Also in der eigenen API oder im Treiber. Macht NV nicht ohne Grund so. Aber ohne die Marktmacht von NV braucht es Crossplattform ansonsten verbreitet es sich nicht. Dafür braucht es dann wahrscheinlich mehr Aufwand (mit den Devs und/oder bei der Robustheit des Codes den man verteilt und dass man den regelmäßig auf die Quirks der ganzen Engines Update)

[Relex]

nein, da du folgenden Punkt übersehen hast:

Ja, die Alternative wäre das Pacing über den Treiber zu machen.

Intel bekommt's aber auch ohne Treibereingriff auf anderen GPUs hin, während es AMD offensichtlich nichtmal mit FSR4 hinbekommt, welches RDNA4 exklusiv ist.

Man kann wohl festhalten, dass das FSR Team einfach generell große Probleme damit hat, die Probleme kennt, aber einfach bisher keine gute und vor allem ROBUSTE Lösung gefunden hat. Weder für Cross Platform noch für die eigene Plattform und die eigenen GPUs.

[robbitop]

Ja meine Vermutung ist auch dass das FSR Team nicht die Ressourcen hat, die man braucht um das alles in guter Form zu stämmen. Die Kollaboration mit Sony war sicherlich auch deswegen.

[aufkrawall]

In Talos ist das Pacing mit Intel-FG auf Nvidia auch semi-kaputt. Ich muss es erst mit DLSS 4 FG starten und dann im Spiel auf Intel umschalten, sonst völlig kaputte Frame Times. Mit dem Workaround ist es dann aber recht gut, und klaut im Gegensatz zum FSR-Pacing auch keine (merkbare) CPU-Leistung.

[Relex]

@robbitop
Ich bezweifle, dass das Thema viele Ressourcen braucht. Das ist an sich ja ne relativ kleine Funktion, das ich eher für ein Logik Problem in der Programmierung halte. Das ist doch kein Problem auf das man 100 Entwickler wirft, damit es besser wird.

Da werden einfach eine Handvoll Spezialisten sitzen, aber einfach keine bessere Lösung finden. Also hofft man natürlich, dass man mit den Sony Ingenieuren ein paar weitere kluge Köpfe dazu gewinnt, mit denen man bessere Lösungen erarbeiten kann.


Ist ja nicht so, dass es die Technik schon hundertfach am Markt gibt. Das ist halt alles nicht so einfach und erfordert Zeit und viel Forschungsarbeit.

Mich wundert es daher auch nicht, dass es da mal Rückschläge gibt oder es einfach länger dauert. Aber trotzdem muss man sich dann halt die Kritik gefallen lassen und gibt sich blöße vor der Konkurrenz die es besser hinbekommt. So läuft das halt.

[robbitop]

Ich meinte eher damit dass zu wenige Leute auf zu vielen Hochzeiten tanzen. Dann wird halt nichts polished und fertig wenn gleich drölf Sachen (FSR4, MLFG, radiance caching und Ray Regeneration) angegangen werden müssen und bis Q4 fertig sein müssen und man auch noch Babysitter bei der Implementierung pro Spiel spielen muss. Sieht man IMO oft genug was wieder für oopsies geschehen und wenn dann solche halbgaren Sachen wie RR kommen und nichts fertig wirkt. Nicht ein Spiel hatte Redstone komplett. Sieht für mich schlecht geführt und überlastet/überhastet aus

[aufkrawall]

Es liegt aber nicht nur an FSR. Wie schon mal gesagt, ist es mit RDNA4 generell nochmal schlechter geworden. Das spinnt schon ohne FG teilweise rum, merkt nur wieder keiner bzw. tritt nicht in jedem Spiel auf.
Würd mich nicht wundern, wenn man mit Vibe Coding (Opus 4.5 ist schon ein richtiger Schlaubi bei Core-Logiksachen, und der Loader/Pacing sind ja weiterhin open-source) das FSR-Pacing auf Nvidia wesentlich besser hinbekommen könnte, und es auf Radeon/RDNA4 dann immer noch schlechter liefe...

[robbitop]

Ist es eigentlich mit Optiscaler injeziert besser? Also im Spiel ein anderes FG Verfahren wählen und dann FSR ML FG überstülpen. Mit RDNA4 HW.

[DrFreaK666]

Ist Ray Regeneration denn mittlerweile 1.0?

[basix]

Laut Webseite: Ja, v1.0.0
https://gpuopen.com/amd-fsr-rayregeneration/

[DrFreaK666]

Aber Datei-Tausch geht nicht wegen Anti-Cheat

[dargo]

Was sich AMD halt trotzdem an Kritik gefallen lassen muss ist, dass es selbst Intel wohl gut hinbekommt (läuft auch auf allen GPUs). Wobei ich das aber auch nicht viel getestet habe.
Guter Witz... ich habe noch kein Game gesehen welche mit XeFG auf non Intel sauber läuft. :ulol: Intel GPUs mal außen vor, das kann ich nicht beurteilen da ich keine entsprechende Graka habe. Und wenn Framepacing hier das Hauptproblem sein soll warum sieht GoT mit FG sauber aus? Ergibt alles irgendwie keinen Sinn.

Edit:
Nennt mir mal paar Spiele die sauber mit XeFG auf non Intel laufen. Ich schaue es mir mal an sofern ich die Spiele habe. Bisher konnte mich nirgendwo XeFG überzeugen, überall Stutter.

[Eadzon64]

Guter Witz... ich habe noch kein Game gesehen welche mit XeFG auf non Intel sauber läuft. :ulol: Intel GPUs mal außen vor, das kann ich nicht beurteilen da ich keine entsprechende Graka habe. Und wenn Framepacing hier das Hauptproblem sein soll warum sieht GoT mit FG sauber aus? Ergibt alles irgendwie keinen Sinn.

Edit:
Nennt mir mal paar Spiele die sauber mit XeFG auf non Intel laufen. Ich schaue es mir mal an sofern ich die Spiele habe. Bisher konnte mich nirgendwo XeFG überzeugen, überall Stutter.

genau

und Wintel = NV, eine große Bande!
natürlich sind AMD auch keine Heiligen

und weg duck

[Relex]

n7bud6P4ugw

[robbitop]

Sehr systematisch analysiert. Schade dass sowas nicht intern bei AMD vor einer Freigabe passiert und man dann nochmal nachbessern kann bevor es dann gereviewt wird.

[Eadzon64]

wer sagt denn eigentlich, das AMD seine eigenen Ziele, die Architktur und Features
nach den Vorstellungen, sog. Innovationen und Vorgaben von Nvidia ausrichten muss?
Nur weil ein "Großmaul sich hin gestellt hat und den Leuten verzapft, das ist es jetzt das revolutionäre, nächste große Ding, ohne das nix mehr geht?
und das Medien gerne etwas wiederkauen, was mit allen großen Marketingposaunen gut verfügbar und ohne große Müh Content,
damit Werbeeinnahmen und Aufmerksamkeit erzeugt, ist jetzt kein Wunder.
Viel wichtiger ist mir da, eine eigene Strategie von AMD, die gut zugänglichen Softwarebibliotheken, die keinen ausperren, oder benachteiligen und das zahlt sich auf lange Sicht und nachhaltig aus, wenn der Schreihals schon längst verhallt ist.
und die Welt, ist nicht, wie oft suggeriert wird Amerika, die haben halt das größte Maul und selbst Ohropax hilft dagegen bei uns leider nix mehr.
auf was bauen die großen, vom US Imperialismus befreiten Marktwirtschaften, also mehr als 2/3 der Menschheit ihre digitale Zukunft?
auf GNU/Linux und open Source.
lieber Wegbereiter einer Digital humanen Zukunft, als Kohle scheffelnde narzistische Unterdrücker!

meine Meinung!

[Relex]

Sehr systematisch analysiert. Schade dass sowas nicht intern bei AMD vor einer Freigabe passiert und man dann nochmal nachbessern kann bevor es dann gereviewt wird.


Fühl mich nur wieder bestätigt :D

FSR FG fehlt einfach die Robustheit im Framepacing, wie ich es heute auch schon erwähnt habe.

bisher keine gute und vor allem ROBUSTE Lösung gefunden hat

Und nein, Nvidia ist auch nicht in jedem Spiel auf anhieb ausnahmslos perfekt. Aber deren Lösung ist eben so robust, dass es in den allermeisten Fällen sehr gut funktioniert.


Und er zeigt auch mal wieder sehr schön auf, dass eine Aufnahme von Display (oder FCAT) das einzig wahre ist und die ganzen Frametime Analyse Tools unzureichend sind. Ein Indikator, ja, aber unzureichend für ein wirkliches Fazit.

Wobei selbst FCAT nur den Abstand der tatsächlich ausgegebenen Frames misst, wohingegen man mit der Kamera auch Animation Error sehen könnte. Aber das ist ein ganz anderes Problem. Also wie immer ist es besser, sich auf seine Augen und den Optischen Output zu verlassen. Sag ich auch schon seit mindestens nem Jahr und hab seitdem auch alle Frametime und Benchmark Tools vom Rechner geschmissen. Für mich einfach unnütz. Entweder es werden schwankungen angezeigt, die nicht im finalen output sichtbar sind, oder es fehlen ruckler im Graphen die man eindeutig sieht.

Hab schon viel zu viel Zeit damit verschwendet. :/

[aufkrawall]

Du übertreibst. msBetweenDisplayChange ist nicht perfekt, zeigt aber bereits deutlich an, dass etwas verkehrt ist. Woran die ganzen Reviewer schon gescheitert sind...

[Relex]

Du kannst es gerne übertreiben nennen, aber ich hatte eben auch schon fälle, wo ich z.B. mit Special-K eine deutlich smoothere Ausgabe erreichen konnte, aber davon einfach überhaupt gar nichts über msBetweenDisplayChange erkennbar war und der Graph einfach identisch aussah.

Also was will ich damit?

[aufkrawall]

Hast das Stichwort Animationsstutter schon selbst genannt. Verkackte Game-Timer können auch den Kamerainput stuttern lassen, was SpecialK mitunter auch fixen kann. Da würde auch eine LCAT-Messung nichts anderes zeigen...
Das hat jetzt alles nichts mehr mit dem FG-Stutter zu tun, den msBetweenDisplayChange ziemlich gut anzeigt. Deine Anekdoten mit irgendwelchen anderen Umständen ändern daran nichts...

[robbitop]

DF Alex hatte alle drei Methoden in seinem heutigen Video verglichen und da war msbetweendisplaychange schon ganz gut aber in Ramdfällen zeigte fcat es dann trotzdem wesentlich deutlicher. Oder habe ich es in dem Video falsch interpretiert?

[Relex]

@aufkrawall
Klar kann auch sein. Bestätigt aber doch nur das gleiche.

Die Tools sind unzureichend, um Animation Stutter zu zeigen und unzureichend, um das tatsächliche Framepacing zu zeigen.

Da du nicht weißt, mit welcher Art von Fehler du es zu tun hast kannst du dich auf msBetweenDisplayChange eben nie verlassen.


Letztendlich sieht man Ruckeln oder kein Ruckeln. Und wenn die Frametime Tools das nicht 1:1 wiederspiegeln können, dann muss da noch sehr viel Arbeit reingesteckt werden, eher man sich auf solche Messungen verlassen kann.
Das Problem ist in Gänze halt verdammt komplex. Gamers Nexus hat sich letztens ja schon die Zähne daran ausgebissen, Animation Error irgendwie praktikabel in einen Graph zu packen. Das ist halt das Problem mit Daten. Man kann sie auf unterschiedlichste Weise erfassen, aufbereiten und zueinander ins Verähltnis setzen und dann trotzdem völlig unterschiedlich interpretieren.

[dargo]

DF Alex hatte alle drei Methoden in seinem heutigen Video verglichen und da war msbetweendisplaychange schon ganz gut aber in Ramdfällen zeigte fcat es dann trotzdem wesentlich deutlicher. Oder habe ich es in dem Video falsch interpretiert?
Nö... sieht doch jeder im Vergleich was Sache ist.

[aufkrawall]

Du hast aber keinen Animation Stutter durch FG, sondern in solchen Fällen dann schon ohne FG. Wenn msBetweenDisplayChange schlechter aussieht als frame present und als ohne FG, ist das ein absolutes Alarmsignal für schlechteres reales on-screen Scan-Out. Und das ist vermutlich bei FSR FG immer gegeben.

[Relex]

@aufkrawall

Das ist natürlich richtig. Es kann ein Indikator sein. Aber mehr eben nicht.

Aber auch da haste eben wieder das Problem. Du versuchst z.B. mit irgendwelchen Tweaks gegenzusteuern und das Pacing zu beeinflussen. Vielleicht würde es sich in der FCAT Messung wiederspiegeln und die Ausgabe sich verbessern. Wenn du es jetzt aber in der msBetweenDisplayChange Messung nicht siehst wie willst du das dann validieren.

Da sind wir dann wieder bei rein Subjektiver bewertung. User X sagt "ich hab das umgestellt und es läuft viel smoother" -> User Y sagte: Zeig mal deinen Frametime Graph -> Man sieht nichts, du lügst.

Das bringt doch alles nichts, wenn man Softwareseitig einfach nicht "the real deal" auslesen kann. Selbst wenn man Animation Error jetzt mal aus der Betrachtung völlig ausklammert. Hat ja auch nichts mit Frame Gen zu tun, aber ich wollte nur weiter verdeutlichen, dass es allgemein einfach nicht funktioniert, sich auf diese Tools zu verlassen.
Die Tools messen natürlich richtig. Aber das Problem ist dass die Schlussfolgerungen die man daraus ziehen kann nur sehr vage oder einfach nichtssagend und falsch sein können (und es öfter auch sind)

[Eadzon64]

immerhin liefert AMD was
das Verhalten ist wohl rein davon abhängig, ob das generierte Bild bereit ist, im gewünschten, durch die Hz Zahl gegebenen Bereich, platziert und ausgegeben zu werden.
Artefakte gibt es wenn das timing nicht gehalten wird, was mit aktuellen AMD Treibern der Fall ist!
Es sind nicht genug Resourcen vorhanden, oder die vorhandenen werden für die priorisierte Generierung und rechtzeitige Platzierung nicht richtig genutzt.

[aufkrawall]

Die Tools messen natürlich richtig. Aber das Problem ist dass die Schlussfolgerungen die man daraus ziehen kann nur sehr vage oder einfach nichtssagend und falsch sein können (und es öfter auch sind)
Was ist denn jetzt an der Annahme unsicher, dass mit schlechter Frame Time Varianz bei Messung von msBetweenDisplayChange mit jetzt mal grob angenommener 99%iger Wahrscheinlichkeit das VRR-Display auch wie bekloppt umschalten, flackern und die Ausgabe ruckelig erscheinen wird? Es gibt keinen Hinweis darauf, dass das nicht so wäre. Wenn es den gäbe, ok. Scheint aber nicht so zu sein.

[Eadzon64]

Es ist eine "Innovation Nvidias, die genau auf die Tensor/AI Engine zugeschnitten ist
da AMD einen general purpose Ansatz für seine Architektur gewählt hat, braucht keinen verwundern,
das es eine große Herausforderung ist da gleich zu ziehen...

[The_Invisible]

wer sagt denn eigentlich, das AMD seine eigenen Ziele, die Architktur und Features
nach den Vorstellungen, sog. Innovationen und Vorgaben von Nvidia ausrichten muss?
Nur weil ein "Großmaul sich hin gestellt hat und den Leuten verzapft, das ist es jetzt das revolutionäre, nächste große Ding, ohne das nix mehr geht?
und das Medien gerne etwas wiederkauen, was mit allen großen Marketingposaunen gut verfügbar und ohne große Müh Content,
damit Werbeeinnahmen und Aufmerksamkeit erzeugt, ist jetzt kein Wunder.
Viel wichtiger ist mir da, eine eigene Strategie von AMD, die gut zugänglichen Softwarebibliotheken, die keinen ausperren, oder benachteiligen und das zahlt sich auf lange Sicht und nachhaltig aus, wenn der Schreihals schon längst verhallt ist.
und die Welt, ist nicht, wie oft suggeriert wird Amerika, die haben halt das größte Maul und selbst Ohropax hilft dagegen bei uns leider nix mehr.
auf was bauen die großen, vom US Imperialismus befreiten Marktwirtschaften, also mehr als 2/3 der Menschheit ihre digitale Zukunft?
auf GNU/Linux und open Source.
lieber Wegbereiter einer Digital humanen Zukunft, als Kohle scheffelnde narzistische Unterdrücker!

meine Meinung!

Äh du weißt schon das fsr4/Redstone closed ist? :freak:

[Eadzon64]

was uns wieder auf die Frage bringt, was sucht eine AI Engine auf einer dedizierten Graka
wer hat das verzapft und braucht es programmierbare, selbständig agierende Maschinen
man köönte den Mensch ja selbst drauf reduzieren:biggrin:

[Eadzon64]

Äh du weißt schon das fsr4/Redstone closed ist? :freak:

weißt schon das dees real Life an scheiß interessiert:wink:

edit: im Kontext un nix gegen Di:smile:

[dargo]

Ich habe jetzt ohne den OptiScaler das offizielle Spielupdate für GoT mit ML-FG ausprobiert. Ingame gibt es jetzt auch direkt von den DEVs FSR 4.0.3. Alles also offiziell wie FSR 4.0.3 + ML-FG (wird auch richtig im Treiber angezeigt) + offizielles AL2 Ingame... Frameausgabe fürs Auge absolut sauber mit freien Frames. Da fragt man sich wirklich warum das woanders kaputt ist.

Falls es wen juckt... mit diesen Settings.
94914

Der Unterschied bei GoT ist der, dass hier offiziell die DEVs ML-FG implementieren und scheinbar auch Ahnung davon haben. Kann das tatsächlich die Ursache dafür sein? :freak:

[Eadzon64]

Ich habe jetzt ohne den OptiScaler das offizielle Spielupdate für GoT mit ML-FG ausprobiert. Ingame gibt es jetzt auch direkt von den DEVs FSR 4.0.3. Alles also offiziell wie FSR 4.0.3 + ML-FG (wird auch richtig im Treiber angezeigt) + offizielles AL2 Ingame... Frameausgabe fürs Auge absolut sauber mit freien Frames. Da fragt man sich wirklich warum das woanders kaputt ist.

Falls es wen juckt... mit diesen Settings.
94914

Der Unterschied bei GoT ist der, dass hier offiziell die DEVs ML-FG implementieren und scheinbar auch Ahnung davon haben. Kann das tatsächlich die Ursache dafür sein? :freak:

da siehste mal was passiert wenn das Framework passt!!!

[aufkrawall]

Äh du weißt schon das fsr4/Redstone closed ist? :freak:
Hast du von ihm schon mal irgendetwas nicht völlig Wirres gelesen?

[Eadzon64]

Hast du von ihm schon mal irgendetwas nicht völlig Wirres gelesen?

in der dritten jetz schon

edit:
frag halt zu Sachen nach oder kritisier mich
habe ja nicht NUR Ideologien gepostet:wink:
nicht zu fein sein

[dargo]

da siehste mal was passiert wenn das Framework passt!!!
Das ist trotzdem irgendwie strange. Jedenfalls zeigt mir GoT, dass (ML)-FG auf RDNA4 nicht generell kaputt ist mit freien Frames. Irgendjemand macht Mist. Entweder AMD oder andere DEVs. Naja... hoffentlich wird das in naher Zukunft richtig aufgeklärt.

[robbitop]

Kannst du mal schauen ob es in Games wo es unsauber läuft über Optiscaler injeziert ggf sauber läuft? Ggf dort DLSS FG auswählen oder XeSS FG und dann über Opti auf fsr ml fg? Ich frage aus Neugier und weil Opti ja schon öfter auch mal schlechte Implementierungen gefixt hat iirc :)

[aufkrawall]

Das ist schon alles längst bekannt. OptiScaler ist besser als diverse Müll-Implementierungen. Es bleibt aber trotzdem je nach Titel insbesondere auf RDNA4 "komisch" kaputt.

Sieht man btw. auch bei DF oder HWUB: In manchen Szenen ist es kurzzeitig sauber, bis es dann wieder kaputt geht. Da ist einfach der Pacing-Code und ggf. noch irgendwas im Treiber Müll.

[robbitop]

Wäre aber trotzdem sinnvoll es einzeln zu bestätigen was für einen Einfluss das macht. :)

[dargo]

Kannst du mal schauen ob es in Games wo es unsauber läuft über Optiscaler injeziert ggf sauber läuft? Ggf dort DLSS FG auswählen oder XeSS FG und dann über Opti auf fsr ml fg? Ich frage aus Neugier und weil Opti ja schon öfter auch mal schlechte Implementierungen gefixt hat iirc :)
Bei dir klingt das so als wenn ML-FG jetzt der heilige Gral wäre. Dem ist nicht so. Die unsaubere Frameausgabe gab es schon vor ML-FG auf RDNA4. Am Beispiel von AC: Shadows... egal ob FSR-FG 4.0.0 über den OptiScaler oder das "alte" FSR-FG 3.x über den OptiScaler oder das offizielle FSR-FG Ingame.... alles ist nicht 100% sauber mit freien Frames. Langsam habe ich den Verdacht wenn DEVs FSR 3.x nicht sauber implementieren wirds auch mit ML-FG automatisch Grütze, das ML-Upgrade verbessert ja nur die BQ von FG. Reine Vermutung natürlich. Aber wie man am Beispiel von GoT sieht sieht es erstmal danach aus. Das lief schon ohne ML-FG bei mir sauber und nun mit ML-FG ebenfalls.

[Eadzon64]

Das ist trotzdem irgendwie strange. Jedenfalls zeigt mir GoT, dass (ML)-FG auf RDNA4 nicht generell kaputt ist mit freien Frames. Irgendjemand macht Mist. Entweder AMD oder andere DEVs. Naja... hoffentlich wird das in naher Zukunft richtig aufgeklärt.

erst ma Mondlandung dann 9/11
Corona?

echt sorry Leute wenn ich mich gern so ausdrücke bin halt teilweise aus der Gosse:biggrin:

ist doch logisch das die Entwickler zumeist den Weg des geringsten wiederstandes und das Framework
nehmen das im PC bereich ja schon fast einem grünen Monophol entspricht.
ist der grüne Wurm ers drinne dann wird es schwierig mit ehrlichem Wettbewerb!
Hat sich halt seit der übernahme von 3DFX so im PC Bereich eingebürgert und spiegelt sich im Aktienwert = Macht

Ich wars nich:wink:
un nicht vergessen, ich finde viele Gimmicks von NV richtig geil, aber das ist doch keine Art!

[robbitop]

Bei dir klingt das so als wenn ML-FG jetzt der heilige Gral wäre. Dem ist nicht so. Die unsaubere Frameausgabe gab es schon vor ML-FG auf RDNA4. Am Beispiel von AC: Shadows... egal ob FSR-FG 4.0.0 über den OptiScaler oder das "alte" FSR-FG 3.x über den OptiScaler oder das offizielle FSR-FG Ingame.... alles ist nicht 100% sauber mit freien Frames. Langsam habe ich den Verdacht wenn DEVs FSR 3.x nicht sauber implementieren wirds auch mit ML-FG automatisch Grütze, das ML-Upgrade verbessert ja nur die BQ von FG. Reine Vermutung natürlich. Aber wie man am Beispiel von GoT sieht sieht es erstmal danach aus. Das lief schon ohne ML-FG bei mir sauber und nun mit ML-FG ebenfalls.
Hm schade. Aber auf jeden Fall schonmal Danke für die Rückmeldung. :)

[dargo]

XeEkFgTVOtU

Bin selbst erst am schauen.

Edit:
Ok... nichts Neues. Ancient verwendet hier zusätzlich zu Vsync On noch den Framelimiter. Dass dann FG sauber läuft sollte klar sein. :tongue: Wobei ich wieder nicht nachvollziehen kann warum er in einem Spiel über RTSS limitiert. Hat er wirklich noch nicht mitbekommen, dass nur der Treiberlimiter mit FG sauber limitiert? :freak:

[DrFreaK666]

Schreib ihm das als Kommentar. Ich glaube Englisch versteht er :D
Notfalls auf Portugiesisch ^^

[dargo]

Mir ist das auf englisch wiederum zu anstrengend alles. :tongue: Ich beherrsche zwar zwei Sprachen, weder englisch noch portugiesisch sind aber dabei. ;)

[robbitop]

siehe da mit Optiscaler kriegt er es auch in Problemfällen hin.

[Eadzon64]

Mir ist das auf englisch wiederum zu anstrengend alles. :tongue: Ich beherrsche zwar zwei Sprachen, weder englisch noch portugiesisch sind aber dabei. ;)

könnte das übernehmen aber dann ist der Zottel fällig:D

@robbitop
da schau einer mal an

[aufkrawall]

siehe da mit Optiscaler kriegt er es auch in Problemfällen hin.
Kann halt ohne msBetweenDisplayChange/FCAT auch Mist erzählen, wie es bei subjektiv angeblich bestätigter Flüssigkeit der Bildausgabe ständig passiert. Bestes Beispiel die ganzen Tests, die nichts gemerkt haben wollen...

[robbitop]

Kann natürlich sein - aber er sagt zumindest dass er es vorher deutlich gemerkt hat dass es kacke war und danach nicht mehr. Ist nicht super firm - da gebe ich dir Recht - aber zumindest Wert genauer untersucht zu werden. Wäre auch nicht das erste Mal dass Optiscaler unschöne Imolementierungen fixt oder zumindest verbessert.

[Eadzon64]

was ich auch nicht verstehe, das hier einige mockern, die Vulkan Unterstützung ist schlecht, un in Redstone nicht gegeben etc.
ist doch gerade bei Optiscaler gar nicht relevant, weil ja überall draw call übersetzung von Dx nach Vulkan statt findet und Vulkan unter Win keine Relevanz bei Spielen hat
der Vulkan Treiber von AMD ist aber Referenz!
da müssen andere erst mal hin kommen...

[dargo]

siehe da mit Optiscaler kriegt er es auch in Problemfällen hin.
Glaube doch nicht jeden Quatsch. ;)

Ich habe das 1:1 in Cronos nachgestellt was Ancient da macht. Das Spiel fühlt sich mit freien Frames sehr gut an mit FG. Das hier ist zumindest brauchbar bei Drehungen. Aber eben nicht perfekt, sondern nur kurz davor. Perfekt ist es nur mit einem Treiberframelimit. Unterschiede sind aber wirklich schon verdammt klein. Wer kein geschultes Auge hat für den werden freie Frames in diesem Spiel auch schon absolut flüssig aussehen. Verglichen habe ich freie Frames mit ~180fps vs. feste 160fps. Letzteres ist wie gesagt perfekt bei der Bildausgabe.

btw.
Dieses ganze "Voodoo" mit OptiScaler + FSRFG3.1 als Input und FSRFG als Output etc. braucht es gar nicht. Das Zauberwort ist wie immer Framelimit über den Treiber.

Edit:
Was mir bei Cronos aber auffällt ist die Tatsache, dass bsw. Nukems-FG mit DLSS-Inputs völlig unbrauchbar ist. Ich stehe einfach nur rum mit 150fps dank FG. Die Frequenz am OLED springt ständig wild hin und her zwischen 9xHz und 20xHz. Die Folge davon ist dann natürlich leichtes VRR-Flicker am OLED. Das passiert mit FSRFG zum Beispiel nicht. Bei vergleichbaren FG-Frames war der tiefste Wert am OLED bei 157Hz, wechselt aber auch immer wieder mal Richtung 20xHz. Hier flackert am OLED dann aber nichts. Scheinbar sind die Wechsel um Flicker auszulösen nicht stark genug.

[raffa]

Unter linux gibts keinen Wunderlimiter per Treiber, da hilft nur Optiscaler mit (nukems)DLSSG->FSR-FG um vernünftiges Pacing mit FSR-FG zu bekommen. (allerdings 3.1, wär interessant ob das mit ML-FG immer noch so ist)

[dargo]

What? Jetzt soll das Pacing unter Linux mit Nukems sauber sein und unter Windows nicht? :freak: Entschuldige bitte meine Skepsis, aber ich glaube sowas erst wenn ich Beweise dafür sehe. :) Am besten Videos wo man den Framecounter inkl. Frequenz vom Bildschirm gleichzeitig sieht. OSD vom Bildschirm bei der Frequenz sollte aber natürlich schnell genug sein.

[Eadzon64]

What? Jetzt soll das Pacing unter Linux mit Nukems sauber sein und unter Windows nicht? :freak: Entschuldige bitte meine Skepsis, aber ich glaube sowas erst wenn ich Beweise dafür sehe. :) Am besten Videos wo man den Framecounter inkl. Frequenz vom Bildschirm gleichzeitig sieht. OSD vom Bildschirm bei der Frequenz sollte aber natürlich schnell genug sein.

Zeichen und Wunder
religious?

traue das aber Linux in Kombination schon zu

aber ma kein Fetish draus machen

[raffa]

What? Jetzt soll das Pacing unter Linux mit Nukems sauber sein und unter Windows nicht? :freak: Entschuldige bitte meine Skepsis, aber ich glaube sowas erst wenn ich Beweise dafür sehe. :) Am besten Videos wo man den Framecounter inkl. Frequenz vom Bildschirm gleichzeitig sieht. OSD vom Bildschirm bei der Frequenz sollte aber natürlich schnell genug sein.

Schon ok, Skepsis ist angebracht. Ich spiel damit MSFS 2024. Hab leider kein Equipment für umfangreiche Tests ala DF oder dergleichen.

[dargo]

Ich sehe da nur, dass der Graphen mit Nukems glatter ist. Das ist aber noch lange kein Beweis für saubere Frameausgabe mit FG. :)

[raffa]

Nuja, ich spiels ja so und nukems ist ok, die Frequenzen an meinem Monitor OSD passen auch soweit dazu, fsr3 only nicht.
Ein Spiel ist aber auch nicht repräsentativ und mehr beweisen kann ichs nicht, das müssen andre tun.

Jedenfalls ist meine Erfahrung mit dem normalen FSR3-FG pacing unter linux eher mäh, vorallem weils keinen Limiter (ingame, al2 opti, mangohud, libstrangle,...) gibt der das glattbügelt (jedenfalls kenn ich keinen)
Wenns so wäre wie mit FSR-ML? unter Windows, so wie das sagst mit Treiber limiter, dann wär ich zufrieden, spiel sowieso alles mit fps-limit

[dargo]

Nuja, ich spiels ja so und nukems ist ok, die Frequenzen an meinem Monitor OSD passen auch soweit dazu, fsr3 only nicht.
Ein Spiel ist aber auch nicht repräsentativ und mehr beweisen kann ichs nicht, das müssen andre tun.

Hmm... das wäre schon mal eine Verbesserung vs. Windows. Jetzt machst du mich neugierig. :D Ich würde zu gern schnell mal eben was unter Linux testen. Aber unter diesem OS bin ich absoluter Noob. :redface:

[raffa]

Man wächst mit seinen Aufgaben :D

[Achill]

Ihr habt im Optiscaler ein Framelimiter, sieht man auch auf Raffa's Bild. Über fakenvapi ... das schon mal probiert unter Win / Linux?

[Eadzon64]

Man wächst mit seinen Aufgaben :D

und eine Aufgabe hat Er ja jetz

muss ja nich der Metal Jesus draus werden:freak:

edit:@Achill
genau Framelimiter im Oscaler ist gegeben

[DrFreaK666]

https://wccftech.com/heres-how-to-add-amd-fsr-redstone-frame-gen-to-almost-any-game-using-optiscaler/

[dargo]

Ihr habt im Optiscaler ein Framelimiter, sieht man auch auf Raffa's Bild. Über fakenvapi ... das schon mal probiert unter Win / Linux?
Der limitiert mit FG unter Windows nicht sauber. Wie der aktuelle Stand ist weiß ich aber nicht, wird ja laufend geupdatet. Und unter Linux kann eh alles anders sein. :tongue:

[Eadzon64]

Der limitiert mit FG unter Windows nicht sauber. Wie der aktuelle Stand ist weiß ich aber nicht, wird ja laufend geupdatet. Und unter Linux kann eh alles anders sein. :tongue:

bligsch nimmee durch?

aber hast ja immer Eine Option, in dem Fall Treiber

und ich manchmal auch nicht, ist ja im Fluss...

[robbitop]

https://www.pcgameshardware.de/FidelityFX-Super-Resolution-Software-277617/News/FSR-Frame-Generation-auf-RDNA-3-unter-Linux-1489450/
Redstone FSR FG (ML) rennt auf RDNA3 unter Linux mit FP8 Emulation.

Da AMD noch sehr aktiv RDNA3 neu verkauft, finde ich sollten sie das schon auch für ihre Kunden bringen. FP8 Emulation scheint ja kein großes Drama zu sein. Damit könnte man auch etwas Sympathie holen.

[OgrEGT]

Hier die Meldung auf VC...
https://videocardz.com/newz/modder-gets-redstone-fsr-4-frame-generation-running-on-rdna-3-gpus
Offensichtlich läuft das derzeit nur unter Linux Proton mit bestimmten Versionen und Optiscaler... Rechenzeit auf einer 7800XT 0.07ms FSR3 FG vs 0.13ms FSR4 FG...
Aber immerhin :)

[dargo]

Endlich habe ich es geschafft paar Spiele unter Bazzite (Linux) zum Laufen zu bringen. :uhippie: Wenn man sich damit etwas beschäftigt ist es eigentlich gar nicht so schwer. :)
https://i.postimg.cc/BtLf0S9r/R-C.jpg (https://postimg.cc/BtLf0S9r)

Das hier ist noch FSR 3.x, für den OptiScaler muss ich mich bei Linux noch etwas reinfuchsen. Aber leider ist es unter Linux genauso wie unter Windows 11 mit FG und freien Frames. Auch unter Linux springt die Frequenz am Bildschirm wild hin und her. Ergo ist hier die Frameausgabe ohne Framelimit nicht 100% sauber.

[robbitop]

Hier die Meldung auf VC...
https://videocardz.com/newz/modder-gets-redstone-fsr-4-frame-generation-running-on-rdna-3-gpus
Offensichtlich läuft das derzeit nur unter Linux Proton mit bestimmten Versionen und Optiscaler... Rechenzeit auf einer 7800XT 0.07ms FSR3 FG vs 0.13ms FSR4 FG...
Aber immerhin :)
Sub ms Bereich. Das ist ok IMO. Insbesondere wenn man in Betracht zieht, dass das mit FP8 Emulation ist (also man ggü FP16 auf rdna3 keinen speedup bekommt).

[raffa]

Endlich habe ich es geschafft paar Spiele unter Bazzite (Linux) zum Laufen zu bringen. :uhippie: Wenn man sich damit etwas beschäftigt ist es eigentlich gar nicht so schwer. :)


Grats!
Falls du Lust auf einen kleinen Nebentest verspüren solltest: Könntest du mal grob ermitteln, wieviel Leistung bei ~50% Powerlimit übrigbleiben? So im Bereich 150/180 Watt, dem Powerlimit einer 9060XT.

Optiscaler: Wie immer ins Spieleverzeichnis neben die exe kopieren, ein Terminal in diesem Verzeichnis öffnen und dann:

chmod +x setup_linux.sh
./setup_linux.sh

[dargo]

Grats!
Falls du Lust auf einen kleinen Nebentest verspüren solltest: Könntest du mal grob ermitteln, wieviel Leistung bei ~50% Powerlimit übrigbleiben? So im Bereich 150/180 Watt, dem Powerlimit einer 9060XT.

Auch das noch. xD


Optiscaler: Wie immer ins Spieleverzeichnis neben die exe kopieren, ein Terminal in diesem Verzeichnis öffnen und dann:

chmod +x setup_linux.sh
./setup_linux.sh
Ich installiere den Optiscaler genau wie unter Windows, das funktioniert auch so. Aber mir ist das noch zu viel Baustelle. v0.79 funktioniert bsw. einwandfrei. v0.9.0 vom 18.12 und 19.12... crash in R&C.

Edit:
max. 304W vs. max. 160W @Stock V/F-Kurve. Das ganze mit 4k + FSR 4.0.2 balanced ohne FG.
https://i.postimg.cc/HcBWGtrb/304W.jpg (https://postimg.cc/HcBWGtrb) https://i.postimg.cc/BtnQTRzp/160W.jpg (https://postimg.cc/BtnQTRzp)

btw.
Die amd_fidelityfx_upscaler_dx12.dll von v0.9.0 macht irgendwie Probleme unter Linux bei R&C, sobald ich die austausche und die aus v0.7.9 nehme crasht nichts. Der crash kam immer sobald ich den Upscaler von XeSS auf FSR4 umschalte.

[raffa]

das liegt eher nicht an Optiscaler, sondern an VKD3D-Proton
mit FSR 4.0.3
https://github.com/HansKristian-Work/vkd3d-proton/issues/2753

Mal mit ProtonEperimental probiert?

edit: Danke dir!

[dargo]

das liegt eher nicht an Optiscaler, sondern an VKD3D-Proton
mit FSR 4.0.3

Jepp... jetzt bin ich auch dahinter gekommen. v0.9.0 funzt ohne Probleme, muss nur FSR 4.0.3 gegen FSR 4.0.2 austauschen. :)
https://i.postimg.cc/0bmYv6CF/v0-9-0.jpg (https://postimg.cc/0bmYv6CF)


Mal mit ProtonEperimental probiert?

Wie aktiviere ich das in Steam?

Habs gefunden, crasht auch.

[Eadzon64]

Moin:D

ihr nehmt aber schon die neuesten Proton Forks wie ProtonGE, EM etc.
VKd3d ist dann die Git Version und die entwickelt sich ja auch ständig weiter
man kann auch den Launcher, wie Lutris direkt auf die System eigene VKD3D
Git Version fest legen, oder eine zB. selbst kompilierte zu weisen...

ProtonPlus, protonup-qt installieren und Fork zum installieren auswählen, bietet auch VKD3D und DXVK

[dargo]

Zu viel Gefrickel, überlasse ich anderen. Allgemein ist mir Linux noch nicht ausgereift genug um ernsthaft Windows 11 zu ersetzen. Vielleicht in 1-2 Jahren oder so. Mich nervt es schon wenn irgendeine Kleinigkeit nicht so funktioniert wie es soll und du wieder Unmengen an Zeit in die Suche im Netz investieren darfst. Nee.... lass mal. Können gerne andere machen. Spielerfahrung ist unter Windows 11 nach wie vor deutlich besser, zumindest für mich.

[Eadzon64]

Zu viel Gefrickel, überlasse ich anderen. Allgemein ist mir Linux noch nicht ausgereift genug um ernsthaft Windows 11 zu ersetzen. Vielleicht in 1-2 Jahren oder so. Mich nervt es schon wenn irgendeine Kleinigkeit nicht so funktioniert wie es soll und du wieder Unmengen an Zeit in die Suche im Netz investieren darfst. Nee.... lass mal. Können gerne andere machen.

hast also doch mal wieder Linux installiert, kannst es nicht lassen:biggrin:
das wird schon!
und was Gefrickel nennts wird ganz schnell DER Standard
Windows Hirn Blockade nannte ich es damals bei mir:smile:

[raffa]

Offtopic: Ich bin vor drei Jahren komplett umgestiegen, nur ein Notfall Win10 hab ich noch auf einer kleinen SSD, falls ich mal ein Tool brauche, das nur nativ läuft, oder um sowas wie Firmwareupdates fürs Mausdongle einzuspielen... - aber ich versteh auch, warum man bei Win11 bleibt. Nicht jeder hat Lust auf das Gefrickel und alle Spiele laufen auch nicht (Stichwort: Anti-Cheat)

Topic:
Amd sollte wirklich mal mit einem FSR4 Redstone Light für RDNA3 um die Ecke kommen, das wär schon wichtig fürs Ansehen und angebracht, weil es immer noch neue RDNA(3.5) Hardware zu kaufen gibt

[Eadzon64]

Offtopic: Ich bin vor drei Jahren komplett umgestiegen, nur ein Notfall Win10 hab ich noch auf einer kleinen SSD, falls ich mal ein Tool brauche, das nicht nur nativ läuft, oder um sowas wie Firmwareupdates fürs Mausdongle einzuspielen... - aber ich versteh auch, warum man bei Win11 bleibt. Nicht jeder hat Lust auf das Gefrickel und alle Spiele laufen auch nicht (Stichwort: Anti-Cheat)

Topic:
Amd sollte wirklich mal mit einem FSR4 Redstone Light für RDNA3 um die Ecke kommen, das wär schon wichtig fürs Ansehen und angebracht, weil es immer noch neue RDNA(3.5) Hardware zu kaufen gibt
war bei mir auch so, immer so paar Sachen, wo man gemeint hat es braucht ein Windows, aber gibt für alles unter Linux workaround, oder die entsprechende Software.
gut mit einer einzigen Ausnahme bis jetz neuer Xbox x/s Controller wo erst die Firmware updaten musst um unter Linux zu laufen und dafür brauchts, wie solls auch anders sein den f. Microsoft Store. Da bin ich dann tatsächlich kurz zum Nachbarn und hab das dort gemacht:freak: gibts aber bestimmt auch einen workaround

verstehe AMD da auch nicht mehr und nervt auch tierisch, haben sich so gut gemacht und dann solch ein Arschloch Verhalten.
Betifft zum Beispiel auch RDNA3.5, AI/Strix ist jetz schon fast 3 Jahre am Markt, aber wollen nochmal 3 Jahre drauf rum reiten, anstatt auf die neue Arch umzustellen.
Ist vielleicht politisch oder so, nicht gewollt, sollen den Platzhirsch Nvidia nicht gefährden
also AMD nervt durchaus genug und sind bei weitem keine Heiligen!

[Ex3cut3r]

Ist vielleicht politisch oder so, nicht gewollt, den Platzhirsch Nvidia zu gefährden


Genau, eine gewinnorientierte Firma mit Sitz im Westen will natürlich den großen Konkurrenten nicht ans Bein pinkeln. Das wird es sein, du bist da einer ganz heißen Spur auf der Ferse, wann ist die DEMO in Leipzig?

[dargo]

Offtopic: Ich bin vor drei Jahren komplett umgestiegen, nur ein Notfall Win10 hab ich noch auf einer kleinen SSD, falls ich mal ein Tool brauche, das nicht nur nativ läuft, oder um sowas wie Firmwareupdates fürs Mausdongle einzuspielen... - aber ich versteh auch, warum man bei Win11 bleibt. Nicht jeder hat Lust auf das Gefrickel und alle Spiele laufen auch nicht (Stichwort: Anti-Cheat)

Nicht nur das, das ganze Ökosystem drum herum passt einfach nicht für meinen user case.

Linux:
* kein korrekt funktionierender Framelimiter
* keine Raumkorrektur der LS (gibt zwar eine Alternative zu Equalizer APO, noch nicht probiert)
* keine Möglichkeit den max. Boost meines 5800X3D zu senken (PBO2-Tuner für Linux fehlt)
* kein Fancontrol (wird sicherlich eine Alternative geben, muss man wieder suchen)
* Idle Verbrauch der Graka deutlich höher weil der Vram in Idle nicht unter 9xxMhz geht
* Textscaling bei Bildschirmen mit hohen ppi manchmal problematisch

Und da reden wir noch nicht mal von dem Rest um jedes Spiel zum Laufen zu bringen. Wobei mir der Faugus Launcher schon ganz gut gefällt. Musste Lutris wieder aufgeben weil ich darunter Visual C++ nicht installiert bekam, was unter Faugus direkt funzte. Bei einer Sache gefällt mir Linux aber gut. Alan Wake 2 läuft unter Linux deutlich sauberer als unter Windows 11. Unter Win ist das Game seit mehreren Grafiktreibern völlig kaputt im Bereich Frametimes. Allerdings hatte ich unter Linux wieder starke Grafikfehler sobald ich nach oben in den Himmel schaute. Auch nicht wirklich geil. Aber vielleicht kann ich das noch fixen wenn ich mich damit mehr beschäftige. Unter Windows ist das Game auf Radeon völlig unspielbar. Stutter, Stutter...

PS: natürlich spielt auch eine große Rolle dabei, dass ich Windows seit Jahrzehnten nutze, vieles ist da schon im Blut. Ein neues OS bringt zwangsläufig Herausforderungen im Bereich Bedienung mit sich.