Microsoft DirectSR: API basiert auf AMD FSR 2.2

[HWL News Bot]

Erst kürzlich hat Microsoft im Rahmen der Game Developers Conference 2024 seine neue Upscaling-Technologie Direct SuperResolution, kurz DirectSR, vorgestellt. Wie der Name schon vermuten lässt, handelt es sich dabei um den Versuch, die Implementierung von Upscalern grundsätzlich zu vereinheitlichen. Wie nun bekannt geworden ist, wird dazu wohl FSR 2.2 für die grundlegende Verarbeitung in die DirectSR-Runtime integriert werden.
... weiterlesen

 

[FirstAid]

Ich sehe hier eine paralle zur Adaptive Sync bzw. AMD FreeSync. Mit der Einführung von VESA Adaptive Sync starben nach und nach die G-SYNC Monitore mit teuren Modulen aus.

Mit Microsoft Marktmacht wird sich dann FSR 2.2 und folge Versionen durchsetzen.

 

[Zyxx]

Die Frage ist dann nur: Setze ich als Spieleentwickler auf eine Schnittstelle von Microsoft, oder auf frei implementierbare Techniken von Nvidia, AMD und intel.
Je nachdem wie die API Calls von Microsoft umgesetzt werden geht dann doch eher Performance flöten, als wenn ich dem Treiber das direkt so mitteile wie er es wissen will, ohne das MS da ein Layer zwischen baut.

 

[Richard88]

Die Frage ist dann nur: Setze ich als Spieleentwickler auf eine Schnittstelle von Microsoft, oder auf frei implementierbare Techniken von Nvidia, AMD und intel.
Je nachdem wie die API Calls von Microsoft umgesetzt werden geht dann doch eher Performance flöten, als wenn ich dem Treiber das direkt so mitteile wie er es wissen will, ohne das MS da ein Layer zwischen baut.

So wie ich die news verstanden habe, setzt microsoft ja selber auf AMD nur eben direkt integriert und zusammen entwickelt. Und AMD'S standard ist offen. Du kannst also beides haben

 

[Liesel Weppen]

Die Frage ist dann nur: Setze ich als Spieleentwickler auf eine Schnittstelle von Microsoft, oder auf frei implementierbare Techniken von Nvidia, AMD und intel.

Die Microsoft-Schnittstelle verwendet doch AMD-Technik.

Je nachdem wie die API Calls von Microsoft umgesetzt werden geht dann doch eher Performance flöten, als wenn ich dem Treiber das direkt so mitteile wie er es wissen will, ohne das MS da ein Layer zwischen baut.

Naja, im Falle von FSR2.2 wenig bis gar nicht, weil das ja genau die grundlegende Technologie ist. Ein Layer dazwischen, der nur durchleitet, kostet bei heutigen Rechenleistungen quasi nix mehr.

Wenn NVidia aber DirectSR unterstützt haben will, im Hintergrund aber trotzdem DLSS anwenden will, müssen sie eben einen Treiber rausbringen, der der DirectSR auf DLSS mapped. Da ist dann die Frage wie gut beide APIs zueinander passen... da könnte dann schon mehr als "einfach nur durchreichen" nötig sein.

Die Frage für Entwickler ist eher: Will ich ein Upscaling haben, das ohne jeglichen Aufwand meinerseits auf allen halbwegs modernen GPUs funktioniert, oder will ich zusätzlichen Aufwand für einen proprietären Upscaler betreiben, der dann sogar nur auf NVidia-Karten (teilweise sogar nur neuerster Generation) funktioniert?

Ich bin zwar nicht gerade ein Microsoft-Fan, aber DirectX war wichtig und richtig. Davor hatte man Glide, OpenGL und wer weiß noch was für andere Entwicklungen. Jetzt hat man mit DLSS und FSR wieder das gleiche und Microsoft versuchts mit DirectSR für Entwickler wieder zu vereinheitlichen. Da hatte MS im Prinzip auch nur die Wahl zwischen FSR oder was ganz neuem. Eine proprietäre Technik von NVidia hätte wohl selbst Microsoft nicht genommen.... bzw. evtl nichtmal nehmen dürfen, zumindest nicht ohne Lizenzgebühren an NVidia abdrücken zu müssen...

 

[Zyxx]

Sagen wir es so: Ich mag Overhead nicht. Die Erfindung von Vulcan und später DirectX 12 war etwas was ordentlich Performance brachte.

Jetzt wieder irgendeine neue Schnittstelle für etwas zu definieren was es schon gibt ist doch Käse.

 

[Infi88]

Vulkan nicht Vulcan. Da kann man nur zu Gott beten das DirectSR nicht so schlecht wird wie der Vulkan Klon DX12.

