News FidelityFX Super Resolution 2.2: AMD veröffentlicht Quellcode der neuesten FSR-Version

Taxxor schrieb:
Es ging bei FSR 1.0, es ging bei FSR 2.0, es ging bei FSR 2.1, nue bei 2.2 soll das plötzlich anders sein?

Lies doch nochmal meinen Text. Ich glaub du verstehst nicht wie so eine Entwicklung läuft, oder, was ich eher glaube, du willst einfach irgendwas hören mit "Die haben sich gegen die Kundschaft und Entwickler verschworen und setzen alles daran, alle immer nur zu enttäuschen".

Such dir aus was für dich das richtige ist :)
 
pvcf schrieb:
Ich glaub du verstehst nicht wie so eine Entwicklung läuft
Na dann erkläre mir doch wo der "Feldeinsatz", ohne den es nicht geht, bei den vorherigen FSR Versionen war, wo es über 3 Monate in einem auf dem Markt verfügbaren Spiel benutzbar ist, bevor es auf Github zur Verfügung gestellt wurde.

AMD hätte bei F1 auch direkt sagen können, deaktiviert die Funktion bis wir das in den Griff bekommen haben
 
DrFreaK666 schrieb:
War das allgemein oder wegen FSR?
Eher allgemein im Bezug auf AMDs Bemühungen in Sachen Open Source und den Support für Linux.

Auch wenn ich kein Freund dieses mitunter albernen alljährlichen „das Jahr des Linux-Desktops“ bin, könnten sich AMDs Bemühungen in dem Bereich mittelfristig auszahlen.

In Sachen Single Player kann man bereits jetzt fast alles unter Linux spielen, in Sachen Multiplayer, Kopierschutz und Anti Cheat Engines dürfte Linux in den nächsten 2 Jahren auch aufschließen können.

Windows muss ja gar nicht abgelöst werden, sondern soll nur eine vollwertige Alternative erhalten.

Bei meiner letzten Stichprobe mit rund 30 Spielen auf dem Steam Deck und einem AMD-Desktop lief bereits alles.
 
  • Gefällt mir
Reaktionen: danyundsahne, al13n, Schäfchen und 4 andere
Na hoffentlich mit baldigen Fortschritten. FSR hat einfach keine Chance aktuell vs DLSS, auch TAA flimmert im Vergleich.

 
Keine Ahnung was du bei dieser komprimierten brühe zu erkennen glaubst.
Vielleicht muss man dafür eine grüne Brille aufsetzen, hab hier leider nur eine Rote rum liegen.
 
  • Gefällt mir
Reaktionen: Epistolarius, Czk666, HierGibtsNichts und 3 andere
Samuelz schrieb:
FSR und TAA flimmern.
Ja, die Unterschiede in der Bildruhe sind eigentlich unübersehbar. Zusätzlich werden bei DLSS die dünnen Zweige besser und ruhiger dargestellt.
 
  • Gefällt mir
Reaktionen: Samuelz
Gewuerzwiesel schrieb:
Äpfel und Birnen sollte man nicht vergleichen
Warum nicht? Wenn ich vor einem Obstkorb mit Äpfel und Birnen stehe, und Lust auf nen Snack habe, dann vergleiche ich sie. Ob nun bewusst oder unbewusst.

Gewuerzwiesel schrieb:
klar garantiert eine große Testcoverage nicht gute Softwarequalität, tendenziell wird die Software aber durchaus besser und macht auch die Pflege viel einfacher.
Niemand hat gesagt, dass das Eine durch das Andere ersetzbar ist. Aber es gab doch einen Witz, wo einer im Kontext "a dude comes into a bar" alle möglichen Variationen getestet hat, der echte User aber plötzlich nach ner Toilette fragt, und der Barman ne Exception wirft.

Ich bin selbst Entwickler und weiß, wie ranzig es ist, wenn man den Tests nicht vertrauen kann; Bei Produkten, die auf massiv heterogenen Systemen laufen, ist eine nennenswerte Testabdeckung aber de facto nicht möglich. Und das betrifft FSR.

Und da sind ein paar Monate Betrieb deutlich zuverlässiger als tausend Tests, die sich ein Programmierer beim Entwickeln ausgedacht hat; Diese werden dadurch aber nicht obsolet. ;)
 
  • Gefällt mir
Reaktionen: ComputerJunge und pvcf
T-Horsten schrieb:
Keine Ahnung was du bei dieser komprimierten brühe zu erkennen glaubst.
Man sieht doch wohl deutlich wie die Bäume mit FSR und TAA flimmern und mit DLSS nicht.

Hier könnte die neue FSR 2.2 dll eventuell helfen
 
  • Gefällt mir
