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

[Tesseract]

"As a base technology, FSR 3 works on any vendor's hardware, but 'out of the box' there is no way to mitigate for the added latency of frame generation. AMD's solution is driver-level Anti-Lag, or better yet, a new Anti-Lag+ technology that the firm did not want to discuss in depth during our presentation."

https://www.eurogamer.net/digitalfoundry-2023-amd-reveals-long-awaited-fsr-3-tech-and-frame-gen-for-every-dx11dx12-game

[Exxtreme]

Ups, dann habe ich mich verlesen. Wie dem auch sei, in Spiele, in die sie FSR3 reinbekommen da würden sie auch Antilag+ reinbekommen, ja. Es wird aber immer Spiele geben, die kein FSR3 können werden. Da hat man mit sowas wie Reflex keine Chance wenn die Entwickler da Hand anlegen müssen. Dann ist etwas treiberseitiges besser.

[Gipsel]

Ups, dann habe ich mich verlesen.Nein, hast Du nicht. Die von Tesseract zitierte Aussage kollidiert ein wenig mit der von AMD selber (nach der im Spiel integriertes FSR3 latenzreduzierende Techniken enthalten soll [das Kind hat nur erstmal keinen Marketingnahmen erhalten]).

[Tesseract]

Ups, dann habe ich mich verlesen. Wie dem auch sei, in Spiele, in die sie FSR3 reinbekommen da würden sie auch Antilag+ reinbekommen, ja. Es wird aber immer Spiele geben, die kein FSR3 können werden. Da hat man mit sowas wie Reflex keine Chance wenn die Entwickler da Hand anlegen müssen. Dann ist etwas treiberseitiges besser.
auf der anderen seite kann das aber auch zu situationen führen wo ein spiel FSR3 aber kein AL+ hat. ich sehe darin keinen vorteil, außer dass man das feature RDNA3-exklusiv machen und gleichzeitig behaupten kann FSR3 wäre hardwareunabhängig.

eigentlich ist dieser latency-zirkus etwas das microsoft schon vor jahren in DX fixen hätte sollen aber die treibervariante ist imho die schlechteste von allen solange es keine globale lösung ist.

Nein, hast Du nicht. Die von Tesseract zitierte Aussage kollidiert ein wenig mit der von AMD selber (nach der im Spiel integriertes FSR3 latenzreduzierende Techniken enthalten soll [das Kind hat nur erstmal keinen Marketingnahmen erhalten]).
wo ist diese aussaage?

[The_Invisible]

außer dass man das feature RDNA3-exklusiv machen und gleichzeitig behaupten kann FSR3 wäre hardwareunabhängig.

Wenn sie das so durchziehen wollen braucht sich aber auch keiner mehr über FG nur auf Ada aufregen...

[DrFreaK666]

...
wo ist diese aussaage?

Hier:https://gpuopen.com/fsr3-announce/

We’ve integrated some latency reduction techniques into FSR 3

Hab ich aber nun wirklich schon oft genug zitiert!

[Tesseract]

das ist eine schwammige aussage die sich genau so gut auf die asynchonität der pipeline bzgl. interpolation, der verzögerten präsentation und der gleichzeitgen berechnung des neuen frames beziehen kann wie sie ein paar zeilen weiter oben gezeigt wird.
wenn richard das so schreibt hat er die leute von AMD wahrscheinlich direkt vor ort und mit kontext explizit danach gefragt.

du liest da was du lesen willst.

[aufkrawall]

In der Tat sehr seltsam, dass eine FSR 3-Implementierung allein nicht das Optimum bei der Latenz rausholt. Kann eigentlich nur heißen, dass es ohne Anti-Lag+ mit CPU Prerender >0 Frames läuft, anders als bei Reflex. Wäre ziemlich bitter.

[robbitop]

Bei CB steht dass AMD auf Nachfrage sagte, dass FSR3 eigene Latenzreduktion mitbringt. Verkürzen der Render queue durch Verringerung der Auslastung. Das ist nicht groß anders als das was reflex macht.


Angesprochen auf das Thema Latenz will AMD diesbezüglich auch bei FSR 3 Verbesserungen eingebaut haben – denn Latenz ist bei Frame Generation immer ein große Thema. Ähnlich wie bei Reflex sollen Spiele mit FSR 3 automatisch nie ganz das GPU-Limit ausnutzen, was dann eine bessere Synchronisation mit der CPU ermöglicht, wodurch die Latenz verbessert werden kann. Darüber hinaus führt AMD im Treiber die Funktion „Anti-Lag+“ ein, die das bereits bekannte Anti-Lag erweitert. Die Option muss unabhängig von FSR 3 im Treiber aktiviert werden, automatisch passiert dies nicht. Details zu Anti-Lag+ gibt es noch nicht.
https://www.computerbase.de/2023-08/amd-fsr-3-frame-generation-laeuft-offiziell-ab-rx-5000-und-rtx-2000/

Antilag/antilag+ ist zusätzlich.

[aufkrawall]

Und was soll dann noch Anti-Lag+ machen?

[basix]

Bei CB steht dass AMD auf Nachfrage sagte, dass FSR3 eigene Latenzreduktion mitbringt. Verkürzen der Render queue durch Verringerung der Auslastung. Das ist nicht groß anders als das was reflex macht.

Ist nur die Frage, wie sie das machen. Reflex bringt Hooks für die Spieleengines mit. Deswegen geht das nur mit expliziter Unterstützung des Games. Im guten Fall hat AMD das in FSR3 integriert (und wird aktiviert, egal ob FMF aktiv ist oder nicht). Im besten Fall lässt es sich wie Reflex noch separat einstellen. Im schlechten Fall haben die Latenzoptimierungen einen anderen Charakter, womit deren Effektivität vermutlich reduziert wäre.

[robbitop]

Ist nur die Frage, wie sie das machen. Reflex bringt Hooks für die Spieleengines mit. Deswegen geht das nur mit expliziter Unterstützung des Games. Im guten Fall hat AMD das in FSR3 integriert. Im besten Fall lässt es sich wie Reflex noch separat einstellen.
Das ist Teil von FSR3 und wird als Paket ins Spiel implementiert. Genau wie Reflex.

Und was soll dann noch Anti-Lag+ machen?
Ich schätze es ist das (funktionierenende?) Gegenstück zu Nvs ULL. Antilag hat ja nicht überall funktioniert laut Tests. Das Plus impliziert es ist das gleiche nur besser wie AL.

[aufkrawall]

Reflex braucht aber expliziten Treiber-Support. Da eine FSR 3-Implementierung auf allen Herstellern läuft, schließt das eigentlich eine exakte Nachbildung dieser Funktionalität aus.

[robbitop]

Reflex braucht aber expliziten Treiber-Support. Da eine FSR 3-Implementierung auf allen Herstellern läuft, schließt das eigentlich eine exakte Nachbildung dieser Funktionalität aus.

Tja oder es ist einfach nur verdongelt. Damit es bloß kein anderer nutzen kann (wie immer). Ich kenne keine Beweise dass das funkionell wirklich nötig ist.

[aufkrawall]

Du kennst auch keine Beweise dafür, was Reflex genau macht. ;)

[basix]

Kurze Beispielrechnung:
- FSR3 Off = 53fps, 10ms Latenz für Eingabe und Monitor, 2x Frames Latenz = 37.7ms
- FSR3 Off = 53fps, 10ms Latenz für Eingabe und Monitor, 3x Frames Latenz = 66.6ms
- FSR3 FMF On = 85fps, 10ms Latenz für Eingabe und Monitor, 2.5x Frames Latenz = 56.6ms

2x Frames = Maximale Latenz im Idealfall (Prerender-Limit = 0, Usereingabe ganz am Anfang bei einem Frame)
3x Frames = Typisch für viele Games
2.5x Frames = Das selbe wie der erste Punkt, aber aufgrund FMF um 0.5 Frames verzögert

AMD muss also irgendwie das Prerenderlimit = 0 forcieren und noch die GPU-Last leicht unter 100% halten. Wie soll das ohne Treiber genau funktionieren? Kann das vom Spiel gesteuert werden?

[Tesseract]

Ich schätze es ist das (funktionierenende?) Gegenstück zu Nvs ULL. Antilag hat ja nicht überall funktioniert laut Tests.

ich dachte ULL ist genau das was anti-lag immer schon gemacht hat. :confused:
das erklärt auch nicht die exklusivität für RDNA3 wenn das quasi nur ein "bugfix" ist.

[Odal]

Ich verstehe eh nicht den Sinn der Frameinterpolation....man braucht 60FPS damit der Lag halbwegs erträglich wird und die BQ steigt mit Sicherheit nicht. Dann wirft man wieder Anti-Lag Features drauf und bremst die GPU aus um das zu kompensieren.

[basix]

Motion Clarity und Smoothnes profitieren ganz klar davon ;)

Selbst in TW3E getestet: 80fps mit FG fühlen sich besser an als 55fps ohne. Reflex bei beiden aktiv.
Visuelles Feedback ist viel direkter als die Latenz, deswegen spürt man das viel schneller, wenn es nicht gut genug ist.

[aufkrawall]

AMD muss also irgendwie das Prerenderlimit = 0 forcieren und noch die GPU-Last leicht unter 100% halten. Wie soll das ohne Treiber genau funktionieren? Kann das vom Spiel gesteuert werden?
Prerenderlimit 0 ließe sich über den Treiber sicherlich erzwingen (Anti-Lag kann ja auch irgendwas von 0.5-1 bereits auch für D3D12 erzwingen), würde aber die GPU-Auslastung und damit die Performance drücken. Wobei das ggf. durch FG wieder ausgefüllt werden könnte, aber vermutlich ist so eine Laien-Vorstellung zu simpel (?). Wenn die App einfach 0 macht, dürfte das das gleiche Problem haben.

Imho ist Reflex ein dynamischer in-game fps-Limiter, der mit Auslastungsdaten vom Treiber gefüttert wird und so Prenrederlimit 0-Latenz hat, aber mit viel geringerem Performance-Verlust.

[robbitop]

Du kennst auch keine Beweise dafür, was Reflex genau macht. ;)

Richtig aber es ging um das FSR3 Äquivalent und wie soll das bloß ohne Treiberintegration gehen. Der Zweifel an der Notwendigkeit der Treiberimplementierung (nur weil MV es so macht) ist legitim.

[basix]

Wie gesagt, ohne Treiber kann das eigentlich nur das Spiel irgendwie regeln (zusammen mit Hilfswerten/Hilfsfunktionen von FSR3).

[robbitop]

ich dachte ULL ist genau das was anti-lag immer schon gemacht hat. :confused:
das erklärt auch nicht die exklusivität für RDNA3 wenn das quasi nur ein "bugfix" ist.

Wir wissen es (noch) nicht. Das ist Spekulation. Aber AMD hat offenbar obiges (Latenzreduktion mit reduktion der GPU Auslastung) gesagt. Also stehen die Vorzeichen für nicht-RDNA3 doch ganz gut.

Im Übrigen haben NV GPUs ja eh Reflex selbst wenn obiges nicht ausreicht. Würde dann also nur rdna2 und geringer betreffen.

[Tesseract]

Imho ist Reflex ein dynamischer in-game fps-Limiter, der mit Auslastungsdaten vom Treiber gefüttert wird und so Prenrederlimit 0-Latenz hat, aber mit viel geringerem Performance-Verlust.

ja, so wie ich das verstanden habe kennt reflex die CPU-time und die GPU-time pro frame und verzögert die freigabe für die CPU so lange dass die CPU möglichst spät mit dem frame beginnt (und dadurch aktuellere inputs pollt) aber rechtzeitig fertig wird um nicht zu limitieren. simplifiziert ist das ein "dynamischer framelimiter".

[basix]

Im Übrigen haben NV GPUs ja eh Reflex selbst wenn obiges nicht ausreicht. Würde dann also nur rdna2 und geringer betreffen.

Nicht zwingend ;)

Nur wenn Reflex oder DLSS3 ebenfalls implementiert wurden. Bei FSR3 only gilt das dann ja nicht.

[robbitop]

Zumindest dafür sollte es aber keine Treibereinbindung brauchen. Beispiel: Doom und Tomb Raider kennen die CPU/GPU Auslastung pro frame auch (kann man sich anzeigen lassen).

[robbitop]

Nicht zwingend ;)

Nur wenn Reflex oder DLSS3 ebenfalls implementiert wurden. Bei FSR3 only gilt das dann ja nicht.

Stimmt den Fall hab ich nicht bedacht. Dann hoffen wir einfach mal dass FSR3 das adäquat abdeckt.

[Gast]

Hier:https://gpuopen.com/fsr3-announce/



Hab ich aber nun wirklich schon oft genug zitiert!

Ist eben eine Aussage ohne wirklichen Inhalt.
Das kann sich auf alles beziehen, auch einfach auf die Latenz der Framegenerierung selbst, und nicht wie bei Reflex um die Latenzminimierung der Engine an sich.

[gedi]

Reflex braucht aber expliziten Treiber-Support. Da eine FSR 3-Implementierung auf allen Herstellern läuft, schließt das eigentlich eine exakte Nachbildung dieser Funktionalität aus.

Hypr braucht zwingend RDNA3?! Dies ist jenes was Anfang September ansteht! FSR3 für alle Q1 2024. Wobei, wenn ich mir den Krempel so anschaue, dann sieht es im ersten Moment nach crab aus. Sprich ein dynamischer Upscaler, not more not less!

[GerryB]

Am Interessantesten ist für mich der Native-Mode als Alternative zu TAA. (bitte schnellstmöglich)
Wenn dann mal noch FMF dazu kommt, why not, probieren kostet nix.

@basix
evtl. musste nochmal mit 49 statt 53fps nachrechnen

[DrFreaK666]

Hoffe den Native Mode kann man rückwirkend erzwingen

[aufkrawall]

Die DLLs für FSR 2 sind ständig nicht abwärtskompatibel, wenn überhaupt durch ein Spiel gesonderte DLLs genutzt werden.
Kann aber auch nicht nachvollziehen, warum man noch native Auflösung will. Ist eher so, dass man in neueren Spielen zunehmend eh Upsampling braucht, um überhaupt noch auf gescheite fps-Raten zu kommen.
Der Algorithmus müsste dann auch speziell für 100% Auflösung getweakt sein, um nicht unnötig schlecht auszusehen. Ich fürchte, das wird deutlich schlechter aussehen als das TAA in den aktuellsten UE5-Branches bzw. Fortnite.

[DrFreaK666]

Für Screenshots wäre das super :)

[Platos]

Ist der native mode nicht das amd pendant zu nvidias DLAA ?

Weil das kann man schon mal brauchen, wenn man Leistung übrig hat. Klar, geht nicht bei jedem Spiel, aber die Option zu haben ist nice.

[aufkrawall]

Wie schon mal gesagt, kann man das schon längst in einigen Spielen haben, indem man die dynamische fps-Skalierung auf einen tiefen Wert setzt.
Es flimmert kaum weniger als 66% und ist dabei auch noch zwangs-überschärft. Es müsste also eine gesonderte Anpassung für den 100%-Modus geben, sofern das AA/Upsampling von FSR 3 jetzt nicht auf einmal magisch gut ist.
Um das mal zu veranschaulichen: Das geht sonst auch bei 100% bei diversen Effekten stärker kaputt als DLSS Performance Preset C. Not shitting you.

[robbitop]

Hypr braucht zwingend RDNA3?! Dies ist jenes was Anfang September ansteht! FSR3 für alle Q1 2024. Wobei, wenn ich mir den Krempel so anschaue, dann sieht es im ersten Moment nach crab aus. Sprich ein dynamischer Upscaler, not more not less!
Anders herum. FSR3 kommt im September für alle. Hypr-RX und Treiber FMF kommt in Q1 2024. Antilag+ und Treiber Fluid Motion Frames (was über alle DX11/12 Spiele gestülpt werden kann) ist RDNA3 exklusiv. Letzteres finde ich etwas unschlau von AMD. Ich würde es auf jeder AMD GPU anbieten. Das würde viel mehr Mindshare erzeugen.

Furchtbar, wie AMD die Kommunikation macht. Ein einfaches Event und sogar wir Nerds kommen total durcheinander. Treiber FMF, FSR3, Antilag+, Hypr-RX. Was kommt wann? Was macht was? Macht FSR3 gleich vernünftige Latenzreduktion?
Wieder ein Beispiel was zeigt, dass AMD Kommunikation nicht so liegt, wie es sein müsste.

[robbitop]

Die DLLs für FSR 2 sind ständig nicht abwärtskompatibel, wenn überhaupt durch ein Spiel gesonderte DLLs genutzt werden.
Diesen Aspekt finde ich furchtbar. Wenn AMD schlau wäre, würden sie es so gestalten, dass DLLs kompatibel und austauschbar wären. Und das dann nutzen, in dem man DLLs kuratiert (per game profile) und über die Radeon software per one-click optimieren kann. (gepaart mit (angemessenen)negativem LoD wenn nötig und CAS - und zwar so spielspezifisch optimiert, dass weder über - noch unterschärft wird). Das hebt potenziell die "out of the box Erfahrung" wahrscheinlich oftmals an.
Das sind immer solche verpassten Chancen, die für mich nicht nachvollziehbar sind.

Ist der native mode nicht das amd pendant zu nvidias DLAA ?

Weil das kann man schon mal brauchen, wenn man Leistung übrig hat. Klar, geht nicht bei jedem Spiel, aber die Option zu haben ist nice.
Ja ist es. Und auch hier ist das Framing von AMD wirklich fraglich. "native mode" - wer soll (außer uns Nerds) damit was anfangen können? Nvidia nennt seinen native mode Deep Learning Anti Aliasing. Und genau das ist es, was FSR 2 dann im native mode macht. Temporales AA. Also Fidelity FX Super AA oder so. FSAA - hehe gleiche Abkürzung wie das gute alte Full Scene Anti-Aliasing.

[Exxtreme]

DLLs abwärtskompatibel halten ist zusätzlicher Aufwand. Der je nach Programmiersprache auch nicht sehr klein ist.

[robbitop]

DLLs abwärtskompatibel halten ist zusätzlicher Aufwand. Der je nach Programmiersprache auch nicht sehr klein ist.
Alles was gut im Leben ist macht Aufwand. Der Vorteil ist potenziell enorm. Intel und Nvidia bekommen es ja auch hin.

[DrFreaK666]

Auf der Folie heißt es Native Anti Aliasing Mode - also NAAM ^^

[Gast]

DLLs abwärtskompatibel halten ist zusätzlicher Aufwand. Der je nach Programmiersprache auch nicht sehr klein ist.

DLL abwärtskompatibel halten ist praktisch 0 Aufwand, das einzige was man sich mit der Abwärtskompatibilität potentiell verbaut ist die zukünftige Flexibilität.

[Exxtreme]

DLL abwärtskompatibel halten ist praktisch 0 Aufwand, das einzige was man sich mit der Abwärtskompatibilität potentiell verbaut ist die zukünftige Flexibilität.

Je nach verwendeter Programmiersprache ist das nicht "praktisch 0 Aufwand". Praktisch 0 Aufwand wäre das nur wenn man alles in C entwickelt. Macht man heutzutage aber eher nicht. Fast immer kommt C++ zum Einsatz, seltener auch noch C#. Und C++ und Bibliotheken ist eine sehr sehr sehr spezielle Sache. Da C++ nichteinmal zu sich selbst kompatibel ist was dieses Thema angeht.


Und dann stellt sich die Frage ob sich der Aufwand für AMD überhaupt lohnt. Denn DLLs austauschen, wieviele Leute tun das weltweit? Vielleicht ein paar tausend?

Edit: eine Garantie hat man bei Intel und Nvidia auch nicht, dass es für immer abwärtskompatibel bleibt. Es zwar war bisher so, kann aber auch Zufall gewesen sein.

[robbitop]

Wie gesagt: man könnte es nutzen, um per Treibertool DLLs zu updaten und (wenn notwendig) mit korrektem CAS und LoD zu kombinieren (per game profile). Das würde sichtbare Vorteile bringen und damit kann man dann wiederum werben (und bzw in reviews besser dazustehen).

[Gast]

Wie gesagt: man könnte es nutzen, um per Treibertool DLLs zu updaten und (wenn notwendig) mit korrektem CAS und LoD zu kombinieren (per game profile).

Das will man als Softwarehersteller aber nicht, das macht es sehr schwierig plötzlich auftauchende Fehler zu finden, weil beim Kunden unerwarteterweise eine andere DLL als in der Entwicklung/Test verwendet wird.

Bei Nvidia gibt es das auch nur als opt-in, und mir ist kein Spiel bekannt dass davon gebrauch macht.

DLL-Austausch ist und bleibt eine Spielerei einiger weniger Enthusiasten.

[robbitop]

Ist ja optional. Man muss den "optimize" Knopf ja nicht drücken. Aktuell kann man das manuell per tool machen. Also die Möglichkeit ist ja bereits da. Warum diese nicht "ownen". Wenn man es vernünftig kuratiert, sollte das Risiko doch minimal sein. Man kann ja eine note anzeigen, dass es eventuell zu Problemen kommen kann, wenn man auf "optimize" klickt und das auch wieder rückgängig machen kann.

