Interview zu FSR 2.0 mit Nicolas Thibieroz, AMDs Director of Game Engineering

AMDs mit Spannung erwartetes, temporales Upsampling-Verfahren FSR 2.0 wurde unlängst in Deathloop und kurz darauf dem Landwirtschaftssimulator 2022 integriert und macht in diesen ersten Anwendungen einen ausgesprochen guten Eindruck. Wir haben darauf eine Einladung zu einem Interview mit Nicolas Thibieroz von AMD erhalten. Nick ist als Director of Game Engineering nicht nur für die Entwicklung von FSR und das gesamte FidelityFX-Programm zuständig, sondern leitet obendrein AMDs Developer-Entwicklungs-Team, welches als Bindeglied zwischen AMDs Hardware- sowie Effekt-Entwicklern und den Spiele-Entwicklern, welche diese Hardware und Effekte nutzen wollen, fungiert. Doch lassen wir Nick selbst zu Wort kommen. Wir präsentieren Ihnen an dieser Stelle das frei übersetzte Interview samt einigen Anmerkungen, auf der zweiten Seite stellen wir Ihnen außerdem eine englische Version zur Verfügung, in die AMDs Anmerkungen und Korrekturvorschläge bereits eingeflossen sind. Unseren ersten Test zu FSR 2.0 finden Sie hier.

Update: AMD bzw. Nick hat uns gebeten, bei einigen Antworten Korrekturen vorzunehmen bzw. noch einige von AMD stammende Informationen zu ergänzen. Dabei handelt es sich zumeist um weitere Ausführungen beziehungsweise Ergänzungen, die wir teilweise bereits in Form unserer Anmerkungen beigefügt haben - etwa, dass DRS "Dynamic Resolution Scaling" bedeutet. Wir heben die AMD-Ergänzungen im Text entsprechend hervor, bei Abweichungen zum Original handelt es sich praktisch ausschließlich um stilistische Änderungen, inhaltlich oder technisch ändert sich durch das Update nichts Bedeutendes.

Interview zu FSR 2.0

Nicolas Thibieroz: Fangen wir damit an, was genau ich eigentlich mache. Als weltweiter technischer Direktor bei AMD arbeiten mein Team und ich mit Spieleentwicklern auf der ganzen Welt zusammen. Das ist im also Grunde genommen nicht nur das, was wir das Dev-Tech-Team nennen, also das Entwickler-Technologie-Team (Anmerkung der Redaktion: jene Entwickler bei AMD, die mit Spiele-Entwicklern zusammenarbeiten), sondern es gibt auch eine Forschungs- und Entwicklungsabteilung. Und das ist natürlich das Team, das FSR 1.0, FSR 2.0 sowie andere GPUOpen-Software, wie Hybrid-Rendering, Hybrid-Raytracing, CACAO (Anmerkung der Redaktion: AMDs Combined Adaptive Compute Ambient Occlusion) und eine ganze Reihe verschiedener Effekte, entwickelt hat. Also ja, es ist ein toller, toller Job, es macht natürlich Spaß, neue Technologien zu erfinden und zu sehen, was all die Spieleentwickler in Bezug auf neue Technologien in ihren Spielen vorhaben. Und ich freue mich sehr, hier zu sein, um Ihre Fragen zum FSR 2.0 zu beantworten.

Update/Ergänzung durch AMD: Ich bin der Worldwide Game Engineering Director bei AMD. Das bedeutet, dass mein Team mit Spieleentwicklern auf der ganzen Welt zusammenarbeitet, um ihre Spiele besser aussehen und schneller laufen zu lassen. Dafür ist das Developer Technology ("DevTech")-Team zuständig, aber meine Organisation umfasst auch eine Forschungs- und Entwicklungsabteilung. Dies ist das Team, das FSR 1.0, FSR 2.0 sowie andere GPUOpen-Software wie Hybrid Raytracing und FidelityFX-Effekte wie FidelityFX Ambient Occlusion, FidelityFX CAS, FidelityFX Screen Space Reflections und mehr entwickelt hat.

PCGH: Die stets neuen Technologien sind es auch, was wir an unserem Job besonders mögen.

Nicolas Thibieroz: Wir lieben PCGH, ich finde übrigens, dass ihr einen prima Job macht, ich bin sehr beeindruckt, wie schnell ihr Benchmarks von Spielen erstellt, ihr seid in der Regel einer der ersten technischen Pressevertreter bei diesen Benchmarks, Leistungsanalysen und so weiter. Also ja, ich bin ein großer Fan von dem, was ihr macht.

PCGH: Dankeschön. Wir haben FSR 2.0 in Deathloop natürlich getestet - offensichtlich gibt es eine Menge Fortschritte bei FSR 2.0 im Vergleich zu 1.0, konventionellem Upscaling und sogar Vorteile gegenüber dem TAA im Spiel. Aber könntest du vielleicht beschreiben, was deiner Meinung nach die Hauptvorteile von FSR 2.0 sind und wie diese das Spielen auf lange Sicht beeinflussen könnten?