Reaktionen: Samuelz
CDLABSRadonP... schrieb:
Lies nochmal das ursprüngliche Posting:

Es ging nur um AMD als eine Firma, die ein OpenSource-Projekt verwaltet. Um nichts spezifisches mehr. Klare Angelegenheit!

Ist mir schon klar, worum es dir ging. Finde ich grundsätzlich auch legitim. Lediglich deine Formulierungen wirken sehr negativ konnotiert (dein Anspruch, die Vergleiche).

Bleibt die Frage, ob deine Ansprüche und Vergleiche in diesem Kontext überhaupt passend sind, da es sich hier eben nicht nur handelt "um AMD als eine Firma, die ein OpenSource-Projekt verwaltet".

Das ist kein "Opensource Projekt". AMD als Hardwareentwickler hat eine GPU Technologie entwickelt und entschieden diese zu veröffentlichen, wovon alle nur profitieren können. Zum Dank geht das jedoch nicht schnell/gut/passend genug.

Entsprechend wüsste ich nicht, wer eine ähnliche/gleiche Technologie schnell/gut/passend entwickelt und veröffentlicht hat. Nvidia, Intel, Microsoft, Google?

Opensource Projekte gibt es grundsätzlich viele, da gebe ich dir recht. Aber wir sind hier im "Forum -> Grafikkarten -> Grafikkarten: Fachgespräche". Also wird selbstverständlich mit anderen Hardwareentwicklern verglichen und nicht mit Äpfel/Birnen. Wie du siehst, geht es nur dir "um Quelltextveröffentlichung und nichts weiter".
 
Zuletzt bearbeitet:
Taxxor schrieb:
Na dann erkläre mir doch wo der "Feldeinsatz", ohne den es nicht geht, bei den vorherigen FSR Versionen war, wo es über 3 Monate in einem auf dem Markt verfügbaren Spiel benutzbar ist, bevor es auf Github zur Verfügung gestellt wurde.

AMD hätte bei F1 auch direkt sagen können, deaktiviert die Funktion bis wir das in den Griff bekommen haben

Ich arbeite weder im AMD FSR2.x Treiberteam noch in allen Spielenginestudios, ansonnsten würd ich dir natürlich sagen, woran es lag :)
Ich hab dir lediglich aufgezeigt, wie es hinter den Kulissen läuft, und was da alles mit dranhängt, was man von aussen nicht sieht.

was viele nicht Wissen, die Treiberteam größe:
Intel: 2 (ja, 2 Mann, für Windows, Linux, Laptop IGPU, alle DX versionen und alle Spieleengines)
AMD: ~20 (war das letzte was ich da mal hörte)
NVIDIA: ~200 (war das letzte was ich da mal hörte)

und ich würde wetten, bei den DLSS und FSR Teams siten jeweils maximal 2-3 Leute, wenn überhaupt, vielleicht auch nur 1 oder 2, die diese Schwarzmagie ernsthaft Beherrschen und den Kompletten Treibercode ihrer Architektur UND die Hardware kennen und damit wissen, wie man sowas angeht.
Wenn da mal einer Krank wird, oder Family oder Urlaub oder oder oder oder oder ...

aber klar: Keule rausholen und draufschlagen, wenn es nicht sofort perfekt überall funktioniert.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Czk666
DocWindows schrieb:
du weißt aber schon dass besagte Firma über 300 Source Code Repositories auf Github bereitstellt?

Ohja. Nvidias großartige Git repos ...
Absolut beschissen dokumentiert, lückenhaft und mit schöner Regelmäßigkeit verschwinden Repos um klamheimlich noch mehr Geld zu scheffeln.

Beispiel? Ansel. Nvidia hat nicht den Source veröffentlicht, aber immerhin eine API und die passende Ansel DLL. Eines Tages von jetzt auf gleich gekillt. Seitdem ist Ansel (und Freestyle) direkt im Treiber integriert. Mit einer Whitelist. Eintragung muss bei Nvidia natürlich beantragt werden. Viel Glück das zu schaffen als kleiner Hobbyentwickler oder Indiestudio.
Eine Weile lang konnte man diese Whitelist mit einem 3rd Party Tool bearbeiten. Nope, geht auch nicht mehr.

Und die alte Implementierung falls man das Repo geforkt hat? Funzt nicht mehr. Wurde auch deaktiviert.
 
  • Gefällt mir
Reaktionen: Epistolarius, InvalidTexture, Czk666 und 3 andere
Bright0001 schrieb:
Warum nicht? Wenn ich vor einem Obstkorb mit Äpfel und Birnen stehe, und Lust auf nen Snack habe, dann vergleiche ich sie. Ob nun bewusst oder unbewusst.
Das ist dann aber eine subjektive Entscheidung zwischen zwei objektiv guten Möglichkeiten. Wenn Äpfel und Birnen frisch und reif sind, isst du morgens den Apfel und abends die Birne und beides ist eine legitime Wahl. Der Apfel ersetzt die Birne nicht und umgekehrt.