Hypr-RX geht ja auch schon ein wenig in diese Richtung.

[Gast]

Ist ja optional. Man muss den "optimize" Knopf ja nicht drücken. Aktuell kann man das manuell per tool machen.

Das nützt dem Softwarehersteller, der sich dann mit Support-Beschwerden auseinandersetzen muss, genauso wenig wie XMP-Profile die vielleicht doch nicht so stabil wie gedacht sind.

[Exxtreme]

Ist ja optional. Man muss den "optimize" Knopf ja nicht drücken. Aktuell kann man das manuell per tool machen. Also die Möglichkeit ist ja bereits da. Warum diese nicht "ownen". Wenn man es vernünftig kuratiert, sollte das Risiko doch minimal sein. Man kann ja eine note anzeigen, dass es eventuell zu Problemen kommen kann, wenn man auf "optimize" klickt und das auch wieder rückgängig machen kann.

Hypr-RX geht ja auch schon ein wenig in diese Richtung.

Es werden trotzdem Kunden beim Support anrufen warum dies und jenes plötzlich nicht geht. ;) Da ist es egal ob man eine große rote blinkende Warnung einbaut oder nicht.

Die Problematik am DLL-Austausch ist, dass der Mechanismus, mit dem DLLs eingebunden werden extrem primitiv ist. Das hat einerseits den Vorteil, dass das sehr schnell und ressourcenschonend ist. Und das will man als Softwareentwickler und auch als Kunde ja. Andererseits funktioniert das Ganze nur solange sich die Semmantik der aufgerufenen Funktionalität nicht ändert. Und das über mehrere Versionen hinweg zu garantieren ist nicht immer einfach. Vor allem dann nicht wenn man ständig diese Funktionalität auch noch verbessert.

Und ja, es ist für AMD-Verhältnisse recht ungewöhnlich, dass sowas bei FSR nicht geht. Denn AMD ist eigentlich die Firma, die Bastler-kompatibel ist, zuindest was Hardware angeht.

[robbitop]

Das nützt dem Softwarehersteller, der sich dann mit Support-Beschwerden auseinandersetzen muss, genauso wenig wie XMP-Profile die vielleicht doch nicht so stabil wie gedacht sind.

Es werden trotzdem Kunden beim Support anrufen warum dies und jenes plötzlich nicht geht. ;) Da ist es egal ob man eine große rote blinkende Warnung einbaut oder nicht.



Ggf. sollte man das mal testen und sehen wie viel Beschwerden da wirklich dabei herumkommen. Sowas sollte besser auf quantitativer Basis entschieden werden (wie fast alles im Leben). :)

Z.B so: Das kann man ja im Lab alles mal validieren und dann mit einer beta Gruppe aus ausgesuchten Usern. Dann hat man auch Zahlen, Daten und Fakten. :)

[Gipsel]

Ggf. sollte man das mal testen und sehen wie viel Beschwerden da wirklich dabei herumkommen. Sowas sollte besser auf quantitativer Basis entschieden werden (wie fast alles im Leben). :)

Z.B so: Das kann man ja im Lab alles mal validieren und dann mit einer beta Gruppe aus ausgesuchten Usern. Dann hat man auch Zahlen, Daten und Fakten. :)Und das willst Du den Spieleentwicklern aufhalsen? Oder willst Du die verpflichten, nur eine DLL mit standardisiertem Interface einzubinden? Denn FSR ist ja OpenSource und wird vom Entwickler üblicherweise auf Quelltextebene eingebaut (und ist dann nicht zwingenderweise [vermutlich sogar eher seltener] in einer separaten DLL isoliert). Wenn man dort was austauschen will, darfst Du Dich mit Function Hooks und Code injection rumschlagen (und mußt dann hoffen, daß der Entwickler nicht noch irgendeinen customized Code gebastelt hat, der nicht 100% mit den sonst üblichen FSR-"Standards" kompatibel ist). Das ist Teil des Fluchs (und Segen) von Open Source.

[Exxtreme]

Ggf. sollte man das mal testen und sehen wie viel Beschwerden da wirklich dabei herumkommen. Sowas sollte besser auf quantitativer Basis entschieden werden (wie fast alles im Leben). :)

Z.B so: Das kann man ja im Lab alles mal validieren und dann mit einer beta Gruppe aus ausgesuchten Usern. Dann hat man auch Zahlen, Daten und Fakten. :)

Ich glaube, man hat es bereits getestet. Zwar nicht direkt mit FSR aber in ähnlichem Kontext. Und es ist auch so, FSR ist Opensource. Man muss also nicht kompatibel zu FSR DLLs des Herstellers sein. Man kann FSR als eigene DLLs kompilieren oder auch gar nicht. Sondern FSR einfach in die Anwendung einkompilieren als wäre es eigener Code.

[robbitop]

Und das willst Du den Spieleentwicklern aufhalsen? Oder willst Du die verpflichten, nur eine DLL mit standardisiertem Interface einzubinden?
DLL so wie bei DLSS/XeSS. Dann braucht der Spieleentwickler nichts mehr zu machen und man kann es per Kurator und Treibertool IHV Seitig optimieren. Auf expliziten Wunsch des Users. Direkt gesehen hat das Studio dann nichts mehr damit zu tun.

Ich glaube, man hat es bereits getestet. Zwar nicht direkt mit FSR aber in ähnlichem Kontext. Und es ist auch so, FSR ist Opensource. Man muss also nicht kompatibel zu FSR DLLs des Herstellers sein. Man kann FSR als eigene DLLs kompilieren oder auch gar nicht. Sondern FSR einfach in die Anwendung einkompilieren als wäre es eigener Code.
Dann ist der default code (bei github) halt so, dass eine DLL beim Kompilieren auftaucht. Alles schön über Schnittstellen machen und Parameter dem Entwickler exponieren. Dann kann er da auch rumspielen hat aber keinen Grund Zeit in Customcode zu investieren. Wer es doch will, den kann man nicht aufhalten.
Ansonsten das ganze in die Optimiziation Guidelines schreiben und ggf. Support vom Befolgen der Guideline abhängig machen.

Kann ich mir nicht vorstellen, dass man das getestet hat. So einfach wie es bei DLSS ist, die DLLs zu tauschen und wie gut das funktioniert, wenn man es selbst kuratiert pro Game. Ich sehe keine Hinweise im Netz, dass das (wenn der jenige der das macht Ahnung und Erfahrung hat -> Kurator) es groß damit Probleme gibt.

[Exxtreme]

Dann ist der default code (bei github) halt so, dass eine DLL beim Kompilieren auftaucht. Alles schön über Schnittstellen machen und Parameter dem Entwickler exponieren. Dann kann er da auch rumspielen hat aber keinen Grund Zeit in Customcode zu investieren. Wer es doch will, den kann man nicht aufhalten.
Ansonsten das ganze in die Optimiziation Guidelines schreiben und ggf. Support vom Befolgen der Guideline abhängig machen.

Kann ich mir nicht vorstellen, dass man das getestet hat. So einfach wie es bei DLSS ist, die DLLs zu tauschen und wie gut das funktioniert, wenn man es selbst kuratiert pro Game. Ich sehe keine Hinweise im Netz, dass das (wenn der jenige der das macht Ahnung und Erfahrung hat -> Kurator) es groß damit Probleme gibt.

Ich glaube, du hast eine bissl falsche Vorstellung wie das funktioniert mit DLLs und Sourcecode. ;)

Es ist so: solange FSR komplett Opensource ist, kann AMD das auch nicht erzwingen wie FSR in die Anwendung eingebunden wird. Das entscheidet der Spielehersteller. Er kann die Vanilla-DLLs nehmen, kann aber auch eigene, angepasste DLLs selbst erzeugen. Oder er kopiert den Sourcecode und bindet ihn in die Anwendung so ein als wäre es eigener Sourcecode. Die MIT Lizenz erlaubt das. Also machen die Spielehersteller das, was für sie am bequemsten ist.

Ganz anders sieht es bei DLSS und Xess aus. Da gibt es nur diese DLLs. Die Spieleentwickler haben hier keine andere Wahl als diese zu nutzen. Hier heisst es "Friss oder stirb". Also entweder vernagelte DLLs nutzen oder diese Upscaler gar nicht erst einbauen. Diese DLLs sind quasi eine Blackbox mit einigen Anschlüssen dran.

[robbitop]

Die meisten scheinen aber den Weg des geringsten Widerstands zu wählen. So wenig Zeit wie für die Implementierung (Mods erreichen oft bessere Resultate als native Implementierungen!) investiert wird, ist das für die Studios offenbar nicht wichtig.
Wenn es default (wäre dann DLL Erzeugung) passt (und gut begründet und dokumentiert ist und man bei AMD Einfluss beim Implementieren nehmen kann), werden die meisten wahrscheinlich nichts dran ändern.

[Tesseract]

kann AMD das auch nicht erzwingen

erzwingen nicht, aber definitiv über mehrere hebel steuern: developer guides, nutzung von logos, vorkompilierte/signierte DLLs anbieten usw.

ist ja nicht so als würde das einen großen unterschied für den developer machen wenn es eine best-practice-vorgabe gibt.

[Achill]

Imho macht man es sich ggf viel zu einfach ...

Bei DLSS darf man nicht vergessen, dass dies nur mit NV GPUs funktioniert. Dies bedeutet:
- die DLSS DLL greift auf die NvAPI zurück (https://github.com/jp7677/dxvk-nvapi/blob/master/README.md)
- die DLSS DLL kann auf den NV Treiber zurück greifen (über die NvAPI)
- welcher Anteil von DLSS in der DLL und was im anderen NV Libs/Treiber liegt ist unklar
=> Die API von der DLSS DLL muss damit nur stabil für die Daten, welche direkt vom Spiel übermittelt werden, stabil sein. Andere benötigte Daten können Aufgrund der direkten Abhängigkeit zu NV GPU & Treiber von dort bezogen werden. Wäre dies der Fall, so würden wir dies nicht beobachten können.

FSR2.x funktioniert mit GPUs von AMD/Intel/NV
- Die API einer der Major Versionen (2.0, 2.1, 2.2, ...) muss die Schnittstelle für benötigten/optionalen Features bereit stellen
- FSR 2.x kann keine Annahme über die GPU / den Treiber treffen, muss also die komplette Implementierung beinhalten
- Mit jeder Version von FSR 2 sind neue Features hinzu gekommen (könnt euch die Changes ansehen):
-- 2.0.x vs 2.1.x > https://github.com/GPUOpen-Effects/FidelityFX-FSR2/compare/v2.0.1...v2.1.2
-- 2.1.x vs 2.2.x > https://github.com/GPUOpen-Effects/FidelityFX-FSR2/compare/v2.1.2...v2.2.1
=> Würde es eine DLL von FSR 2.2 geben, die auch FSR 2.0 und FSR 2.1 als Subsets unterstützt, so würde es ggf trotzdem keine Verbesserung geben, da die neuen Features wie Reactive-Mask m.W. direkten Input vom Spiel/Engine benötigen. Ein Austausch der DLL würde mit gewisser Wahrscheinlichkeit nichts groß ändern ...

Disclaimer: Ist natürlich Spec - aber zumindest bin ich SWE und kann aus dem Context von SW-Systemen hier schreiben. Kenne aber DLSS/FSR nicht im Detail ...

[aufkrawall]

Ein Austausch der DLL würde mit gewisser Wahrscheinlichkeit nichts groß ändern ...

Das rächt sich dann leider mehrfach. In Saints Row gibts etwa das gleiche Problem wie in Call of Duty: Selbst weitestgehend unverdeckte Alphatests von Bäumen jittern abartig vs. TAA. Das Spiel bietet dann noch selbst einen "UQ"-Modus an, was offenbar 100% Auflösung ist, da es deutlich langsamer als TAA läuft (>20% in 4k auf einer 4090). Und trotzdem ändert sich nichts an dem Jittering-Problem, flimmert ohne bewegte Kamera stärker als gar kein AA. :freak:
Irgendwas in der Grundkonzeption ist mächtig im Hintern, wenn es über mehrere Spiele solche Probleme gibt, mit DLSS/XeSS hingegen gar nicht.

[robbitop]

Vieles davon (Kommunikation mit der Engine) gilt aber auch für DLSS. Eine andere DLL kann ohne neuen Treiber und neuen Patch riesen Unterschiede machen (optisch). Und sogar Zeug fixen wo man annahm, dass motion vectors fehlten (zB die Particles, Transparenzen etc).

Gleiches übrigens per MOD wo neuere FSR Versionen in Spiele gemoddet wurden. Ich glaube du bist eher zu pessimistisch

[aufkrawall]

Das ist allerdings auch nicht nur positiv, Nvidia baut ziemlichen Mist mit diesen Schrott-Presets. Das Video sagt im Grunde fast alles (andere Upsampler auch dabei):
uMkOUBJd3fU

Zum Glück kann man das Preset jetzt global per Inspector erzwingen. Call of Doofy müsste nur mal die DLL updaten, hat sogar BF2042 hinbekommen :freak: . Hoffentlich im Herbst...

[Deisi]

Die meisten scheinen aber den Weg des geringsten Widerstands zu wählen. So wenig Zeit wie für die Implementierung (Mods erreichen oft bessere Resultate als native Implementierungen!) investiert wird, ist das für die Studios offenbar nicht wichtig.
Wenn es default (wäre dann DLL Erzeugung) passt (und gut begründet und dokumentiert ist und man bei AMD Einfluss beim Implementieren nehmen kann), werden die meisten wahrscheinlich nichts dran ändern.

Genau das. In der aktuellen Praxis macht es keinen Unterschied ob FSR Open Source ist oder nicht. Die Library bzw das UE Plugin wird hinzugefügt und fertig.

[Ex3cut3r]

Das ist allerdings auch nicht nur positiv, Nvidia baut ziemlichen Mist mit diesen Schrott-Presets. Das Video sagt im Grunde fast alles (andere Upsampler auch dabei):
https://youtu.be/uMkOUBJd3fU

Zum Glück kann man das Preset jetzt global per Inspector erzwingen. Call of Doofy müsste nur mal die DLL updaten, hat sogar BF2042 hinbekommen :freak: . Hoffentlich im Herbst...

Gutes Video. DLSS ist ziemlich überlegen. :freak:

[ChaosTM]

https://www.youtube.com/watch?v=1WiIX2aUq9E&t=37s

FSR3 ab ca 12 Minuten. Die Implementation von FG ist sehr interessant und kommt in 3 verschiedenen "Ausführungen". Keine dedizierte HW (Optical Flow Analyzer) wie bei NV nötig sondern via Async Compute und dadurch universell nutzbar.

Add.:was DLAA ähnliches kommt auch.

Den Jungs von DF hats gefallen.

[crux2005]

Gutes Video. DLSS ist ziemlich überlegen. :freak:

Survivor unterstützt gar kein DLSS. :freak:

[BlacKi]

https://www.youtube.com/watch?v=1WiIX2aUq9E&t=37s

FSR3 ab ca 12 Minuten. Die Implementation von FG ist sehr interessant und kommt in 3 verschiedenen "Ausführungen". Keine dedizierte HW (Optical Flow Analyzer) wie bei NV nötig sondern via Async Compute und dadurch universell nutzbar.

Add.:was DLAA ähnliches kommt auch.

Den Jungs von DF hats gefallen.


bei spielen die async großzügig nutzen, wird async performance für FMF klauen.

[aufkrawall]

Survivor unterstützt gar kein DLSS. :freak:
Ist aber zweifelsfrei im Video zu sehen.

[GerryB]

bei spielen die async großzügig nutzen, wird async performance für FMF klauen.

Das wird auf jeden Fall interessant, ob RDNA3 dann mehr profitiert als RDNA2.

[Tesseract]

bei spielen die async großzügig nutzen, wird async performance für FMF klauen.

generell in spielen mit hoher auslastung. async compute ist im prinzip wie hyperthreading auf CPUs, wenn die graphics queue ressourcen die FMF ebenfalls braucht bereits gut auslastet dann wird der rest einfach langsamer wenn FMF läuft (ich nehme an FMF hat höhere schedulingpriorität als fast alles andere).

[rumpeLson]

Gutes Video. DLSS ist ziemlich überlegen. :freak:
Gerade die Stelle hier in dem Video fand ich sehr eindrucksvoll:
https://youtu.be/uMkOUBJd3fU?si=QOk18ANNI-h15mQK&t=308

DLSS ist aktuell nicht grundlos die Referenz und XESS scheint ebenfalls auf einem vielversprechenden Weg zu sein.

[Hammer des Thor]

Das Monty hat heute gesagt das FSR2 300% schneller sein soll als ohne FSR. Frage: Werden da die Techniken der Auflösungserhöhung und Zwischenframes kombiniert?

[aufkrawall]

DLSS ist aktuell nicht grundlos die Referenz und XESS scheint ebenfalls auf einem vielversprechenden Weg zu sein.
FSR 2 ist noch inkompatibler mit Regen als DLSS mit Vögeln. :D

[The_Invisible]

Das Monty hat heute gesagt das FSR2 300% schneller sein soll als ohne FSR. Frage: Werden da die Techniken der Auflösungserhöhung und Zwischenframes kombiniert?

Jap Perf Upsampling + Frame Generation, da scheinen sich nvidia/AMD ja mal einig...

[Achill]

bei spielen die async großzügig nutzen, wird async performance für FMF klauen.

generell in spielen mit hoher auslastung. async compute ist im prinzip wie hyperthreading auf CPUs, wenn die graphics queue ressourcen die FMF ebenfalls braucht bereits gut auslastet dann wird der rest einfach langsamer wenn FMF läuft (ich nehme an FMF hat höhere schedulingpriorität als fast alles andere).

K.a. warum es bei AMD ein Problem/Nachteil sein soll und bei NV wieder mal nicht. Erstmal gibt es nur von NV (Marketing / Produkt Managemant) die Aussage, dass NV Optical Flow eine dedizierte HW-Unit ist und darüber hinaus limitiert bei einer GPU unter Auslastung nicht unbedingt deren Compute-Leistung sondern ggf. auch die Leistungsaufnahme oder termische Entwicklung. Das kann auch bei einer 4000er dann die Leistung reduzieren ...

Aber sowohl bei NVs und AMDs gilt doch, wenn das berechneten Zwischenframes "günstiger" als ein voll berechnetet Frame ist, dann bleibt untern Strick mehr FPS übrig. Es gibt eine Grenze, wird diese erreicht bringt der Einsatz von NVs oder AMDs Lösung einfach nichts in dem Spiel/Auflösung.

---
Off-topic: Was trägt das DLSS Vergleichs-Video jetzt hier zur Diskussion zu FSR 3 bei?

[aufkrawall]

Wieso soll das hier nicht diskutiert werden?

[Tesseract]

ich habe mit keinem wort nvidia erwähnt. :rolleyes:

[DrFreaK666]

Weil das nichts mit FSR zu tun hat? Es ist schon spät. Du solltest schlafen gehen.

Im DLSS-Thread kommt auch niemand auf die Idee verschiedene FSR-Versionen miteinander zu vergleichen

[aufkrawall]

In welchem Thread soll man der Gnade einiger Member nach denn vergleichen dürfen? Was ein BS.

[DrFreaK666]

Mein Fehler. Geht nicht nur um DLSS, wie es das Thumbnail suggeriert

[robbitop]

Den Jungs von DF hats gefallen.
Und das ist schonmal ein gutes Zeichen.

1.) sind sie schon ziemlich penibel bei BQ
2.) gelten sie seit einer Weile als NV biased (was nicht meiner Meinung über sie entspricht)

Mal sehen wie gut es in der Praxis ist. Wenn sich der erste Eindruck festigt, ist das schonmal interessant, dass es doch ohne Fixed Function Hardware zu gehen scheint. (und man die Vorgängergenerationen, die diese ein wenig langsamer hatten, unbedingt aussperren muss)

Das Monty hat heute gesagt
:D Ach du lieber Himmel - warum schaust du denn diesen brain dead Typen? Man sagt ja immer "davon kannst du nicht dümmer werden, wenn du XYZ schaust". Davon schon. :D

[Gast]

1.) sind sie schon ziemlich penibel bei BQ
2.) gelten sie seit einer Weile als NV biased (was nicht meiner Meinung über sie entspricht)


Aber sie sind komplett unempfindlich was Latenz angeht, die empfehlen allen ernstes mit VSYNC zu spielen oder gar den Framelimiter vom Steamdeck, der erzeugt schlimmere Latenz FG.

Was Bildqualität und auch Performance angeht sind sie top.
Für Latenzeinschätzungen leider unbrauchbar.

[Platos]

Das lustige ist ja, dass Konsolenspieler seit Jahren (wen nicht schon fast Jahrzenten) mittels Frame Interpolation spielen, da am TV das meist standartmässig eingestellt ist.

In diesem Fall wird die Treiber-Version (AFMF) in etwa ebenbürdig sein zum TV, nehme ich mal an. Lustig also, dass ein so altes Feature erst jetzt kommt im PC Bereich. Bin ja gespannt, ob es besser wird, wie am TV. Wenn nicht, wäre das schon lächerlich. Eig. finde ich es sowieso lächerlich, dass es das am PC de facto nicht gibt von der Monitorseite her.