Nicolas Thibieroz: Aber klar. FSR 1.0 wurde ja nun vor fast einem Jahr veröffentlicht. Damals waren wir der Meinung, dass wir eine sehr gute Lösung hatten, eine sehr einfach zu integrierende, sehr preiswerte Lösung in Bezug auf die Leistungskosten, die im Grunde einer Vielzahl von Plattformen helfen würde. Und in diesem Sinne waren wir mit dieser Lösung sehr zufrieden. Aber selbstredend haben wir mit der Entwicklung nicht einfach an dieser Stelle aufgehört. Wir wussten, dass wir uns trotz der guten Trade-offs, die wir mit FSR 1.0 in Bezug auf all diese verschiedenen Metriken eingegangen waren, weiterhin auf die Bildqualität konzentrieren wollten. Vor allem wollten wir eine Bildqualität erreichen, die besser ist als die native Renderauflösung.

Deshalb haben wir uns im Rahmen unserer Forschung - und wir haben mehrere Teams, die Forschung zu Upscaling betreiben - schon vor langer Zeit als Ziel gesetzt, eine temporale Upscaling-Lösung zu entwickeln. Temporal oder zeitbasiert bedeutet dabei, dass die Hochskalierung, die man am Bild vornimmt, nicht nur auf einem einzigen Bild mit der Quellauflösung beruht (Anmerkung der Redaktion: Source Resolution, also jene Auflösung, von der das Bild beim Upscaling heraufgerechnet wird), sondern dass wir auch zusätzliche Eingangsbilder verwenden, um ein besonders hochwertiges, hochskaliertes Bild zu rekonstruieren. Natürlich braucht man den Farbpuffer der Quellauflösung. Aber wir verwenden auch einen Tiefenpuffer in der Quellauflösung sowie einen Bewegungsvektorpuffer in der Quellauflösung. Und die Bewegungsvektoren sind im Grunde der entscheidende Trick in diesem Algorithmus, denn die Bewegungsvektoren verraten uns im Wesentlichen, wo sich die Pixel des aktuellen Bilds im vorherigen Frame zuvor befanden. Wir machen also im Prinzip ein Supersampling über Frames hinweg - Temporal Supersampling. Und genau das ermöglicht uns eine viel bessere Qualität.

(Update/Ergänzung durch AMD: Bei AMD arbeiten mehrere Teams an der Erforschung der Bildhochskalierung, und wir haben uns schon vor langer Zeit daran gemacht, eine zeitbasierte Hochskalierungslösung zu entwickeln. Zeitliche Hochskalierung bedeutet, dass die Hochskalierung, die Sie an Ihrem Bild vornehmen, nicht nur auf einem einzigen Fame in Quellauflösung, sondern auch zusätzliche Eingaben und frühere Frames verwendet, um ein hochwertiges hochskaliertes Bild zu rekonstruieren. Neben dem Farbpuffer für die Quellauflösung verwenden wir auch einen Tiefenpuffer für die Quellauflösung sowie einen Bewegungsvektorpuffer für die Quellauflösung. Bewegungsvektoren sind der entscheidende Trick in diesem Algorithmus, da sie angeben, wo sich die Pixel des aktuellen Bildes im vorherigen Bild befunden haben. Diese Daten ermöglichen uns im Wesentlichen ein Supersampling über Frames hinweg. Auf diese Weise erhalten wir eine viel bessere Qualität als bei einer rein räumlichen Lösung.)

Die Qualität war also definitiv der wichtigste Punkt, den wir bei der FSR-2.0-Lösung verbessern wollten. Wir sind natürlich sehr zufrieden mit dem, was wir erreicht haben. Gleichzeitig wollten wir die breite Kompatibilität mit verschiedenen Plattformen beibehalten. Wisst ihr, wir bei AMD glauben fest an das Thema Open Source. Unsere Möglichkeit, mehrere Plattformen zu unterstützen, sodass mehrere Spieleentwickler, Spiele und Benutzer davon profitieren, war natürlich auch bei FSR 2.0 der Weg zu unserem Ziel. Auch hier haben wir eine ansprechende Lösung gefunden, denn wie ihr wisst, wird GPUOpen nicht nur mehrere Plattformen unterstützen, sondern auch noch in der ersten Jahreshälfte Open Source sein.

Die Performance war natürlich immer noch etwas, das wir im Fokus hatten - eine hohe Leistung. Ich meine, Upscaling ist großartig. Aber wenn man viele GPU-Zyklen braucht, um das zu erreichen, dann nimmt der Ertrag natürlich ab.

PCGH: Ja, wenn das Upsampling zu teuer ist, wird es irgendwie überflüssig.

Nicolas Thibieroz: Ganz richtig. Allerdings müssen wir uns darüber im Klaren sein, dass eine temporale Lösung, insbesondere FSR 2.0, ziemlich komplex ist. Es ist ein komplexer Algorithmus mit mehreren Durchläufen (Anmerkung der Redaktion: Render-Passes, welche die GPU durchlaufen muss), um die Qualität zu erreichen, die mit FSR 2.0 möglich ist. Der Algorithmus ist definitiv teurer als jener von FSR 1.0, aber wir haben viel Zeit damit verbracht, den FSR-2.0-Algorithmus zu optimieren - und zwar sehr umfangreich! Und dann kamen wir an den Punkt, an dem wir mehrere Permutationen auf Grundlage verschiedener Hardware-Architekturen durchführten, nicht nur über verschiedene GPU-Vendors, sondern sogar über verschiedene Grafikkarten-Generationen hinweg. Also mehrere schnelle Pfade im Algorithmus, um sicherzustellen, dass man die höchste Leistung erhält (Anmerkung der Redaktion: FSR 2.0 nutzt also je nach GPU-Architektur und -Hersteller für diese Hardware jeweils optimierte Pfade für die Berechnung des Algorithmuses). Wir sind also ziemlich zufrieden mit dem, was wir in Bezug auf die Leistung erreicht haben. Das ist natürlich etwas, das wir beibehalten wollen. Und wie zuvor erwähnt, ich denke, Open Source war der Schlüssel dazu, ist aber auch unsere Philosophie. Wir wollten also den Open-Source-Charakter des FSR 2.0 beibehalten, was wir in den nächsten Wochen bewerkstelligen werden.