Bei dem Spruch geht es aber darum zu sagen "Ich habe Lust auf den Geschmack einer Birne" dann aber einen Apfel zu essen und im Anschluss zu sagen "Der Apfel schmeckt mir nicht genug nach Birne."
Überraschung!

Man soll Sachen auch nur dann vergleichen, wenn prinzipiell gleich sein wollen bzw den exakt gleichen Zweck erfüllen sollen.
 
Taxxor schrieb:
Man sieht doch wohl deutlich wie die Bäume mit FSR und TAA flimmern und mit DLSS nicht.

Hier könnte die neue FSR 2.2 dll eventuell helfen
Er sagt es ja selber. Er hat eine rote Brille auf. Man sieht es halt wohl doch, will es aber nicht wahrhaben. ;)
 
Eine sehr gute und ueberfaellige Entwicklung, die Oeffnung von FSR 2, so dass dadurch natuerlich mehr Entwickler ermutigt werden darauf zu zu greifen und das wiederum die AMD/RTG Grafikkarten attraktiver und langlebiger werden laesst.

SVΞN schrieb:
RX 7800 (XT) und RX 7700 (XT) zu einem guten Kurs, ein noch stärkerer Fokus auf Open Source und Linux sowie eine noch bessere Effizienz, darauf sollte AMD abzielen.
Ja, das waere ein guter Ansatz (zumal wegen der Zertifizierung bei der RRA in Suedkorea es auch nicht mehr lange dauern duerfte bis die naechsten RDNA 3 Karten auf den Markt kommen), aber weiter an HYPR-RX und FSR 3 (als Pendants zu nVidias Reflex und DLSS3/FG) zu arbeiten/optimieren, ist natuerlich wichtig um den Anschluss nicht zu verlieren.

Inwieweit RDNA 4 dann eine zu erwartende Architektur-Korrektur/Verbesserung (bzgl. des Chiplet-Designs, so dass die vorher antizipierte Leistungssteigerung auch komplett auf die Strasse gebracht wird) und erstmals dedizierte A.I./RT-RT-Kerne oder -Einheiten eingefuehrt werden von AMD/RTG, bleibt abzuwarten (ich rechne mit letzteren erst bei RDNA 5, wuerde mich aber gerne irren, und es haengt auch davon ab, wie ambitioniert man die Architektur modifizieren wird und wie weit man entwicklungstechnisch bei AMD/RTG mit den vorhandenen Ressourcen kommt).

Oops, gerade darueber gestolpert, dass man bei AMD/RTG das schon fuer RDNA 4 beherzigt hat mit den A.I. Beschleunigern :).

W0dan schrieb:
ber das zeigt mal wieder, wie gut es ist, wenn es Konkurrenz gibt. Sowohl AMD als auch Nvidia arbeiten kontinuierlich und mit relativ häufigen Updates an Verbesserungen.

Intel nicht vergessen, die haben sich in den letzten Wochen auch gemausert mit den neuen Treiberupdates und Preissenkungen bei den Alchemist Erstgenerations-Gaming-dGPUs, so dass die A750 Karten mittlerweile sogar eine bessere Alternative (gemessen an Preis-Leistung) zu einer RTX 3060 darstellen.

Besonders bei Intel hoffe ich, dass diese am Ball bleiben, denn es braucht einen dritten Mitstreiter im Grafikkartenentwicklermarkt, sonst wird der Keil - der von nVidia produkt- und preistechnisch zwischen Einsteiger- und High-End-/Enthusiastenkartenklassen getrieben wird - immer groesser und da braucht es Intel und AMD/RTG um weiterhin faire Einsteiger- und Mittelklasse-Grafikkarten zu entwickeln.

Dann duerften auch weniger (bewusst) speicher-(interface-)unterbestueckte Grafikkarten zu neuen Hoechstpreisen in dem Bereich von nVidia (mit Pseudo-RT-RT-Marketing, fuer welche die Karten sowieso zu schwach sind und/oder am Speicher verhungern, zumal RT-RT in Full-HD im Zusammenspiel mit Upscaling-Techniken eher wenig bringt) abgesetzt werden/den Markt dominieren (zumindest besteht die Hoffnung).
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: SVΞN
SVΞN schrieb:
RX 7800 (XT) und RX 7700 (XT) zu einem guten Kurs, ein noch stärkerer Fokus auf Open Source und Linux sowie eine noch bessere Effizienz, darauf sollte AMD abzielen.