Bin mir nicht sicher, ob das bei den Konsolen dann genutzt wird. Wenn man dann am TV nochmals frame interpolation nutzt, sind dann ja nur noch 1/4 echte Bilder übrig :D

Am PC wird es auf jeden Fall von vielen TVs nicht genutzt. Sobald man nen PC anschliesst, kann man bei vielen TVs keine Frame Interpolation mehr nutzen.

Gibt aber auch Modelle, bei denen das möglich ist.

[ChaosTM]

Frame Interpolation am TV ist bei Spielen nicht besonders toll. Da bist du selbst mit den flottesten Prozessoren schnell mal über 100ms. Bei manchen Spielen mag das ja ok sein, aber allgemein nicht so sehr.

Bei Filmen oder Serie ist das vernachlässigbar, solange der Ton Syncron bleibt.

[Tesseract]

vor allem ist es in den für konsolen bestimmten gaming modes off.

[Troyan]

Das lustige ist ja, dass Konsolenspieler seit Jahren (wen nicht schon fast Jahrzenten) mittels Frame Interpolation spielen, da am TV das meist standartmässig eingestellt ist.

In diesem Fall wird die Treiber-Version (AFMF) in etwa ebenbürdig sein zum TV, nehme ich mal an. Lustig also, dass ein so altes Feature erst jetzt kommt im PC Bereich. Bin ja gespannt, ob es besser wird, wie am TV. Wenn nicht, wäre das schon lächerlich. Eig. finde ich es sowieso lächerlich, dass es das am PC de facto nicht gibt von der Monitorseite her.

Bin mir nicht sicher, ob das bei den Konsolen dann genutzt wird. Wenn man dann am TV nochmals frame interpolation nutzt, sind dann ja nur noch 1/4 echte Bilder übrig :D

Am PC wird es auf jeden Fall von vielen TVs nicht genutzt. Sobald man nen PC anschliesst, kann man bei vielen TVs keine Frame Interpolation mehr nutzen.

Gibt aber auch Modelle, bei denen das möglich ist.

Naja, die Latenz erhöht sich bei Samsung um das 3x liegt z.B. bei aktuellen Bildschirmen dann bei 30ms statt 11ms: https://www.rtings.com/tv/reviews/samsung/q70c-q70-q70cd-qled#test_14

[Cubitus]

Es gibt erhebliche Unterschiede, zwischen FG und der Interpolation der normalen TVs mit Seifenoper Effekt.

Kann euch einen guten Artikel ans Herz legen :)

https://blurbusters.com/frame-generation-essentials-interpolation-extrapolation-and-reprojection/

[Troyan]

Die Treiberversion macht aber das selbe wie Samsung: Zwei Frames werden abgefangen und ein drittes interpoliert.

[Cubitus]

So einfach ist es nicht, so wie ich es verstanden habe, werden für die Bilderzeugung durch Interpolation bei Nvidias-FG zusätzlich Tiefeninformationen verwendet, die eben je nach Positionsvektoren der Engine oder des Z-Buffers
vom Optical Flow Accelerator verarbeitet werden.

Die Bewegungsvektoren und Z-Buffer können effektiv für die KI-gestützte Schätzung von bewegten Elementen in der Umgebung verwendet werden. Diese Technik kann den Zustand des Bildes bis zum geschätzten Zeitpunkt der Anzeige des endgültigen Bildes extrapolieren und dann die Information über die Kameraposition verwenden, um das extrapolierte Bild neu zu projizieren.

Diese Technik ist also im Grunde mehr als nur die Erzeugung von "abgefangenen" Doppelbildern.

[Exxtreme]

Bei Nvidia ja, bei AMD womöglich nein. AMD bringt auch eine Treiberversion von Fsr3. Die braucht zwar keine Spieleunterstützung, wird aber womöglich so ähnlich funktionieren wie das Fernsehen-FG.

[Gast]

Naja, die Latenz erhöht sich bei Samsung um das 3x liegt z.B. bei aktuellen Bildschirmen dann bei 30ms statt 11ms: https://www.rtings.com/tv/reviews/samsung/q70c-q70-q70cd-qled#test_14

Bei Samsung gibt es 2 Interpolationsverfahren, 1x das "normale" in hoher Qualität und hoher Latenz was beim Fernsehen zum Einsatz kommt und ein anderes Latenzoptimiertes für den Gamemode geringerer Qualität.
Die 30ms stammen garantiert von letzterem, die "normale" Interpolation ist mit Sicherheit eher auf dem Level der "outside gamemode" Messungen.

[Ex3cut3r]

Survivor unterstützt gar kein DLSS. :freak:

Mit Mod schon, die habe ich übrigens auch genutzt. :tongue:

[robbitop]

Aber sie sind komplett unempfindlich was Latenz angeht, die empfehlen allen ernstes mit VSYNC zu spielen oder gar den Framelimiter vom Steamdeck, der erzeugt schlimmere Latenz FG.

Was Bildqualität und auch Performance angeht sind sie top.
Für Latenzeinschätzungen leider unbrauchbar.
Naja Latenz kann man (dann zum review) messen. Einschätzen konnten sie diese glaube ich aus 2 Gründen nicht. Die Demo lief mit einem Gamecontroller (AFAIK) und sie wurde nicht durch die Zuschauer gesteuert.

In einer Welt ohne VRR Displays in der man ohne Tearing leben will, ist VSync (mit Fastsync) - insbesondere bei nicht voller Renderlast wahrscheinlich nicht das schlechteste oder? Weil die Renderqueue etwas sinkt.

Ich bin selbst ein Steamdeck Nutzer und empfinde den Framelimiter als zu latenzerzeugend. Wenn ich nur die Bildfrequenz senke (und VSync anlasse) geht es einigermaßen. Leider hat das Steamdeck ja kein VRR Display.

Das lustige ist ja, dass Konsolenspieler seit Jahren (wen nicht schon fast Jahrzenten) mittels Frame Interpolation spielen, da am TV das meist standartmässig eingestellt ist.

In diesem Fall wird die Treiber-Version (AFMF) in etwa ebenbürdig sein zum TV, nehme ich mal an. Lustig also, dass ein so altes Feature erst jetzt kommt im PC Bereich. Bin ja gespannt, ob es besser wird, wie am TV. Wenn nicht, wäre das schon lächerlich. Eig. finde ich es sowieso lächerlich, dass es das am PC de facto nicht gibt von der Monitorseite her.

Bin mir nicht sicher, ob das bei den Konsolen dann genutzt wird. Wenn man dann am TV nochmals frame interpolation nutzt, sind dann ja nur noch 1/4 echte Bilder übrig :D

Am PC wird es auf jeden Fall von vielen TVs nicht genutzt. Sobald man nen PC anschliesst, kann man bei vielen TVs keine Frame Interpolation mehr nutzen.

Gibt aber auch Modelle, bei denen das möglich ist.

Meine Erwartung wäre, dass FMF besser bei der Latenz ist als ein TV und optisch weniger Artefakte produziert (weil das Processing sicherlich besser ist als auf einem schnell veralteten low cost TV SoC).

Bei Nvidia ja, bei AMD womöglich nein. AMD bringt auch eine Treiberversion von Fsr3. Die braucht zwar keine Spieleunterstützung, wird aber womöglich so ähnlich funktionieren wie das Fernsehen-FG.
FSR3 soll laut DF ziemlich analog zu DLSS 3 FG laufen. Man hat motion vectors und optical flow. Nur dass bei FSR3 alles über compute läuft.
FMF (Treiber FSR3) hingegen nutzt nur optical flow, weil es ja ohne Informationen von der Spieleengine funktionieren muss.

[Ex3cut3r]

Wird das nicht je nach GPU ziemlich unterschiedliche Ergebnisse (FPS) liefern? Einige ältere GPUs pfeifen ja so schon aus dem letzten Loch. Jetzt soll FSR 3.0 auch noch über Compute mit Async laufen.....

Ich persönlich hoffe ja immer noch auf die Minimal Chance das FG zumindest für Ampere freigeschaltet wird. Ich plane zwar Ende des Jahres sowieso den Kauf einer 4090, wäre aber trotzdem eine tolle Sache.

[GerryB]

Wird das nicht je nach GPU ziemlich unterschiedliche Ergebnisse (FPS) liefern? Einige ältere GPUs pfeifen ja so schon aus dem letzten Loch. Jetzt soll FSR 3.0 auch noch über Compute mit Async laufen.....

Genau DAS machts ja interessant. Du kannst jetzt inGame-ASYNC mal probehalber abschalten, um zu schauen wieviel FMF dann runder läuft.

[TheAntitheist]

K.a. warum es bei AMD ein Problem/Nachteil sein soll und bei NV wieder mal nicht. Erstmal gibt es nur von NV (Marketing / Produkt Managemant) die Aussage, dass NV Optical Flow eine dedizierte HW-Unit ist

Das ist gelogen und das weißt du. Es wurde danach doch herausgefunden das dieser Chip auch schon bei Turing und Ampere vorhanden ist, nur eben eine langsamere Version... Desweiteren würde AMD sofort eine Lüge aufgreifen und 100x drauf hinweisen.

Nvidia hat sich nicht lustig gemacht über den Kühlerfail der oft vorkam, AMD hingegen über viel unwichtigere Sachen, die auch noch user error waren.

[Ex3cut3r]

Genau DAS machts ja interessant. Du kannst jetzt inGame-ASYNC mal probehalber abschalten, um zu schauen wieviel FMF dann runder läuft.
Die Option Async abzuschalten, bietet mittlerweile doch kaum ein Spiel noch an, oder meinst du mit FSR 3.0 wird diese Option wieder vermehrt im Spiele Menü auftauchen?

[Gast]

Naja Latenz kann man (dann zum review) messen. Einschätzen konnten sie diese glaube ich aus 2 Gründen nicht. Die Demo lief mit einem Gamecontroller (AFAIK) und sie wurde nicht durch die Zuschauer gesteuert.



Ich meine das generell, nicht auf die Demo bezogen. Dass man bei einer Demo, bei welcher man nur Zuschauer ist nichts dazu sagen kann ist klar, außer sie wäre dermaßen schlimm, dass man schon Audio-Desyncs bemerkt.
Wobei wir hier generell sehr viel gewohnt sind, Audio in Spielen hat fast immer eine Latenz im 3-Stelligen ms Bereich, was deutlich bemerkbar ist wenn man darauf achtet, nur haben wir uns bereits daran gewöhnt.

Im Gegensatz zu deren Bildanalysen die Großartig sind würde ich allerdings auch nichts auf deren Latenzeinschätzung geben selbst wenn sie selbst spielen dürfen.

Messungen sind freilich gut, aber nur innerhalb des selben Messaufbaus wirklich vergleichbar, nicht alle Reviewer messen Latenz auf die selbe Art, weshalb es in der Regel auch größere Unterschiede gibt.


In einer Welt ohne VRR Displays in der man ohne Tearing leben will, ist VSync (mit Fastsync) - insbesondere bei nicht voller Renderlast wahrscheinlich nicht das schlechteste oder? Weil die Renderqueue etwas sinkt.


Tearing ist hier das kleinere Übel.


Ich bin selbst ein Steamdeck Nutzer und empfinde den Framelimiter als zu latenzerzeugend. Wenn ich nur die Bildfrequenz senke (und VSync anlasse) geht es einigermaßen. Leider hat das Steamdeck ja kein VRR Display.


Ja, deshalb bin ich auch so froh mittlerweile auf das ROG Ally upgegraded zu haben.
Der Unterschied zwischen 60Hz ohne VRR und 120Hz mit VRR ist einfach gigantisch.
Was alle nicht kapieren, wenn sie sagen das 120Hz Display ist umsonst, weil man eh keine so hohen Frameraten erreicht, ist dass selbst 120Hz ohne VRR schon ein riesiger Fortschritt wären, weil man mit 120Hz Tearing so viel weniger wahrnimmt als bei 60Hz.



Meine Erwartung wäre, dass FMF besser bei der Latenz ist als ein TV und optisch weniger Artefakte produziert (weil das Processing sicherlich besser ist als auf einem schnell veralteten low cost TV SoC).


Ich würde nicht darauf wetten, dass ein general purpose shader unbedingt so viel besser ist als dedizierte Hardware die extra für den Zweck gebaut wurde.

Die GPU hat freilich den Vorteil Motion-Vectoren von der Engine zu bekommen sowie auch Zugriff auf den Z-Buffer zu haben, dessen Informationen auch helfen können die Interpolation zu verbessern, während TVs die Motion-Vectoren sich erst aus den Differenzen aufeinanderfolgender Bilder selbst errechnen müssen.
Wobei dieser Vorteil beim Treiberansatz zumindest teilweise wegfällt, dann gibt es auch keine Motion-Vectoren von der Engine, wobei zumindest der Z-Buffer-Zugriff noch möglich sein sollte, und umgekehrt der Vorteil vielleicht gar nicht so groß ist wie man denkt.

Dass der TV keine Motion-Vectoren hat stimmt nämlich nur wenn man ihn als reines Display verwendet. Im komprimierten Video-Datenstrom sind nämlich durchaus Motion-Vectoren enthalten, und wenn der TV nicht nur als Anzeige- sondern auch als Wiedergabegerät fungiert, kann er diese auch für die Interpolation verwenden.

[GerryB]

Die Option Async abzuschalten, bietet mittlerweile doch kaum ein Spiel noch an, oder meinst du mit FSR 3.0 wird diese Option wieder vermehrt im Spiele Menü auftauchen?

Das wäre net schlecht, wenn man die Wahl hätte.
vllt.
Ist es derzeit eher so, das wenige Games AC nutzen(x), und dann meistens AC im GrafikOptionsMenü drin ist.


(x) damits auf alter Hardware läuft
gehe mal davon aus, das man die Games eher auf Pascal ohne AC optimiert als EinstiegsPreset
Gears5+TS sind ja nur künstlich passend gemachte Sonderfälle

[robbitop]

Die Option Async abzuschalten, bietet mittlerweile doch kaum ein Spiel noch an, oder meinst du mit FSR 3.0 wird diese Option wieder vermehrt im Spiele Menü auftauchen?

Das wird, wie DLSS3, schon eingeschränkt sein. Nvidia und AMD empfehlen jeweils 60 fps (intern). Die muss die GPU für das jeweilige Spiel schon schaffen, damit es überhaupt Sinn macht. Das schließt dann schon einige Kombinationen aus dem sinnvollen Rahmen aus.
Ich denke mal GPUs, die sinnvoll Async Compute können (Nvidia ab Turing kann das richtig gut und AMD ab Vega IIRC) und genug Leistung für 60 fps in FSR3 Spielen haben.
Ich schätze mal dann wird man also bei RDNA1 und Turing (und vermutlich Alchemist bei Intel) als sinnvolle Mindestgeneration vorfinden - je nach Auflösung.
Ich hoffe, dass es meiner 3080 nochmal einen zweiten Frühling schenkt (so wie es tatsächlich FSR2 für meine 1080ti damals schon tat - klar war DLSS besser aber FSR2 war besser als gar nichts ^^).

[Gast]

Die Option Async abzuschalten, bietet mittlerweile doch kaum ein Spiel noch an, oder meinst du mit FSR 3.0 wird diese Option wieder vermehrt im Spiele Menü auftauchen?

Alles was der ShaderCore macht ist Compute, dem ist vollkommen ob das was er computed Pixel sind oder was anderes, genau genommen hat er nicht mal eine Ahnung was er computed.

Die Grafikpipeline hat allerdings aufgrund der verwendeten APIs gewisse Constraints in welcher Reihenfolge Berechnungen durchzuführen sind. Wenn also ein Grafikshader nicht starten kann, weil die Voraussetzungen dafür noch nicht gegeben sind und auch kein anderer Grafikshader aktuell in flight ist, welcher ausführbar ist stallt die Pipeline.
Alles was Async Compute macht ist bestimmten Shader ein Tag zu verpassen, dass sagt mir ist vollkommen egal wann du den Shader ausführst.
Und diese Shader können dann zwischengeschoben werden, wenn die Grafikpipeline stallt.

Idealerweise will man aber keine stallende Grafikpipeline, und je besser die Grafikpipeline die Hardware bereits auslastet umso weniger freie Zeit ist vorhanden in denen man Compute-Berechnungen verstecken könnte.
Der Hauptgrund warum AMD den Ruf hat stark von Async-Compute zu profitieren, und Nvidia weniger bis gar nicht ist dass (vor allem noch vor RDNA-Zeiten) bei Nvidia die Grafikpipeline einfach viel besser ausgelastet ist.

[robbitop]

Tearing ist hier das kleinere Übel.
Ich mag Tearing nicht und kann es seit es VRR gibt nicht mehr akzeptieren. :)
Du würdest wenn du ein Steam Deck hättest einfach immer 60 Hz laufen lassen und VSync ausschalten? Bei einem 120 Hz Display ist das viel erträglicher als auf einem 60 Hz Display.



Ja, deshalb bin ich auch so froh mittlerweile auf das ROG Ally upgegraded zu haben.
Der Unterschied zwischen 60Hz ohne VRR und 120Hz mit VRR ist einfach gigantisch.
Was alle nicht kapieren, wenn sie sagen das 120Hz Display ist umsonst, weil man eh keine so hohen Frameraten erreicht, ist dass selbst 120Hz ohne VRR schon ein riesiger Fortschritt wären, weil man mit 120Hz Tearing so viel weniger wahrnimmt als bei 60Hz.
Das glaube ich sofort! Wer schonmal ein 120Hz+ VRR Display besessen hat, weiß sofort was du meinst. Nie wieder zurück.


Offtopic:
Das Ally ist ein gutes Gerät - aber ich fand das Steam Deck aus folgenden (für mich persönlich wichtigeren) Gründen besser:

1.) das Steamdeck hat touchpads womit man auch Strategie und Aufbau spielen kann (Civilization oder XCom gehen wunderbar)
2.)das Steamdeck hat kein Windows braucht also kein Gefummel (sofern man alle Spiel in Steam hat -> für mich ein großer Incentive alles nur noch auf Steam zu kaufen -> jaja ich weiß Opfer... :-D aber die Erfahrung ist einfach super.
3.) Hohe Akkulaufzeiten mit lowTDP. Ich hole aus vielen Spielen mit Optimierung 3-4h Akkulaufzeit raus. Dank SteamOS scheint der SoC wenn er nicht ausgelastet ist sowohl bei der GPU als auch bei der CPU in den niedrigst möglichen Betriebspunkt zu gehen völlig ohne AutoTDP. Und gerade in den niedrigen TDP Regionen ist die Performance bis dato ungeschlagen (der Vorteil des Custom SoCs)
4.) Der Preis. Ich hab mein Steamdeck für 400 EUR gekauft und für 30 EUR eine SD Karte dazu. Rennt. Keine Probleme.

@Konzept mobile Gaming
Ich bin hooked. Ich wechsle zwischen PC und Steamdeck hin und her je nach Situation und kann auf einmal deutlich mehr spielen (weil man mehr Gelegenheiten nutzen kann). Einfach schnell mal aus dem Standby direkt weiter zocken oder in den Standby innerhalb einer Sekunde ist das Ding aus und man kann wieder das normale Leben fortsetzen (kannst du schnell auf die Kids aufpassen? Klick. Jap kein Problem).

Wenn es ein Steamdeck 2 geben wird, bin ich ab Anfang an dabei diesmal. Ich gehe davon aus, dass es auch VRR geben wird und einen noch besseren SoC in Bezug auf Perf/W bis zu 15W. Mehr als 15W sind für mich zumindest eh sinnlos weil die Akkulaufzeit dann für mich zu kurz ist. Alle 2h ist sowas von 1990er. Eher will ich noch mehr Leistung in 5-8W haben um mal auf zeitgemäße Akkulaufzeiten zu kommen. ^^




Ich würde nicht darauf wetten, dass ein general purpose shader unbedingt so viel besser ist als dedizierte Hardware die extra für den Zweck gebaut wurde.

Die GPU hat freilich den Vorteil Motion-Vectoren von der Engine zu bekommen sowie auch Zugriff auf den Z-Buffer zu haben, dessen Informationen auch helfen können die Interpolation zu verbessern, während TVs die Motion-Vectoren sich erst aus den Differenzen aufeinanderfolgender Bilder selbst errechnen müssen.
Wobei dieser Vorteil beim Treiberansatz zumindest teilweise wegfällt, dann gibt es auch keine Motion-Vectoren von der Engine, wobei zumindest der Z-Buffer-Zugriff noch möglich sein sollte, und umgekehrt der Vorteil vielleicht gar nicht so groß ist wie man denkt.

Dass der TV keine Motion-Vectoren hat stimmt nämlich nur wenn man ihn als reines Display verwendet. Im komprimierten Video-Datenstrom sind nämlich durchaus Motion-Vectoren enthalten, und wenn der TV nicht nur als Anzeige- sondern auch als Wiedergabegerät fungiert, kann er diese auch für die Interpolation verwenden.
Grundsätzlich gebe ich dir Recht. Aber ich vermute, die TV Hersteller haben (noch?) gar nicht den Fokus auf low latency frame interpolation für das Gaming.
Die konzentrieren sich darauf, dass es bei Filmmaterial gut funktioniert (Latenz egal). Auch das Tuning ist nicht auf Spiele optimiert.
Und die aller döllsten SoCs stecken da ja nicht gerade drin. Wenn jetzt ein A16 oder M2 drin stecken würde: okay. Aber die Dinger in den TVs sind eher vergleichbar mit low cost phones IIRC.