PCGH: Oh, interessant - FSR 2.0 verwendet also verschiedene Optimierungen/Pfade eures Algorithmuses für verschiedene Hardware. Warum gibt es nur Unterstützung für DirectX 12? Was ist mit Vulkan und DirectX 11?

Nicolas Thibieroz: Okay, lasst mich erklären, was hier passieren wird. Während der Entwicklung wollten wir uns der Einfachheit halber auf eine einzige API konzentrieren. Denn während der Forschung und Entwicklung ist es verfrüht, mehrere APIs gleichzeitig unterstützen zu wollen. Das kann man tun, wenn man das Produkt hat, wenn man denn so will, also wenn man die Finalisierung-Phase erreicht hat. Also ja, während der Entwicklung haben wir uns definitiv auf DirectX 12 konzentriert. Aber ich freue mich, sagen zu können, dass wir zum offiziellen Launch (von FSR 2.0) auch Vulkan unterstützen werden. DirectX 11 ist ein wenig komplizierter, was die Unterstützung angeht. Aber was ich hier sagen kann, ist, dass jeder Spieleentwickler, der daran interessiert ist, FSR 2.0 auf DX 11 zu unterstützen, uns kontaktieren sollte. Wir werden es wahrscheinlich nicht öffentlich machen. Aber vielleicht haben wir etwas oder eine Version, die wir mit Entwicklern teilen können, die sie brauchen. Ich denke also, dass wir in Bezug auf die API-Unterstützung ziemlich gut aufgestellt sind.

PCGH: Wie will AMD die Entwickler dazu bringen (Anmerkung der Redaktion: im Interview verwendetes englisches Verb: to compel), FSR 2.0 auf breiterer Basis zu nutzen?

Nicolas Thibieroz: Meinst du vielleicht ermutigen? Das ist eine gute Frage. Ich denke allerdings, dass "to compel" ein ziemlich starkes Wort ist. Es bedeutet sozusagen, dass man die Leute zwingt, etwas zu tun. Und das ist nicht das, was wir bei AMD tun, okay. Wir möchten den Entwicklern keine Technologien aufzwingen, wozu vielleicht einige andere Agenturen neigen, aber das lasse ich einmal unkommentiert. Letztendlich ist es unsere Aufgabe, Entwicklern dabei zu helfen, großartige Technologien in ihre Spiele zu integrieren. Dazu müssen wir aber natürlich sicherstellen, dass unsere Technologien für sich selbst sprechen. Wir müssen Technologien anbieten, die die Entwickler wirklich nutzen wollen, wir müssen Technologien anbieten, die tatsächliche Probleme der Entwickler lösen. Das ist der beste Weg, um das gewünschte Ergebnis zu erreichen: Die Massenakzeptanz, auf die du vorhin angespielt hast. Wenn wir die Probleme der Entwickler lösen, gewinnt AMD, gewinnen die Gamer, gewinnen alle. So einfach ist das. So sehe ich die Sache. Und das ist die Aufgabe meines Teams, nicht wahr? Wenn man also eine gute Technologie anbietet, die optimiert ist, die plattformübergreifend ist, die es den Entwicklern ermöglicht, mehrere Architekturen und Plattformen zu unterstützen und die Spiele besser macht, dann ist das ein No-Brainer. Dann wird die Akzeptanz auf ganz natürliche Weise folgen. Das ist also unsere Herangehensweise, um die Technik in so vielen Spielen wie möglich integriert zu bekommen. Wir wussten außerdem, dass wir mit FSR 2.0 eine Nachfrage stillen bzw. eine Versorgungslücke in Bezug auf die Verfügbarkeit einer hochwertigen und plattformübergreifenden temporalen Upsampling-Lösung schließen konnten. Insgesamt sind wir also sehr zufrieden mit dem, was wir erreicht haben.

PCGH: Also wird FSR 2.0 auch auf den Konsolen funktionieren? Gibt es aktuelle Projekte von Konsolen-Entwicklern, die FSR 2.0 verwenden, über die du berichten könntest?

Nicolas Thibieroz: Wir können ein wenig über Konsolen sprechen. Natürlich gibt es Dinge, über die ihr vielleicht besser mit Microsoft und Sony sprechen solltet. Aber zum Beispiel haben wir bereits angekündigt, dass Microsoft FSR 2.0 auch im Microsoft im GDK, also dem Game-Developement-Kit für Entwickler, zur Verfügung stellen wird und sämtliche Xbox-Entwickler FSR 2.0 nutzen können. Ich würde euch aber ermutigen, mit den Entwicklern von Konsolenspielen zu sprechen, wenn ihr weitere Informationen darüber wünscht, ob FSR 2.0 auch auf anderen Konsolen verfügbar sein wird. Die Technologie ist quelloffen. Und auch hier wird der vollständige Quellcode der API zur Verfügung gestellt. Es liegt also wirklich an den Entwicklern, ob sie es auf andere Plattformen portieren wollen. Es gibt nichts, was FSR 2.0 im Wege steht, auf andere Plattformen portiert zu werden, wenn die Entwickler es wollen.

