Test AMD FSR Redstone im Test: AI Frame Generation auf FPS, Bildqualität & Latenz untersucht

[ElliotAlderson]

welches waren denn die letzten projekte die Amd eingestellt hat weil sie das interresse daran verloren haben?

https://gpuopen.com/tressfx/

 

[Northstar2710]

@ElliotAlderson und woran siehst du das tressfx eingestellt wurde?
Im August 2025 gab es für die 5.0version erst einen patch für die UE5.4

 

[ElliotAlderson]

@Northstar2710 Wer nutzt es? Niemand. Das letzter mir bekannte Spiel war Tomb Raider und das ist 12 Jahre her. Was bringt mir Software, die Theoretisch existiert, aber nicht genutzt wird. TressFX ist Tot.

 

[Northstar2710]

@ElliotAlderson aber das war nicht das thema. Sondern was AMD eingestellt hat, weil sie keine lust mehr haben.

 

[ElliotAlderson]

@Northstar2710 aus Kundensicht ist es das. AMD bemüht sich nicht um die Implementation in spielen -> sie haben keine Lust mehr. Alles andere ist Wortklauberei.

 

[Northstar2710]

Es ist als Plugin in der UE5 drin, wenn die Entwickler es nicht nutzen, ist es entweder nicht gut oder sie haben keine Verwendung dafür. hairworks von Nvidia wurde ja auch nicht viel öfters benutzt.

Aber eingestellt ist es nicht und somit passt es nicht.

Vielleicht hat AMD keine Lust mehr für jedes Tool bei den Entwicklern betteln zugehen, OK. Aber es ist was ganz anderes als wenn man etwas nicht mehr supportet.

 

[TheInvisible]

Also wenn selbst ein ehemaliger FSR Entwickler sagt das das Framepacing schlecht ist muss wohl was dran sein...

https://bsky.app/profile/domipheus.bsky.social%2Fpost%2F3ma3qii7g2c2f

 

[Quidproquo77]

Wo ist das entsprechende Zitat des Entwicklers zu sehen?

 

[TheInvisible]

@Quidproquo77

AMD hat sich mit diesem OpenSource Ansatz also quasi selber sabotiert. Noch schräger weil FSR4/Redstone jetzt ja Closed ist, trotzdem hat man die Chance nicht genützt es gleich richtig zu machen

 

[Quidproquo77]

Sehe nirgends einen Beleg dafür, dass das Pacing-Problem eine grundsätzliche Sache ist, vor allem da der Entwickler bei der aktuellen Version gar nicht mehr dabei ist. Das soll eine Quelle sein?^^

 

[TheInvisible]

@Quidproquo77 Ernsthaft jetzt, du kannst daraus keinen Kontext ziehen? Der Dude war noch auf der GDC dabei als AMD Dev:

Nochmals aufbereitet: FramePacing Probleme kommen daher weil diese im Userspace und nicht im Treiber stattfinden wie es bei DLSS der Fall ist. Das war eine Vorraussetzung weil man FSR OpenSource machen musste. Da es jetzt eh kein OpenSource mehr ist fragt er sich selbst warum das nicht behoben wurde

 

[Quidproquo77]

Ernsthaft jetzt, du kannst daraus keinen Kontext ziehen?

Ja, er trifft keine klare Aussage, sondern nur vage und mit der aktuellen Entwicklung hat er nichts mehr zu tun.

FramePacing Probleme kommen daher weil diese im Userspace und nicht im Treiber stattfinden wie es bei DLSS der Fall ist.

Schon klar, wenig direkte Kontrolle über die Hardware Queues Grafiktreibers im Verhältnis zu Nvidias Vorgehensweise...das war aber das alte FSR.
FSR Redstone hat den Ansatz dementsprechend geändert und damit sind die Informationen belanglos.
Die spezifischen Probleme in diversen Tests können auch von etwas anderem herrühren, also inwiefern soll das eine verwertbare Information sein? Die bestätigt doch wenn überhaupt das Gegenteil von dem was du behauptest.

Und das da was nicht behoben worden sei geht auch nirgends hervor. Also ein typischer Nvidia-Cope.

 

[TheInvisible]