[robbitop]

Der Hauptgrund warum AMD den Ruf hat stark von Async-Compute zu profitieren, und Nvidia weniger bis gar nicht ist dass (vor allem noch vor RDNA-Zeiten) bei Nvidia die Grafikpipeline einfach viel besser ausgelastet ist.
Das kommt IMO auf die Generation an. Turing holte bisher am meisten pro TFLOP heraus. Ampere und Ada haben mehr Ausführungsresourcen pro Kontrolllogik und holen verglichen zu Turing pro FLOP anscheinend weniger heraus.
RDNA1 holt am meisten pro FLOP heraus, RDNA2 hatte ganz leichte Regression und RDNA3 ist wahrscheinlich ähnlich schlimm wie GCN.

[GerryB]

müsste net RDNA3 durch die FP32-verdopplung brachliegende Reserven haben
glaube net, das OREO bereits so 100%ig in allen Games funzt

[Gast]

Ich mag Tearing nicht und kann es seit es VRR gibt nicht mehr akzeptieren. :)
Du würdest wenn du ein Steam Deck hättest einfach immer 60 Hz laufen lassen und VSync ausschalten?


So mache ich es auf dem Steamdeck, ingame Framelimiter auf 60, wenn möglich Settings finden die das auch einigermaßen erreichen können und VSYNC aus.


Bei einem 120 Hz Display ist das viel erträglicher als auf einem 60 Hz Display.


So ist es, deshalb hab ich auch den großen Jubel als das Steamdeck per Update die komplett freie Konfiguration der Refreshrate bekommen hat nicht verstanden.

40Hz statt 60Hz macht nur mit VSYNC noch mehr LAG, ohne VSYNC Tearing noch sichtbarer und mit VSYNC falls man die FPS mal doch nicht halten kann das Stuttering schlimmer.
Da nehm ich lieber 40FPS ohne SYNC auf 60Hz.


Das glaube ich sofort! Wer schonmal ein 120Hz+ VRR Display besessen hat, weiß sofort was du meinst. Nie wieder zurück.


Ja, hat mich damals vor 2 Jahrzehnten oder so beim Umstieg von CRT auf LCD auch gewundert warum tearing so viel stärker sichtbar war, bis ich verstanden habe dass die Refreshrate (damals bei CRT so ±100Hz) den Unterschied macht.


Offtopic:
Das Ally ist ein gutes Gerät - aber ich fand das Steam Deck aus folgenden (für mich persönlich wichtigeren) Gründen besser:

1.) das Steamdeck hat touchpads womit man auch Strategie und Aufbau spielen kann (Civilization oder XCom gehen wunderbar)
Finde ich persönlich jetzt keinen großen Nachteil, im Gegenteil ich bevorzuge da die kompaktere Bauweise. Die Touchpads am Deck sind zwar nett gedacht, aber für die ernsthafte Verwendung doch deutlich zu klein, da wäre es glaube ich sogar besser wenn man den Screen asymmetrisch gebaut hätte und dafür nur eines aber dafür ausreichend großes Touchpad verbaut hätte. Strategiespiele habe ich zwar mal kurz ausprobiert, war mir dann aber zu fummelig. Und für schnell auf dem Display was klicken wenn es mal notwendig ist und die Controller gerade nicht verwendbar sind ist der Touchscreen sogar besser, und den hat der Ally auch

2.)das Steamdeck hat kein Windows braucht also kein Gefummel (sofern man alle Spiel in Steam hat -> für mich ein großer Incentive alles nur noch auf Steam zu kaufen -> jaja ich weiß Opfer... :-D aber die Erfahrung ist einfach super.
Das liest man immer wieder in Reviews, wobei ich der Meinung bin nachdem ich beides gesehen habe, dass hier Windows viel Unrecht getan wird.
Nicht Linux ist ist besser oder weniger fummelig, Steam ist auf dem Steamdeck weniger fummelig als Windows. Wenn ich am Ally direkt beim Start Steam im Big Picture Modus starte habe ich aber das selbe.
Und genau dieses fixieren auf Steam hat mich am Steamdeck gestört. Sobald man sich außerhalb von Steam bewegt wird es am Deck extrem fummelig.
Am Ally kann ich ganz ohne Probleme auch Spiele außerhalb von Steam installieren und verwenden. Der Windows Desktop funktioniert am kleinen Touchscreen zwar nicht so gut wie auf einem Smartphone aber OK. Der Desktop vom Steamdeck ist eine absolute Katastrophe, selbst mal kurz einen Browser aufmachen und ein youtube video suchen wird zur Tortur. Mit Windows funktioniert das mehr oder weniger gleich gut wie am Smartphone. Ähnliches gilt für die virtuelle Tastatur wenn man sie doch mal braucht, die vom Steamdeck ist eine absolute Katastrophe, die von Windows steht einem Smartphone um nichts nach, bzw. ist sogar besser da freier konfigurierbar und auch PC-Spezifische Tasten vorhanden sind die am Deck komplett fehlen.
Weiterer Bonus, auf Windows kann man das ganz normale AMD Treiberpanel verwenden, Windows kann man ganz einfach von der Ferne steuern für Konfigurationsmöglichkeiten bzw. Installationen und dergleichen. Man kann auch einfach AMD-Treiber direkt herunterladen und Updaten, und es besteht zumindest die Hoffnung dass auch der Z1 in naher Zukunft in den allgemeinen Grafiktreiber aufgenommen wird.
Insgesamt würde ich sagen für ein Gaming-Device ist aktuell Windows ganz klar und deutlich besser als Linux, und würde Valve die selbe Steam-Version die es am Deck anbietet auch für Windows anbieten gäbe is absolut 0 Nachteile.


3.) Hohe Akkulaufzeiten mit lowTDP. Ich hole aus vielen Spielen mit Optimierung 3-4h Akkulaufzeit raus. Dank SteamOS scheint der SoC wenn er nicht ausgelastet ist sowohl bei der GPU als auch bei der CPU in den niedrigst möglichen Betriebspunkt zu gehen völlig ohne AutoTDP. Und gerade in den niedrigen TDP Regionen ist die Performance bis dato ungeschlagen (der Vorteil des Custom SoCs)


Low-TDP ist sicher das Steamdeck immer noch King, der 10W Mode vom Ally ist kaum brauchbar. Wobei es gegen Apple immer noch erbärmlich aussieht, das Deck verliert eine Nacht unangesteckt gleich mal 20% Akku, ein Apple Notebook zu wenig um es mit einer Prozentanzeige ohne Nachkommastellen überhaupt abbilden zu können. Wobei man ehrlicherweise sagen muss, wenn man nicht nur uraltes Zeugs spielt fehlt beiden unter 15W Powerlimit einfach die Performance. Und bei 15W ist das Ally sogar ca. 5-10% besser, scheinbar ist die Rest-of-System-Power beim Ally effizienter. Gesamtleistungsaufnahme beim Deck mit 15W PL ist ca. 25W, beim Ally ca. 23W, und das trotz "verschwenderischem" 120Hz screen. Man kann beim Ally auf ±17W SOC-Power gehen und erreicht in etwa die gleiche Gesamtleistungsaufnahme wie vom Deck. Und die bringen auch viel Performance, für das Ally sind die 15W eigentlich noch zu wenig, ein paar W mehr geben da gleich mal +50% manchmal auch +100% Performance.
Insgesamt sehe ich die Akkulaufzeit gar nicht mehr als so ein Problem, meistens verwende ich es eh zuhause auf der Couch weil es gemütlicher ist, oder auf der Terasse da ist nirgends die Steckdose weit weg. Und unterwegs ist es auch nicht so, dass man das mal eben für 10min rausnimmt, dafür sind beide doch zu sperrig, sondern man sitzt 1h oder so am selben Fleck, und da stört es auch nicht wenn man zusätzlich zum Deck/Ally die Powerbank aus der Tasche holt.

Wobei der größte Vorteil neben dem Screen das deutlich bessere Kühlsystem ist. Auf 15W ist das Ally praktisch unhörbar, und um auf SteamDeck Lautstärke zu kommen muss man schon auf 30W gehen (was nur am Kabel geht)


4.) Der Preis. Ich hab mein Steamdeck für 400 EUR gekauft und für 30 EUR eine SD Karte dazu. Rennt. Keine Probleme.
Also die 64GB eMMC Version mit dem 512GB NVME Ally zu vergleichen ist schon etwas unfair. Da müsste man schon auch vom Deck die 512GB Version nehmen, und dann ist der Preisunterschied nicht mehr so hoch, und da würde ich sogar sagen hat das Ally das bessere P/L-Verhältnis (wobei ich unter Leistung nicht nur die Performance sondern das Gesamtpaket meine)
BTW: weiterer Vorteil vom Ally, es verwendet Gewindebuchsen womit man die strukturelle Integrität beim Öffnen nicht schwächt, und die SSD upgraden ist extrem einfach. Wenn es kein OS findet bootet es direkt ins UEFI und fragt ob es Windows installieren will, dann sagst du ja, wartest ein wenig und es ist fertig.

@Konzept mobile Gaming
Ich bin hooked. Ich wechsle zwischen PC und Steamdeck hin und her je nach Situation und kann auf einmal deutlich mehr spielen (weil man mehr Gelegenheiten nutzen kann). Einfach schnell mal aus dem Standby direkt weiter zocken oder in den Standby innerhalb einer Sekunde ist das Ding aus und man kann wieder das normale Leben fortsetzen (kannst du schnell auf die Kids aufpassen? Klick. Jap kein Problem).

Wenn es ein Steamdeck 2 geben wird, bin ich ab Anfang an dabei diesmal. Ich gehe davon aus, dass es auch VRR geben wird und einen noch besseren SoC in Bezug auf Perf/W bis zu 15W. Mehr als 15W sind für mich zumindest eh sinnlos weil die Akkulaufzeit dann für mich zu kurz ist. Alle 2h ist sowas von 1990er. Eher will ich noch mehr Leistung in 5-8W haben um mal auf zeitgemäße Akkulaufzeiten zu kommen. ^^

Ich glaube da müsstest du eher auf Apple warten, wobei das noch Jahre dauern wird, deren Proton-Variante steckt noch immer ziemlich in den Kinderschuhen.
Aber insgesamt muss ich sagen, ein neues Steamdeck müsste schon deutlich mehr bringen um mich vom "freien" Windows (klingt echt komisch das zu sagen 😆) wieder zurück zu einem System zu bringen für das man Klimmzüge machen muss wenn man irgendwas außerhalb von Steam verwenden will.







Grundsätzlich gebe ich dir Recht. Aber ich vermute, die TV Hersteller haben (noch?) gar nicht den Fokus auf low latency frame interpolation für das Gaming.


Es gibt TVs mit einem FG-Modus speziell für Gaming.


Und die aller döllsten SoCs stecken da ja nicht gerade drin.


Deshalb haben sie auch so lahmes UI. Aber nur weil die GeneralPurpose Leistung gering ist, muss das nicht für die spezialisierte Hardware gelten.
Die können teilweise 8K wiedergeben, unter dem sogar moderne CPUs ächzen.

[Gast]

Das kommt IMO auf die Generation an. Turing holte bisher am meisten pro TFLOP heraus.


Auch, Context-Switches sind bei Nvidia vor Turing und insbesondere vor Pascal recht teuer.

Wobei man hier wenn man Generationen vergleicht das FL streichen sollte.
Wenn man nämlich pro TOP/s rechnet wird man sehen dass es nach Turing aufwärts gegangen ist.

[Gast]

müsste net RDNA3 durch die FP32-verdopplung brachliegende Reserven haben

Nein, der limitierende Faktor sind hier die ALUs selbst.

Das Scheduling erfolgt immer in Threadpaketen, bei Nvidia Warps, bei AMD Waves genannt.

Wenn ein Warp/Wave nicht alle ALUs ausnutzt kannst du diese nicht einfach über Async-Compute einen anderen Shader rechnen lassen.

Die nicht zeitkritischen Threads die über Async Compute laufen müssen über ihre eigene Wave/Warp Scheduled werden, das Limit ist hier wieviele Warps/Waves durch den Scheduler passen.

Die höhere ALU-Anzahl kann hier nur helfen, dass ein Threadpaket schneller abgearbeitet wird, nicht dass mehr Threadpakete parallel abgearbeitet werden.

[Gast]

Dass der TV keine Motion-Vectoren hat stimmt nämlich nur wenn man ihn als reines Display verwendet. Im komprimierten Video-Datenstrom sind nämlich durchaus Motion-Vectoren enthalten, und wenn der TV nicht nur als Anzeige- sondern auch als Wiedergabegerät fungiert, kann er diese auch für die Interpolation verwenden.

Die Bewegungsvektoren aus den Videocodecs sind im Allgemeinen nicht so einfach für Bildinterpolationen zu gebrauchen. Sie sind auf möglichst geringe rate distortion optimiert, nicht auf kohärente Bewegung. Da wird sich der passende Block halt da zusammengesucht, wo es am wenigsten Bitrate kostet. Das muss nicht der Bewegung des Objekts ensprechen, gerade wenn das Objekt aus mehreren Blöcken besteht. Und es hängt dann auch von der Qualität des Encoders ab, wie gut die Vektoren zu gebrauchen sind.

[Platos]

Naja, die Latenz erhöht sich bei Samsung um das 3x liegt z.B. bei aktuellen Bildschirmen dann bei 30ms statt 11ms: https://www.rtings.com/tv/reviews/samsung/q70c-q70-q70cd-qled#test_14

Stimmt natürlich, aber wer weiss, ob das bei AMD dann besser ist.

Wobei ich sagen muss, dass ich am TV und an der Konsole lieber Frameinterpolation anmache. Ist einfach flüssiger vom Bild her.

Bei Samsung gibt es 2 Interpolationsverfahren, 1x das "normale" in hoher Qualität und hoher Latenz was beim Fernsehen zum Einsatz kommt und ein anderes Latenzoptimiertes für den Gamemode geringerer Qualität.
Die 30ms stammen garantiert von letzterem, die "normale" Interpolation ist mit Sicherheit eher auf dem Level der "outside gamemode" Messungen.

Wo findet man denn die beiden Einstellungen? Kannst du da die Bezeichnungen sagen für beide? Ich kannte bisher nur eine.


Meine Erwartung wäre, dass FMF besser bei der Latenz ist als ein TV und optisch weniger Artefakte produziert (weil das Processing sicherlich besser ist als auf einem schnell veralteten low cost TV SoC).



Das wäre meine Hoffnung, aber erwarten tue ich mal nichts. Ich bin da eher skeptisch.

[Gast]

Wo findet man denn die beiden Einstellungen? Kannst du da die Bezeichnungen sagen für beide? Ich kannte bisher nur eine.



Die Einstellung ist die selbe, es hängt davon ab ob der gamemode aktiv ist oder nicht.

[robbitop]

Auch, Context-Switches sind bei Nvidia vor Turing und insbesondere vor Pascal recht teuer.

Wobei man hier wenn man Generationen vergleicht das FL streichen sollte.
Wenn man nämlich pro TOP/s rechnet wird man sehen dass es nach Turing aufwärts gegangen ist.
Ja aber TFLOPs sind nunmal das was die Grafikpipelines brauchen. TOPs braucht man nur für den NN Kram, der selbst mit DLSS3 laut nsight nur für einen super duper kurzen Bruchteil der Frametime mal aufleuchtet. Mehr TOPs und mehr Auslastung dieser sind zumindest aktuell für das Gaming nicht so relevant. :)

[Platos]

Die Einstellung ist die selbe, es hängt davon ab ob der gamemode aktiv ist oder nicht.

Ah ok, muss ich mal ausprobieren. Mal sehen, ob meiner das auch schon kann.

[Gast]

Ja aber TFLOPs sind nunmal das was die Grafikpipelines brauchen.

Auch für Grafik braucht man nicht nur FLOPS, laut der NV-Folie damals bei Turing ist der INT-Anteil bis zu 50% und im Schnitt um die 30%.

[robbitop]

Auch für Grafik braucht man nicht nur FLOPS, laut der NV-Folie damals bei Turing ist der INT-Anteil bis zu 50% und im Schnitt um die 30%.
Du hast aber von TOPs gesprochen. Meint das nicht Matrix Operationen?
Ansonsten glaube ich hat NV bei Turing mit dem INT Anteil total übertrieben in ihren Präsentationen. Das geht bei nsight IIRC überhaupt nicht auf von dem was ich gesehen habe und die Performance von Turing geht damit ggü Pascal (pro TFLOP) nicht auf. Bei gleichem FPU Durchsatz war Turing kaum schneller als Pascal obwohl man ja nochmal die gleiche Menge an INTs über hatte. Wenn die 30% stimmen würden, hätte er da mehr rausholen müssen in Spielen.

Letzten Endes aber seit Ampere auch egal weil wieder voller FP Durchsatz pro SM.

---------------------------------


So mache ich es auf dem Steamdeck, ingame Framelimiter auf 60, wenn möglich Settings finden die das auch einigermaßen erreichen können und VSYNC aus.
Also ich habe beobachtet, dass externe Framelimiter teurer in der Latenz zu sein scheinen als VSync (wenn man tearing vermeiden will).
60 fps sind leider in vielen Spielen nicht erreichbar. Nach meinen Beobachtungen liegt das an der CPU. Man kann ja in Spielen die GPU durch Auflösung und Details entlasten. Die CPU nimmt sich dann in vielen Fällen den Löwenanteil der 15W und schafft es dann trotzdem oft nicht auf 60 fps sondern häufig in den 50ern. Und dabei habe ich schon jeweils CPU/NB/GPU um 50 mV undervolted.

Die CPU ist einfach zu schwach für 60 fps in vielen Fällen. Laut dem Chipsandcheese Review ist die Memorylatency total hoch (~120 ms!) und dann ist der L3 Cache auch noch so klein (4 MiB) und dann gibt es auch noch nur 4 Kerne. Wahrscheinlich liegt das Ding in der Praxis knapp unter Zen1 IPC und gurkt dann mit knapp 3 GHz (wenn man die Auflösung total runterstellt und die CPU sich 8-10W genehmigen darf) herum. Einfach zu wenig.

Das lässt erkennen, dass das Steamdeck (bzw dessen SoC) eher für 30 fps (Konsolenerfahrung) konzipiert wurde.

Wenn ich runter auf 40-45 Hz gehe, geht der Verbrauch in so ziemlich allen Spielen massiv runter. Dazu die Auflösung etwas runter und schon springt die Akkulaufzeit hoch.
In ganz neuen Titeln allerdings braucht man die 15W dann für die Refreshrate allerdings. Armored Core 6 läuft vernünftig (leider kein temporales Upsampling :() auf 45 fps aber der Akku ist in unter 2h leer.


So ist es, deshalb hab ich auch den großen Jubel als das Steamdeck per Update die komplett freie Konfiguration der Refreshrate bekommen hat nicht verstanden.

40Hz statt 60Hz macht nur mit VSYNC noch mehr LAG, ohne VSYNC Tearing noch sichtbarer und mit VSYNC falls man die FPS mal doch nicht halten kann das Stuttering schlimmer.
Da nehm ich lieber 40FPS ohne SYNC auf 60Hz.

@Limiter/VRR
Selbst bei einem VRR Screen wäre ein Framelimiter immer noch gut, weil der halt ordentlich Energie spart. Klar kann man mit VRR auch einfach die TDP drosseln. Aber ich möchte lieber eine konsistente Spielerfahrung haben und er spart Energie an Stellen, wo er die Frametime locker schafft.
Allerdings bin ich enttäuscht wie selten Spielinterne Framelimiter (geringerer Latency hit als externe) sind - insbesondere einstellbare (so dass man auch 40 oder 45 fps anpeilen kann).

Dank Gamepad ist man ja nicht ganz so latenzsensibel wie auf M+T. Aber dennoch sind 45 fps mit VSync (kein Limiter) für mich das unterste wo ich noch Spaß habe. Darunter wird es mir zu zäh.








Finde ich persönlich jetzt keinen großen Nachteil, im Gegenteil ich bevorzuge da die kompaktere Bauweise. Die Touchpads am Deck sind zwar nett gedacht, aber für die ernsthafte Verwendung doch deutlich zu klein, da wäre es glaube ich sogar besser wenn man den Screen asymmetrisch gebaut hätte und dafür nur eines aber dafür ausreichend großes Touchpad verbaut hätte. Strategiespiele habe ich zwar mal kurz ausprobiert, war mir dann aber zu fummelig. Und für schnell auf dem Display was klicken wenn es mal notwendig ist und die Controller gerade nicht verwendbar sind ist der Touchscreen sogar besser, und den hat der Ally auch

Ja ideal ist es nicht. Es geht nicht alles damit. Je nach dem wie klick-intensiv das Spiel ist.


Das liest man immer wieder in Reviews, wobei ich der Meinung bin nachdem ich beides gesehen habe, dass hier Windows viel Unrecht getan wird.
Nicht Linux ist ist besser oder weniger fummelig, Steam ist auf dem Steamdeck weniger fummelig als Windows. Wenn ich am Ally direkt beim Start Steam im Big Picture Modus starte habe ich aber das selbe.
Und genau dieses fixieren auf Steam hat mich am Steamdeck gestört. Sobald man sich außerhalb von Steam bewegt wird es am Deck extrem fummelig.
Am Ally kann ich ganz ohne Probleme auch Spiele außerhalb von Steam installieren und verwenden. Der Windows Desktop funktioniert am kleinen Touchscreen zwar nicht so gut wie auf einem Smartphone aber OK. Der Desktop vom Steamdeck ist eine absolute Katastrophe, selbst mal kurz einen Browser aufmachen und ein youtube video suchen wird zur Tortur. Mit Windows funktioniert das mehr oder weniger gleich gut wie am Smartphone. Ähnliches gilt für die virtuelle Tastatur wenn man sie doch mal braucht, die vom Steamdeck ist eine absolute Katastrophe, die von Windows steht einem Smartphone um nichts nach, bzw. ist sogar besser da freier konfigurierbar und auch PC-Spezifische Tasten vorhanden sind die am Deck komplett fehlen.
Weiterer Bonus, auf Windows kann man das ganz normale AMD Treiberpanel verwenden, Windows kann man ganz einfach von der Ferne steuern für Konfigurationsmöglichkeiten bzw. Installationen und dergleichen. Man kann auch einfach AMD-Treiber direkt herunterladen und Updaten, und es besteht zumindest die Hoffnung dass auch der Z1 in naher Zukunft in den allgemeinen Grafiktreiber aufgenommen wird.
Insgesamt würde ich sagen für ein Gaming-Device ist aktuell Windows ganz klar und deutlich besser als Linux, und würde Valve die selbe Steam-Version die es am Deck anbietet auch für Windows anbieten gäbe is absolut 0 Nachteile.

stimmt. Aber ein paar Vorteile gibt es schon noch:

1.) Vorkompilierte Shader - finde ich sau geil!
2.) keine kack Updates, die einen aus der UI rausreißen - ist deutlich konsoliger.