PCGH: Warum hat sich AMD entschieden, FSR 2.0 als Open Source zu veröffentlichen? Offensichtlich fördert dies potenziell die Verbreitung des FSR 2.0. Aber steckt vielleicht auch eine andere Philosophie hinter dieser Entscheidung?

Nicolas Thibieroz: Da hast du recht, es ist definitiv eine Philosophie. Ich gehe außerdem einmal stark davon aus, ihr seit doch schon mit AMD vertraut - und bei AMD gibt es ein langes Vermächtnis bezüglich Open-Source-Software, oder etwa nicht? Wir glauben im Allgemeinen, wie ich bereits sagte, dass alle gewinnen, wenn der Spieleentwickler gewinnt. Die Entwickler und ihre Publisher bekommen größere, bessere Spiele, aber FSR 2.0 ist auch ein Feature, das AMD eine bessere Leistung bringt, und die Gamer gewinnen, weil all diese Technologie zu besser aussehenden Spielen führt, die auch schneller sind und so weiter. Der Open-Source-Charakter von FSR 2.0 ist meiner Meinung nach der Schlüssel zur GPUOpen-Philosophie, die wir vor einigen Jahren begonnen haben. Und vor allem für die Marke FidelityFX, unter der wir alle unsere Effekte anbieten.

Für mich ist Open Source der beste Weg, um die Akzeptanz zu sichern. Und warum? Weil man, wenn man eine Blackbox hat (Ergänzung durch AMD: d.h. eine Bibliothek, für die der Quellcode nicht bereitgestellt wird), nicht weiß, welcher Code auf der Ziel-Hardware läuft, man weiß es nicht wirklich oder kann es nicht wirklich portieren, aber es ist nicht nur das. Open Source gibt den Entwicklern auch die Gewissheit, dass der Code tatsächlich mit ihrem Spiel funktioniert, denn das Letzte, was man als Entwickler will, ist ein Problem, das man nicht debuggen kann, richtig? Weil etwas in der Blackbox-Bibliothek, die man hat, nicht funktioniert. Außerdem ist Open Source für mich das beste Mittel, um Innovationen zu fördern. Wenn man eine Blackbox hat, dann kann es zwar eine großartige Technologie sein, die man in die Blackbox integriert. Aber mit Open Source kann man den Entwicklern ermöglichen, sich den Code anzusehen, ihn zu verstehen. Und ihn möglicherweise zu verbessern. Potenziell kann man ihn im Hinblick auf die visuelle Qualität oder die Leistung optimieren und natürlich auch bei der Portierung auf andere Plattformen helfen. Für mich ist das also wichtig. Und in der Spieleindustrie gibt es diese lange Philosophie des Wissensaustauschs, nicht wahr? Und am Ende sehen wir GPUOpen und die Marke FidelityFX als Schlüssel zu dieser Philosophie, und wir möchten unseren Teil dazu beitragen. Deshalb sind GPUOpen beziehungsweise der größte Teil der Inhalte von GPUOpen und auch FSR 2.0 Open Source. Und deshalb ziehe ich es vor, Open Source zu verwenden. Diese Entscheidung war für meine Mitarbeiter und mich besonders wichtig, weil wir alle fest an Open Source glauben. Auch hier bin ich sehr froh, dass wir uns für diese Lösung entschieden haben.

PCGH: Wie viel Arbeit ist für Sie als Entwickler mit dem FSR 2.0 im Vergleich zum FSR 1.0 verbunden - wie sieht das im Vergleich zu anderen modernen Techniken aus? Ihr arbeitet ja außerdem an einer FSR-2.0-API, so haben wir gehört - wie wird diese API funktionieren? Wird man sie einfach in die Spiel-Engine integrieren können, sozusagen als eine Art Middleware, und das war's?

Nicolas Thibieroz: Ja, das sind gute Fragen. Lasst mich also von Anfang an beginnen. Da es sich bei FSR 2.0 um einen zeitbasierten Algorithmus handelt, der eine höhere Bildqualität erzeugt, kann man wohl mit Fug und Recht behaupten, dass er fortschrittlicher ist als FSR 1.0 und daher etwas mehr Aufwand bei der Integration erfordert. So sind zum Beispiel mehr Inputs erforderlich. Ich glaube, ich habe bereits erwähnt, dass Farbinputs, Tiefenpuffer und Bewegungsvektoren und sogar einige optionale Inputs für eine noch bessere Bildqualität erforderlich sind oder zumindest für ein besseres Ergebnis bereitgestellt werden können.