Was wäre denn für dich ein guter Kurs für eine 7800XT? Realistisch sehe ich sie in der Performance ca gleichauf mit ner 6950XT und damit ~15% über ihrem Namensvorgänger der 6800XT. Dort wird auch eine 4070 ungefähr sitzen und da gehe ich nicht von unter 700€ aus.

Ich kann mir auch nicht vorstellen, dass man in dieser Generation noch bei der Effizienz punkten können wird, das wird eher ein Thema für RDNA4 sein.
 
SVΞN schrieb:
In Sachen Single Player kann man bereits jetzt fast alles unter Linux spielen, in Sachen Multiplayer,

Solange man die alte Generation vom AMD 6xxx nutzt mag das stimmt. Mit der 7900XTX habe ich nur Probleme, ich war ewig auf Archlinux. Aber im Moment ist es leider einfach nur unbenutzbar. Habe damals die Karte eingebaut und das Linux wollte nicht mal booten. Dann musste man sich im Netze Workarounds suchen damit das System wieder läuft.

Beim neuinstallation fehlt die Maus(Softwaremaus einschalten in Xorg11), gut kann man fixen. Aber ätzend ist es trotzdem. Warum so ein Mist? War davor nie ein Problem.

Dann geht Adaptivsync nicht, auch wenn man das einschaltet und es im Log angezeigt wird...was für ein rotzt wenn man sich nicht mal auf die Ausgabe in der Konsole verlassen kann.

Zweiten Monitor konnte man auch in Linux nie nebenher laufen lassen wenn man Adaptivsync nutzen möchte usw. nur ohne Adaptivsync oder keine zwei Monitore. Tolle Wahl.

Ich habe voll bock auf Linux, aber im Moment bin ich froh das es Windows gibt. Es ist leider immer noch so was einfach nicht alles einfach "so" läuft und man muss sich schon mal häufiger mit Problemen befassen(zumindest bei neuer AMD Hardware) die man unter Windows einfach nicht hat.

Nicht falsch verstehen, Windows ist lange nicht Fehlerfrei, und klaut sicherlich massig Nutzerdaten und hat hier und da auch Probleme. Aber mir nützt ein Linux nichts was unbenutzbar ist... ich wünschte es wäre nicht so
 
CDLABSRadonP... schrieb:
Finde es sehr merkwürdig, dass AMD bislang so lange zwischen erstmals veröffentlichen und Quellcode veröffentlichen braucht.

warum? vielleicht wollen sie erst mal austesten wie das ganze in freier wildbahn funktioniert, bevor es einfach jeder verwenden kann und dann unedlich probleme damit hat
auch die bugreports dürften von SPIELEENTWICKLERN umfangreicher sein, als von irgendeinem dahergelaufenen anfänger (das hört man auch immer wieder von spieleentwicklern, dass zB linux nutzer sehr oft den besseren bugreport schreiben, als der standard windows nutzer und so probleme dann natürlich auch schneller behoben werden können)

ich finde daran absolut nichts merkwürdig
 
longusnickus schrieb:
auch die bugreports dürften von SPIELEENTWICKLERN umfangreicher sein, als von irgendeinem dahergelaufenen anfänger
Diese können bzw sollten aber auch von Spieleentwicklern kommen bevor sie die FSR Version in ihrem Spiel der Öffentlichkeit freigeben.
Darum ging es ja, es wurden ja bereits im November in 2 Spielen veröffentlicht, sodass alle Nutzer es erleben können. Das hätte man eigentlich nicht getan wenn man noch ne Menge bug reports erwartet.

Dann hätte man die Spiele mit 2.1 releasen lassen sollen, intern weiter 2.2 testen und mit AMD austauschen und dann heute bzw im Verlauf der nächsten Woche 2.2 per Patch nachreichen
 
Taxxor schrieb:
Diese können bzw sollten aber auch von Spieleentwicklern kommen bevor sie die FSR Version in ihrem Spiel der Öffentlichkeit freigeben.
Darum ging es ja, es wurde ja bereits im November in 2 Spielen veröffentlicht, das hätte man eigentlich nicht getan wenn man noch ne Menge bug reports erwartet.

wird ja auch so gekommen sein, aber keine software ist fehlerlos. irgendwann muss man sie nunmal in der realen welt testen und so kann man eben kontrollieren WER es nutzt und von WEM man dann die fehlerberichte bekommt

wenn es gleich alle haben, dann kommt irgendeiner hobby spaßentwickler, der ein spiel mit unity zusammenschustert und beschwert sich, dass das nicht funktioniert. darauf hatte AMD anscheinend keine lust
 
  • Gefällt mir
Reaktionen: Onkel Föhn
Zurück
Oben