Aber ansonsten hast du natürlich mit Big Picture Mode schon recht.



Low-TDP ist sicher das Steamdeck immer noch King, der 10W Mode vom Ally ist kaum brauchbar. Wobei es gegen Apple immer noch erbärmlich aussieht, das Deck verliert eine Nacht unangesteckt gleich mal 20% Akku, ein Apple Notebook zu wenig um es mit einer Prozentanzeige ohne Nachkommastellen überhaupt abbilden zu können. Wobei man ehrlicherweise sagen muss, wenn man nicht nur uraltes Zeugs spielt fehlt beiden unter 15W Powerlimit einfach die Performance. Und bei 15W ist das Ally sogar ca. 5-10% besser, scheinbar ist die Rest-of-System-Power beim Ally effizienter. Gesamtleistungsaufnahme beim Deck mit 15W PL ist ca. 25W, beim Ally ca. 23W, und das trotz "verschwenderischem" 120Hz screen. Man kann beim Ally auf ±17W SOC-Power gehen und erreicht in etwa die gleiche Gesamtleistungsaufnahme wie vom Deck. Und die bringen auch viel Performance, für das Ally sind die 15W eigentlich noch zu wenig, ein paar W mehr geben da gleich mal +50% manchmal auch +100% Performance.
Insgesamt sehe ich die Akkulaufzeit gar nicht mehr als so ein Problem, meistens verwende ich es eh zuhause auf der Couch weil es gemütlicher ist, oder auf der Terasse da ist nirgends die Steckdose weit weg. Und unterwegs ist es auch nicht so, dass man das mal eben für 10min rausnimmt, dafür sind beide doch zu sperrig, sondern man sitzt 1h oder so am selben Fleck, und da stört es auch nicht wenn man zusätzlich zum Deck/Ally die Powerbank aus der Tasche holt.

Wobei der größte Vorteil neben dem Screen das deutlich bessere Kühlsystem ist. Auf 15W ist das Ally praktisch unhörbar, und um auf SteamDeck Lautstärke zu kommen muss man schon auf 30W gehen (was nur am Kabel geht)


Ja das Kühlsystem musste fähiger sein, da das Ally ja deutlich höhere Betriebspunkte erreicht. Ich finde das beim Steamdeck auch nicht ideal. Aber, da ich meist probiere nicht so hohe TDPs anzupeilen wirds dann auch meist leiser. Wenn man mit Kopfhörern spielt (insbesondere mit noise canceleation) ist es auch IMO gar kein Problem mehr.


4.) Der Preis. Ich hab mein Steamdeck für 400 EUR gekauft und für 30 EUR eine SD Karte dazu. Rennt. Keine Probleme.
Also die 64GB eMMC Version mit dem 512GB NVME Ally zu vergleichen ist schon etwas unfair. Da müsste man schon auch vom Deck die 512GB Version nehmen, und dann ist der Preisunterschied nicht mehr so hoch, und da würde ich sogar sagen hat das Ally das bessere P/L-Verhältnis (wobei ich unter Leistung nicht nur die Performance sondern das Gesamtpaket meine)
BTW: weiterer Vorteil vom Ally, es verwendet Gewindebuchsen womit man die strukturelle Integrität beim Öffnen nicht schwächt, und die SSD upgraden ist extrem einfach. Wenn es kein OS findet bootet es direkt ins UEFI und fragt ob es Windows installieren will, dann sagst du ja, wartest ein wenig und es ist fertig.
Mag unfair sein aber war für mich irrelevant. Ich wollte so ein Ding haben und mir ist es egal wo der Speicher herkommt solange es funktioniert. Beim Steamdeck gibt es die 64 GB Optionen und 1 TB SSDs sind schweine billig. Warum soll ich in dem Fall die 512 GB Version nehmen und vergleichen? Ich wollte Preis/Leistung. Wenn ASUS sowas nicht anbietet selbst schuld. Ich war für deutlich weniger Geld dabei und merke mit der SD Karte in Spielen keine Nachteile. *Schulterzuck*



Ich glaube da müsstest du eher auf Apple warten, wobei das noch Jahre dauern wird, deren Proton-Variante steckt noch immer ziemlich in den Kinderschuhen.
Aber insgesamt muss ich sagen, ein neues Steamdeck müsste schon deutlich mehr bringen um mich vom "freien" Windows (klingt echt komisch das zu sagen ��) wieder zurück zu einem System zu bringen für das man Klimmzüge machen muss wenn man irgendwas außerhalb von Steam verwenden will.


Ja wenn ein Apple M im Steamdeck (oder Equivalent) stecken würde, wäre das wahrscheinlich eine Perf/W Explosion. Aber Apple hat daran anscheinend kein Interesse. Sie framen ja ihr Translation Layer (der ja gar nicht ihrer ist sondern zu 99% open source source code nutzt) eher als Dev Kit, um zu helfen Spiele zu porten. Es wirkt nicht so als wenn sie analog zu Valve richtig permanenten Aufwand treiben wollen, den Layer schneller zu machen und auf jedes Spiel anzupassen (und quirks die von Spielen kommen durch den Layer zu umgehen).

Aber ganz ehrlich: man stelle sich vor, was AMD mit einem 3nm SoC machen könnte. Das wäre auch schon fein. Ich hätte gern einen IF$ für den SoC (was Valve aus Kostengründen nicht machen wird). Das senkt den Energiebedarf sicherlich (lokale Datenzugriffe sind energetisch viel billiger als externe) und bringt die Performance von GPU und CPU nochmal nach oben. Dazu ein Zen5c/6c und RDNA4 wieder als custom SoC optimiert auf 15W oder darunter. Dann wäre schon ein ordentlicher Sprung zu erwarten.

Naja jedenfalls bei Spielen aus der PS4 Ära kann ich oft in low TDP Regionen vordringen. Ich limitiere dazu gar nicht die TDP sondern setze die Refreshrate auf 40-45 Hz und senke Auflösung/Details etwas. Und schon laufen CPU und GPU in niedrigen Betriebspunkten. Oft zwischen 5-10W. Dann gibt's richtig Akkulaufzeit.




Es gibt TVs mit einem FG-Modus speziell für Gaming.

Der aber nicht so gut interpoliert. Man wird den Vergleich abwarten müssen. Man könnte ja heute bereits DLSS3 mal mit einem low latency FG mode vergleichen. Mein LG OLED hat das leider nicht und meine Ampere hat kein FG.

[Gast]

Du hast aber von TOPs gesprochen. Meint das nicht Matrix Operationen?

TOPS sind Tera-Operations, das sind alle Operationen. FLOPS beschränkt das auf FP, IOPS auf INT.
Der Grund warum Nvidia für die Tensorcores TOPS angibt ist ja genau dieser, dass diese sowohl mit INT als auch mit FP rechnen können.

Aber ja, ich meine hier nur die general Purpose TOPS, nicht die speziellen Tensor-TOPS.


Ansonsten glaube ich hat NV bei Turing mit dem INT Anteil total übertrieben in ihren Präsentationen. Das geht bei nsight IIRC überhaupt nicht auf von dem was ich gesehen habe und die Performance von Turing geht damit ggü Pascal (pro TFLOP) nicht auf. Bei gleichem FPU Durchsatz war Turing kaum schneller als Pascal obwohl man ja nochmal die gleiche Menge an INTs über hatte. Wenn die 30% stimmen würden, hätte er da mehr rausholen müssen in Spielen.


Es hängt natürlich stark vom verwendeten Spiel ab, aber INT-Operationen sind in Shadern jetzt nicht so selten (kann man sich ja bei verfügbaren Opensource-Engines selbst ansehen).

Der "Fehler" ist eben dass alle Welt bei Turing --> Ampere von 2x FLOP-Durchsatz pro SM ausgeht. Real steigt der FLOP-Durchsatz gegenüber Turing aber je nach INT-Anteil nur um 30-50%, und das passt auch recht gut in die Performancesteigerung pro SM.


Letzten Endes aber seit Ampere auch egal weil wieder voller FP Durchsatz pro SM.

Es ist aber eben nicht egal, wenn man Turing gegenüber den Nachfolgern pro SM vergleichen will.
---------------------------------




Also ich habe beobachtet, dass Framelimiter teurer in der Latenz zu sein scheinen als VSync (wenn man tearing vermeiden will).


Ich meine ausschließlich Ingame Framelimiter, der Steamdeck Framelimiter ist wie schon früher geschrieben furchtbar, und dieser limitiert die Frames indem er VSYNC erzwingt. Die neue "Allow Tearing" Option ist jetzt gefühlt auch nicht viel besser.


Die CPU ist einfach zu schwach für 60 fps in vielen Fällen. Laut dem Chipsandcheese Review ist die Memorylatency total hoch (~120 ms!) und dann ist der L3 Cache auch noch so klein (4 MiB) und dann gibt es auch noch nur 4 Kerne. Wahrscheinlich liegt das Ding in der Praxis knapp unter Zen1 IPC und gurkt dann mit knapp 3 GHz (wenn man die Auflösung total runterstellt und die CPU sich 8-10W genehmigen darf) herum. Einfach zu wenig.



Ja die CPU ist definitiv eine Schwachstelle und 3GHz sind nach meiner Erfahrung im Gaming auch schon sehr hoch gegriffen, 2GHz Realtakt sind eher realistisch, die GPU will schließlich auch noch ihren Anteil am Powerbudget.
IPC-Mäßig ist das in etwa auf dem Niveau, der Efficiency-Kerne von Apple, die schaffen das allerdings im 3-Stelligen mW-Bereich.


In ganz neuen Titeln allerdings braucht man die 15W dann für die Refreshrate allerdings. Armored Core 6 läuft vernünftig (leider kein temporales Upsampling :() auf 45 fps aber der Akku ist in unter 2h leer.


Ja, so kenne ich das 90-120min sind einigermaßen realistisch.


@Limiter/VRR
Selbst bei einem VRR Screen wäre ein Framelimiter immer noch gut, weil der halt ordentlich Energie spart.


Auf jeden Fall, ich Spiele am Ally auch (fast) nur mit 60FPS-Limiter, aber eben Ingame, und mit VRR wirkt es am kleinen Screen bis runter auf ca. 40FPS noch ziemlich flüssig.


Allerdings bin ich enttäuscht wie selten Spielinterne Framelimiter (geringerer Latency hit als externe) sind - insbesondere einstellbare (so dass man auch 40 oder 45 fps anpeilen kann).


Stimmt, den könnte man definitiv öfter brauchen.


1.) Vorkompilierte Shader - finde ich sau geil!
2.) keine kack Updates, die einen aus der UI rausreißen - ist deutlich konsoliger.

Aber ansonsten hast du natürlich mit Big Picture Mode schon recht.


1 ist schon genial, allerdings frage ich mich warum da oft fast täglich ein update kommen muss.

2 ist überhaupt kein Problem, Asus hat Windows im Ally so konfiguriert dass es dauerhaft im "Nicht Stören" Modus ist, von Windows selbst bekommst du da gar nichts mit, und die Armory Crate-Software fängt die Benachrichtigungen ab, so dass man sie auf deren Oberfläche anschauen kann ohne zu Windows zurück zu müssen. Die sind aber auch überhaupt nicht aufdringlich, du siehst lediglich in der Kopfzeile neben Akku und Uhr an einer Glocke dass es was gibt.
Was Asus allerdings verkackt hat ist ein einheitliches Update fürs Ally selbst. In der Armory Crate Software gibt es nur eine Update-Funktion für Armory Crate und allem was dazugehört selbst.
Updates für das Ally selbst (Treiber, UEFI etc.) laufen über die MyAsus-Anwendung die nicht für die Controllersteuerung angepasst ist.
Falls sie das doch irgendwann mal in ArmoryCrate integrieren würden, stünde man da dem Steamdeck um nichts nach, den Desktop siehst du dann nur 1x kurz nach dem Booten bis ArmoryCrate geladen ist, bzw. beim Spielstart kurz wenn ein Launcher geladen werden muss.


Mag unfair sein aber war für mich irrelevant. Ich wollte so ein Ding haben und mir ist es egal wo der Speicher herkommt solange es funktioniert. Beim Steamdeck gibt es die 64 GB Optionen und 1 TB SSDs sind schweine billig. Warum soll ich in dem Fall die 512 GB Version nehmen und vergleichen?


Ja ist verständlich.


Ich war für deutlich weniger Geld dabei und merke mit der SD Karte in Spielen keine Nachteile. *Schulterzuck*


Das wiederum kommt mir seltsam vor, die SD-Karte ist doch deutlich langsamer als eine SSD, speziell bei Random zugriffen, zudem ist der Reader vom Steamdeck auch langsamer (ich hatte glücklicherweise keine Probleme mit meinem am Ally)



Ja wenn ein Apple M im Steamdeck (oder Equivalent) stecken würde, wäre das wahrscheinlich eine Perf/W Explosion.

So ist es, wobei man wenn man Apple kennt die das sicher auf Ihr Ökosystem beschränken wollen.
Auf jeden Falls gibt es in der aktuellen MacOS-Beta einen Proton-Äquivalenten Translation-Layer. Allerdings ist das ganze noch eine ziemlich frühe Alpha, extrem Stuttery und wenn man dem Overlay glauben darf wird die GPU nur zu einem Bruchteil ausgelastet.


Aber Apple hat daran anscheinend kein Interesse. Sie framen ja ihr Translation Layer (der ja gar nicht ihrer ist sondern zu 99% open source source code nutzt) eher als Dev Kit, um zu helfen Spiele zu porten. Es wirkt nicht so als wenn sie analog zu Valve richtig permanenten Aufwand treiben wollen, den Layer schneller zu machen und auf jedes Spiel anzupassen (und quirks die von Spielen kommen durch den Layer zu umgehen).


Selbst dafür müssten sie es auf eine brauchbare Performance bringen, es soll ja dem Dev zeigen dass sein Spiel auch auf MacOS gut lauffähig wäre.
Da bringt ein unperformantes Ergebnis mit dem Versprechen, wenn du es nativ machst läuft es eh ordentlich wenig.


Aber ganz ehrlich: man stelle sich vor, was AMD mit einem 3nm SoC machen könnte.


Keine Ahnung so lange es keine Hardware zum "angreifen" gibt bin ich erstmal skeptisch was neue Prozesse angeht. Reine Verkleinerungen ohne gänzlich neue Technologie (damals FINFET) haben jedenfalls jetzt schon für einige Zeit enttäuscht, speziell die frühen Iterationen.
Perf/Watt ist jetzt der Z1E auch nicht so der Bringer gegenüber VanGogh, trotz 4N vs. 7N.


Das wäre auch schon fein. Ich hätte gern einen IF$ für den SoC (was Valve aus Kostengründen nicht machen wird).


Würde ich zumindest als Variante mit 3D-Cache nicht ausschließen. Das Hauptziel vom Steamdeck war ja, sich beim Preis nicht allzu sehr von der Switch zu distanzieren, und Valve war ja laut eigenen Aussagen darüber überrascht wie viele zum teuersten Modell greifen, was darauf hindeuten würde, dass sie für die nächste Generation eher das höherpreisige Segment anvisieren wollen.







Der aber nicht so gut interpoliert. Man wird den Vergleich abwarten müssen. Man könnte ja heute bereits DLSS3 mal mit einem low latency FG mode vergleichen. Mein LG OLED hat das leider nicht und meine Ampere hat kein FG.


Ja, und vor allem nicht so dynamisch, z.B. geht es am Fernseher nur ohne VRR.

[robbitop]

Was mich richtig wundert ist immer noch Star Field.
Kein Wort über FSR. Egal welche Version. 1, 2 oder 3. AMD ist Technologiepartner und bringt Star Citizen CPU/GPU Bundles raus (mit Star Citizen Package und Star Citizen Kühler für die Grafikkarte). Aber kein Wort über die Technologie, die bei Starfield genutzt werden soll. (FidelityFX ist ja eine mittlerweile recht große Library)

Bei der FSR3 Präsentation ist es weder als Spiel noch als Studio was FSR3 Implementierung für (kommende oder existierende) Spiele genannt worden.

Vermutung: ob sie wegen des Shitstorms um DLSS jetzt den Ball komplett flach halten? Entsprechend ein "stilles release" ohne Ankündigung. Bis es jemandem auffällt "huch - hat ja FSR3".

Falls es das nicht hat, verstehe ich diese besondere Technologiepartnerschaft irgendwie nicht.

-------





Ja die CPU ist definitiv eine Schwachstelle und 3GHz sind nach meiner Erfahrung im Gaming auch schon sehr hoch gegriffen, 2GHz Realtakt sind eher realistisch, die GPU will schließlich auch noch ihren Anteil am Powerbudget.
Naja wenn man die Auflösung etwas runterdreht, PS4 Ära Games betrachtet und nur 40-45fps will, wird die GPU laut dem overlay UI super sparsam. Bei mir dümpelt sie dann zwischen 2 und 5W. Das heißt die CPU kann sich 10-13W genehmigen. Dazu habe ich Glück mit dem undervolting (-50/-50/-50 mV) gehabt - die CPU und GPU fährt TDP normiert tatsächlich höhere Betriebspunkte. Ein paar hundert MHz hat das gebracht bei mir.



IPC-Mäßig ist das in etwa auf dem Niveau, der Efficiency-Kerne von Apple, die schaffen das allerdings im 3-Stelligen mW-Bereich.
Ist das nicht etwas pessimistisch? Die E Cores sind bei Apple immerhin ooo Kerne aber schon ziemlich winzig. ^^

Ich denke mal es ist für zukünftige SoCs ordentlich Potenzial für ein Upgrade vorhanden.

+2-4x Cores mehr
Zen 5c oder neuer
größerer LLC

Gar nicht unrealistisch, dass man da die CPU Leistung mehr als verdoppelt ohne den Verbrauch zu erhöhen (~3 nm vorausgesetzt - da Valve gesagt hat es wird eine ganze Weile keinen Nachfolger geben -> also vergeht hier etwas Zeit - also mind 1 weiterer Fullnodeshrink ggü N5).


1 ist schon genial, allerdings frage ich mich warum da oft fast täglich ein update kommen muss.
Wundert mich auch. Ob es am Proton-Experimental Setting liegt? (setze ich immer bei jedem Spiel)


2 ist überhaupt kein Problem, Asus hat Windows im Ally so konfiguriert dass es dauerhaft im "Nicht Stören" Modus ist, von Windows selbst bekommst du da gar nichts mit, und die Armory Crate-Software fängt die Benachrichtigungen ab, so dass man sie auf deren Oberfläche anschauen kann ohne zu Windows zurück zu müssen. Die sind aber auch überhaupt nicht aufdringlich, du siehst lediglich in der Kopfzeile neben Akku und Uhr an einer Glocke dass es was gibt.
Was Asus allerdings verkackt hat ist ein einheitliches Update fürs Ally selbst. In der Armory Crate Software gibt es nur eine Update-Funktion für Armory Crate und allem was dazugehört selbst.
Updates für das Ally selbst (Treiber, UEFI etc.) laufen über die MyAsus-Anwendung die nicht für die Controllersteuerung angepasst ist.
Falls sie das doch irgendwann mal in ArmoryCrate integrieren würden, stünde man da dem Steamdeck um nichts nach, den Desktop siehst du dann nur 1x kurz nach dem Booten bis ArmoryCrate geladen ist, bzw. beim Spielstart kurz wenn ein Launcher geladen werden muss.
Ah okay das macht Sinn.