Außerdem muss das Spiel eine zeitliche Schleife für das Rendering unterstützen. Im Grunde also die Möglichkeit, den aktuell erzeugten Puffer in die Pipeline zurückzuspeisen (Anmerkung der Redaktion: Temporal Feedback Loop, das Endergebnis des Rendervorgangs wird also wieder dem Anfang der Render-Pipeline zugeführt, um auch die Informationen vorheriger Frames nutzen zu können), sowie das Konzept der Entkopplung der Anzeigeauflösung von der Quellauflösung. Die meisten Spiele unterstützen diese Funktionen bereits auf die eine oder andere Weise. Wenn dies der Fall ist, wird die Integration von FSR 2.0 wesentlich einfacher sein. Vor allem, wenn die Spiele bereits eine Form der zeitlichen Hochskalierung unterstützen, wird die Integration definitiv einfacher sein. In diesen Best Cases wäre die Integration also ziemlich einfach. Es gibt vielleicht noch ein paar Sonderfälle, die man beachten muss, etwa wenn man mit Transparenz, Spiegeln und dergleichen zu tun hat. Aber insgesamt wäre dies eine einfachere Integration.

Bei Spielen, die noch keine entkoppelten Auflösungen und zeitlichen Rückkopplungsschleifen unterstützen, muss diese Infrastruktur natürlich erst geschaffen werden, bevor der FSR 2.0 integriert werden kann. Und dann reden wir von vielleicht einer Woche, zwei Wochen Arbeit und so weiter. Es kann also wirklich variieren. Einige Spiele funktionieren so gut wie sofort out-of-the-Box, mit einer direkten Integration. Der Landwirtschafts-Simulator 2022 war ein Beispiel dafür. Das wurde gestern veröffentlicht (Anmerkung der Redaktion: Der Interview-Termin war am 25.05), die API wurde integriert, es mussten nur wenige Änderungen vorgenommen werden, und das Ergebnis ist wirklich gut. Aber richtig, einige Spiele haben da etwas mehr Zuwendung benötigt. Es hängt also wirklich von Spiel zu Spiel ab, mit welcher Art von Komplexität diese Titel umgehen müssen, oder auch um Sonderfälle zu berücksichtigen und so weiter.

Im Fall von Unreal-Engine-Titeln wie UE4 und in Zukunft auch UE5 ist die Integration sogar noch einfacher, weil wir dafür ein Plugin haben respektive haben werden. Alles, was man dann tun muss, ist, das Plugin in sein Spiel zu integrieren und vielleicht mit ein paar CVARs herumzuspielen, also den Konsolen-Variablen (Anmerkung der Redaktion: Gemeint sind Variablen, die via Engine oder API zugänglich sind und welche bestimmte Eigenschaften von FSR 2.0 steuern), um die Ergebnisse basierend auf den Präferenzen des Künstlers zu optimieren, und dann sollte die Integration, zumindest wenn man gute Arbeit leistet, sehr ansprechende Ergebnisse liefern.

Aber nun zu eurer Frage in Bezug auf die API: Ja, wir haben eine API zur Verfügung gestellt. Wenn wir das jetzt mit FSR 1.0 vergleichen, das war so simpel gestrickt, dass wir einfach nur den Shader bereitgestellt haben. Und diesen Shader können die Leute einfach in ihr Spiel implementieren und los geht's. Schon hat man gute Upscaling-Ergebnisse. Bei FSR 2.0 haben wir uns stattdessen für eine API entschieden, weil wir über mehrere (Hardware-)Pfade im Algorithmus sprechen. Wir stellen nach wie vor den vollständigen Quellcode der API zur Verfügung, falls ein Entwickler die API selbst ändern möchte. Wir gehen jedoch davon aus, dass die meisten Entwickler in der Regel einfach die API-Points aufrufen werden, um einen Context und Dispatch zu erstellen (Anmerkung der Redaktion: Der Entwickler nutzt also die bereits in der API integrierte, vereinfachte Eingabe-Punkte bzw. im Grunde Optionsregler, um die API wiederum damit zu beauftragen, FSR 2.0 entsprechend zu steuern). Die Dispatches (Anmerkung der Redaktion: "Versendung" eines Befehls, eine Anordnung über die API/das Plug-In an FSR 2.0) an die eigentlichen FSR-2.0-Calls und zusätzlich vielleicht noch ein Aufruf einiger, wie wir sie nennen, optionaler Funktionen, also um beispielsweise Hilfsfunktionen zu nutzen, die sich mit der Berechnung der Quellpositionsgröße aus der Zielauflösung und solchen Dingen beschäftigen (Update durch AMD: Die API unterstützt einige optionale "Hilfsfunktionen", z. B. zur Berechnung der Source-Ausgangsmaße). Und dann wird die API im Wesentlichen die erfolgreiche Integration ermöglichen.

Wir stellen sogar sogenannte Callback-Funktionen zur Verfügung. Diese Callback-Funktionen sind für Entwickler gedacht, die spezielle Teile des Algorithmus anpassen wollen, z. B. wenn Sie mit speziellen Textur-Formaten arbeiten müssen, die möglicherweise nicht standardmäßig von der API unterstützt werden. In diesem Fall würde man einen Callback für diese Funktionen implementieren, der automatisch die Integration in die API ermöglicht, ohne dass die API selbst geändert werden muss. Auch hier könnte man, so man denn möchte, tief in die API eindringen, um sie zu ändern. Aber wir versuchen, das Ganze so einfach wie möglich zu machen, daher die Verwendung von Hilfsfunktionen und Callback-Funktionen. (Lacht) Hat das alles für eure Ohren verständlich geklungen?

