Archiv verlassen und diese Seite im Standarddesign anzeigen : DirectX DirectSR "Super Resolution"
DrFreaK666
2024-02-26, 11:09:02
Noch kein Thread?
MS wird auf der GDC 2024 DirectSR vorstellen.
Aus der Pressemitteilung:
Microsoft will provide a preview into DirectSR, making it easier than ever for game devs to scale super resolution support across Windows devices.
Da MS ziemlich aktiv im Bereich AI ist, bin ich gespannt, was sie präsentieren werden.
https://schedule.gdconf.com/session/directx-state-of-the-union-ft-work-graphs-and-introducing-directsr-presented-by-microsoft/903872
basix
2024-02-26, 12:11:20
Ich nehme an, dass DirectSR primär eine API & Framework ist. Allenfalls präsentieren sie noch ein paar in Windows 11 eingebaute Features, welche darauf aufbauen (z.B. Super Resolution in 2D-Content)
AMD und Nvidia sind Partner bei dieser Präsentation.
The_Invisible
2024-02-26, 12:16:39
Sehr cool, wie ich schon öfter gefordert habe, es gehört hier endlich eine API/Framework von MS her
basix
2024-02-26, 12:21:03
Release 24H2, also gegen Ende Jahr:
https://www.igorslab.de/gdc-2024-microsoft-enthuellt-directsr-die-zukunft-der-pc-gaming-grafik/
DrFreaK666
2024-02-26, 12:27:18
AutoSR ist womöglich eine andere Technologie.
readonly
2024-02-26, 12:29:19
Mit 24h2 ist dann WMR Geschichte. Da muss man entscheiden was man will 😬
Achill
2024-02-26, 12:34:30
Ich nehme an, dass DirectSR primär eine API & Framework ist. Allenfalls präsentieren sie noch ein paar in Windows 11 eingebaute Features, welche darauf aufbauen (z.B. Super Resolution in 2D-Content)
AMD und Nvidia sind Partner bei dieser Präsentation.
Wichtig neben einen API/Framework, insb. wenn es mehr API als Implementierung ist, dass MS genügend Test-Cases vorgibt die das Minimum / das Zielbild definieren.
DrFreaK666
2024-02-26, 12:39:47
Ich hoffe nicht, dass es nicht nur eine API ist, im Hinblick auf die nächste Xbox
basix
2024-02-26, 13:33:19
Wichtig neben einen API/Framework, insb. wenn es mehr API als Implementierung ist, dass MS genügend Test-Cases vorgibt die das Minimum / das Zielbild definieren.
Die Idee ist gut, doch ich stelle mir die Umsetzung schwierig vor. Was ist denn das Zielbild? Wie definiere ich das? Ist das ein 16K downsampled Bild auf 4K, welches mit fixed 60fps läuft und das via SR-Algo ebenfalls auf 4K/60fps bringt, dann das PSNR/Flip Metriken ausrechnet und unter dem Minimum von dem sein muss? Kann man machen. Wiederholt man das Verfahren über mehrere Auflösungen bei verschiedenen FPS? Was, wenn das Spiel ungenügende/fehlerhafte Datenqualität bereitstellt?
Ich denke eher, dass die Standardisierung der Interfaces Spiel <-> SR-Algo inkl. entsprechender Vorgaben über die Art der Daten und Datenqualität bereits viel bringen wird. Seit DLSS 2.0 hatte man nun fast 3 Jahre Lernphase und AMD, Nvidia und Intel wissen, was in der Tendenz am besten funktioniert. Ein standardisiertes Framework (=Ersatz von Nvidias Streamline) ist hier für Entwickler eine Erleichterung. Sie müssen sich nur an einem Interface orientieren und die Hersteller (AMD, Nvidia, Intel, Microsoft, Epic?) können oben drauf innovieren. Schlussendlich nimmt es primär den Entwicklern Arbeit ab. Die Qualität ist da nicht der primäre Gedanke hinter DirectSR. Die Standardisierung wird aber automatisch die minimale/durchschnittliche Qualität nach oben heben. Neben Erleichterungen für Entwickler bietet es darüber hinaus die Option, dass andere Applikationen ebenfalls auf DirectSR aufsetzen können. Was ist mit CAD Anwendungen, wo Mechanikteile gerendert werden? Das in 1080p rendern und auf 4K hochskalieren?
DirectSR deutet vom Namen her auch an, dass Upscaling auf Treiberebene passieren könnte.
Ich hoffe nicht, dass es nicht nur eine API ist, im Hinblick auf die nächste Xbox
Da wird sicher was kommen. Aber muss nicht bei der DirectSR Vorstellung sein. Xbox Next ist noch weit weg. Aber klar, wenn ein neues und gutes Verfahren direkt in DirectSR integriert ist, wieso nicht? Dann wäre das per Default vorhanden und die Konkurrenz muss sich daran messen.
Edit:
Noch von PCGH: https://www.pcgameshardware.de/Windows-11-Software-277633/News/Microsoft-Direct-Super-Resolution-1441586/
DirectML und ONNX Runtime dienen als Basis
Als Basis dient der Neural Processor Unit (NPU) Support in DirectML, den Microsoft am 1. Februar 2024 als Entwicklervorschau vorgestellt und zum Testen freigegeben hat. Unterstützt werden zu Beginn die Core Ultra 100 ("Meteor Lake"), welche über eine kompatible NPU verfügen. Auch Ryzen 7000 und 8000 alias "Phoenix" und "Hawk Point" kommen voraussichtlich später infrage.
Muss man mal erklären was an einer von MS gesteuerten Schnittstelle so viel besser ist, als was Streamline bereits als Opensource bieten kann.
DrFreaK666
2024-02-27, 14:42:51
Muss man mal erklären was an einer von MS gesteuerten Schnittstelle so viel besser ist, als was Streamline bereits als Opensource bieten kann.
Wir wissen ja nicht, was MS wirklich zeigen wird.
basix
2024-02-29, 11:37:30
Wie erwartet: DirectSR ist eine API
https://www.computerbase.de/2024-02/microsoft-erklaert-directsr-ermoeglicht-dlss-fsr-xess-und-co-pauschal-in-spielen/
Das wichtigste:
Wenn ein Spiel DirectSR unterstützt, wird es in Zukunft immer Nvidia DLSS, AMD FSR oder Intel XeSS unterstützen, ohne dass sich der Spieleentwickler explizit um jede dieser Technologien kümmern muss.
Ich nehme an, AMD, Nvidia, Intel etc. können ihre Upsampling Technologien dann zusätzlich auch via Treiber anbieten. Dann gibt es nie mehr die Situation, ach es unterstützt FSR aber ich will XeSS auf meiner Intel Karte nutzen. Oder es ist DLSS drin aber kein FSR usw.
Interessant wird es, wenn man über die Vendor-Grenzen hinaus will. Was macht man, wenn ich als Intel User FSR nutzen will? Oder umgekehrt bei AMD mit XeSS?
Lurtz
2024-02-29, 12:04:54
Gute Sache. Ist die Frage ob das jetzt tendenziell für bessere oder schlechtere Implementierungen sorgen wird, wenn sich alle nur noch auf einen Automatismus verlassen ;D
The_Invisible
2024-02-29, 12:08:25
Na endlich, dann sollte dieser Kleinkrieg mal aufhören.
Hoffentlich wird an FG auch gleich gedacht und zusätzlich eine LowLatency Option. Hoffen wir mal das Beste.
DrFreaK666
2024-02-29, 12:38:14
Na endlich, dann sollte dieser Kleinkrieg mal aufhören...
Glaubst du das wirklich? FSR wird dadurch ja nicht schöner.
Ich hab leider mehr erhofft.
XeSS in mehr Games wäre ein Plus. Entwickler sollten die Möglichkeit aber auch nutzen
basix
2024-02-29, 12:42:12
Hoffentlich wird an FG auch gleich gedacht und zusätzlich eine LowLatency Option. Hoffen wir mal das Beste.
Ich hoffe doch schwer, man hatte hier genug Weitsicht ;)
Edit:
Ach ja hinsichtlich Treiberintegration: Die GPU-Hersteller können via Treiber Updates nachreichen ;) DLSS-Swap wäre dann nicht mehr zwingend nötig. Bei FSR hat man momentan gar keine Möglichkeit zum Update, da meistens nicht als DLL ins Spiel eingebunden.
redpanther
2024-02-29, 14:37:44
Warum bekommt das einen eigenen Namen und man verpasst DX nicht einfach ein Update auf 12.1 ?
Tobalt
2024-02-29, 18:41:38
Dies ist genau der richtige Schritt zur konsequenten Verbreitung von temporalem Upsampling in nahezu jedes Spiel. Habe das ja wie viele andere schon lange herbeigesehnt.
Ich stelle mir das so vor, dass für jede Technik in DirectX eine Art default NN hinterlegt ist, was aber vom Grafiktreiber ersetzt werden kann mittels library. Auf diese Weise ist gewährleistet:
a) dass Updates des NN easy über Grafiktreiber ausgeliefert werden können
b) Programmspezifische NN ebenfalls vom Grafiktreiber eingesetzt werden können
c) Initiative und Motivation zur Verbesserung der Tech bleiben bei den IHV
d) Vertriebsarbeit für Adoption von temp Upsampling entfällt bei den IHV, dadurch DirectX defacto erledigt.
Sollte also hoffentlich ein richtiger Turbo für Verbreitung, Kompatibilität und Qualität von temporalem Upsampling sein.
Also im Endeffekt das selbe was Streamline schon lange kann, nur mit dem Nachteil in DX integriert zu sein.
Tobalt
2024-03-01, 08:55:12
Vergleich die Verbreitung von Streamline und von DirectX..
Exxtreme
2024-03-01, 09:03:12
Und AMD boykottiert Streamline. FSR ist deshalb nicht drin.
The_Invisible
2024-03-01, 09:06:19
Glaubst du das wirklich? FSR wird dadurch ja nicht schöner.
Ich hab leider mehr erhofft.
XeSS in mehr Games wäre ein Plus. Entwickler sollten die Möglichkeit aber auch nutzen
Meine damit eher dass es derzeit eher ein Wildwuchs ist, welches Upsampling integriert ist. Danach sollte jeder die Wahl haben. Cool wäre natürlich wenn man dann Upscaling mit FrameGeneration beliebig mischen könnte.
DrFreaK666
2024-03-01, 09:30:46
Das wäre echt nice. Aber NV wird ihr FG sicherlich nicht für alle verfügbar machen.
Hoffen wir dass es mit AMDs FG möglich wird
Vergleich die Verbreitung von Streamline und von DirectX..
Vergleiche die Trägheit von MS mit Opensource.
Und AMD boykottiert Streamline. FSR ist deshalb nicht drin.
Zum Nachteil für AMD-User.
Meine damit eher dass es derzeit eher ein Wildwuchs ist, welches Upsampling integriert ist. Danach sollte jeder die Wahl haben. Cool wäre natürlich wenn man dann Upscaling mit FrameGeneration beliebig mischen könnte.
Da klingt das Gegenteil wesentlich wahrscheinlicher.
Wenn Spiele Upsampling über DX integrieren, wird es eher nur mehr einen Schalter für FG Ein/Aus, und evtl. einen für Upsampling geben, oder man lässt letzteren sogar ganz weg und macht das nur über den Resolution-Slider.
Was genau dann zum Einsatz kommt entscheidet der Grafiktreiber.
Exxtreme
2024-03-01, 11:43:43
Zum Nachteil für AMD-User.
Ich wüsste jetzt nicht welchen Vorteil ein AMD-User hätte wenn AMD die eigene Konkurrenz stärkt.
basix
2024-03-01, 12:01:06
Man könnte hinter dem Gast ja Troyan vermuten aber hey, Anonymität des Internets ;)
Niemand wird gezwungen DirectSR zu verwenden. Man kann wie gehabt FSR oder DLSS oder Streamline integrieren. Aber ich behaupte, 99% der Entwickler werden auf DirectSR aufspringen, weil es eben einfach Sinn macht. Egal, was gewisse "Gäste" hier dagegen stänkern. Ach ja, Nvidia unterstützt DirectSR aktiv, die werden bei der MS Präsentation dabei sein, nur mal so nebenbei. Und das Argument Trägheit ist nur zum Teil gültig, nämlich bei der API. Bei der Implementation kann jedes Treiberupdate Verbesserungen bringen. Und soweit ich weiss, ist die DLSS API sehr stabil gewesen, bei FG gab es noch ein Update. Ist das via Treiberupdate nun träger als vorher oder schneller? Vorher musste es der Entwickler anpassen oder wir hier als versierte Nutzer haben die DLSS-DLL getauscht. Ersteres passierte eigentlich nie und letzteres ist ein Aufwand und viele Nutzer kennen es nichtmal (haben also keinen Benefit)
Beim Vendor-Vergleich entscheidet zudem immer noch die Qualität. Da hat DLSS momentan immer noch die Nase vorn. Nur macht DirectSR das Leben für Entwickler leichter und für GPU-Nutzer kommt die "Garantie", dass die eigene Karte eine Form von Temporal Upsampling nutzen kann. Inkl. der Möglichkeit für treiberseitige Updates und Verbesserungen. Man kann hier gegen das MS-DX-Monopol wettern wie man will, für den User ist das unter dem Strich eine deutliche Verbesserung. Egal, von welchem GPU-Vendor man eine Karte besitzt. Ich habe eine Nvidia Karte und finde DirectSR eine gute Sache. Wenn AMD oder Nvidia nochmals "andere" Sachen machen wollen, kann man das ja wieder so machen wie es mit DLSS angefangen hat. Der Spieleentwickler baut es separat ein. Da es dann aber ja eben "anders" wäre als DLSS, hätte man es eh separat oder zusätzlich machen müssen, egal ob DirectSR oder nicht. Innovation wird dadurch nicht behindert.
DrFreaK666
2024-03-01, 13:09:01
Zum Nachteil für AMD-User.
Welchen Nachteil? Gibt es dank Streamline öfter XeSS statt FSR in Games?
MiamiNice
2024-03-01, 13:14:51
Nein, der Nachteil für AMD User ist, dass dann jeder DLSS nutzen wird und es kein Zwangs FSR mehr geben wird. Für die einen ist das ein Nachteil, alle anderen freuen sich einen Ast.
Mir persönlich gefällt der MS move ziemlich gut.
basix
2024-03-01, 15:49:27
Ich bin gespannt auf die Argumentationskette, wieso das ein Nachteil für AMD User ist, wenn bisher "nur" FSR implementiert wurde. DLSS konnten die ja eh nicht nutzen.
Und "jeder" kann man auf "Nvidia RTX" beschränken. AMD, Intel und GTX Nutzer sind da nicht eingeschlossen ;)
AffenJack
2024-03-01, 16:08:23
Niemand wird gezwungen DirectSR zu verwenden. Man kann wie gehabt FSR oder DLSS oder Streamline integrieren. Aber ich behaupte, 99% der Entwickler werden auf DirectSR aufspringen, weil es eben einfach Sinn macht. Egal, was gewisse "Gäste" hier dagegen stänkern. Ach ja, Nvidia unterstützt DirectSR aktiv, die werden bei der MS Präsentation dabei sein, nur mal so nebenbei.
Wer weiß ob DirectSR am Ende nicht sogar auf Streamline basiert mit MS Stempel, damit das auch AMD verwenden kann. Streamline war doch eh Open Source.
Exxtreme
2024-03-01, 16:40:40
Wer weiß ob DirectSR am Ende nicht sogar auf Streamline basiert mit MS Stempel, damit das auch AMD verwenden kann. Streamline war doch eh Open Source.
AMD kann Streamline jetzt schon verwenden. Sie wollen nur nicht.
basix
2024-03-01, 17:15:33
Wer weiß ob DirectSR am Ende nicht sogar auf Streamline basiert mit MS Stempel, damit das auch AMD verwenden kann. Streamline war doch eh Open Source.
Möglich, ja. Würde mich bei MS aber ein wenig überraschen ;)
Mit DirectSR wird Streamline aber eigentlich obsolet, ja.
Tobalt
2024-03-01, 17:38:52
Hmm wie ist das mit den anderen Render API neben DirectX?
][immy
2024-03-01, 19:03:23
AMD kann Streamline jetzt schon verwenden. Sie wollen nur nicht.
Ob nicht wollen oder keine Kapazitäten ist wohl eher die Frage. Mit "wollen nicht" unterstellst du etwas, wofür man natürlich auch Fakten bräuchte um das zu untermauern. Bislang sehr ich bei AMD eigentlich das sie viel wollen, aber nicht die Kapazitäten haben.
Hatte es tatsächlich ausbessern gefunden wenn MS hier eine Standardlösung bringt und nicht nur standard API. Aber ist immerhin ein Anfang.
Mir können diese "Lösungen" nach wie vor gestohlen bleiben. Dafür sind sie mir nach wie vor zu Artefaktbelastet
AffenJack
2024-03-01, 19:50:08
Möglich, ja. Würde mich bei MS aber ein wenig überraschen ;)
Mit DirectSR wird Streamline aber eigentlich obsolet, ja.
Wieso würde es dich überraschen? Wieso sollte MS Geld dafür in die Hand nehmen und von vorne entwickeln, wenn man die Basis von Streamline nur etwas erweitern kann?
Das hat MS doch schon oft so gemacht. Das war schon so bei DX12, ebenso bei DXR.
Tobalt
2024-03-01, 20:25:34
[immy;13501229']Ob nicht wollen oder keine Kapazitäten ist wohl eher die Frage. Mit "wollen nicht" unterstellst du etwas, wofür man natürlich auch Fakten bräuchte um das zu untermauern. Bislang sehr ich bei AMD eigentlich das sie viel wollen, aber nicht die Kapazitäten haben.
Hatte es tatsächlich ausbessern gefunden wenn MS hier eine Standardlösung bringt und nicht nur standard API. Aber ist immerhin ein Anfang.
Mir können diese "Lösungen" nach wie vor gestohlen bleiben. Dafür sind sie mir nach wie vor zu Artefaktbelastet
Ich gehe schon davon aus, dass DirectSR von jedem Verfahren eine Standardimplementierung enthalten wird die dann anwendungsagnostisch zum Einsatz kommt.
Aber dabei sollte es natürlich dem Grakatreiber überlassen sein, etwas besseres an dessen Stelle zu patchen.
Ich wüsste jetzt nicht welchen Vorteil ein AMD-User hätte wenn AMD die eigene Konkurrenz stärkt.
Der AMD-User hätte in jedem Spiel das Streamline verwendet automatisch Upscaling zur Verfügung und wäre nicht darauf angewiesen, dass FSR noch extra implementiert wird.
Aber für AMD ist es natürlich ein Nachteil, denn je mehr Spiele es gibt die DLSS+FSR unterstützen desto öfter werden diese auch verglichen und desto schlechter sieht FSR aus, deshalb will AMD natürlich nicht, dass neben FSR andere Upscaler zum Einsatz kommen.
Ich gehe schon davon aus, dass DirectSR von jedem Verfahren eine Standardimplementierung enthalten wird die dann anwendungsagnostisch zum Einsatz kommt.
Genau das ist es nicht, es ist eine API keine Implementierung.
AMD kann Streamline jetzt schon verwenden. Sie wollen nur nicht.
tja OpenSource ist für AMD nur gut wenn es von AMD kommt... das ist so lächerlich.
Tobalt
2024-03-05, 06:15:47
Genau das ist es nicht, es ist eine API keine Implementierung.
Gut, dann wird es aber sicher im ersten Treiber Update von Intel/AMD/nV eine Standardimplementierung geben.
robbitop
2024-03-05, 09:50:01
Die Implementierung macht nach wie vor der Developer des Spiels. Die Schnittstelle (DirectSR) ist nur eine Schnittstelle zwischen Spiel und den verschiedenen Verfahren. Im Prinzip das gleiche was Steamline schon war.
robbitop
2024-03-05, 09:52:10
tja OpenSource ist für AMD nur gut wenn es von AMD kommt... das ist so lächerlich.
Wer weiß ob DirectSR am Ende nicht sogar auf Streamline basiert mit MS Stempel, damit das auch AMD verwenden kann. Streamline war doch eh Open Source.
Das erinnert mich an Mantle was ja auch Open Source war. Wollte Nvidia auch nicht unterstützen. Aber sobald es den Vulkan Stempel bekommen hat und AMD raus war haben es alle unterstützt.
Es gibt (auch bei Open Source) wahrscheinlich eine Art Interessenkonflikt. (Branding und auch Ownership des Verfahrens - auch wenn es open source ist)
Troyan
2024-03-05, 09:56:45
Mantel war AMD Technik. Vollkommen belanglos, ob das Open Source war. Vulkan ging durch das Kommitee und dort konnte jeder seine Anpassungen einbringen.
Streamline ist nichts anderes als ein paar Interfaces, die nichts machen sondern nur beschreiben. Die Funktionalität erfolgt in der DLL für das Upscaling.
Ganon
2024-03-05, 10:03:30
Das erinnert mich an Mantle was ja auch Open Source war
War es nicht.
robbitop
2024-03-05, 10:07:19
War es nicht.
Oh ok - danke für die Korrektur. Aber zumindest konnte das IIRC jeder IHV unterstützen der es wollte. Ich meine es war zumindest dokumentiert so dass jeder einen Treiber dafür schreiben konnte.
Ganon
2024-03-05, 10:18:32
Aber zumindest konnte das IIRC jeder IHV unterstützen der es wollte.
Auch das nicht:
https://www.heise.de/news/AMD-beerdigt-3D-Schnittstelle-Mantle-1-0-und-empfiehlt-DirectX-12-und-Vulkan-2566057.html
AMD hat Mantle bis zum heutigen Tag nicht für Grafikeinheiten von Intel und Nvidia geöffnet.
AMDs "Öffnung" von Mantle heißt Vulkan, DX12 oder Metal. Aus der damals noch geplanten Öffnung von Mantle ist nie etwas geworden. Am Ende hat nur die Idee überlebt.
robbitop
2024-03-05, 10:21:14
OK dann hatte ich das falsch im Hinterkopf. Danke für die Korrektur.
Achill
2024-03-05, 13:10:35
[..]
AMDs "Öffnung" von Mantle heißt Vulkan, DX12 oder Metal. Aus der damals noch geplanten Öffnung von Mantle ist nie etwas geworden. Am Ende hat nur die Idee überlebt.
Stimmt so auch nicht ganz, AMD hat Mantle schon geöffnet, nur nicht für die Öffentlichkeit in Form eines OSS Projekts. Der Quellcode ging schon (Speculation im Fall von MS) an MS und die Khronos Group ... das ist dann doch etwas mehr als nur die Idee. Und wer wirklich SW entwickelt weiß, dass man basieren auf einer funktionierenden Umsetzung (also API, Treiber, Tests, Doku usw) diese viel leichter Iterative weiter entwickeln kann.
[..]
In fact Khronos has confirmed that AMD has contributed Mantle towards the development of Vulkan, and though we need to be clear that Vulkan is not Mantle, Mantle was used to bootstrap the process and speed its development, making Vulkan a derivation of sorts of Mantle (think Unix family tree). What has changed from Mantle is that Khronos has gone through a period of refinement, keeping what worked in Vulkan and throwing out portions of Mantle that didn’t work well – particularly HLSL and anything that would prevent the API from being cross-vendor – replacing it with the other necessary/better functionality.
[..]
https://pbs.twimg.com/media/CBBu9COWwAAPzZB?format=jpg&name=medium
Ganon
2024-03-05, 13:26:38
Und wer wirklich SW entwickelt weiß, dass man basieren auf einer funktionierenden Umsetzung (also API, Treiber, Tests, Doku usw) diese viel leichter Iterative weiter entwickeln kann.
Sicherlich, aber letztendlich bleibt die Idee. Sie ist natürlich untermauert mit einer herstellerspezifischen Beispielimplementierung, aber es ist nicht so, dass z.B. Vulkan einfach nur Mantle mit leichtem Fine-Tuning ist.
Dass AMD Mantle als Vorlage für eine neue API bereitgestellt hat, will ich auch gar nicht abstreiten. Aber zu dem Zeitpunkt als Mantle auch nur mimimal Verwendung fand war es weder Open Source, noch war es für andere Hersteller möglich es zu implementieren. Und nach der Übergabe, gab es kein "offenes Mantle", sondern gänzlich neue APIs.
fondness
2024-03-05, 14:12:16
Dass AMD Mantle als Vorlage für eine neue API bereitgestellt hat, will ich auch gar nicht abstreiten. Aber zu dem Zeitpunkt als Mantle auch nur mimimal Verwendung fand war es weder Open Source, noch war es für andere Hersteller möglich es zu implementieren. Und nach der Übergabe, gab es kein "offenes Mantle", sondern gänzlich neue APIs.
Sie hätten es gerne weiter laufen lassen und OpenSource gemacht. Die andere waren halt für eine unabhängige Vulkan/DX Implementierung.
=Floi=
2024-03-05, 14:55:37
Vergleiche die Trägheit von MS mit Opensource.
und das ist noch nett geschrieben. Win10 bekommt sicher auch nix.
DrFreaK666
2024-03-05, 20:48:36
Was spricht denn dagegen auf Win11 upzugraden, außer wenn die Hardware nicht reicht?
TheAntitheist
2024-03-06, 04:23:56
Was spricht denn dagegen auf Win11 upzugraden, außer wenn die Hardware nicht reicht?
was spricht dafür? =D
Performance war lange schlechter (mindestens 1+Jahr). Wie es heute ist kA, finde viele Menüs sind versteckt und schlechter erreichbar.
Loeschzwerg
2024-03-06, 07:12:43
Für alle Win11 Verweigere: Schaut euch AtlasOS an ;) Und jetzt btt.
DrFreaK666
2024-03-24, 21:50:34
Microsoft DirectSR API Is Based on AMD FSR 2.2.2 ...
Built-in variants will ship as part of Direct SuperResolution and will be used across all hardware, while other variants will be specific to particular GPU/NPU hardware. All the available techniques will be enumerated, allowing the developer to pick which one they want...
Since AMD Fidelity FX Super Resolution 2 was originally written as a general-purpose shader program and works on any graphics cards that support Compute Shader 6.2, Microsoft has decided to integrate the core processing of AMD FSR2 into the DirectSR runtime.
https://wccftech.com/microsoft-directsr-api-is-based-on-amd-fsr-2-2-2/
FSR2.2.2 wird also eine Art Standard, wenn man keine zusätzliche Arbeit haben will?
vinacis_vivids
2024-03-24, 22:42:57
Kompatibilität = Standard.
DrFreaK666
2024-03-25, 01:08:03
wieso nicht TAAU? Zu simpel im Vergleich?
robbitop
2024-03-25, 04:32:42
wieso nicht TAAU? Zu simpel im Vergleich?
Epics TAAU? Nicht open source und nur für UE verfügbar. Außerdem dank TSR obsolet und schlechter als FSR2.
fondness
2024-03-25, 07:41:02
tja OpenSource ist für AMD nur gut wenn es von AMD kommt... das ist so lächerlich.
Lächerlich ist es, AMD für open source zu kritisieren, während NV defacto alles vendor locked und closed source macht.
DrFreaK666
2024-03-25, 07:44:16
Bitte beim Thema bleiben
basix
2024-03-25, 13:26:37
https://wccftech.com/microsoft-directsr-api-is-based-on-amd-fsr-2-2-2/
FSR2.2.2 wird also eine Art Standard, wenn man keine zusätzliche Arbeit haben will?
Ich glaube eher, dass FSR 2.2.2 der Minimal-Fallback ist, wenn der GPU-Treiber nichts anderes anbietet. Ist das einzige Verfahren, welches Hersteller unahbängig und auch mit relativ alten GPUs wie Pascal oder Vega funktioniert. DLSS und XeSS sind da schwieriger. Klar, kann man hier noch von Spiel-Seite sagen, dass der Treiber nichts machen darf und man sich auf FSR 2.2.2 beschränkt (absolute Minimalvariante). Generell dürfte man aber von Seiten GPU-Treiber aktuellere Verfahren anbieten können.
Fixiert man auf FSR 2.2.2 kann man zu heutigen Zeitpunkt auch eine Verifikation machen, dass es überall mit allen GPUs so wie gewünscht funktioniert. Bei neuen GPUs oder API Erweiterungen kann man erneuerte Verfahren bereitstellen, ohne das Rückwärtskompatibilität flöten geht. Damit werden zukünftige Änderungen ebenfalls vereinfacht, es gibt immer die funktionierende Fallback-Variante.
Ich hoffe zumindest, dass diese "Enumeration" der Algos nicht dazu führt, dass ein Spiel keine neuen vom Treiber bereitgestellten Verfahren verwenden kann. Ich hoffe, das ist sowas wie eine >= Versionierung, welche das Spiel verwenden kann. Den Rest regelt der Treiber.
Da hätte man wenigstens noch bis FSR3.1 warten können.
Lurtz
2024-03-25, 21:11:17
Wäre schon ziemlich "toll" wenn FSR 2.x dann die Standardversion wird und man sie weiterhin nicht updaten kann :frown:
basix
2024-03-25, 21:18:13
Da hätte man wenigstens noch bis FSR3.1 warten können.
Im Zusammenhang mit DirectSR habe ich noch nichts zu Frame Generation gehört. Geht immer nur um Super Resolution. Frame Generation ist noch etwas zu neu und hat noch lange nicht den Reifegrad von Temporal Upsampling. Die nächste DirectSR Version wird es vermutlich dann mit FG erweitern, nehme ich an.
Wäre schon ziemlich "toll" wenn FSR 2.x dann die Standardversion wird und man sie weiterhin nicht updaten kann :frown:
Deswegen sage ich ja: Fallback. AMD kann das mit besseren FSR Varianten ersetzen und Nvidia mit DLSS. Ich nehme an, dass der Spieleentwickler die Hoheit behält, ob man das zulassen will. Denke aber schon, dass man das wird, da z.B. DLSS2 im Regelfall ja schon besser ist als FSR2. Und beim "FSR-Next" wird das vermutlich ebenfalls so sein. Ich kann mir gut vorstellen, dass FSR 2.2.2 die letzte FSR2.x Version ist (ausserhalb von Bug Fixes) und als nächstes was neues kommt.
The_Invisible
2024-03-25, 21:43:50
Im Zusammenhang mit DirectSR habe ich noch nichts zu Frame Generation gehört. Geht immer nur um Super Resolution. Frame Generation ist noch etwas zu neu und hat noch lange nicht den Reifegrad von Temporal Upsampling. Die nächste DirectSR Version wird es vermutlich dann mit FG erweitern, nehme ich an.
Wäre aber auch "mehhh", zumindest wenn man nicht DirectSR mit einem externen FG kombinieren kann. Bis DirectSR spruchreif ist, ist doch schon die nächste GPU Gen draußen, wer weiß was es bis dort wieder neues gibt. MS ist da einfach zu langsam, DLSS gibts schon seit 2018, vielleicht hätte man sich doch Streamline oder so ansehen sollen...
DrFreaK666
2024-03-25, 22:26:57
Streamline ist auch nur Upscaling, oder würde Nvidia einfach AMDs FG erlauben?
Im Zusammenhang mit DirectSR habe ich noch nichts zu Frame Generation gehört.
FSR3.1 wird ein major upgrade vom Upsampling.
aufkrawall
2024-03-26, 01:32:22
Ich kann keinen anderen Zweck von DirectSR ausmachen, als StreamLine zu schaden. Nach AMD, hat offenbar auch Microsoft keine Lust, eines von Nvidias vergifteten Geschenken anzunehmen.
DrFreaK666
2024-03-26, 09:25:41
Da es Teil von DX wird, dürfte es für Entwickler noch einfacher sein es zu nutzen
The_Invisible
2024-03-26, 10:10:56
Streamline ist auch nur Upscaling, oder würde Nvidia einfach AMDs FG erlauben?
Streamline ist nur ein OpenSource Framework das selber nix tut außer die Schnittstellen zu vereinheitlichen. Mit Plugins kann da jeder andocken. Zudem ist es schon "battle-testet", aktiv in vielen Games und auch als UE5 Plugin.
Aber gut, OpenSource ist halt anscheinend nicht OpenSource, kommt immer auf den Vendor an von dem es kommt. Sollte DirectSR wirklich nur mit Upscaling kommen wäre das eher ein Rückschritt.
DrFreaK666
2024-03-26, 10:17:24
Das SR steht ja für Super Resolution, da FSR in Zukunft mit jedem Upscaler funktioniert, sollte es ein Kleines sein beide FG-Techniken einzufügen. Wäre aber natürlich besser wenn es Teil von DirectSR wäre
Exxtreme
2024-03-26, 10:20:45
Aber gut, OpenSource ist halt anscheinend nicht OpenSource, kommt immer auf den Vendor an von dem es kommt.
Natürlich. Es hängt imer davon ab, welche Erfahrungen man mit bestimmten Herstellern gemacht hat. Und es ist kein Geheimnis, dass sich Nvidia und Micros~1 wegen der ersten Xbox nicht mehr sehr gut verstehen.
Sollte DirectSR wirklich nur mit Upscaling kommen wäre das eher ein Rückschritt.
Ein Rückschrit zu was? Zu nichts?
DrFreaK666
2024-03-26, 10:22:31
Natürlich. Es hängt imer davon ab, welche Erfahrungen man mit bestimmten Herstellern gemacht hat. Und es ist kein Geheimnis, dass sich Nvidia und Micros~1 wegen der ersten Xbox nicht mehr sehr gut verstehen.
Es ist auch bekannt dass MS und NV gemeinsam an RT für DX gearbeitet haben
The_Invisible
2024-03-26, 10:33:56
Natürlich. Es hängt imer davon ab, welche Erfahrungen man mit bestimmten Herstellern gemacht hat. Und es ist kein Geheimnis, dass sich Nvidia und Micros~1 wegen der ersten Xbox nicht mehr sehr gut verstehen.
Ein Rückschrit zu was? Zu nichts?
Ob das noch relevant ist, MS hat jedenfalls 150k H100 GPUs bestellt...
Rückschritt im Sinne von weil es 2 FG Implementierungen schon gibt, aber mal sehen wie das wirklich implementiert ist.
FSR2.2 läuft halt überall und das performant, daher ist es schlau, das als Grundlage zu nutzen. Klar wird man dann auf RDNA1/2-Karten FSR 3.1 nutzen und ab RDNA3 dann das AI FSR.
DrFreaK666
2024-03-26, 10:46:22
Was einige übersehen: das zweite Logo oben rechts neben dem Windows-Logo.
MS hat natürlich auch Interesse daran, dass Upscaling öfters in Xbox-Games genutzt wird. Da ist Steamline eher keine Hilfe
basix
2024-03-27, 09:41:46
Wie gesagt, FG ist einfach noch zu neu und instabil für solch eine "Industrie-Standard" API. Wartet noch 1 Jahr, dann kommt das auch.
Wie gesagt, FG ist einfach noch zu neu und instabil für solch eine "Industrie-Standard" API. Wartet noch 1 Jahr, dann kommt das auch.
Wer redet von FG?
aufkrawall
2024-03-27, 22:14:48
Da ist Steamline eher keine Hilfe
Wieso nicht, wenn es mit D3D12 funktioniert? Ich würde eher annehmen, dass sie eben verhindern wollen, dass sich solche Abhängigkeiten für so wichtige Features zu Nvidia auf der Xbox einstellen. Bei AMD haben sie halt die Garantie, dass es keine Fouls von ihnen geben wird, weil sie auch u.a. Partner für den SoC sind.
MS hat natürlich auch Interesse daran, dass Upscaling öfters in Xbox-Games genutzt wird. Da ist Steamline eher keine Hilfe
Streamline ist open source, was bedeutet dass man es für jede Plattform die man möchte kompilieren kann.
Exxtreme
2024-03-28, 11:41:20
Streamline ist open source, was bedeutet dass man es für jede Plattform die man möchte kompilieren kann.
Micros~1 kontrolliert Streamline aber nicht. Und das dürfte wohl das Problem sein. Und was mit Opensource passieren kann, das sieht man aktuell bei Redis.
https://lwn.net/Articles/966133/
Micros~1 kontrolliert Streamline aber nicht. Und das dürfte wohl das Problem sein.
Jeder der möchte kontrolliert was Opensource ist.
aufkrawall
2024-03-28, 15:37:31
Ist dann aber Aufwand und könnte mit einem Fork enden, was unschön für Entwickler ist.
Ganon
2024-03-28, 15:52:21
Ich finde es schon witzig, dass es hier überhaupt eine Diskussion darüber gibt, dass Microsoft eine eigene API macht, statt was vorhandenes zu verwenden :ugly:
The_Invisible
2024-03-28, 15:53:15
Micros~1 kontrolliert Streamline aber nicht. Und das dürfte wohl das Problem sein. Und was mit Opensource passieren kann, das sieht man aktuell bei Redis.
https://lwn.net/Articles/966133/
Naja, gibt halt einen Fork und weiter gehts, wär net das erste mal, ist ja das Gute an OpenSource...
@Ganon
Deswegen meinte ich ja Streamline, aber gut, sich neu erfinden geht ja auch
Exxtreme
2024-03-28, 15:57:51
Naja, gibt halt einen Fork und weiter gehts, wär net das erste mal, ist ja das Gute an OpenSource...
Mit einem Fork hätte man dann die gleiche Situation wie jetzt auch. ;) Und es ist halt so, dieses API ist weiterhin freiwillig. Sprich, die Entwickler müssen es nicht anbieten und können weiterhin Streamline nutzen.
Lurtz
2024-03-28, 16:28:52
Obligatorisch:
https://imgs.xkcd.com/comics/standards.png
Mit einem Fork hätte man dann die gleiche Situation wie jetzt auch. ;)
Nur völlig unnotwendig, und vor allem lustig wie alle jubeln wenn ein Großkonzern was proprietäres für ein bestehendes Problem bringt für welches es schon eine OS Lösung gibt.
basix
2024-03-31, 11:33:01
DirectSR soll ja FSR 2.2.2 mitbringen. Ich hätte nun gehofft, dass es doch noch FSR 3.1 wird, da anscheinend das Temporal Upsampling verbessert wird: https://www.pcgameshardware.de/FidelityFX-Super-Resolution-Software-277617/News/AMD-stellt-das-neue-FSR-vor-1443490/
Also genauer gesagt meine ich damit, FSR 3.1 ohne FG.
*Daumen drück*
DrFreaK666
2024-03-31, 17:06:08
Wäre schon nicht schlecht. Das würde weniger Arbeit für Entwickler bedeuten
aufkrawall
2024-03-31, 17:23:42
Also genauer gesagt meine ich damit, FSR 3.1
Glaub ich noch nicht, weil 3.1 die neue FidelityFX SDK API erfordern soll. Sonst wäre das einfach nur eine 1:1 Kopie mit Microsoft-Label, was sie doch etwas lächerlich aussehen lassen würde. Gut, aber nur FSR 2.2 wäre natürlich noch lächerlicher...
robbitop
2024-03-31, 17:49:59
Ggf ist ein Teil des Qualitätsgewinn Teil der API? Die dann, korrekt implementiert, dafür sorgt dass FSR in jedem Fall immer die korrekten Inputs bekommt (also die Implementierungsgüte konsistenter wird und potentiell immer so gut wie möglich -> quasi nur noch best cases)?
Nur als Gedanke - ob das so klappt -> keine Ahnung.
basix
2024-03-31, 18:03:39
Wenn ich das hier lese, scheint es zumindest keine grösseren funktionellen Unterschiede zu geben. Also keine neuen Inputs fürs Upscaling benötigt, mehr eine Umstrukturierung.
This will be launched alongside AMD FSR 3.1. It is designed to significantly lower our ABI surface, and encourage DLL use across the board. This allows better debugging capabilities, and also enable game developers to upgrade to new versions of FSR faster and with fewer code changes.
With AMD FSR 3.1, the frame generation can run with any third party upscale component – with the small caveat that an additional step is required to precompute some data from the upscaler inputs.
Neue AMD FidelityFX API:
Vereinfacht das Debuggen für Entwickler und ermöglicht die Vorwärtskompatibilität mit aktualisierten Versionen von FSR.
Vorwärtskompatibilität ist doch genau das, was man mit DirectSR auch will. Und für AMD & Microsoft wäre es ja smart, wenn man bei der Implementation von DirectSR auch in diese Richtung gedacht hat. Und für AMD wäre es doppelt smart, wenn man die eigene API daran angleicht.
dildo4u
2024-05-21, 15:09:48
Auto SR erstmal nur für Snapdragon SOC.
https://videocardz.com/newz/windows-automatic-super-resolution-auto-sr-to-be-initially-limited-to-copilot-pcs-with-qualcomm-x-elite-processors
aufkrawall
2024-05-29, 19:35:57
Ich kann keinen anderen Zweck von DirectSR ausmachen, als StreamLine zu schaden.
Sagen sie nun quasi auch ganz offen :eek: :
DirectSR itself is a standalone solution, meaning it removes the need to integrate vendor-specific SDKs or package vendor-specific libraries with your title.
https://devblogs.microsoft.com/directx/directsr-preview/
robbitop
2024-05-29, 21:34:08
Ist halt ohne Geschmäckle da es nicht von einem IHV kommt. Dementsprechend hat das bessere Chancen auf breitere Unterstützung von allen IHVs.
DrFreaK666
2024-05-29, 22:18:49
Falls sich jemand dafür interessiert
Microsoft® DirectSR and AMD FidelityFX™ Super Resolution technology
https://gpuopen.com/learn/microsoft-directsr-announced/
Ist aber eher was für Entwickler
aufkrawall
2024-05-29, 22:27:32
Ist halt ohne Geschmäckle da es nicht von einem IHV kommt. Dementsprechend hat das bessere Chancen auf breitere Unterstützung von allen IHVs.
Aber offenbar dafür schon wieder halbgare Kacke von Microschrott, da kein Wort erwähnt hinsichtlich einer Funktionalität für FG oder Latenzreduktion.
Erinnert an die nutzlose (zumindest laut Nixxes) DirectStorage GPU Dekompression ohne gleichzeitigen Hardware-Standard für Fixed Function-Einheiten...
Ist halt ohne Geschmäckle da es nicht von einem IHV kommt. Dementsprechend hat das bessere Chancen auf breitere Unterstützung von allen IHVs.
es hat aber auch ein Geschmäckle das AMD, auf Kosten der Kunden, sich gegen Streamline gestellt hat. Für alle Konsumenten macht es keinen Unterschied und Streamline war doch OpenSource... Es geht AMD nicht um OpenSource
Lurtz
2024-05-30, 07:59:26
Ist halt ohne Geschmäckle da es nicht von einem IHV kommt. Dementsprechend hat das bessere Chancen auf breitere Unterstützung von allen IHVs.
Wenn es von Microsoft kommt muss man sich allein um die Ausführung und die Pflege große Sorgen machen. Könnte ein Schritt vor, drei Schritte zurück sein.
Ist halt ohne Geschmäckle da es nicht von einem IHV kommt.
Aber von einem ISV. Take your poison.
Achill
2024-05-30, 09:46:51
Ich verstehe hier einige nicht, es wird so getan als ob MS bei APIs den Gaming Bereich nichts tut. Gibt es keine Weiterentwicklung / Pflege bei DX12? Beispiele sind doch:
- Direct Storage
- DXR
- Mesh Shader
- Work Graphs
... und was ich noch so vergessen habe.
Das es nicht Streamline wird, war imho klar, MS wird sich weder an die API noch an den Namen binden und damit NV unterstützen, dafür definiert NV's Marketing zu oft was zukünftig möglicherweise Gaming bedeutet. Dies setzten zum Teil auch die Konsolen unter drucken ... ist aber nur meine Meinung.
Aber anstatt hier traurig zu sein, dass es nicht Streamline geworden ist, sollten die entsprechenden Leute lieber trommeln, dass NV in ihren offenen Ansatz DirectSR als Lösung für den Teil des Upscaling aufnehmen .. dann könnten wir sehen, wie ernst es NV mit der Integration von anderen Lösung nimmt. Gewinnen würde NV dann immer noch, da Reflex und DLSS-FG out of the box mit dabei wären.
robbitop
2024-05-30, 10:58:11
es hat aber auch ein Geschmäckle das AMD, auf Kosten der Kunden, sich gegen Streamline gestellt hat. Für alle Konsumenten macht es keinen Unterschied und Streamline war doch OpenSource... Es geht AMD nicht um OpenSource
Nvidia übernimmt auch nichts was von AMD kommt und OpenSource ist. Sind halt Wettbewerber. Das ist leider normal.
Aber von einem ISV. Take your poison.
Naja die Schnittstellen, die MS zur Verfügung stellt werden seit Jahrzehnten von IHVs genutzt. Da gibt es einen Trackrecord und MS ist auch kein Wettbewerber der IHVs.
Es geht mir ja nicht darum, so zu tun als wären die Entscheidungen richtig oder falsch sondern darum zu erklären warum sie (IMO) so getroffen werden.
The_Invisible
2024-05-30, 14:02:06
Aber von einem ISV. Take your poison.
Joah, eigentlich müssten dann alle auf Vulkan gehen wenn man schon auf den OpenSource Pferd herumreitet... MS ist in der Hinsicht nämlich noch ein größerer Monopolist.
Exxtreme
2024-05-30, 14:30:15
es hat aber auch ein Geschmäckle das AMD, auf Kosten der Kunden, sich gegen Streamline gestellt hat. Für alle Konsumenten macht es keinen Unterschied und Streamline war doch OpenSource... Es geht AMD nicht um OpenSource
Niemand, der bei Verstand ist, übernimmt irgendetwas von Nvidia. Vor allem dann nicht wenn man die Konkurrenz ist. Übrigens, Intel macht bei Streamline auch nicht mit. Und die wissen bestimmt auch sehr genau warum sie da nicht mitmachen.
fondness
2024-05-30, 15:44:27
Niemand, der bei Verstand ist, übernimmt irgendetwas von Nvidia. Vor allem dann nicht wenn man die Konkurrenz ist. Übrigens, Intel macht bei Streamline auch nicht mit. Und die wissen bestimmt auch sehr genau warum sie da nicht mitmachen.
This. Eine Firma die wie Nvidia auftritt braucht sich echt nicht wundern.
DrFreaK666
2024-10-24, 11:50:26
Microsoft DirectSR gains AMD FSR 3.1 upscaling support
https://videocardz.com/pixel/microsoft-directsr-gains-amd-fsr-3-1-upscaling-support
FSR 2.2 wird ersetzt. Das könnte erklären wieso manche Games nur FSR 2.2 hatten
basix
2024-10-24, 20:44:22
Wäre cool, wenn das dann auch mit FSR4 passieren würde ;)
aufkrawall
2024-10-24, 21:41:34
Immer noch kein FG, und die reguläre FSR 3.1.1-Implementierung hat mittlerweile auch noch Anti-Lag 2 dabei (keine Ahnung, ob "auf Kopfdruck"). Wie blöd sind die bei Microschrott eigentlich, die Funktionalitätslücke also noch weiter anwachsen zu lassen? Was ein überflüssiger Müll.
Exxtreme
2024-10-24, 22:08:59
FSR kann weg
Warum? Das Ding ist herstellerneutral und läuft auch auf jeder Gurke, auch nachträglich.
Platos
2024-10-24, 22:39:58
https://videocardz.com/pixel/microsoft-directsr-gains-amd-fsr-3-1-upscaling-support
FSR 2.2 wird ersetzt. Das könnte erklären wieso manche Games nur FSR 2.2 hatten
Also was heisst das? Jedes Spiel mit FSR 2.x wird ersetzt durch 3.1 ? Oder wie muss man das verstehen?
Warum? Das Ding ist herstellerneutral und läuft auch auf jeder Gurke, auch nachträglich.
Auf richtigen Gurken (IGPs) läuft es jetzt auch nicht so toll.
aufkrawall
2024-10-24, 22:48:54
Auf APUs ist FSR 1 tatsächlich oft massiv schneller, mit 2/3 kommt man oft kaum in spielbare Bereiche.
DrFreaK666
2024-10-24, 23:05:42
Also was heisst das? Jedes Spiel mit FSR 2.x wird ersetzt durch 3.1 ? Oder wie muss man das verstehen?
Ich verstehe das so: FSR 2.2 war der Standard-Upscaler bei DirectSR. Alle anderen waren optional.
Jetzt wird FSR 3.1 der Standard.
Wenn Entwickler also DirectSR verwenden, dann ist FSR 3.1 auf jeden Fall im Spiel.
Auf APUs ist FSR 1 tatsächlich oft massiv schneller, mit 2/3 kommt man oft kaum in spielbare Bereiche.
FSR2 ist zwar ziemlich billig bei den Compute-Anforderungen, aber die Bandbreitenanforderungen sind durchaus erheblich, zumindest in der offiziellen Variante.
basix
2024-10-25, 09:14:26
Immer noch kein FG, und die reguläre FSR 3.1.1-Implementierung hat mittlerweile auch noch Anti-Lag 2 dabei (keine Ahnung, ob "auf Kopfdruck"). Wie blöd sind die bei Microschrott eigentlich, die Funktionalitätslücke also noch weiter anwachsen zu lassen? Was ein überflüssiger Müll.
Hey, es ist immer noch MS, das dauert ;)
Ich denke aber schwer, dass FG in DirectSR einzug halten wird. Und hey, wenn FSR4 Ray Reconstruction usw. mitbringt das evtl auch ;)
Ich denke vor allem AMD müsste das pushen. Wenn ihre Lösung als standard Upscaler in DirectSR integriert ist und viele Entwickler das verwenden, hat AMD hinsichtlich Upsampling-Technologie Verbreitung langfristig gesehen gewonnen. Jetzt müsste nur noch Qualität und Featureset auf DLSS 3.7 Niveau gehoben werden und das immer noch auf allen GPUs gut laufen.
Warum? Das Ding ist herstellerneutral und läuft auch auf jeder Gurke, auch nachträglich.
Weil es nicht taugt, somit keinen Einsatzzweck erfüllt, weder im Jetzt noch in Zukunft.
Exxtreme
2024-10-25, 12:01:42
Weil es nicht taugt, somit keinen Einsatzzweck erfüllt, weder im Jetzt noch in Zukunft.
Wenn man bedenkt wie viele Spiele es haben, scheint es doch zu was zu taugen. Wenn es nichts taugen würde dann würde man es nicht einbauen.
Wenn man bedenkt wie viele Spiele es haben, scheint es doch zu was zu taugen. Wenn es nichts taugen würde dann würde man es nicht einbauen.
Selbst Sony hat ne bessere Lösung parat. Sagt schon vieles, wenn nicht Alles zum Nutzwert aus.
The_Invisible
2024-10-25, 12:31:29
Hey, es ist immer noch MS, das dauert ;)
Ich denke aber schwer, dass FG in DirectSR einzug halten wird. Und hey, wenn FSR4 Ray Reconstruction usw. mitbringt das evtl auch ;)
Ich denke vor allem AMD müsste das pushen. Wenn ihre Lösung als standard Upscaler in DirectSR integriert ist und viele Entwickler das verwenden, hat AMD hinsichtlich Upsampling-Technologie Verbreitung langfristig gesehen gewonnen. Jetzt müsste nur noch Qualität und Featureset auf DLSS 3.7 Niveau gehoben werden und das immer noch auf allen GPUs gut laufen.
Hätte, hätte Fahrradkette... die sollen lieber schauen das sie RDNA4 + FSR AI zeitig rausbringen bevor sie von Blackwell wieder überrannt werden.
Exxtreme
2024-10-25, 12:32:22
Selbst Sony hat ne bessere Lösung parat. Sagt schon vieles, wenn nicht Alles zum Nutzwert aus.
Sonys Lösung läuft aber nicht auf Gurkenhardware.
basix
2024-10-25, 13:33:37
... die sollen lieber schauen das sie RDNA4 + FSR AI zeitig rausbringen bevor sie von Blackwell wieder überrannt werden.
Logisch, AMD wird hier diese Priorität aber schon selbst haben.
Nur wäre eine DirectSR Integration von FSR4 für AMD wie auch für Spieler vorteilhaft. Deshalb darf man sich das doch auch wünschen ;) Dass MS hier bereits von FSR 2.2 auf FSR 3.1 nachgezogen hat wiederspiegelt zumindest die Bereitschaft von MS, den "Default Pfad" von DirectSR Up-to-Date zu halten und nicht bei FSR 2.2 vergammeln zu lassen. Ich persönlich habe das Update auf FSR 3.1 nämlich nicht erwartet.
robbitop
2024-10-25, 13:39:41
Wäre aber schön wenn sie auch was für FG und Inputlagreduktion gemacht hätten. Source code ist ja da.
Sonys Lösung läuft aber nicht auf Gurkenhardware.
Spielt ja keine Rolle, Intel war da schon weiter mit XeSS und ein Lernprozess stattgefunden, jedoch leider nur mit der XMX Variante und letztlich unterm Strich genauso bedeutungslos wie FSR.
Hätte, hätte Fahrradkette... die sollen lieber schauen das sie RDNA4 + FSR AI zeitig rausbringen bevor sie von Blackwell wieder überrannt werden.
RDNA4 wird schon von Ada überrannt da braucht es nicht mal Blackwell
aufkrawall
2024-10-25, 16:47:43
Jo, etwa eine Cross-Vendor-API für Lag-Reduktion als Äquivalent zu den Hersteller-Vulkan-Extensions. Aber so etwas Sinnvolles kann man vom aktuellen Microsoft wohl nicht mehr zeitnah erwarten. Work Graphs sollen auch Schrott sein...
https://www.phoronix.com/news/VKD3D-Proton-Work-Graphs
TheGood
2024-10-25, 19:20:09
Natürlich ist das sinnvoll und ein grossteil der User sieht die probleme eh nicht. Von daher gibts keinen Grund das nicht zu integrieren....
aufkrawall
2024-10-25, 19:23:03
Ja, macht voll Sinn, das Upsampling via DirectSR zu implementieren, um dann zusätzlich noch alles andere eh reinpacken zu müssen, will man seine Kunden nicht mit fehlenden Features arschen. Deine Ausführung mit lauter validen Argumenten überzeugt voll und ganz...
Auf APUs ist FSR 1 tatsächlich oft massiv schneller, mit 2/3 kommt man oft kaum in spielbare Bereiche.
Yep, das betrifft auch Gammel-GPUs wie Maxwell und Polaris. Hier laufen die neuen Algos nicht so gut (sprich: Beschleunigungsfaktor hält sich in Grenzen), speziell XeSS lahmt. FSR 1 ist dagegen rasant und hilft den Bildraten massiv ... sieht nur nicht gut aus, aber Not, Teufel und so.
MfG
Raff
Exxtreme
2024-10-25, 19:51:32
Das Problem, was FSR 2 und 3 haben, ist dass sie viel Speicherbandbreite brauchen. Und Speicherbandbreite hat man grad bei IGPs nicht. Und deswegen scheitert das. Deshalb, wenn man sowas nutzen will dann auch keinen Bandbreitenkrüppel kaufen.
Lurtz
2024-10-25, 20:39:57
Dann soll Valve einen Algorithmus fürs Steam Deck bauen und AMD kann für Desktop-GPUs endlich was vernünftiges anbieten. Kann doch nicht so schwer sein.
Achill
2024-10-25, 20:59:38
Bei DirectSR ist FSR2 bzw. jetzt dann 3.x nur eine Referenz-Implementierung und fungiert damit als Fallback falls eine Hersteller spezifische Lösung via API im Treiber nicht zur Verfügung steht.
Die spezifischen Lösungen wurden auch schon beworben und wurde auch schon verlinkt.
Was einige übersehen: das zweite Logo oben rechts neben dem Windows-Logo.
MS hat natürlich auch Interesse daran, dass Upscaling öfters in Xbox-Games genutzt wird. Da ist Steamline eher keine Hilfe
https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=87641
Das wir das auch für FG und Input-Reduction brauchen steht außer Frage, ob es in diese oder eine andere API kann, dass ist dann eine andere ...
Das wir das auch für FG und Input-Reduction brauchen steht außer Frage, ob es in diese oder eine andere API kann, dass ist dann eine andere ...
Nicht wirklich, im Gegensatz zu Upsampling ist FG einen Nischenanwendung mit sehr begrenztem Nutzen
robbitop
2024-10-26, 08:32:25
Das Problem, was FSR 2 und 3 haben, ist dass sie viel Speicherbandbreite brauchen. Und Speicherbandbreite hat man grad bei IGPs nicht. Und deswegen scheitert das. Deshalb, wenn man sowas nutzen will dann auch keinen Bandbreitenkrüppel kaufen.
Eines der Studios was Switch Spiele macht hat FSR2 für mobile Plattformen optimiert und damit war der Performancedrop kleiner. Wäre cool wenn es eine „mobile“ Auskopplung von FSR mit diesem Kniff gäbe.
DrFreaK666
2024-10-26, 11:58:20
Das war für No Man's Sky. Bild und Framerate waren stabiler
Hier gibt's Vergleichs-Shots:
https://www.eurogamer.net/digitalfoundry-2023-fixed-on-switch-no-mans-skys-custom-fsr-2-support-dramatically-improves-the-game
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.