Das wiederum kommt mir seltsam vor, die SD-Karte ist doch deutlich langsamer als eine SSD, speziell bei Random zugriffen, zudem ist der Reader vom Steamdeck auch langsamer (ich hatte glücklicherweise keine Probleme mit meinem am Ally)
Naja ich benchmarke die SD Karte ja nicht. Ich nutze sie ^^
Eine echte SSD wäre bestimmt schneller beim Spieledownload / Installation und würden bestimmt die Spiele ein bisschen schneller laden. Aber ganz ehrlich: ich hab den 1:1 Vergleich nur zu meinem Full Size PC und klar der macht all das schneller. Wie das jetzt mit einem Steamdeck wäre: keine Ahnung. Aber: es fühlt sich finde ich nicht lahm an. Ein paar Sekunden hin oder her -> was solls. Und es gibt kein SD begründetes Laggen in Spielen.
Kurzum: es tut einfach. Ich bin selbst überrascht aber cool ist es schon.
IIRC hatte Valve das aber auch so gesagt, als sie das Steamdeck gelauncht haben. Ggf. cachen sie mit dem RAM noch etwas oder so. Keine Ahnung. Aber wie gesagt: tut was es soll. :)





Keine Ahnung so lange es keine Hardware zum "angreifen" gibt bin ich erstmal skeptisch was neue Prozesse angeht. Reine Verkleinerungen ohne gänzlich neue Technologie (damals FINFET) haben jedenfalls jetzt schon für einige Zeit enttäuscht, speziell die frühen Iterationen.
Perf/Watt ist jetzt der Z1E auch nicht so der Bringer gegenüber VanGogh, trotz 4N vs. 7N.
Ja der SoC muss schon custom sein. Ein 0815 Laptop SoC hat definitiv Nachteile bei LowTDP und Valve hat AMD ja wirklich so einiges ändern lassen bei Van Gogh. Ich kann mir gut vorstellen, dass man das nochmal macht. Aber das kann man natürlich nicht jedes Jahr machen. Custom Silicon kostet halt ^^



Würde ich zumindest als Variante mit 3D-Cache nicht ausschließen. Das Hauptziel vom Steamdeck war ja, sich beim Preis nicht allzu sehr von der Switch zu distanzieren, und Valve war ja laut eigenen Aussagen darüber überrascht wie viele zum teuersten Modell greifen, was darauf hindeuten würde, dass sie für die nächste Generation eher das höherpreisige Segment anvisieren wollen.
Das wäre schon extrem fettig. Dann kann man sicherlich nochmal ordentlich perf/W rausquetschen.

[Platos]

Naja, die Latenz erhöht sich bei Samsung um das 3x liegt z.B. bei aktuellen Bildschirmen dann bei 30ms statt 11ms: https://www.rtings.com/tv/reviews/samsung/q70c-q70-q70cd-qled#test_14

Um das nochmals aufzugreifen (Bild unten).

Also bei Samsung sind immerhin jetzt immerhin unter 20ms drin. Bei dieser (mir) unbekannten Marke sinds 10, aber da kennt man halt die Qualität nicht.

Und um den Bogen zu AMD zu machen: Bin ja gespannt, ob sie bei der Treiberversion da vom Inputlag mithalten können.

[The_Invisible]

Was mich richtig wundert ist immer noch Star Field.
Kein Wort über FSR. Egal welche Version. 1, 2 oder 3. AMD ist Technologiepartner und bringt Star Citizen CPU/GPU Bundles raus (mit Star Citizen Package und Star Citizen Kühler für die Grafikkarte). Aber kein Wort über die Technologie, die bei Starfield genutzt werden soll. (FidelityFX ist ja eine mittlerweile recht große Library)


Ich hoffe mal das ist eine astreine Implementierung von FSR in Starfield so wie man darüber geredet hat. AMD hat Zugriff im Code, Technologiepartner, beste Optimierung usw... aber gut, ist auch AMD, was ist da schon ein Marketingfail mehr :freak:

Vermutung: ob sie wegen des Shitstorms um DLSS jetzt den Ball komplett flach halten? Entsprechend ein "stilles release" ohne Ankündigung. Bis es jemandem auffällt "huch - hat ja FSR3".

Naja Avatar: Frontiers of Pandora hat jetzt ja auch plötzlich DLSS bekommen, ganz still und leise. Irgendwie "lustig" geschrieben auf der Ubisoft Seite, quasi "aja dlss wird ja auch unterstütz":

AMD FSR Technology, Resolution and Ratio Adaptability

Avatar: Frontiers of Pandora will utilize AMD's FSR 2 technology so players can fine-tune visual quality and performance, and it will be able to handle most resolution and aspect ratios; including ultra-wide screens. The game will also support DLSS at launch.

[Silvir]

Was mich richtig wundert ist immer noch Star Field.
Kein Wort über FSR. Egal welche Version. 1, 2 oder 3. AMD ist Technologiepartner und bringt Star Citizen CPU/GPU Bundles raus (mit Star Citizen Package und Star Citizen Kühler für die Grafikkarte). Aber kein Wort über die Technologie, die bei Starfield genutzt werden soll. (FidelityFX ist ja eine mittlerweile recht große Library)


Nichts offizielles bisher, aber FSR 2 ist wohl implementiert:

https://www.dsogaming.com/wp-content/uploads/2023/08/Starfield-PC-settings.jpeg

[Gast]

Ich hoffe mal das ist eine astreine Implementierung von FSR in Starfield so wie man darüber geredet hat. AMD hat Zugriff im Code, Technologiepartner, beste Optimierung usw... aber gut, ist auch AMD, was ist da schon ein Marketingfail mehr :freak:


Die Implementierung kann noch so astrein sein, beim falschen Content sieht FSR einfach beschissen aus.

[blaidd]

Schaut glaubhaft aus.

[Nazar]

Die Implementierung kann noch so astrein sein, beim falschen Content sieht FSR einfach beschissen aus.

Genauso wie DLSS bei "falschem Content" auch beschissen aussieht?
Ich bin über die "logischen" Schlüsse und Aussagen einiger Nutzer immer wieder hellauf begeistert. :freak:
Nach dem Motto: Lasst und diskutieren, aber ich bin schon irgendwie dagegen. :confused:
Und wenn du mir nicht glaubst, habe ich immer dieses "Argument": "Der Andere ist einfach scheiße, weil, ist eben so." :rolleyes:
Passt schon. ;D

[robbitop]

Ja naja FSR2 hat unabhängig von der Implementierung Schwächen bei bestimmten Content und bestimmten Situationen. Die sind dem Verfahren zuzuordnen.
ZB Disocclusion. Auch bestimmte geometrische Muster wenn man sich vorwärts bewegt (Gitterstrukturen).
Was wirklich implemtierungsabhängig ist, ist zum Beispiel Artefaktbildung bei Transparenzeffekten. Das funktioniert zwar meistens nicht aber IIRC gab es wenigstens eine Implementierung wo das okay war.

Das nützt nichts. Der Upsampling Teil von FSR2 hängt einfach ein gutes Stück zurück. Selbst Intel und Epic mit ihrem TSR sind mittlerweile oft besser. Kein Wunder da es seit FSR 2.1 keine wesentlichen Verbesserungen mehr gab. Und das ist jetzt über 1 Jahr her.
Entweder haben die FSR2 Leute wegen FSR3 keine Zeit mehr gehabt oder aber sie arbeiten an einem (ggf auch NN basiertem) Nachfolger.

[Gast]

Genauso wie DLSS bei "falschem Content" auch beschissen aussieht?




FSR sieht bei Disocclusion immer beschissen aus, ganz egal mit welcher Implementierung und Disoclussion lässt sich in den meisten Fällen nicht vermeiden.

Das einzige Spiel in dem FSR nicht komplett beschissen aussieht ist Diablo 4, weil es dank isometrischer Ansicht fast kein Disoclussion gibt.

Wobei es auch hier Ausnahmen gibt, Zaubereffekte die mit dem Untergrund geblendet werden führen auch hier zu grieseln, sind aber meistens schnell genug dass es nicht zusehr stört.

[Linmoum]

Genauso wie DLSS bei "falschem Content" auch beschissen aussieht?
Ich bin über die "logischen" Schlüsse und Aussagen einiger Nutzer immer wieder hellauf begeistert. :freak:
Nach dem Motto: Lasst und diskutieren, aber ich bin schon irgendwie dagegen. :confused:
Und wenn du mir nicht glaubst, habe ich immer dieses "Argument": "Der Andere ist einfach scheiße, weil, ist eben so." :rolleyes:
Passt schon. ;DNutzt du beide Verfahren eigentlich? Oder überhaupt eines davon? Oder worauf basieren sonst deine ständigen Ausführungen zu dem Thema?

Du schreibst immer viel, was im Endeffekt permanent darauf hinausläuft, irgendwas (insbesondere DLSS) abzulehnen und "Upscaling" ins Lächerliche zu ziehen oder FSR als den heiligen Gral bei solchen Diskussionen zu verteidigen. Was beides einfach albern ist, wenn du auch mal Praxiserfahrungen hättest und der Realität ins Auge blicken würdest.

[robbitop]

FSR sieht bei Disocclusion immer beschissen aus, ganz egal mit welcher Implementierung und Disoclussion lässt sich in den meisten Fällen nicht vermeiden.

Das einzige Spiel in dem FSR nicht komplett beschissen aussieht ist Diablo 4, weil es dank isometrischer Ansicht fast kein Disoclussion gibt.

Wobei es auch hier Ausnahmen gibt, Zaubereffekte die mit dem Untergrund geblendet werden führen auch hier zu grieseln, sind aber meistens schnell genug dass es nicht zusehr stört.
(das ist nicht direkt an dich gedacht, weil ich den Eindruck habe, dass du das alles viel besser weißt als ich - sondern eher an die Allgemeintheit :)):
Das Problem bei Disocclusion ist halt, dass es eine Daten aus vorherigen Frames gibt, die valide sind. Und dort "denkt" sich das NN bei DLSS konkludente Werte aus. Das ist ohne NN wirklich eine mehr als harte Nuss.

Die Zaubereffekte - sind meist problematisch. Aber ich hab auch schon von einer Implementierung gehört, wo es unproblematisch ist. Anscheinend muss man in der Renderpipeline irgendwas spezifisches bedenken, damit FSR dort sinnvoll greift.

Nichts offizielles bisher, aber FSR 2 ist wohl implementiert:

https://www.dsogaming.com/wp-content/uploads/2023/08/Starfield-PC-settings.jpeg
Immerhin FSR2. Aber wirklich schade, dass es offenbar kein FSR3 gibt. Wozu dann diese Partnerschaft, wenn das technologische Highlight auf AMDs 2023 Roadmap nicht implementiert wird? Ggf. wird es ja (wie FSR2 bei Deathloop) nachgeliefert.

[DrFreaK666]

...und der Realität ins Auge blicken würdest.

Naja. Hier im Forum wurde DLSS schon mal ein paar Mal als nicht besonders gut bezeichnet, oder z.B. bei JA3 laut CB. Da schneidet FSR besser ab, wenn ich mich nicht täusche

[aufkrawall]

Es geht aber nie so großflächig kaputt wie das bei FSR 2 leider oft der Fall ist. Das ist der springende Punkt.

[Exxtreme]

Genauso wie DLSS bei "falschem Content" auch beschissen aussieht?
Ich bin über die "logischen" Schlüsse und Aussagen einiger Nutzer immer wieder hellauf begeistert. :freak:
Nach dem Motto: Lasst und diskutieren, aber ich bin schon irgendwie dagegen. :confused:
Und wenn du mir nicht glaubst, habe ich immer dieses "Argument": "Der Andere ist einfach scheiße, weil, ist eben so." :rolleyes:
Passt schon. ;D

Naja, DLSS kann die typischen TAA-Artefakte etwas besser kaschieren als FSR. Ich bin aber auf FSR 3 gespannt. Eventuell kann AMD das auch ohne neurale Netzwerke.

Naja. Hier im Forum wurde DLSS schon mal ein paar Mal als nicht besonders gut bezeichnet, oder z.B. bei JA3 laut CB. Da schneidet FSR besser ab, wenn ich mich nicht täusche

Also mir gefällt bisher beides nicht wirklich. Ich finde DLSS zwar etwas besser als FSR. Aber gegen das gute alte MSAA kommen beide qualitativ nicht einmal ansatzweise ran. Dummerweise funktioniert MSAA in neueren Spielen oft nicht da die Engines auf das sog. "deferred rendering" setzen.

[aufkrawall]

Aber gegen das gute alte MSAA kommen beide qualitativ nicht einmal ansatzweise ran.
Wirklich grotesker Quatsch. Selbst mit PBS gibt es real zuhauf Shader-Aliasing, und da bringt MSAA rein null Komma nichts...
DLSS ist viel näher an SGSSAA als an MSAA...

[Gast]

Immerhin FSR2. Aber wirklich schade, dass es offenbar kein FSR3 gibt.


FSR3 Aká FG ist komplett uninteressant so lange man die Basisqualität des Upsamplings nicht in den Griff bekommt.

FG ist lediglich die "Cherry on Top" nachdem man mit Upsampling schon in zufriedenstellende Regionen vorgedrungen ist.

Wenn die Torte schon nicht schmeckt kann die Kirsche darauf auch nichts mehr retten.

[robbitop]

FSR3 Aká FG ist komplett uninteressant so lange man die Basisqualität des Upsamplings nicht in den Griff bekommt.

FG ist lediglich die "Cherry on Top" nachdem man mit Upsampling schon in zufriedenstellende Regionen vorgedrungen ist.

Wenn die Torte schon nicht schmeckt kann die Kirsche darauf auch nichts mehr retten.
Schwer zu sagen finde ich. Es gibt ja auch einen native mode. Oder für Ampere/Turing könnte man es mit DLSS2 kombinieren.

[Gast]

Also mir gefällt bisher beides nicht wirklich. Ich finde DLSS zwar etwas besser als FSR. Aber gegen das gute alte MSAA kommen beide qualitativ nicht einmal ansatzweise ran. Dummerweise funktioniert MSAA in neueren Spielen oft nicht da die Engines auf das sog. "deferred rendering" setzen.

Sorry, aber MSAA ist qualitativ nicht mal ansatzweise vergleichbar, temporales Aliasing wird damit kaum verringert, und das ist mit Abstand der störendste Teil beim Aliasing.

Realistischerweise ist man auch bei akzeptabler Performance auf 4-8 Samples pro Pixel limitiert, während TAA schon mal 30+ Samples akkumulieren and damit ein viel glatteres Ergebnis liefern kann.

[Lurtz]

Keine Ahnung was dieser MSAA-Quatsch immer soll. Selbst wenn es qualitativ noch relevant wäre, was es nicht ist, ist es schlichtweg im Großteil der Spiele nicht mehr nutzbar.

[robbitop]

Allerspätestens seit ids 8xTSSAA ist TAA absolut überlegen. Der Weg war ziemlich lang (IIRC angefangen mit den ersten TAA Versuchen in Crysis 2) bis TAA wirklich richtig gut wurde. Aber Stand der Technik ist TAA das beste was man machen kann. (sofern das Studio über ein gutes TAA verfügt - ich bin mir nicht sicher ob das auch heute für alle AAA Studios gilt)

[00-Schneider]

Allerspätestens seit ids 8xTSSAA ist TAA absolut überlegen. Der Weg war ziemlich lang (IIRC angefangen mit den ersten TAA Versuchen in Crysis 2) bis TAA wirklich richtig gut wurde. Aber Stand der Technik ist TAA das beste was man machen kann.


Das Problem an TAA ggü. (heute nicht mehr nutzbarem) MSAA oder SSAA ist, dass es das Bild leicht unschärfer macht. Dieser Effekt wird deutlicher, je niedriger die Auflösung ist.

Wirklich gut ist TAA daher meiner persönlichen Wahrnehmung nach nur in 4K. Da fällt der "Vaselinefilter" eher gering bzw. noch akzeptabel aus.

[robbitop]

Das Problem an TAA ggü. (heute nicht mehr nutzbarem) MSAA oder SSAA ist, dass es das Bild leicht unschärfer macht. Dieser Effekt wird deutlicher, je niedriger die Auflösung ist.

Wirklich gut ist TAA daher meiner persönlichen Wahrnehmung nach nur in 4K. Da fällt der "Vaselinefilter" eher gering bzw. noch akzeptabel aus.
Dafür gibt es ja mittlerweile exzellente Schärfefilter wie RCAS.
Allerdings muss man auch immer zwischen echter Unschärfe und subjektiver Schärfe.

Subjektive Schärfe (=hoher Kontrast) kann aber auch keine echte Schärfe sein. Man schaue auf eine Geometriekante ohne AA. Dann hat man scharfe Kontraste an den Treppchen.
Das ist aber Aliasing - hier fehlen Informationen. Eine ge-AAte - Kante ist unschärfer aber aus Informationssicht korrekter.

[Tesseract]

ja, da werden begriffe falsch verwendet. schärfe ist die unterscheidbarkeit von details. kein AA ist nicht scharf, es ist kontrastreich aber extrem unscharf weil die szene ungenau abgebildet wird. rendering funktioniert halt anders als optik wo der kontrast bei unschärfe abnimmt.

[Exxtreme]

Mit keinem AA bzw. MSAA ist das Bild allerdings zu scharf.

Nein, ist es nicht. Denn die Texturfilter sorgen für die exakte Schärfe. Zu scharf ist es dann wenn die Texturen in Bewegung flimmern und grieseln. Und das passiert beim korrekt eingestellten Lod-Bias nicht. Allenfalls Kanten sind zu scharf, aber nicht das gesamte Bild.

Und das ist halt der Wurm, der in den TAA-basierenden Antialiasing-Modi steckt. Die Texturen wirken extrem vermatscht wenn man das aktiviert. Man braucht also wieder einen Filter, der das Vermatschen nachträglich wieder so halbwegs korrigiert. Und ein Spiel, welches das sehr gut kann, ist mir noch nicht untergekommen.

[RoNsOn Xs]

Im Benchmark von FC5 kann man am Zaun sehr gut das flimmern ohne TAA sehen. Mit TAA schön glatt, aber eben auch sehr unscharf/weich. SotR mit der Vegetation ist ebenso ein gutes Beispiel. Ist aber interessant hier zu lesen. Bin wieder weg. :>

[robbitop]

Nein, ist es nicht. Denn die Texturfilter sorgen für die exakte Schärfe. Zu scharf ist es dann wenn die Texturen in Bewegung flimmern und grieseln. Und das passiert beim korrekt eingestellten Lod-Bias nicht. Allenfalls Kanten sind zu scharf, aber nicht das gesamte Bild.

Und das ist halt der Wurm, der in den TAA-basierenden Antialiasing-Modi steckt. Die Texturen wirken extrem vermatscht wenn man das aktiviert. Man braucht also wieder einen Filter, der das Vermatschen nachträglich wieder so halbwegs korrigiert. Und ein Spiel, welches das sehr gut kann, ist mir noch nicht untergekommen.

Schon RCAS probiert via reshade?

[Gast]

Nein, ist es nicht. Denn die Texturfilter sorgen für die exakte Schärfe.
Die Zeit in der Pixel ausschließlich Bi/Trilinear/Anisotrop gefilterte Texturen waren liegen schon lange in der Vergangenheit.

Zudem versagen Texturfilter bei Alphatests.

[Lehdro]

FSR3 Aká FG ist komplett uninteressant so lange man die Basisqualität des Upsamplings nicht in den Griff bekommt.

FG ist lediglich die "Cherry on Top" nachdem man mit Upsampling schon in zufriedenstellende Regionen vorgedrungen ist.

Wenn die Torte schon nicht schmeckt kann die Kirsche darauf auch nichts mehr retten.
Und wenn ich nur Kirschen essen will? Du kannst doch FG auch ohne DLSS Upsampling nutzen. Sollte bei FSR 3 (A)FMF genauso gehen.

[Gast]

Und wenn ich nur Kirschen essen will? Du kannst doch FG auch ohne DLSS Upsampling nutzen. Sollte bei FSR 3 (A)FMF genauso gehen.

Das ist schon eine extreme Nischenanwendung. Dass man in dem engen Fenster landet in dem FG sinnvoll ist landet ist schon recht unwahrscheinlich und fast immer upscaling notwendig um in diesem zu landen.

[Linmoum]

@Raff
@blaidd

Habt ihr schon Eindrücke zu FSR2? Ist das tatsächlich so bescheiden, wie es erste Berichte vermuten lassen?

[Lurtz]

There is no way to adjust its setting or internal resolution in a way that is clear to users as they toggle settings (ie no choice between "quality" "balanced" "performance" etc)https://www.resetera.com/threads/starfield-pc-performance-thread.759439/page-9#post-111319800

WTF?! Hat AMD jetzt endgültig den Verstand verloren?

[Oliver_M.D]

and there's really really bad shimmer and ghosting when using the default settings at 4K. I can't even imagine what this looks like on lower-resolution rigs that are using fewer pixels to upscale.
* Perf ain't great. This is a largely single-threaded game for some reason.
* Shadows range from appropriately rendered to N64 grade, depending on the type of object casting a shadow.Sehr geil;D