PCGH: Ja, das hat es tatsächlich. Das hört sich eigentlich gar nicht einmal so kompliziert an. Kannst du uns noch ein paar andere Details nennen? Wie viele Frames verwendet der FSR 2.0 eigentlich für seine zeitliche Rekonstruktion? Ich nehme an, das kommt darauf an?

Nicolas Thbieroz: (lacht): Sehr gut, sehr gut! Die Antwort ist tatsächlich: Es kommt darauf an. Aber lasst mich euch die ganze Antwort geben, ja? Die Antwort ist allerdings ein wenig kompliziert, weil ich euch gar keine genaue Zahl nennen kann. Denn wie viele Frames der temporal History tatsächlich zu jedem aktuellen Frame beitragen, hängt von einer Reihe von Faktoren ab. Es hängt natürlich von den verwendeten Qualitätsmodi ab, also ob es sich (bei der FSR-Qualitätsstufe) um Performance, Balanced oder Qualtity handelt. Es hängt von der Amplitude der Bewegungsvektoren ab. Wenn der Bewegungsvektor Null ist, können wir natürlich viele Frames mehr akkumulieren als bei Bewegungsvektoren, die sich tatsächlich schnell bewegen. Es hängt auch davon ab, ob in dem Frame eine Okklusion oder Disocclusion stattgefunden hat - also ob neues Material hinzugekommen ist oder noch verdeckt wird. Insgesamt würde ich schätzen, dass für die Rekonstruktion durch FSR 2.0 zwischen 18 und 72 Bilder zeitlich verrechnet werden. Wie viele genau, das hängt von verschiedenen Faktoren ab. Aber diese Spanne ist der zeitliche Rahmen, den ich euch aufrichtig nennen kann.

PCGH: Wow. Das scheint ja eine ganze Menge zu sein.

Nicolas Thibieroz: (lacht): Nun ja, aber das hängt auch davon ab, oder? Wenn man nun eine sehr hohe Bildrate hat, sind das nur ein paar Millisekunden. Es kommt eben immer darauf an. Aber es liegt irgendwo zwischen diesen beiden Klammern. Nun, die einzige Möglichkeit, wie Entwickler die tatsächlichen Beiträge zum zeitlichen Verlauf (Anmerkung der Redaktion: History Contributions) beeinflussen können, ist, den Verlauf zurückzusetzen (Anmerkung der Redaktion: Temporal History Reset). Da wir Daten über mehrere Frames hinweg akkumulieren, ist es offensichtlich, dass die Daten von früheren Frames nicht mehr mit dem aktuellen Frame korrelieren, wenn man zum Beispiel einen Kameraschnitt macht. Dann sollte man die Historie zurücksetzen, damit die Daten des alten Frames keinen Einfluss auf den neuen, grundverschiedenen Frame haben.

(Update durch AMD: Die einzige Möglichkeit, wie Entwickler die tatsächlichen Beiträge zur Historie beeinflussen können, ist, wenn sie die Historie der FSR 2.0-Bilder zurücksetzen wollen. Dies kann in Fällen geschehen, in denen die aktuellen Frame-Daten nicht mehr mit dem vorherigen Frame korrelieren, z. B. wenn Sie einen "Kameraschnitt" durchführen.)

PCGH: Interessant. Das dynamische Upsampling klingt allerdings auch ziemlich spannend, insbesondere für Konsolen-Entwickler, würde ich meinen. Ist das nicht ziemlich kompliziert? Ist es nicht schwierig, ein Bild temporal zu rekonstruieren, wenn sich die Quellauflösung ständig ändert? Das könnte ich mir zumindest vorstellen.

Nicolas Thibieroz: Ja, das ist eine wirklich gute Frage. Ich bin tatsächlich ein wenig überrascht, dass du diese Frage stellst, aber ja, es ist wahr. Wenn sich die Auflösung der Quelle regelmäßig ändert, kann es Probleme bei der Korrelation der tatsächlichen Bewegungsvektoren und der History Data geben. Ich denke also, dass man in der Praxis auf jeden Fall damit rechnen sollte, dass sich die Auflösung der Quelle über mehrere Frames hinweg ändert. Der FSR 2.0-Algorithmus ist diesbezüglich aber tatsächlich erstaunlich stabil. Ich denke, das ist das Wort, das ich für solche Änderungen der Quellenauflösung verwenden würde. Und auch in der Praxis, wenn man DRS (Anmerkung der Redaktion: Dynamic Resolution Scaling) nutzt, wenn man eine dynamische Auflösungsskalierung nutzt, neigt die Auflösung normalerweise nicht dazu, sehr viel zu springen, das wird (Anmerkung der Redaktion: wie auch Schwankungen bei der Framerate) graduell sein. Ihr wählt also eure Zielbildrate, und damit wird sich natürlich das Bild der Quellauflösung auf der Grundlage dieser Zielbildrate ändern. Und das geschieht in der Regel sehr, sehr sanft. Wenn man nicht gerade von einem Sprung von dem einen Extrem zum anderen Extrem ausgeht (Anmerkung der Redaktion: damit gemeint ist ein plötzlicher Wechsel von einer extrem hohen zu einer extrem niedrigen Lastsituation oder umgekehrt), wird es auch keine großen Sprünge in der Auflösung geben. Da die Quellauflösung also in der Regel ziemlich gleichmäßig variiert, wird die Diskrepanz, so könnte man sagen, in den zeitlichen Daten minimiert, durch die temporale Verrechnung geglättet. Und wir können immer noch eine sehr erfolgreiche Arbeit, ich würde sogar sagen, fast perfekte Arbeit bei der aktuellen Datenerfassung leisten, unabhängig von dieser Auflösungsänderung, und natürlich ein sauberes Ergebnis erzielen.