Ja, er trifft keine klare Aussage, sondern nur vage und mit der aktuellen Entwicklung hat er nichts mehr zu tun.

Das ist keine klare Aussage? OK...

Und er war auch bei FSR4 Dev als Lead beteiligt, wenn weiß er also mehr als wir alle zusammen...

FSR Redstone hat den Ansatz dementsprechend geändert und damit sind die Informationen belanglos.

Sagt wer? Da hätte er dann sicher einen Hinweis gegeben.

 

[TheInvisible]

Und das da was nicht behoben worden sei geht auch nirgends hervor.

DF ist sicher auch wieder falsch ; )

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung

 

[Quidproquo77]

Das ist keine klare Aussage? OK...

Du redest vom alten FSR 3 FG Modell das analytisch vorging, während das neue eine Art von Hardware Flip Metering unterstützt und die Logik für das Frame Pacing nicht mehr von der CPU (Userspace) abhängig ist, sondern es explizit! direkt in der Display Engine passiert.

Die Probleme mit dem Pacing kommen bei HWU also woanders her und dein Argument gilt nur für das alte FSR 3.1 FG, worauf RDNA3 User sitzen bleiben und worauf sich die Aussage des Entwicklers bezieht welche von dir falsch interpretiert wurde.

Das ändert natürlich nichts dran, dass auch Digital Foundry auch mit Redstone Ml Framepacingprobleme gefunden hat, wobei es insgesamt etwas besser wurde.
https://www.digitalfoundry.net/features/fsr-redstone-frame-generation-better-images-still-too-shaky

 

[dx1]

Unterstützen ist nicht gleich verwenden.

 

[TheInvisible]

Die Probleme mit dem Pacing kommen bei HWU also woanders her und dein Argument gilt nur für das alte FSR 3.1 FG, worauf RDNA3 User sitzen bleiben und worauf sich die Aussage des Entwicklers bezieht welche von dir falsch interpretiert wurde.

Das DF Video nicht gesehen?

 

[Quidproquo77]

Unterstützen ist nicht gleich verwenden.

Ich nehme mal nicht an, dass AMD in ihrem Paper lügt und die generierten Frames nicht mehr von der Applikation in die Warteschlange geschoben, sondern vom Treiber direkt in die Hardware Pipeline injiziert werden.

Und diese sicherere Methode läuft proprietär und nicht mehr auf allen GPUs.
Die bisherigen technischen Analysen belegen eigentlich gut, dass das so läuft und ist auch bei GPU Open nachzulesen.
"Mandatory Call Order".

Das DF Video nicht gesehen?

Natürlich. Aber da man dir alles aus der Nase ziehen muss: Nenne die konkrete Stelle im Video die zeigt wovon du redest.

Aber da wird nichts kommen, weil sich die Aussage des Entwicklers auf FSR3.1 bezieht und nicht auf den ML Ansatz ohne "Userspace".

 

[TheInvisible]

Die bisherigen technischen Analysen belegen eigentlich gut, dass das so läuft und ist auch bei GPU Open nachzulesen.
"Mandatory Call Order".

Das sagt gar nix aus, das ist nur die Order wie die API Aufrufe auszuführen sind

Natürlich. Aber da man dir alles aus der Nase ziehen muss: Nenne die konkrete Stelle im Video die zeigt wovon du redest.

1+1=? Wenn das Frame Pacing noch immer schlecht ist wirds nicht implementiert sein...

 

[Quidproquo77]

Das sagt gar nix aus, das ist nur die Order wie die API Aufrufe auszuführen sind

Wenn die Doku von GPU Open nichts aussagt, könntest du die Funktionsweise auch bei Nvidia GPUs in Frage stellen.

FSR 3 nutzt eine softwarebasierte Proxy sweptchain.
Frame Gen ist dort nur ein Software Layer und hat mit "ML" gar nichts zu tun und das ist schlussendlich auch das Problem mit dem Pacing. Das ist laut Digital Foundry auch verbessert, aber immer noch nicht besonders.

Wenn das Frame Pacing noch immer schlecht ist wirds nicht implementiert sein...

Tja da muss man sich auf AMDs Angaben verlassen, könnte ja auch zu Nvidia das gleiche spekulieren. Laut Doku wird es genutzt.