[Gast]

https://www.resetera.com/threads/starfield-pc-performance-thread.759439/page-9#post-111319800

WTF?! Hat AMD jetzt endgültig den Verstand verloren?

Wieso AMD? Die Entwickler dürfen doch machen was sie wollen.

[Achill]

https://www.resetera.com/threads/starfield-pc-performance-thread.759439/page-9#post-111319800

WTF?! Hat AMD jetzt endgültig den Verstand verloren?

Warum den schon wieder AMD und nicht Bethesda? Und warum in diesen Thread? Und btw geht es wohl, die Presets haben definierte Skalierung aber anscheinend geht es mittels Benutzerspezfischen Profil, dann gibt es den Slider für die Auflösung: https://youtu.be/fXG7gxVcVws?t=884 (Portugiesisches Video => Untertitel anmachen und in den YT Settings auf autom. Übersetzung ins Englische stellen, dann versteht man es einigermaßen)

[Linmoum]

So pompös, wie AMD die exklusive technische Partnerschaft auch anpreist bzw. angepriesen hat, würde ich schon erwarten, dass man penibel darauf achtet, wie die eigene Technologie im Spiel implementiert ist. Das ist kein Indie-Spiel, sondern für viele DAS Spiel des Jahres. Wirft wieder kein gutes Licht auf AMD und FSR(2).

Ich hoffe mal nicht für AMD, dass die Implementierung eines Modders von DLSS dafür sorgt, dass FSR2 hier qualitativ die Hosen runtergezogen werden. Die ersten Berichte zu FSR2 sind ja auch schon wieder alles andere als toll, gerade hier, wo Bethesda ja auch noch davon geschwärmt hat, dass sie lauter AMD Engineers haben, die hier mit optimieren. Wenn sowas dann schon unter "optimiert" fällt, dann ist das wahrlich kein gutes Zeichen.

[Exxtreme]

@Raff
@blaidd

Habt ihr schon Eindrücke zu FSR2? Ist das tatsächlich so bescheiden, wie es erste Berichte vermuten lassen?

Die sind bestimmt beim Haare färben weil diese alle grau geworden sind. X-D

Scheint aber ein Spiel zu sein, dem man 1 Jahr Reifezeit geben sollte.

[Taigatrommel]

Ich sehe es ähnlich, vor allem wenn man bedenkt, welche Aufmerksamkeit sowohl AMD als auch Bethesda wegen der DLSS / FSR Diskussion im Vorfeld bekommen haben. Sollten jetzt wirklich ein paar Modder binnen kurzer Zeit DLSS realisieren und dieses dann dem nativen FSR Support auch noch sichtbar überlegen sein, ist das alles andere als gute Werbung für die Technologie.

[robbitop]

https://www.resetera.com/threads/starfield-pc-performance-thread.759439/page-9#post-111319800

WTF?! Hat AMD jetzt endgültig den Verstand verloren?

Warum AMD? Die Settings bestimmt der Entwickler.

Am Ende hat AMD da nicht viel zu sagen. Aber andererseits hätte ich an AMDs Stelle klar die Erwartungen formuliert und würde sich das Studio dann nicht committen gäbe es keine Partnerschaft.

Das ist leider leider typisch AMD. Kommunikation und Qualitätssicherung von solchen Dingen. Man kann mangels Marktmacht nichts fordern aber entweder man macht es partnerschaftlich oder nicht.

Ich vermute mal man wollte einfach den Hype von Starfield mitnehmen und war dann froh als Bethesda ja gesagt hat.

[aufkrawall]

Warum AMD? Die Settings bestimmt der Entwickler.

Weil sich ein AMD-Entwickler auf YT hinstellt und besteste Zusammenarbeit bei der Implementierung von FSR 2 verspricht.

[Gast]

So pompös, wie AMD die exklusive technische Partnerschaft auch anpreist bzw. angepriesen hat, würde ich schon erwarten, dass man penibel darauf achtet, wie die eigene Technologie im Spiel implementiert ist. Das ist kein Indie-Spiel, sondern für viele DAS Spiel des Jahres.


Wohl eher die Enttäuschung des Jahres:
https://www.youtube.com/watch?v=3uuI-6fwwtY


Wirft wieder kein gutes Licht auf AMD und FSR(2).

Naja, das einzige was FSR2 in einem guten Licht erscheinen lässt, ist dem Spieler DLSS vorzuenthalten.

[The_Invisible]

9ABnU6Zo0uA

Jap, "we have AMD engineers in our Codebase working on FSR2..." würde mich interessieren was die dort gemacht haben :D

[DrFreaK666]

Wohl eher die Enttäuschung des Jahres:
https://www.youtube.com/watch?v=3uuI-6fwwtY...

Dein Cherrypicking hat mich überzeugt :ugly:
https://www.metacritic.com/game/pc/starfield

[TheAntitheist]

DF hat ein Video zu Starfield und das ghosting ist so extrem mit FSR... wir können jetzt endgültig sagen, dass das das beste ist, was FSR kann. Ich bezweifle das AMD nicht alles aus FSR rausholen kann. Ich könnte kotzen...

sieht man schön hier

https://youtu.be/LlStOHRI56o?si=V06_nNMZceBuVC66&t=397

[dildo4u]

Das ist für 30fps super diese Techniken arbeiten dort am schlechtesten.

[Gast]

Dein Cherrypicking hat mich überzeugt :ugly:
https://www.metacritic.com/game/pc/starfield

Du solltest vielleicht das Video zu Ende ansehen bevor du darüber herziehst.

Er sagt ja nicht, dass es ein schlechtes Spiel wäre, ganz im Gegenteil, es ist dennoch eine der großen Enttäuschungen weil es nicht einhält was es versprochen hat.

[Blediator16]

CB2077 launch relived

[DrFreaK666]

Du solltest vielleicht das Video zu Ende ansehen bevor du darüber herziehst.

Er sagt ja nicht, dass es ein schlechtes Spiel wäre, ganz im Gegenteil, es ist dennoch eine der großen Enttäuschungen weil es nicht einhält was es versprochen hat.

Mich interessiert sowas nicht. Mich interessiert das Status Quo. Hab mich im Vorfeld auch nicht großartig informiert.
Finde die "graphics downgraded"-Videos auch immer super peinlich

[vinacis_vivids]

N33 full vs AD104 salvage
https://abload.de/thumb/starfiled2023hwuuhd-unsfgs.png (https://abload.de/image.php?img=starfiled2023hwuuhd-unsfgs.png)

RX7600
~ 28fps@FSR2
~ 18fps@UHD
FSR2 +55%

RTX4070
~ 30fps@FSR2
~ 24fps@UHD
FSR2 +25%

Hier schlagen die 43,5/21,7 Tflops fp16/fp32 voll durch und die RX7600 erreicht mit etwas mehr als die hälfte der Bandbreite 288 GB/s die Leistung der RTX4070 mit 504 GB/s und 29,1 Tflops fp16/fp32.

[Linmoum]

Da schlägt nichts durch, eine 4090 beispielsweise dümpelt in Starfield teilweise nur bei 200W rum. Ist offensichtlich, warum die Performance bei Nvidia so ausfällt und hat nichts mit AMD zu tun und dass die Karten anders performen als sonst.

[dargo]

Da schlägt nichts durch, eine 4090 beispielsweise dümpelt in Starfield teilweise nur bei 200W rum. Ist offensichtlich, warum die Performance bei Nvidia so ausfällt und hat nichts mit AMD zu tun und dass die Karten anders performen als sonst.
Starfield pushes even the fastest GPUs to their limits (power limits, at least). The Radeon RX 7900 XTX consumes ~350W on average, with a peak of 468W. The GeForce RTX 4090 averages 410W with an upper limit of 435W. The RX 7900 XTX averages over 300W, while the RTX 3080 Ti comes in at just 350W.
https://www.hardwaretimes.com/amds-rx-7900-xtx-beats-the-nvidia-rtx-4090-in-starfield-despite-being-650-cheaper/

[redpanther]

Vielleicht ist mein 5800x zu lahm, aber meine 4090 ist dauernd voll ausgelastet und läuft selten über 300W.
Aber ich weiß auch nicht wo die da gemessen haben

[Wiseman]

https://www.hardwaretimes.com/amds-rx-7900-xtx-beats-the-nvidia-rtx-4090-in-starfield-despite-being-650-cheaper/

Danke für deinen Hinweis auf diesen Artikel von "hardwaretimes". Sehr aufschlussreich. :biggrin: Sowohl Überschrift als auch Fazit.

Überschrift:

AMD’s RX 7900 XTX Beats the NVIDIA RTX 4090 in Starfield Despite Being $650 Cheaper

Fazit:

Starfield pushes even the fastest GPUs to their limits (power limits, at least). The Radeon RX 7900 XTX consumes ~350W on average, with a peak of 468W. The GeForce RTX 4090 averages 410W with an upper limit of 435W.


Hardwaretimes schreibt, sie hätten im Startgebiet getestet. Ihre 7900XTX war sicher eine MBA XTX. Sobald ich in 2 Tagen loslegen kann, werde ich mit meiner Custom XTX auch mal im Startgebiet Performance und Wattverbrauch überprüfen und hier berichten. Wobei ich heute schon weiß, dass mein Wattverbrauch nicht höher als 312W sein kann, da PL -10%. Schade, wenn PL -20% oder mehr möglich wären, könnte ich den Wattverbrauch deutlich unter 300W bringen.

[Langlay]

https://www.hardwaretimes.com/amds-rx-7900-xtx-beats-the-nvidia-rtx-4090-in-starfield-despite-being-650-cheaper/

Kein Plan wo sie den Wert gemessen haben wollen, meine 4090 mit Stock Settings kommt kaum über 300W. Mit UV braucht mein ganzer PC so 300-340W an der Dose beim Starfield zocken.

Das ist die schlimmste Stelle die mir Stromverbrauchmässiguntergekommen ist.
Das sind Stock Settings.

https://abload.de/img/2023-09-0319_33_13-stziez6.png

[Monsta]

Ist Deine Cpu evtl. der Flaschenhals?


https://www.pcgameshardware.de/Starfield-Spiel-61756/Specials/cpu-benchmark-requirements-anforderungen-1428119/

[Linmoum]

Bei dem GPU Load ist das Problem nicht die CPU.

[The_Invisible]

Ist Deine Cpu evtl. der Flaschenhals?


https://www.pcgameshardware.de/Starfield-Spiel-61756/Specials/cpu-benchmark-requirements-anforderungen-1428119/

99% gpu load... schreiben aber auch im reddit einen haufen leute das sie einen niedrigen watt load haben, irgendwas läuft da noch nicht rund

[Troyan]

Ne, ist nicht CPU limitierend. Wahrscheinlich wird dort kein culling betrieben, wodurch die GPU Dinge rendern muss, die hinter dem Vordergrund sind. Das führt zu Blasen in der GPU Pipeline.

Ansonsten sieht das absolut miserabel aus: Kein GI, keine Schatten, nix. The Witcher 3 mit Raytracing läuft in 3440x1440 mit 60FPS auf einer 4090 im Wald...

[aufkrawall]

Das ist die schlimmste Stelle die mir Stromverbrauch untergekommen ist.

Das sieht so unfassbar zum Kotzen aus, da sind die FSR 2-Probleme im Grunde schon wieder egal. :freak:

[Langlay]

Das sieht so unfassbar zum Kotzen aus, da sind die FSR 2-Probleme im Grunde schon wieder egal. :freak:


Ich wurde im Starfield Thread noch belehrt ich müsse meine Erwartungen runterschrauben, als ich angemerkt hab das ich entgegen der Meinung von Computerbase und DF nicht der Meinung bin Starfield sähe überdurchschnittlich gut aus sondern doch eher maximal durchschnittlich.

[Tesseract]

Das sieht so unfassbar zum Kotzen aus, da sind die FSR 2-Probleme im Grunde schon wieder egal. :freak:

"das magische auge" vibes. :freak:

[Gast]

Ich wurde im Starfield Thread noch belehrt ich müsse meine Erwartungen runterschrauben, als ich angemerkt hab das ich entgegen der Meinung von Computerbase und DF nicht der Meinung bin Starfield sähe überdurchschnittlich gut aus sondern doch eher maximal durchschnittlich.

Das geniale ist ja, dass bei Immortals alle geschrien haben, dass es für die Performance nicht gut aussieht.

Jetzt läuft Starfield genauso lahm und ist dabei mindestens 10x hässlicher.

[DrFreaK666]

https://abload.de/img/starfield-amd-fsr-30cdon.jpg (https://abload.de/image.php?img=starfield-amd-fsr-30cdon.jpg)

AMD, her mit der SDK

[Platos]

Ist das DLSS Addon jetzt eig. kostenpflichtig?

[Wake]