(Update durch AMD: Ich war eigentlich überrascht, dass du diese sehr gute Frage gestellt hast, denn es handelt sich um ein berechtigtes Anliegen: Wenn sich die Auflösung der Quelle regelmäßig ändert, kann es aufgrund von Unterschieden in der Bildgröße zu Problemen bei der Korrelation von tatsächlichen Bewegungsvektoren und ihren Verlaufsdaten kommen. Es hat sich herausgestellt, dass der FSR 2.0-Algorithmus erstaunlich unempfindlich gegenüber Änderungen der Eingangsauflösung ist. Aber auch bei der dynamischen Auflösungsskalierung (Dynamic Resolution Scaling, DRS) sind Änderungen der Bildgröße in der Praxis eher allmählich: Bei einer festgelegten Zielbildrate wird die Größe der Quellauflösung in der Regel sanft variiert, um das vorgegebene Leistungsbudget einzuhalten. Daher sollten keine großen Schwankungen der Eingangsgröße auftreten, was dazu beiträgt, dass die DRS-Funktion von FSR 2.0 überzeugende Ergebnisse liefert. Ich möchte auch sagen, dass DRS nicht nur für Konsolen geeignet ist: Auch der PC kann davon profitieren und die Jungs von Arkane Studios haben gute Arbeit bei der Integration dieser Funktion in Deathloop geleistet.)

Aber ich muss sagen, dass DRS nicht nur für Konsolen gedacht ist, ich meine, Konsolen, ja da ist es ein weiteres Feature, ganz sicher. Aber ich denke, dass Dynamic Resolution Scaling auch für den PC geeignet ist, und die Leute von Arkane Studios haben hier wirklich gute Arbeit geleistet. Sie unterstützen DRS auch in Deathloop. Und ich denke, das ist ein Feature, von dem ich generell gerne mehr sehen würde - gerade auch bei PC-Spielen.

PCGH: Ja, FSR 2.0 sieht in Deathloop auch mit DRS wirklich sehr beeindruckend aus. FSR 2.0, das muss ich sagen, ist schon eine Freude. Es ist ja außerdem das allererste Spiel mit FSR 2.0 und ich nehme an, man kann in Zukunft wahrscheinlich eher noch mit weiteren Verbesserungen rechnen. Uns sind natürlich ein paar kleine Macken aufgefallen, schätze ich. Eine davon sind Partikel, etwa Schnee, die werden offenbar etwas betont, irgendwie hervorgehoben. Und einige von ihnen neigen dazu, ein wenig zu ghosten. Aber ich denke, es wird wohl immer einige Nebeneffekte geben, wenn man temporales Upsampling anstatt native Auflösung verwendet.

Nicolas Thibieroz: Ja, ich meine, man kann wohl sagen, dass keine temporale Lösung, keine Art von Upscaling-Lösung perfekt ist. Seien wir doch mal ehrlich, oder? Letztlich hat man es mit einem Supersampling über mehrere Frames hinweg zu tun, man versucht, das aktuelle Bild aus den Daten früherer Frames zu interpretieren, bei denen die Pixel vielleicht verdeckt waren, oder es gab einen ganzen Haufen Rauch oder Partikel davor. Das ist ein komplexes Problem, für das es derzeit keine perfekte Lösung gibt. FSR 2.0 liefert insgesamt ein wirklich gutes Ergebnis. Aber ja, manchmal stößt man auf einige Einschränkungen.

Und natürlich bieten wir einige Kompromisse in Bezug auf die Qualitätsmodi, wie Qualität, Leistung, Ausgewogenheit und sogar einen Hochleistungsmodus, der eine Menge Leistung bringt. Wenn man sich also damit arrangieren kann, vielleicht ein wenig Bildqualität unter den Tisch fallen zu lassen, kann man den Hochleistungsmodus verwenden. Und wer lieber auf hohe Qualität setzt, der wählt natürlich den Qualitätsmodus. Es gibt also Kompromisse, die es dem Benutzer ermöglichen, das zu wählen, was er möchte.

Ich denke, ich kann auch sagen, dass FSR 2.0 bei AMD schon seit geraumer Zeit ein Thema der laufenden Forschung ist, und es wird auch weiterhin ein Thema der laufenden Forschung sein. Ich glaube, ich habe das bereits anklingen lassen. Ich kann mich nicht zu zukünftigen Veröffentlichungen äußern - wie üblich - ich bin sicher, dass ihr als Pressemitglieder daran gewöhnt seit (lacht). Aber ich kann euch sagen, und ich denke, es ist ehrlich zu sagen, dass wir in absehbarer Zukunft weiter an API-Verbesserungen arbeiten werden. Auf jeden Fall. FSR wird bleiben, das kann ich euch sagen. Ich erwarte weitere Verbesserungen in Bezug auf Qualität, Leistung, Benutzerfreundlichkeit und so weiter. Und ich freue mich darauf, hoffentlich noch einmal mit euch darüber sprechen zu können, wenn wir bereit sind, mehr Details über die Zukunft zu verraten.

PCGH: Das wäre großartig. Ich wollte gerade fragen, was ihr jetzt, wo FSR 2.0 launch-reif ist, nun mit all eurer Freizeit anfangen werdet. Aber offensichtlich werdet ihr gar nicht allzu viel freie Zeit haben, oder (lacht)?

Nicolas Thibieroz (lacht): Nein, nein. Und ich weiß nicht, wie du auf diese Idee kommst. Ich meine, es ist eigentlich ganz interessant, denn ich leite ein ziemlich großes Team von Entwicklungsingenieuren, die mit den Spiele-Entwicklern zusammenarbeiten. Das nimmt also schon eine Menge meiner Zeit in Anspruch. Aber FSR 2.0 ist für uns, wie ihr euch vorstellen könnt, ein großer Schwerpunkt für die Zukunft. Also, nein, es gibt keine Freizeit. Und natürlich ist unsere Zeit nicht nur mit der Vorbereitung der eigentlichen Open-Source-Veröffentlichung des FSR 2.0 in Anspruch genommen, die vor Ende des ersten Halbjahres 2022 erfolgen wird. Sondern auch mit der Unterstützung unserer bestehenden Partner bei der Integration des FSR 2.0 in ihre Spiele. Das nimmt auch einen Teil unserer Zeit in Anspruch. Wir wollen sicherstellen, dass wir gute Arbeit leisten.

Selbst wenn FSR-2.0-Quellcode veröffentlicht ist und es den Leuten von da an freisteht, FSR 2.0 selbst zu implementieren, werden wir weiterhin versuchen, ihnen dabei zu helfen, die bestmögliche Arbeit zu leisten. Aber ja, wir wollen natürlich sicherstellen, dass die Technik so gut wie möglich dargestellt wird. Unser Hauptaugenmerk liegt also darauf, die Qualität und die Leistung all unserer Partnerspiele auf das erforderliche Niveau zu bringen. Und ich freue mich sehr, dass wir mit so vielen talentierten Spieleentwicklern zusammenarbeiten können, die sehr interessiert sind und uns nach der Technologie gefragt haben. Dem sind wir natürlich nachgekommen, und wir haben diese laufenden Dialoge zu unterstützen. Also ja, das ist großartig. Man arbeitet mit all diesen Entwicklern zusammen. Aber ja, keine freie Zeit, nein.

PCGH: Ja, das habe ich mir schon gedacht. Nun, das war's dann wohl, denke ich. Damit sind wir am Ende unserer Fragen angelangt. Vielen Dank für deine Zeit und deine ausführlichen Erklärungen.

Interview zu FSR 2.0 - Fazit

Im rund halbstündigen Interview hat Nicolas Thibieroz einige interessante Details angesprochen und spannende Details offenbart. Dass durch FSR 2.0 etwa je nach Bildinhalt und Situation bis zu 72 Frames verrechnet werden können, hätten wir nicht direkt erraten. Auch die Informationen bezüglich APIs, Implementationen und Details zu dem Support auf den (Nex-Gen-)Konsolen sind sehr interessant. Dazu zählt nicht nur, dass Microsoft respektive die Xbox FSR 2.0 durch das Entwicklungs-Kit standardmäßig unterstützt, sondern auch, dass Nick offenkundig nicht viel zu Sony und der Playstation sagen kann - oder darf.

Es ist ebenso offenkundig, dass mit FSR 2.0 noch nicht das Ende der Fahnenstange erreicht ist - zumindest, wenn es nach Nick und seinem Team geht. Es dürfte obendrein interessant zu beobachten sein, wie schnell sich AMDs Temporal-Upsampling durch die API und die Integration in die Unreal Engine verbreiten wird sowie außerdem, wie und in welcher Form sich FSR 2.0 durch den Open-Source-Ansatz in Zukunft verändern oder eventuell auch adaptiert werden könnte, etwa um es auf anderen Plattformen oder in vielleicht eher exotischen Anwendungen nutzen zu können. Wir bleiben gespannt und kommen bei Gelegenheit gerne noch einmal auf Nicks Angebot zurück, uns in einem zukünftigen Interview weiterführend über AMDs temporale Rekonstruktionstechnik FSR 2.0 oder FidelityFX-Effekten im Generellen zu informieren. Wie ist Ihr Eindruck zu FSR 2.0, sehen Sie Potenzial für AMDs neue Upsampling-Technologie? Nutzen Sie unsere Kommentarfunktion.

Artikel teilen

Interview zu FSR 2.0 mit Nicolas Thibieroz, AMDs Director of Game Engineering Wir hatten die Möglichkeit, ein Interview mit Nick Thibieroz, AMDs Director of Game Engineering und Hauptverantwortlichen für FSR 2.0 zu halten. Die Gelegenheit, einen technisch hoch qualifizierten Gesprächspartner auszuquetschen, haben wir uns selbstredend nicht entgehen lassen. Erfahren Sie zusammen mit uns weitere, spannende Details zu FSR 2.0.

Per E-Mail versenden

22

1. Seite 1 Interview zu FSR 2.0 - Deutsche Übersetzung
2. Seite 2 Interview zu FSR 2.0 - Englische Version