Schon fast absurd auch der Starfield Vergleich, Presse und Entwickler bezahlt um im Sinne eines Exklusivdeals nur ihren Upscaler zu verwenden hatte nVidia nicht nötig gehabt bis dato . Da Microsoft als Messias zu feiern der Entwickler und Hardwarehersteller wieder zusammen bringt ist doch etwas fragwürdig.

 

[Liesel Weppen]

Jetzt wieder irgendeine neue Schnittstelle für etwas zu definieren was es schon gibt ist doch Käse.

Mir scheint du vermischt Schnittstelle und Implementierung.

FSR und DLSS sind zunächst mal Implementierungen... jeweils mit ihrer eigenen, exklusiven Schnittstelle. D.h. mit der Wahl der Schnittstelle lege ich mich als Entwickler auch gleich verbindlich darauf fest, ob da jetzt FSR oder DLSS angewandt wird. Wenn ich FSR wähle, kann das kein DLSS und umgekehrt. Will ich beides unterstützen, muss ich BEIDE Schnittstellen anbinden.

DirectSR soll das vereinheitlichen. Ein Entwickler soll einfach NUR gegen die Schnittstelle von DirectSR entwickeln können. Ob dahinter dann FSR oder DLSS angewandt wird, braucht den Entwickler nicht zu interessieren.
DirectSR ist NUR eine Schnittstelle. Laut der Meldung soll FSR2.2 lediglich die Defaultimplementierung für DirectSR werden. Heisst, wenn der Grakatreiber nix anderes macht, wird hintenrum FSR angewandt.

Nötig ist so eine Schnittstelle, weil Nvidia und AMD sich nicht von selbst auf eine einheitliche Schnittstelle "einigen" können. NVidia könnte die Schnittstelle von AMD adaptieren, denn die wäre ja immerhin offen. Aber das tut man natürlich nicht, wenn man die eigene proprietäre Lösung pushen will. Damit dann der Entwickler nicht als der übrig gebliebene Dumme da steht, braucht man halt jetzt wieder einen Layer der das auf Entwicklerseite wieder Vereinheitlicht und damit den schwarzen Peter wieder den Graka-Herstellern zurückschiebt.

Und dann kommt Intel womöglich noch mit der dritten abweichenden Lösung...

 

[Zyxx]

Ich möchte hierauf hinaus, ich bin kein Fan von:

"Leute wir bauen das jetzt nicht mehr in unser Spiel ein, sondern wir lassen das Windows machen."
Bei FSR / DLSS etc. kommt es doch darauf an die Hardware zu entlasten und nicht weitere Fehlerquellen mit ins Boot zu holen.
Oder hat irgendwer diese Mechanismen freiwillig an? Das ist doch immer nur ein Notnagel für fehlende Leistung.

 

[Liesel Weppen]

"Leute wir bauen das jetzt nicht mehr in unser Spiel ein, sondern wir lassen das Windows machen."

Und Entwickler sind keine Fans davon in jedes Spiel Unterstützung für jede Hardware/Hersteller einbauen zu müssen.

Bei FSR / DLSS etc. kommt es doch darauf an die Hardware zu entlasten und nicht weitere Fehlerquellen mit ins Boot zu holen.
Oder hat irgendwer diese Mechanismen freiwillig an? Das ist doch immer nur ein Notnagel für fehlende Leistung.

Bei Enshrouded hatte ich es tatsächlich absichtlich an. 3440x1440 60fps capped bei 80% FSR Quality macht mal eben 150W statt 200W auf der GPU und wenn ich nicht gerade Screenshots auf Pixelniveau vergleiche, fällt mir im bewegten Spiel kein Unterschied auf.

 

[Infi88]

So fundamental und schwierig wie Liesel Weppen das darstellt sind die Implimentierung von DLSS und FSR auch nicht. Er versucht halt wie viele mit Begrifflichkeiten wie "proprietär" usw. intelligent zu wirken, dabei ist die Gratislösung sollte man eigentlich seit Karl Marx gelernt haben nicht immer die Beste geschweige denn DirectX freie Software.

NVidia könnte die Schnittstelle von AMD adaptieren, denn die wäre ja immerhin offen. Aber das tut man natürlich nicht, wenn man die eigene proprietäre Lösung pushen will.

Ein AMD und Nvidia Spezi waren doch bei der Präsentation anwesend .
Microsoft baut keinen zusätzlichen Layer oder Wrapper ein sondern macht ihn auf Betriebssystemebene für das Integer Scaling im Optimalfall obsolet, dafür verwendet man hauptsächlich Code von FSR 2.2.. Wenn die Khronos Gruppe einen Sinn hat dann wohl diesen.