Von PureDark gibts DLSS2 & XeSS gibts für lau auf Nexusmods (https://www.nexusmods.com/starfield/mods/111/), für DLSS3 mit FG wird aber Kohle auf Patreon verlangt (https://www.patreon.com/PureDark) (und wurde btw. schon gecrackt).

Alternativ gibts auch noch einen 2. Mod von einem anderen Dev (https://www.nexusmods.com/starfield/mods/196?tab=description) aber auch "nur" DLSS2 ohne FG.

[aufkrawall]

AMD, her mit der SDK
Da das den Kundenkreis extrem erhöht, kann er sich danach wohl zur Ruhe setzen. :eek:

[DrFreaK666]

AMD sollte ihn einstellen, denn er nimmt die Sache ernst

[aufkrawall]

Lieber nicht, sonst endet das so kläglich wie mit RadeonPro...

[Gast]

AMD sollte ihn einstellen, denn er nimmt die Sache ernst

Lieber NV, FSR-Substitution direkt im Treiber integriert.

[Lurtz]

Das geniale ist ja, dass bei Immortals alle geschrien haben, dass es für die Performance nicht gut aussieht.

Jetzt läuft Starfield genauso lahm und ist dabei mindestens 10x hässlicher.
Im Gegensatz zu Immortals of Irgendwas ist Starfield aber auch ein RPG und seit Ewigkeiten in Entwicklung.

Ich wills gar nicht zu sehr verteidigen, allein Dinge wie das kaputte HDR (und SDR), fehlende Helligkeit/Gamma-Option, die miserable deutsche Übersetzung, sind eigentlich bei so einem wichtigen Titel nicht zu entschuldigen.

Ich habe aber das Gefühl, dass sich die vokale PC-Spielerschaft in den letzten zwei, drei Jahren ziemlich reingesteigert hat. Da werden mittlerweile Spiele als hässlicher, inperformanter Crap abgestraft, da hätte man vor einiger Zeit nur mit den Schultern gezuckt. Vielleicht auch geschuldet der Tatsache, dass die Grafikkarten so teuer geworden sind und das wahrscheinlich umso mehr frustriert.

Aber man merkts ja jetzt auch bei Starfield, das Spiel wird von vielen Spielern als technisch veraltet empfunden und abgekanzelt, obwohl die meisten Reviewer die Grafik als überdurchschnittlich beschreiben. Wenn so ein Spiel einmal den Stempel hat, ist es schwer da wieder rauszukommen. Dabei spielen es die meisten (bisher) nicht mal selbst, sondern schnappen es in Foren, bei Reddit oder Youtube auf.
Dabei darf man nicht vergessen, dass das im Kern immer noch ein RPG ist, und ein verdammt großes auch noch, egal wie sehr man nun zu den prozeduralen Inhalten steht. Das sind jetzt selten die Titel, die in der Vergangenheit die Grafikmesslatte neu definiert haben.

Das ist irgendwie gerade ein komischer Zwiespalt. Die Ansprüche steigen und steigen, aber an ein RPG, das deutlich mehr als fünf Jahre in Entwicklung war, sind die zu einem guten Teil wohl auch einfach falsch angelegt... Dass die Performance dabei so schlecht ist, muss man wohl schon eher kritisieren.

[Gast]

Im Gegensatz zu Immortals of Irgendwas ist Starfield aber auch ein RPG und seit Ewigkeiten in Entwicklung.


Und RPGs sehen automatisch schlechter als FPS aus?

Muss ja deshalb kein schlechtes Spiel sein, die Grafik ist jetzt ja nicht so schlecht dass es einen sofort aus der Immersion rausreißt, wobei es auch spielerisch ziemliche Defizite hat, mit den ganzen leeren Umgebungen, und die haufenweise invisible walls gehen schon gar nicht, das stört imo viel mehr als die nicht herausragende aber immerhin zweckmäßige Grafik.

Qualität vor Quantität wäre da wohl angesagt gewesen, anstatt 1000 Planeten (was eigentlich nicht viel mehr als 1000 Städte sind) hätte man sich vielleicht auf 10 oder so konzentrieren sollen, und die dafür ordentlich ausbauen.

[Ex3cut3r]

Mir ein Rätsel wie man FSR irgendwas abgewinnen kann, eine Fail Tech durch und durch, kann nicht mal gegen eine 5 Minuten DLSS Mod von Person X standhalten.

ciOFwUBTs5s

https://abload.de/thumb/imageoid7o.png (https://abload.de/image.php?img=imageoid7o.png)

Und jetzt wird auch noch die Ray Rekonstruktion mit "3.5" immer mehr zum Vorschein kommen. AMD ist quasi 3 Gens zurück.

Und wollen für ihre GPUs immer noch verdammt viel Geld, warum zur Hölle sollte ich mir eine AMD Karte kaufen, um mit schlechter Bildqualität zu leben?

[boxleitnerb]

Selbst wenn AMD wieder mal einen "me too" Moment hat, ist es wahrscheinlich zu wenig und vor allem wieder mal zu spät. Offene Technologie nützt mir nichts, wenn sie solch schlechte Qualität hat. Da zahle ich lieber mehr und spiele mit Premium Qualität - dein Screenshot im vorigen Post ist wie Tag und Nacht. Wer soll sich das freiwillig geben, wenn es eine viel bessere Alternative gibt?

[Gast]

Mir ein Rätsel wie man FSR irgendwas abgewinnen kann, eine Fail Tech durch und durch, kann nicht mal gegen eine 5 Minuten DLSS Mod von Person X standhalten.

FSR flimmert in diesem Spiel sogar @100% wie die Hölle, da sieht TAA + CAS wesentlich besser aus.

[The_Invisible]

Ohne KI werden sie da halt nie aufholen können. Da AMD jetzt eh schon einige Features RDNA3 exklusiv macht könnte man in RDNA3 gleich die KI-Beschleuniger nutzen (ja weiß das keine vollwertigen sind, aber fp16 Leistung habens eh genug).

[ChaosTM]

Momentan hat NV eine Vorsprung bezüglich Entwicklung und natürlich Geld ..
Ob man bezüglich "AI" daraus einem Vorsprung erziehen kann ?

Nobody knows*

[Lurtz]

Auf der Konsole mögen sie es durchaus, da täuscht aber unter anderem auch Motion Blur über die Fails hinweg. Ändert nur nichts daran, dass DLSS Super Resolution FSR2 auf den ersten Blick massiv übertrifft.

[ChaosTM]

Auf der Konsole mögen sie es durchaus, da täuscht aber unter anderem auch Motion Blur über die Fails hinweg. Ändert nur nichts daran, dass DLSS Super Resolution FSR2 auf den ersten Blick massiv übertrifft.


Ich versuche das seit ein paar Wochen nachzuvollziehen..


meistens mit 77, FS2020 oder Witcher 3.


Der klare Gewinner ist immer natives 4k.
Bei Cp77 muss ich Upscaling einsetzen, sonst geht die Bildrate in den Keller

[Platos]

Da AMD jetzt eh schon einige Features RDNA3 exklusiv macht könnte man in RDNA3 gleich die KI-Beschleuniger nutzen (ja weiß das keine vollwertigen sind, aber fp16 Leistung habens eh genug).

Welche sind das?

[robbitop]

Driver FMF und Antilag+.

Ich finde die Bewertung von FSR2 ist eine Frage des Referenzpunktes.
„Totaler fail“ ist IMO polemisiert und übertrieben. FSR2 leistet bessere Ergebnisse als 99% der TAAs. Verglichen mit bisherigen Upsamplern war es sogar ein Fortschritt.
Und ob Mod oder nicht - das hat keinen Einfluss auf die (hervorragende Funktionsweise von DLSS).

Aber natürlich ist das bessere des guten Feind. Und mit den NN basierten Lösungen kann man ohne NN einfach nicht mehr mithalten.

Ich sehe es allerdings auch so. AMD sollte mal aufwachen und mehr als schlechtere, später kommende me2 Dinge abliefern.
Aber RTG ist nicht besonders gut gefundet - entsprechend hat man nur ein Bruchteil der Resources.

Allerdings kann man ja immerhin XeSS mit RDNA3 nutzen.

[aufkrawall]

Das Ghosting in Starfield ist schon wieder ziemlich übel. In Ratchet & Clank wurde auf 2.2 geupdatet und das Disocclusion-Geflimmer in Bäumen ist immer noch genau so hässlich. In zig Spielen mit UE Plug-In sieht es auch immer noch zum Kotzen aus.

Der größte Pluspunkt an FSR 2 ist für PC-Spieler mittlerweile im Grunde, dass man über generische Mods DLSS verwenden kann. Sonst wär in AMD-gesponserten Titeln womöglich nicht mal das drin. :eek:
Mag man jetzt gemein polemisch finden, aber für viele Spieler mit RTX-Karte wird das nun mal so sein...

[Redneck]

Driver FMF ist auch wirklich das einzige, was mich aktuell zu Rdna3 treiben könnte.. Finde ich echt spannend für VR mit den Produktionen kleinerer Studios , welche weder DLSS noch FSR bieten.
Aber bis das kommt.... Evtl hat NV schon vorher ihre Version davon gebracht.

[DrFreaK666]

No Man's Sky auf der Switch hat ein FSR2 Update erhalten. Trotz niedriger Auflösung ist der Qualitäts-Gewinn sichtbar

dR2fNkab5Vc

[Lurtz]

Ich versuche das seit ein paar Wochen nachzuvollziehen..


meistens mit 77, FS2020 oder Witcher 3.


Der klare Gewinner ist immer natives 4k.
Bei Cp77 muss ich Upscaling einsetzen, sonst geht die Bildrate in den Keller
In 1440p ist das nicht mal ein Wettbewerb. Da gewinnt DLSS eigentlich immer gegen TAA native.

Die Tage mal DLSS in Enderal SE reingemoddet, die Vegetation zB vermatscht mit TAA komplett und sieht schon mit DLSS Performance besser aus.

[crux2005]

Von PureDark gibts DLSS2 & XeSS gibts für lau auf Nexusmods (https://www.nexusmods.com/starfield/mods/111/), für DLSS3 mit FG wird aber Kohle auf Patreon verlangt (https://www.patreon.com/PureDark) (und wurde btw. schon gecrackt).

Alternativ gibts auch noch einen 2. Mod von einem anderen Dev (https://www.nexusmods.com/starfield/mods/196?tab=description) aber auch "nur" DLSS2 ohne FG.

Es gibt auch einen kostenlosen FG Mod: https://videocardz.com/newz/starfield-gets-dlss3-frame-generation-mod-and-its-free

[Platos]

In 1440p ist das nicht mal ein Wettbewerb. Da gewinnt DLSS eigentlich immer gegen TAA native.

Die Tage mal DLSS in Enderal SE reingemoddet, die Vegetation zB vermatscht mit TAA komplett und sieht schon mit DLSS Performance besser aus.

Ich denke er meint mit nativ nativ, also ohne jegliches AA.

[Gast]

Ich denke er meint mit nativ nativ, also ohne jegliches AA.

Ohne AA ist komplett unbrauchbar.

[robbitop]

Driver FMF ist auch wirklich das einzige, was mich aktuell zu Rdna3 treiben könnte.. Finde ich echt spannend für VR mit den Produktionen kleinerer Studios , welche weder DLSS noch FSR bieten.
Aber bis das kommt.... Evtl hat NV schon vorher ihre Version davon gebracht.
Für VR ist treiber FMF wahrscheinlich ungeeignet weil du ja niedrige Latenz brauchst. Das ist (so einigermaßen nur mit FSR3 und DLSS3 wegen der inherenten Latenzreduktion nutzbar). Aber auch dann brauchst du eine gewisse Grundframerate damit es sich gut anfühlt. Am Monitor spricht man von 60 fps bei einigermaßen schnellen Spielen. Kann mit vorstellen, dass bei VR nich kritischer ist.

Aber für VR gibts ja andere Techniken, die helfen wie das Rendern in niedriger Auflösung in abhängigkeit vom Fokuspunkt der Augen.
Oder dieses Verfahren was den Viewpoint schneller als die Framerate aktualisiert.

Wenn VR in Richtung >144Hz geht, fängt es an, dass Framegeneration Verfahren auch dort einen Mehrwert bieten weil die Latenz dann gut genug ist und die Imagepersistqnce verbessert wird -> mehr Bewegtschärfe ist eichtig in VR soweit ich weiß.

[Redneck]

Für VR ist treiber FMF wahrscheinlich ungeeignet weil du ja niedrige Latenz brauchst. Das ist (so einigermaßen nur mit FSR3 und DLSS3 wegen der inherenten Latenzreduktion nutzbar). Aber auch dann brauchst du eine gewisse Grundframerate damit es sich gut anfühlt. Am Monitor spricht man von 60 fps bei einigermaßen schnellen Spielen. Kann mit vorstellen, dass bei VR nich kritischer ist.

Aber für VR gibts ja andere Techniken, die helfen wie das Rendern in niedriger Auflösung in abhängigkeit vom Fokuspunkt der Augen.
Oder dieses Verfahren was den Viewpoint schneller als die Framerate aktualisiert.

Wenn VR in Richtung >144Hz geht, fängt es an, dass Framegeneration Verfahren auch dort einen Mehrwert bieten weil die Latenz dann gut genug ist und die Imagepersistqnce verbessert wird -> mehr Bewegtschärfe ist eichtig in VR soweit ich weiß.

Die 60 Fps min sollten bei den meisten Titeln kein Problem sein, da man ohnehin versucht 90 FPS und mehr zu erzielen.. Ein Grund, weshalb RT hier noch keine Rolle spielt und die Titel i.d.R. grafisch einfacher gestrickt sind.

[robbitop]

Ich sehe gerade moderne VR Brillen schaffen immerhin 120 Hz da beginnt Framegeneration IMO sinnvoll zu werden. Mehr wäre aber besser.

[Platos]

Ohne AA ist komplett unbrauchbar.

Es bietet das schärfste Bild. Darum gings (mir).

[Gast]

Für VR ist treiber FMF wahrscheinlich ungeeignet weil du ja niedrige Latenz brauchst.


Vor allem vollkommen unnotwendig. VR verwendet schon seit der ersten Oculus FrameGeneration.



Am Monitor spricht man von 60 fps bei einigermaßen schnellen Spielen. Kann mit vorstellen, dass bei VR nich kritischer ist.

Angeblich sind 90FPS für 95% ausreichend, wobei FPS hier missverständlich sind, entscheidend ist die Latenz, ein möglichst geringes Motion to Pixel Delay.


Aber für VR gibts ja andere Techniken, die helfen wie das Rendern in niedriger Auflösung in abhängigkeit vom Fokuspunkt der Augen.


Damit das gut funktioniert braucht es aber eye tracking, was kaum ein headset unterstützt.



Wenn VR in Richtung >144Hz geht, fängt es an, dass Framegeneration Verfahren auch dort einen Mehrwert bieten weil die Latenz dann gut genug ist und die Imagepersistqnce verbessert wird -> mehr Bewegtschärfe ist eichtig in VR soweit ich weiß.

Weshalb alle VR Displays low persistence sind, höhere FPS bringen hier kaum Bewegtschärfe sondern, verringert „nur“ das Flimmern, natürlich nur wenn das VR-Display auch entsprechende refresh rate bietet.

[Gast]

Es bietet das schärfste Bild. Darum gings (mir).

Aliasing ist keine Schärfe.

[robbitop]

Auf der PS5 soll das mit dem Fokus und der adaptiven Auflösungsredujtion laut Reviews schon sehr gut.

[Gast]

Auf der PS5 soll das mit dem Fokus und der adaptiven Auflösungsredujtion laut Reviews schon sehr gut.

Ist auch eines der wenigen Headsets, welches Eyetracking unterstützt.

Das andere ist die Quest Pro, aber viel mehr fällt mir jetzt nicht ein.
Und das Problem ist natürlich wenn es kaum Hardware mit Eyetracking-Unterstützung gibt, gibt es natürlich auch keine Software die das auch implementiert.

[robbitop]

Nicht unwahrscheinlich jetzt wo Sony das gemacht hat, dass es andere in den next gen Brillen auch umsetzen. Das wird schon. :up: Dafür ist der Vorteil einfach zu gut um ihn entgehen zu lassen

[Gast]

Nicht unwahrscheinlich jetzt wo Sony das gemacht hat, dass es andere in den next gen Brillen auch umsetzen. Das wird schon. :up: Dafür ist der Vorteil einfach zu gut um ihn entgehen zu lassen

So neu ist die Erkenntnis jetzt auch nicht, und trotzdem setzt es kaum jemand um. Auch die Quest 3 wird kein Eye-Tracking bieten, obwohl Meta ja offensichtlich die Technologie hat, und schon die Quest 2 (statisches) foveatet Rendering unterstützt.

Und die wenigen Headsets die es haben sind alle in einer sehr hohen Preisklasse angesiedelt, selbst PSVR2 eigentlich ziemlich teuer, wenn man bedenkt, dass Sony das Geld mit der Software macht.

[perforierer]

FSR flimmert in diesem Spiel sogar @100% wie die Hölle, da sieht TAA + CAS wesentlich besser aus.

So spiele ich es auch. An sich Nativ, aber mit Schärfung. Letzteres braucht man. Sonst ist das Bild zu verwaschen.

In bestimmten Bereichen hat Starfield wirklich prima Grafik. Es gibt aber halt auch Stellen, die enorm abfallen...

[vinacis_vivids]

Dead Space RT@UHD@FSR2 in "Perfektion"
_PMFtNVYpK4

[DrFreaK666]

Mit 3rd Party Treibern kann man HYPR-RX wohl auf älteren Karten aktivieren. Sollte es problemlos funktionieren, dann gibt es keinen Grund (außer Verkaufspolitik) für AMD, es in einem zukünftigen Treiber freizuschalten

E1kX6f-mzsU

[Oliver_M.D]

Die Frage ist, ob es auch gescheit funktioniert.
Ich hab den Treiber vor 1-2 wochen ausprobiert, um "AMDs Shadowplay" auf meiner APU nutzen zu können.
Leider war das feature voller fehler und glitches, daher komplett nutzlos für mich:freak:

[DrFreaK666]

Anti-Lag+ Test

Ut4y97xu0NM

[HOT]

Sind schon heftige Unterschiede vor allem im Gefühl. Galgenhügel voll RT an, FSR Quality
- kein Anti Lag ca. 45ms
- Anti Lag ca. 25ms
- Anti Lag+ ca. 13ms
Mit Intel PresentMon gemessen
Anti Lag+ fühlt sich extrem flüssig an, ist kein Vergleich ohne.

[DrFreaK666]

Gute Voraussetzungen für FSR3

[Gast]

Gute Voraussetzungen für FSR3
Er zeigt doch das die frametimes dadurch schlechter werden, eher schlechte Voraussetzung würde ich sagen. zumindest mit Antilag+ werden sie schlechter

[Lurtz]

Anti Lag+ fühlt sich extrem flüssig an, ist kein Vergleich ohne.
Umso mieser dass es nicht für RDNA2 (und vorher) verfügbar ist.

[vinacis_vivids]

FSR3 ist wohl geiler als DLSS3, welches Input-Lag verursacht.

[Platos]

Muss das implementiert werden oder kann man es per Treiber erzwingen ?

[vinacis_vivids]

https://gpuopen.com/fsr3-announce/

"Performance is key. FSR 3 includes a highly-optimized optical flow technology, written in pure HLSL, which when combined with our Frame Interpolation pass allows us to generate a new 4K frame in less time than some upscale technologies. These workloads run in asynchronous compute as to not impact the main game render pipeline."

FSR3 läuft über HLSL (wahrscheinlich fp16) mit Asynchronous-Compute und macht keine Eingriffe in die eigentliche Redering-Pipeline. Deshalb ist FSR3 + Frame Generation auch "smooth".

Die FSR3-Technik ist somit dem DLSS3 deutlich überlegen.


GCN ist leider raus bei FSR3, erst ab RDNA verfügbar (bspw. RX 5700XT) inkl. Frame Generation.

[Exxtreme]

Naja, mal schauen wie die Bildqualität von FSR3 so wird. Hat das die typischen TAA-Probleme dann ist das nur sehr begrenzt zu gebrauchen.

[vinacis_vivids]

Du musst mal lesen:
https://gpuopen.com/fsr3-announce/

Lies nochmal und komm dann wieder.

[Exxtreme]

Das ist Marketing-Blabla. Mir ist wichtig was am Ende hinten rauskommt.

[DrFreaK666]

Das ist Marketing-Blabla. Mir ist wichtig was am Ende hinten rauskommt.

So isses. Und ich geh davon aus, dass es schlechter wird als DLSS3.

[horn 12]

Hoffe es kommt mal ein AMD - Werbe Video
oder wird AMD bis zum 30-ten September abwarten :-(

[DrFreaK666]

Vielleicht wird aus "early fall" "late fall"

[aufkrawall]

Habe TSR in Immortals of Aveum zum Laufen gekriegt
AppData\Local\P3\Saved\Config\Windows
engine.ini
[ConsoleVariables]
r.AntiAliasingMethod=4
r.ScreenPercentage.MaxResolution=960
(Die relative Variante r.ScreenPercentage wird ignoriert.)

GameUserSettings.ini
[ScalabilityGroups]
sg.AntiAliasingQuality=2
2 = high
3 = epic
4 = cinematic

und es sieht viel besser aus als FSR 2. Viel weniger Jittering auf Geometrie etc. und viel weniger Disocclusion-Aliasing, etwa auch hinter semitransparentem Nebel. :freak:

[robbitop]

Wie macht sich TSR „cinematic“ in Bezug auf Kosten und BQ vs Epic hnd high? Bringt das noch was?

Auf jeden Fall interessant, dass es ohne NN noch ordentlich Potenzial zu geben scheint.
Allerdings scheint es doch (ich hatte es mal vor ein paar Monaten in Fortnite getestet) relativ zu FSR2 relativ teuer zu sein. Ggf ähnlich teuer wie XeSS dp4a?

[Gast]

Sollte FSR3 nicht im September kommen, lange ist der Monat ja nicht mehr?

[Gast]

Auf jeden Fall interessant, dass es ohne NN noch ordentlich Potenzial zu geben scheint.

Es gibt keinerlei technische Gründe, warum es NN dafür benötigt.

[Gast]

Er zeigt doch das die frametimes dadurch schlechter werden, eher schlechte Voraussetzung würde ich sagen. zumindest mit Antilag+ werden sie schlechter

Die 2 Anforderungen stehen diametral gegenüber.
Wenn du jedes fertige Frame so schnell wie möglich an den Monitor bringst, kommen zwangsweise auch Unterschiede in den Frametimes 1:1 zum Monitor.
Wenn du die Frameausgabe verzögerst, kannst du auch für eine gleichmäßigere Ausgabe sorgen.

Wobei schwankende Frametimes kein großes Problem sind, sofern die längsten Frametimes immer noch kurz genug sind, und eine gleichmäßige Frameausgabe noch lange kein "smoothes" Ergebnis garantiert.
Nur weil die Frameausgabe gleichmäßig ist heißt es noch lange nicht, dass der virtuelle Zeitpunkt der berechneten Frames auch zur Ausgabe passt.

[aufkrawall]

Auf 3/Epic läuft es hier an der getesteten Stelle ca. 2-3% langsamer als FSR 2. Tippe, die TSR-Einstellungen für die Stufen sind nicht zu denen von Fortnite vergleichbar. Erst ab 4/Cinematic wird es in Aveum viel schärfer, aber nicht viel teurer und mit schlechter Bildruhe vs. 3 oder Epic in Fortnite.

[Gast]

Auf 3/Epic läuft es hier an der getesteten Stelle ca. 2-3% langsamer als FSR 2.


Interessant laut den Entwicklern von Immortals war die Entscheidung Pro-FSR und gegen TSR ja die Performance.

[Troyan]

Spielt mal "The First Descendant" mit FSR 2.2. Mir kommt es so langsam vor, dass das mit UE5 (und Nanite) nicht sauber funktioniert. Ist richtig übel. So übel, dass es eigentlich komplett nutzlos ist.

[vinacis_vivids]

The First Descendant ROG ALLY | FSR 2.2
RSzzhur7NdE

[Gast]

The First Descendant ROG ALLY | FSR 2.2
https://youtu.be/RSzzhur7NdE

Amazing, dass FSR auf einem Minidisplay, dass noch dazu abgefilmt wurde dermaßen beschissen aussehen kann.

[DrFreaK666]

Was erwartest du bei 720p?
Immerhin ist das spielbar

[Exxtreme]

Amazing, dass FSR auf einem Minidisplay, dass noch dazu abgefilmt wurde dermaßen beschissen aussehen kann.

FSR ist halt grundsätzlich TAA mit so ziemlich allen Stärken und Schwächen davon. Und TAA ist neben FXAA und Quincunx so ziemlich die schlechteste AA-Implementierung. Viel mehr sollte man nicht wirklich erwarten.

[DrFreaK666]

FSR ist halt grundsätzlich TAA mit so ziemlich allen Stärken und Schwächen davon. Und TAA ist neben FXAA und Quincunx so ziemlich die schlechteste AA-Implementierung. Viel mehr sollte man nicht wirklich erwarten.

Du stellst Quincunx (also ein Blurfilter) und TAA auf eine Stufe? :ugly:
Sogar FXAA ist deutlich besser als Quincunx

[Exxtreme]

Ja, ist auf einer Stufe. Quincunx ist anders schlecht als TAA. Und das ist anders schlecht als FXAA. :) Keins davon ist gut. Und FSR ist ein aggressives TAA mit einem Upscaler drin. Deshalb hat es so ziemlich die gleichen Schwächen wie TAA. Es ist zwar besser was Bildschärfe angeht, dafür aber wirkt das Bild ausgefranster und unruhiger.

Ich muss mir mal echt nen Spiel besorgen, welches auch Xess hat und man das auf einer NV-Karte testen kann. Mal schauen wie das Ding so ausschaut.

[DrFreaK666]

Du laberst Müll und hast wohl vergessen wie Quincunx funktioniert
https://alt.3dcenter.org/artikel/anti-aliasing/index11.php

[Exxtreme]

Ich weiss wie Quincunx funktioniert. :rolleyes: Das macht TAA und FXAA trotzdem nicht besser.

[aufkrawall]

Ich muss mir mal echt nen Spiel besorgen, welches auch Xess hat und man das auf einer NV-Karte testen kann. Mal schauen wie das Ding so ausschaut.
Bei unverdeckter Geometrie oder Alphatests kann FSR 2 besser sein, das Gras in Witcher 3 schmeckt XeSS DP4a nicht sonderlich gut. Dafür ist es allerdings viel gleichmäßiger, mit entsprechend viel besser geglätteten Effekten als FSR 2 (und auch als TSR, das prinzipiell die gleichen Schwächen wie FSR 2 mit Effekten und Disocclusion hat, nur nicht so arg dumm verkackt).

[DrFreaK666]

Ich weiss wie Quincunx funktioniert. :rolleyes: Das macht TAA und FXAA trotzdem nicht besser.

Sorry, kann dich nicht ernst nehmen :lol:
Quincunx wäre wahrscheinlich scheiße, wenn es von AMD wäre...
Blurfilter von 2002 besser als TAA. Blödsinn, besonders in Bewegung

[Deisi]

Diese Anti TAA Posts nerven echt langsam. Bitte mal in 2023 ankommen und nicht immer noch dauernd über MSAA oder gar FXAA schreiben.

[Gast]

Ich weiss wie Quincunx funktioniert. :rolleyes: Das macht TAA und FXAA trotzdem nicht besser.

Dann weißt du anscheinend nicht wie TAA funktionier, ansonsten könntest du das niemals als „gleich schlecht“ bezeichnen (bei FXAA würde ich ja noch mitgehen)

Quincux ist von der Grundidee eigentlich sogar genial, das Problem ist dass es MSAA als basis nimmt. Quincux mit SSAA alls Basis wäre sogar ein richtig brauchbarer Kompromiss aus Performance und Qualität

[Gast]

Was erwartest du bei 720p?
Immerhin ist das spielbar

DLSS sieht dermaßen viel besser aus. Ich hab das selbst mit einem Steamdeck und In-house Streaming von einem GeForce-Rechner ausprobiert, und DLSS ist bei dem kleinen Screen auch auf geringen Auflösungen richtig brauchbar.

[Thunder99]

Gibt es eigentlich Pläne Ray Reconstruction zu realisieren wie Nvidia? Oder ist da AMD noch meilenweit weg was vergleichbares anzubieten?

[dargo]

Wofür? Um noch mehr Grafikfehler zu generieren? :freak:
https://www.forum-3dcenter.org/vbulletin/showpost.php?p=13402697&postcount=7576

Diese ganzen Technologien werden langsam absurd. Zumindest im aktuellen Zustand.

[The_Invisible]

Wofür? Um noch mehr Grafikfehler zu generieren? :freak:
https://www.forum-3dcenter.org/vbulletin/showpost.php?p=13402697&postcount=7576

Diese ganzen Technologien werden langsam absurd. Zumindest im aktuellen Zustand.

Stimmt, AMD schaffts ja nicht mal mit normalen Algorithmen keine Grafikfehler zu produzieren... und wo ist eigentlich das superduper FSR3?

Zu denken das in Zukunft alles nur mehr mit BruteForce geht ist absurd, sonst nichts...

[dargo]

Zu denken das in Zukunft alles nur mehr mit BruteForce geht ist absurd, sonst nichts...
Comedy pur... denn nichts anderes betreibt Nvidia mit dem Lederjacken-Raytracing-Modus in bsw. CP77. :lol: