Archiv verlassen und diese Seite im Standarddesign anzeigen : Diskussion zu: nVidia will zukünftig eher bessere Upscaler statt (viel) mehr ...
Leonidas
2023-09-25, 12:54:21
Link zur News:
https://www.3dcenter.org/news/nvidia-will-zukuenftig-eher-bessere-upscaler-statt-viel-mehr-rohpower-bringen
Redirion
2023-09-25, 13:41:48
muss ja gar nicht Frame-Generation sein. Ich denke da eher an so etwas wie Variable-Rate-Shading.
Es wird dann noch mehr Pixelbrei produziert, der dann durch irgendwelche Helfer wieder geschärft werden soll.
Man könnte fast meinen, wir entwickeln uns rückwärts. Bald heißt es: 16bit ist das neue 32bit! Jetzt mit "AI-Farb-Upscaler". Wobei, wird bestimmt dann "AI-HDR-Upscaler" sein, man möchte ja "blenden". Beispielsweise kann dann wieder schön verglichen werden gegen total schlechten Bloom Effekt und behaupten, alles sei wieder besser geworden.
Ich erinnere mich noch an einen "Skandal". War das 3DMark2003? Dort hatte Nvidia beim Filtering geschummelt und statt (eingestellem) Anistrophischen Filtering nur den Trillinearen Filter genutzt oder so. Sah ja "vergleichbar" aus, also warum die Rechenleistung investieren.
Ben Carter
2023-09-25, 13:43:44
Ich denke (und z.T. auch fürchte), dass der Weg über mehr AI-Power gehen könnte. Wenn man sich ansieht, was diverse AI Bildgeneratoren liefern, vor allem teils auch an optischer Qualität, dürfte eher so etwas in nVidias Sinn sein.
Die Engine liefert gar keine Bilder, die ausgegeben werden, sondern dient als Beschreibungsgrundlage für einen AI-Bildgenerator, der wiederum das Bild erzeugt. Natürlich wesentlich konsistenter als aktuelle AI-Bildgeneratoren, da auch der Input weitaus spezifischer is. Oder vielleicht eine Mischung aus beidem.
Im Moment sind wir natürlich noch weit davon weg, Bilder auch nur annähernd schnell genug zu erzeugen, doch möglicherweise liegt hier noch viel an Potential.
Kulasko
2023-09-25, 14:32:43
Das ist ja alles schön und gut... aber heißt das dann, dass Spiele gezwungenermaßen Nvidia-exklusive Software einbauen müssen, damit es ausschließlich auf Nvidia-Karten anständig läuft? Das wäre eine ganz neue Dimension von lock-in.
Redirion
2023-09-25, 14:42:07
Die Engine liefert gar keine Bilder, die ausgegeben werden, sondern dient als Beschreibungsgrundlage für einen AI-Bildgenerator, der wiederum das Bild erzeugt. Natürlich wesentlich konsistenter als aktuelle AI-Bildgeneratoren, da auch der Input weitaus spezifischer is. Oder vielleicht eine Mischung aus beidem.
Gibt es schon. Hat sicherlich Potenzial. Wird wieder weniger Festplattenspeicher benötigt.
https://de.wikipedia.org/wiki/Prozedurale_Synthese
Früher unter Moore's Law hat man Hardware Einheiten gekauft bzw. bezahlt, ab nun kauft man Softwareamplikationen teuer ein, die auf dedizierten Cores lediglich beschleunigt werden. Sry wer soll das denn bezahlen bei den Mondpreisen die Nvidia dafür verlangt, wenn man dann deren Ergebnis, bei deutlich geringerer Anzahl aber noch Moore's Law Prinzipien einpreist.
Das sollte mir Nvidia mal erklären! Dann sollte man den Preisvorteil der sich bei Abweichung von dem Prinzipien, auch an den Kunden weitergeben, was Nvidia absolut nicht macht. Geringer Aufwand bei der Hardwarekomplexität bei immer höherem Preis und letztlich Gewinn, ja klar...um nichts anderes geht es diesen Spinnern.
Wer den Unterschied zwischen nativ und DLSS nicht sieht, hat Tomaten auf den Augen. Das sieht nur besser in extrem höheren Auflösungen wie 4 oder 8k im Qualitätsmodus aus, aber definitiv nicht in 1k.
Einfach mal als kühne Spekulation in den Raum gestellt:
Frame Generation als Zwischending zwischen komplettem Frame-Rendering und neural-network unterstütztem Flow-Modell
1. Schritt
Ein Frame wird ganz klassisch gerendert
Kamerawinkel, viele Objekte im 3D Raum, Abbildung der Geometrie auf den Screen, Texturen auf die sichtbaren Flächen machen, Frame zuzammenfügen)
3D Szene und der Frame decken dabei einen Bereich etwas grösser als den Screen ab.
2. Schritt
aktuelle Kamerabewegung bzw Blickwinkel wird erfasst
3. Schritt
3D Szene wird erstellt und auf Veränderungen / Differenzen überprüft: Welche Objekte haben sich merklich bewegt / rotiert und in welche Richtung. Und welche nicht.
4. Schritt
Mithilfe eines neoral networks wird das existierende Frame per Bewegungsvektoren und Flow Modell angepasst. Durch die aktuelle Kamerastellung wird der passende Ausschnitt des zuvorigen grösser gerenderten Frames verwendet. Frameinhalte deren Objekte sich nicht / wenig bewegt haben werden übernommen. Inhalte deren Objekte sich wahrnehmbar bewegt haben werden per Flow Modell angepasst. Bereiche die neu sichtbar werden (z.B. bei Objektkanten) werden vom NN mit spekulativem Inhalt befüllt.
Vorteil soweit:
Der so erstellte Frame benötigt wenig Rechenzeit, und der neue Input (e.g. Kamerabewegung) wird erfasst und berücksichtigt -> sogar reduzierter Input Lag
Nachteile soweit:
ggf Artefakte, Bildfehler, spekulativer Bildinhalt
5. Schritt
Solange die Bildfehler klein bleiben, der initial gerenderte Screenausschnitt bezüglich Kamerabewegung ausreicht, der spekulative Inhalt gerung bleibt werden aus dem initialen gerendertem Frame auf diese Weise weitere Zwischenframes erzeugt
6. Wenn dies nicht mehr der Fall ist:
Sind grosse und/oder viele Framebereiche betroffen, wird ein neuer kompletter Frame gerendert
Sind nur partitiell Screenbereiche betroffen, werden nur diese (partitieller Screen, weniger Pixel) neu gerendert, der Rest des Screens per Flow Modell übernommen.
Beispiel: nahe Objekte in der Bildschirmmitte sind stark von Kamerabewegung betroffen, also wird die Bildschirmmitte neu gerendert. Hintergrund vor allem Himmel bleibt gleich. Der Inhalt des vorherigen Frames wird nur gemäß Kamerabewegung verschoben, aber nicht neu gerendert.
7. Alle Frames laufen durch den spacialen und temporalen DLSS Filter, werden dadurch homogeniesiert, aliasing unterdrückt, Bildfehler verringert bzw "verteilt" etc
Was ist problematisch?
- weite Kamerabewegungen (aber schnelle Kamerabewegungen nicht unbedingt)
- Objekte, vor allem grosse oder im Vordergrund befindliche, welche sich schnell bewegen und/oder schnell rotieren
Also die Überschrift ist schon extremer Clickbait, in einer Form es in der Originalquelle niemals erwähnt wird.
Nirgends hat Nvidia behauptet, dass Upscaler ein Ersatz für Performance sein soll.
Die Grundaussage ist, dass es ineffizient ist einfach rohe Pixel zu pushen, und man mit "intelligenteren" Herangehensweisen ein wesentlich besseres Verhältnis aus Performance und Qualität erreicht, als es mit der stumpfen Berechnung mehrerer Pixel (und Strahlen) möglich wäre.
Und das ist auch schon heute eindeutig der Fall, und es geht nicht rein um Upscaling. ReSTIR als eine intelligente Methode die wichtigen Strahlen zu ermitteln, anstatt einfach die Strahlen pro Pixel zu erhöhen gehört beispielsweise auch dazu.
Und intelligente Entwickler werden auch in Zukunft Methoden finden um die Grafikberechnung effizenter zu gestalten.
Κριός
2023-09-25, 16:38:26
Also die Überschrift ist schon extremer Clickbait, in einer Form es in der Originalquelle niemals erwähnt wird.
Es ist eine Notwendigkeit der Chipfertigung. TSMC 2nm wird zum Vorgänger nur 20% mehr Transistorendichte Liefern. Das soll am Ende bei 15% mehr Leistung oder 25% weniger Leistungsaufnahme rauskommen.
Wenn Grafikkarten nicht auf 1000 Watt und höher gehen sollen, dann sind die Zeiten einfach vorbei, wo man die Leistung recht einfach verdoppeln konnte. Die Transistorendichte nimmt ab und man ist langsam an einem TDP Punkt angelang der auch nicht mehr problemlos gesteigert werden kann.
Ich denke (und z.T. auch fürchte), dass der Weg über mehr AI-Power gehen könnte. Wenn man sich ansieht, was diverse AI Bildgeneratoren liefern, vor allem teils auch an optischer Qualität, dürfte eher so etwas in nVidias Sinn sein.
Die Engine liefert gar keine Bilder, die ausgegeben werden, sondern dient als Beschreibungsgrundlage für einen AI-Bildgenerator, der wiederum das Bild erzeugt. Natürlich wesentlich konsistenter als aktuelle AI-Bildgeneratoren, da auch der Input weitaus spezifischer is. Oder vielleicht eine Mischung aus beidem.
Im Moment sind wir natürlich noch weit davon weg, Bilder auch nur annähernd schnell genug zu erzeugen, doch möglicherweise liegt hier noch viel an Potential.
Auja, vielleicht gibt es demnächst wieder mehr Textadventures und AI macht daraus eine Grafik. Mit ein paar zusätzlichen Parameter kann sich dann jeder seine eigene Welt kreiren.
Der eine mag's quietsche bunt, der andere düst und dunkel. Selbst Gegner könnten flauschige Plüschhasen oder Skelettkrieger sein. Die Möglichkeiten sind schier unbegrenzt
Korvaun
2023-09-25, 17:41:54
Dann bleibt nur noch die Frage wann die ganzen Bildverbesserungs-Verfahren so viel eigene spezialisierte Hardware (AI/Tensor/etc.) brauchen dass sich das Ganze nicht mehr lohnt und man dann doch wieder in "normale" Rohleistung/Hardware investieren kann ;)
AtTheDriveIn
2023-09-25, 17:57:07
Jetzt noch die Spieleentwickler mit Geld um den Fingern wickeln damit DLSS X.Y implementiert wird. Dann jede Kartengeneration mit eigenem DLSS kommen lassen, das nicht (oder nur mit Abstrichen) abwärtskompatibel ist. Schach matt.
In Zügen doch schon bei der jetzigen Generation zu sehen. 4060 ist nur über Softwarefeature überhaupt eine "Verbesserung" zur 3060.
Altehardware
2023-09-25, 18:01:29
Das könnte nvidia so passen
chipentwicklung derzeit zwei Wege möglich
1 man behält das design das mt ampere eingeführt wurde bei, sprich 64+64 davon 32fp32 16 dediziert und bis zu 16 per Treiber aktiviert spielabhängig die norm ist 8 fp32 = 88fp32 per sm
Erhöht die alu in ner sku und gibt mehr takt
gb207 24sm 2gpc 3,2ghz = 13,5tf chipgröße grob 122mm² Kosten etwa 43$ mit 128bit si und 4 *24gbit gddr7 =12gb ~389€ +15% vs ad 107
gb206 36sm gleiche konfig chipgröße bei 152mm² kosten 50$ 4* 24gbit 12gb =409€ +21% ad106
gb205 60sm 235mm² kosten 94$ 6*24gbit gddr7 18gb =649€ +14% vs ad104
neue design was eher anzunehmen ist
96+64 in 32 hybrid davon 16fp32 garantiert +16 fp32 übern treiber wie vorher 8 fp32 garantiert. = 120fp32 per sm
Folglich gb207 18sm 2,7ghz maximal umsetzbar. = 11,6tf chipgröße 121mm² kosten 42$ 9gb gddr7 =319€ 60er sku +-0% aber mehr vram
gb206 36sm 2,7ghz 23,3tf 12gb chipgröße bei 159mm² 59$ Sku ab 429€ 70er sku +10%
gb205 60sm 2,7ghz 38,8tf 18gb chipgröße bei 243mm² kosten ab 104$ 679€ 80er sku +15%
Beide fälle wird rtx50 kein großer sprung werden
Erst in n2x mit gaa wird die Leistung verdoppelt je sku da wird nvidia sich aber dann einfallen die sku nochmal die chips aufzustufen quasi ne 80er sku mit gx106 chip
Der Takt indes wird von 2,7 auf 3,8ghz steigen
n2 bietet etwa 15% dense an gaa halbiert die Fläche
mit n2 wird backside Stromversorgung realisiert was den verbrauch um 50% senkt quasi +25% Takt.
n2x kommt q2 2026 in Serie bei gpu dann ab q2 2027
DXR ist ne andere Geschichte da primär RT core die perf bestimmt und es abhängt wie gut die cpu diese füttern kann.
Ein neues design bedingt weniger Rt cores daher ist das eher fraglich außer nvidia hat den rt core so stark verbessert das dieser mehr bvh erreicht maßgeblich ist hier sar wichtig
Das dxr quasi out of order ermöglicht bedingt aber dlss mit FG
ch sehe es kommen der unterschied wird sein dlss und rt nur der Takt die cores unterscheiden vs ada design.
Aus 24 rt cores wird mit 2,8ghz genauso schnell wie 18rt auf 3,2ghz weil ohne sar und fg kein perf Zuwachs gibt. Einziger Vorteil 9gb statt 8gb vram
Das nvidia marketing da von neuralen rendern fabuliert ist kein wunder bis n2x wird man nicht viel Leistungsplus bekommen.
Als Fazit steht sicher das für mich nur die rtx4060 super bzw rtx5060 ti infrage kommen.
Entweder rtx4060 super 16gb vram mit 20gbps (320gb/s) diese sku sehe ich q1 2024 oder rtx5060ti 12gb ab q2 2025 (384gb/s)
Der Grund ist klar 170w und 140w tbp
mehr darf ne gpu bei mr nicht ziehen
MiamiNice
2023-09-25, 18:02:07
Dann jede Kartengeneration mit eigenem DLSS kommen lassen, das nicht (oder nur mit Abstrichen) abwärtskompatibel ist.
Das war auch mein erster Gedanke.
Leonidas
2023-09-26, 05:26:37
Die Grundaussage ist, dass es ineffizient ist einfach rohe Pixel zu pushen, und man mit "intelligenteren" Herangehensweisen ein wesentlich besseres Verhältnis aus Performance und Qualität erreicht, als es mit der stumpfen Berechnung mehrerer Pixel (und Strahlen) möglich wäre.
Das ist nun exakt " nVidia will zukünftig eher bessere Upscaler statt (viel) mehr Rohpower bringen". Man kann darüber diskutieren, ob es nur Upscaler sein müssen. Aber NV traf diese Aussage in einem 50-Minuten-Video rein zu DLSS und brachte selber in diesem Zusammenhang RR ins Spiel. Die NV-Aussage ist somit zumindest *auch* auf DLSS bezogen. Andere Optimierungs-Möglichkeiten sind zweifellos nicht auszuschließen, so gesehen passt der Titel nur halb. Aber falsch ist er nicht.
Einfach mal als kühne Spekulation in den Raum gestellt:
Frame Generation als Zwischending zwischen komplettem Frame-Rendering und neural-network unterstütztem Flow-Modell ......
+1
Loeschzwerg
2023-09-26, 07:45:06
Unabhängig davon was Nvidia an Entwicklungen in der Pipeline hat, es bräuchte in meinen Augen auch dringend wieder vermehrt Entwickler die mit den vorhanden Ressourcen besser umgehen können. Was da in letzter Zeit vermehrt an schlecht optimierten PC-Spielen auf den Markt kommt ist einfach nicht akzeptabel. Diese Unzulänglichkeiten dann mit neuen Techniken auszubügeln... ganz toll... nicht.
Das ist nun exakt " nVidia will zukünftig eher bessere Upscaler statt (viel) mehr Rohpower bringen".
Das wurde eben überhaupt nicht gesagt, es wurde lediglich gesagt dass es effizienter ist Pixel "intelligenter" zu berechnen als einfach Bruteforce die Pixelanzahlen zu pushen, was jetzt auch nicht großartig überraschend ist, fast überall versucht man Algorithmen zu finden die mit weniger Schritten zum Ziel kommen als alle möglichen Lösungen zu probieren.
Es wurde mit keinem Wort erwähnt wie dieses "intelligenter" aussehen soll
Aber NV traf diese Aussage in einem 50-Minuten-Video rein zu DLSS und brachte selber in diesem Zusammenhang RR ins Spiel. Die NV-Aussage ist somit zumindest *auch* auf DLSS bezogen.
DLSS ist nicht (nur) ein Upscaler, ob das Klug ist, dass Nvidia jetzt alles möglich unter dem Namen DLSS zusammenfasst ist eine andere Geschichte.
So wie es aktuell aussieht ist es eher so als wäre die Kategorie "Upscaling" mit ca. DLSS2.4 mehr oder weniger "Done" mit wenig Luft nach oben.
3.0 war eben Framegeneration, 3.5 Ray Reconstruction, beides sicher mit Luft nach oben. Aber beim Upscaling gab es schon länger keine nennenswerte Fortschritte mehr.
Nvidia wird bestimmt noch weitere Ideen haben, die sie verständlicherweise aktuell noch nicht an die große Glocke hängen wollen. Dass es noch große Sprünge beim Upscaling gibt ist jedenfalls eher Unwahrscheinlich, eher wird es Verbesserungen in den anderen DLSS-Techniken geben, bzw. was ganz neues.
Unabhängig davon was Nvidia an Entwicklungen in der Pipeline hat, es bräuchte in meinen Augen auch dringend wieder vermehrt Entwickler die mit den vorhanden Ressourcen besser umgehen können.
Das gesamte DLSS-Paket ist eine der besten, wenn nicht aktuell sogar die beste Methode um effizienter mit den vorhandenen Ressourcen umzugehen.
Leonidas
2023-09-26, 08:28:50
Nvidia wird bestimmt noch weitere Ideen haben, die sie verständlicherweise aktuell noch nicht an die große Glocke hängen wollen.
Selbstverständlich.
Dass es noch große Sprünge beim Upscaling gibt ist jedenfalls eher Unwahrscheinlich, eher wird es Verbesserungen in den anderen DLSS-Techniken geben, bzw. was ganz neues.
Nein. Das sie DLSS melken wollen, haben sie später nochmal explizit im Video gesagt. Bei 52:30, siehe hier:
https://www.3dcenter.org/news/news-des-25-september-2023
Geldmann3
2023-09-26, 08:59:41
Denke auch, dass die nächste, große Innovation Frame-Generation ohne zusätzlichen Input-Lag ist. (Sogar mit Verringerung der Latenz) Natürlich redet Nvidia nicht darüber, damit die Konkurrenz nicht auch direkt mit den Arbeiten daran beginnt. Denn die Daten des nächsten Frames inklusive User-Inputs hat man bereits, sie sind nur noch nicht gerendert. (Sonst könnte die GPU schließlich nicht beginnen daran zu arbeiten.)
Man nimmt also RGB+Motion-Vektoren+ZBuffer+AI und generiert daraus einen Zwischenframe, bevor der nächste Frame gerendert ist. Natürlich funktioniert auch das umso besser, desto geringer die Differenz zwischen dem aktuellen und dem folgenden Frame ist. Doch ich denke, das ist DLSS 4.0 und Nvidia zeigt es schon mit der nächsten Generation von GPUs...
Ist dann vielleicht der ,,Low Latency Mode" und die alte Frame Generation ,,Quality Mode". Denn sicher erreicht man mit den Bilddaten des nächsten Frames eine noch höhere Qualität.
Könnte mir vorstellen, dass langfristig 1/4 der Output-Auflösung und ein Viertel der Output Framerate das Ziel sein wird und man als letzten Pass irgendwann nochmal eine Generative-AI über das Bild laufen lässt, um der Grafik letztendlich den absoluten ,,photoreal" Look zu geben.
Loeschzwerg
2023-09-26, 09:05:19
Das gesamte DLSS-Paket ist eine der besten, wenn nicht aktuell sogar die beste Methode um effizienter mit den vorhandenen Ressourcen umzugehen.
Das ist völlig unabhängig von generellen Optimierungen zu sehen. Auf z.B. Jedi Survivor kannst du noch so viel "DLSS" werfen, es läuft einfach immer schlecht und stottert.
Auf z.B. Jedi Survivor kannst du noch so viel "DLSS" werfen, es läuft einfach immer schlecht und stottert.
Weil die UE4 nicht wirklich gut für Open World ausgelegt ist.
Dass ist kein Ressourcenproblem sondern ein Architekturproblem, und die Architektur lässt sich nach so vielen Jahren eben nicht mehr großartig ändern.
Altehardware
2023-09-26, 09:20:36
Das wäre technisch unmöglich, das frame gen ist nur mit Latenz möglich.
Was die aussage betrifft das bessere Bildqualität durch ai kommt liegt aber nicht an ai sondern schlicht am denoising von pathtracing man bemerke man vergleicht hier pathtracing vs raytracing was weniger strahlen erzeugt folglich wird auch weniger details sichtbar
Das kostet Leistung und das ne mengel, unter 50tf sieht man kein land auf 1080p für 30fps
Ich sage euch die chips die es aktuell gibt de das schaffen sind ad102 und kommend gb202 (180sm oder 216sm) dieser wird aber nicht am desktop geben
Erst n2x wird min 150tf schaffen und ich meine nicht nvidia Märchen tf (218tf 202tf),sondern die echten.
Die rt cores die anscheinend ohne Takt dxr ermöglichen bsp ga106 vs ad107 (28 vs 24sm) ist die dxr perf identisch Takt vs Takt.
Diese ganze ai Geschichte ist pures marketing
Nein. Das sie DLSS melken wollen, haben sie später nochmal explizit im Video gesagt. Bei 52:30, siehe hier:
https://www.3dcenter.org/news/news-des-25-september-2023
Hier schreibst du eben genau nicht über upscaling.
Denke auch, dass die nächste, große Innovation Frame-Generation ohne zusätzlichen Input-Lag ist.
Framegeneration ohne zusätzlichen Input-Lag, bzw. genauer genommen sogar zur Reduktion des Input-Lags existiert schon lange in den VR-Frameworks.
Man nimmt also RGB+Motion-Vektoren+ZBuffer+AI und generiert daraus einen Zwischenframe, bevor der nächste Frame gerendert ist.
Davon gehe ich auch aus, dass was derartiges kommen wird, wichtig ist es dass man die User-Inputs für die generierten Frames mit berücksichtigt, was speziell in FirstPerson gar nicht so schwer ist.
Das Hauptproblem ist Disocclusion, bei dem man ohne echten nächsten Frame nicht wirklich sagen kann was im vorherigen verdeckt war. Eigentlich muss das NN "nur" gut genug werden, dass die vorhersagen für verdeckte Bereiche gut genug werden, dass es nicht mehr auffällt.
Vorher wird aber wohl DLSS4.0 mit Ray Reconstruction in seiner finalen Form kommen, 3.5 hat ja noch eher den Status einer Tech Preview.
Das wäre technisch unmöglich, das frame gen ist nur mit Latenz möglich.
Wenn meine Prediction gut genug ist, dass ich nur aus vergangenen Frames ein neues berechnen kann ohne das nächste zu kennen, ist es sehr wohl möglich FG ohne zusätzliche Latenz zu machen.
Genau genommen wäre sogar FG mit verringerter Latenz möglich, wenn man die User-Inputs mit der Frequenz der angezeigten anstatt der real berechneten Frames samplet.
Leonidas
2023-09-26, 09:48:58
Hier schreibst du eben genau nicht über upscaling.
Das hast Du vom genauen Wortinhalt sogar Recht, mir eben erst selber aufgefallen.
Aber ich sehe das sinngemäß: All dies läuft unter dem Stichwort "Upscaler", wie auch die genaue Technik dahinter aussehen mag. Zukünftig kann der kleinere Teile davon wirkliches Upscaling sein, der größere Teil aus KI bestehen. Aber auch das ist Upscaling im eigentlichen Sinn: Aus kleinerem Datenbestand dennoch wieder das Original herzustellen.
Exxtreme
2023-09-26, 10:11:20
Das wäre technisch unmöglich, das frame gen ist nur mit Latenz möglich.
Das stimmt so auch nicht. Die bisherige FG-Implementierung hat deshalb zusätzliche Latenz weil diese Implementierung ein Interpolator ist. Es sind aber FG-Implementierungen möglich, die die zusätzlichen Bilder extrapolieren. Das wäre dann praktisch ohne zusätzliche Latzenz möglich. Extrapolatoren haben aber ihre eigenen Nachteile.
Platos
2023-09-26, 11:37:56
Denke auch, dass die nächste, große Innovation Frame-Generation ohne zusätzlichen Input-Lag ist. (Sogar mit Verringerung der Latenz) Natürlich redet Nvidia nicht darüber, damit die Konkurrenz nicht auch direkt mit den Arbeiten daran beginnt. Denn die Daten des nächsten Frames inklusive User-Inputs hat man bereits, sie sind nur noch nicht gerendert. (Sonst könnte die GPU schließlich nicht beginnen daran zu arbeiten.)
Man nimmt also RGB+Motion-Vektoren+ZBuffer+AI und generiert daraus einen Zwischenframe, bevor der nächste Frame gerendert ist. Natürlich funktioniert auch das umso besser, desto geringer die Differenz zwischen dem aktuellen und dem folgenden Frame ist. Doch ich denke, das ist DLSS 4.0 und Nvidia zeigt es schon mit der nächsten Generation von GPUs...
Ist dann vielleicht der ,,Low Latency Mode" und die alte Frame Generation ,,Quality Mode". Denn sicher erreicht man mit den Bilddaten des nächsten Frames eine noch höhere Qualität.
Könnte mir vorstellen, dass langfristig 1/4 der Output-Auflösung und ein Viertel der Output Framerate das Ziel sein wird und man als letzten Pass irgendwann nochmal eine Generative-AI über das Bild laufen lässt, um der Grafik letztendlich den absoluten ,,photoreal" Look zu geben.
Wie soll das gehen? Man kann ja nicht erahnen, was der Gamer für eine Bewegung macht. Man müsste dann quasi erraten, was als nächstes kommt. Wenn ich z.B eine Richtungsänderung mache, würde das gar nicht funktionieren. Wenn ich mich beispielsweise gerade nach rechts drehe und mich jetzt nach links drehe, wird zuerst ein Bild erzeugt, dass weiter nach rechts dreht.
Das dürfte sich vermutlich ziemlich komisch anfühlen. Ich mach' A, Bild zeigt aber B.
Und wenn man solche Bilder einfach auslässt, dürfte es ja genau in dem Moment ein Einbruch der Framerate geben und genau bei Richtungswechsel wird es dann also stocken.
Aber selbst bei einer einfachen Drehung, wie soll das funktionieren? Man braucht doch 2 Vektoren, um eben das Mittelstück zu berechnen. Mit nur einem, wie geht das ? Ein Vektor alleine gibt ja nur die Richtung an, aber keine Richtungsänderung. Dafür braucht es ja immer 2.
Wie wird das eig. momentan gemacht? Wird das 2. Bild komplett fertig gerendert und erst dann das Zwischenbild berechnet oder werden als allererstes Motion-Vektoren ausgerechnet und dann quasi parallel das Zwischenbild errechnet?
Wie soll das gehen? Man kann ja nicht erahnen, was der Gamer für eine Bewegung macht. Man müsste dann quasi erraten, was als nächstes kommt.
Indem man die Bewegung der letzten vergangenen Frames betrachtet und davon ausgeht dass diese gleich weitergehen, anstatt 1 Frame zurückzuhalten und aufgrund er Bewegungsvektoren zwischen diesen die "Mitte" auszurechnen.
Wenn ich z.B eine Richtungsänderung mache, würde das gar nicht funktionieren. Wenn ich mich beispielsweise gerade nach rechts drehe und mich jetzt nach links drehe, wird zuerst ein Bild erzeugt, dass weiter nach rechts dreht.
Und das könnte man noch damit erweitern, dass die Bewegung der Kamera davon abgezogen wird.
Aktuell ist die statische Referenz die Kamera, die steht virtuell still und die Bewegungsvektoren werden relativ zu dieser ermittelt.
Man könnte allerdings über den Input von Tastatur und Maus bzw. Gamepad auch die Kamera bewegen/rotieren lassen, und damit die Bewegungsvektoren der Frames anpassen. Das erfordert logischerweise eine Integration in die Gameengine selbst, weshalb man es aktuell nicht macht, die aktuelle FG funktioniert mehr oder weniger als PP-Effekt hinten dran.
Das ist auch keine Zukunftsmusik, sondern wird schon seit Jahren für VR-Headsets verwendet. Wenn dein PC die volle Refreshrate nicht schafft wird real nur mehr die halbe Refreshrate berechnet und jedes 2. Bild ist ein generiertes aus dem vorherigen Frame mit der aktualisierten Kopfposition.
Das dürfte sich vermutlich ziemlich komisch anfühlen. Ich mach' A, Bild zeigt aber B.
Wie wird das eig. momentan gemacht? Wird das 2. Bild komplett fertig gerendert und erst dann das Zwischenbild berechnet oder werden als allererstes Motion-Vektoren ausgerechnet und dann quasi parallel das Zwischenbild errechnet?
Die Bewegungsvektoren sind einfach ein Ergebnis des Rendervorganges selbst. Modernes Rendering verwendet nicht 1 Puffer sondern viele verschiedene, und das Bild was du am Ende siehst ist eine Kombination aus diesen. Die Bewegungsvektoren sind einfach ein weiterer Puffer.
Der OFA analysiert dann die fertigen Bilder und korrigiert daraus die Bewegungsvektoren. Das erfolgt immer mit fertigen Bildern.
Die Renderreihenfolge ist:
Frame 1 rendern --> Frame 1 anzeigen
Frame 2 rendern --> Immer noch Frame 1 anzeigen
OFA aus Frame 1 und 2 zur Korrektur der Bewegungsvektoren.
Parallel Frame 3 Rendern und Frame 1,5 interpolieren
In der Zeitlichen Mitte zwischen Frame 1 und 2 Frame 1,5 anzeigen.
Frame 3 fertig gerendert, Frame 2 wird angezeigt und das Spiel beginnt von vorne.
Loeschzwerg
2023-09-26, 12:09:29
Dass ist kein Ressourcenproblem sondern ein Architekturproblem, und die Architektur lässt sich nach so vielen Jahren eben nicht mehr großartig ändern.
Das geht schon Hand in Hand, denn mit stärkerer Hardware lassen sich die Probleme abmildern. Und ganz ehrlich, wir hatten genügend UE4 Spiele mit sehr großen Arealen welche nicht so stark mit diesen Problem zu kämpfen hatten, sofern überhaupt bemerkbar.
Ich will zumindest nicht dass DLSS und damit verbundene neue Techniken nur dazu genutzt werden um schlecht optimierte Spiele erst spielbar zu machen. Das ist keine Kritik an NV, sondern an den Publishern und Studios.
Das geht schon Hand in Hand, denn mit stärkerer Hardware lassen sich die Probleme abmildern.
Logisch. Die Ruckler sind im Prinzip Ladebildschirme, nur gibt es eben keinen Ladebildschirm sondern stattdessen einen kurzen Framespike. UE4 kann eben keine "richtige" Openworld, stattdessen wird die gesamte Openworld in kleinere "Levels" unterteilt und wenn man zwischen denen wechselt gibt es die Nachladeruckler.
Und ganz ehrlich, wir hatten genügend UE4 Spiele mit sehr großen Arealen welche nicht so stark mit diesen Problem zu kämpfen hatten, sofern überhaupt bemerkbar.
Ich kenne kein UE4 Spiel dass dermaßen detailliert ist, was natürlich nicht heißt dass es in Jedi Survivor nicht dennoch besser ginge.
Ich will zumindest nicht dass DLSS und damit verbundene neue Techniken nur dazu genutzt werden um schlecht optimierte Spiele erst spielbar zu machen.
Das eine hat mit dem anderen nichts zu tun.
DLSS macht das Rendering effizienter. Die Laderuckler kommen nicht durch schlechtes/ineffizientes Rendering zustande.
Loeschzwerg
2023-09-26, 13:19:18
Das eine hat mit dem anderen nichts zu tun.
DLSS macht das Rendering effizienter. Die Laderuckler kommen nicht durch schlechtes/ineffizientes Rendering zustande.
Alter... lies doch von Anfang an und wir sparen uns diese ganze Diskussion :freak:
Unabhängig davon was Nvidia an Entwicklungen in der Pipeline hat, es bräuchte in meinen Augen auch dringend wieder vermehrt Entwickler die mit den vorhanden Ressourcen besser umgehen können. Was da in letzter Zeit vermehrt an schlecht optimierten PC-Spielen auf den Markt kommt ist einfach nicht akzeptabel. Diese Unzulänglichkeiten dann mit neuen Techniken auszubügeln... ganz toll... nicht.
Alter... lies doch von Anfang an und wir sparen uns diese ganze Diskussion :freak:
Diese Aussage macht im Bezug auf Jedi Survivor überhaupt keinen Sinn.
Nachladeruckler und ineffizientes Rendering sind ganz einfach 2 paar Schuhe, und Nachladeruckler können eben mit keinem DLSS ausgeglichen werden, und daher macht es auch keinen Sinn darüber zu Diskutieren ob DLSS oder vergleichbare Techniken in irgendeiner Form dazu eingesetzt wird diese auszugleichen, weil es einfach nicht geht.
Das eine spart GPU-Leistung, beim anderen ist die CPU der Flaschenhals.
Loeschzwerg
2023-09-26, 17:27:11
Wo habe ich etwas von einer GPU geschrieben? Gut, vielleicht war das im Kontext mit der News nicht klar (sorry dafür), aber ich meinte schon alle verfügbaren Ressourcen. Survivor läuft auf den Konsolen auch alles andere als gut.
Mir als Gamer bringen tolle neue Techniken nix wenn das Spielgefühl schlichtweg suboptimal ist. Die Basics müssen passen, dann können wir über weitere Dinge reden. Ich möchte gar nicht wissen was im theoretischen Beispiel von Orko in Survivor passieren würde, nachdem ja alle paar Sekunden ein Stottern in der Animation sichtbar ist.
Platos
2023-09-26, 18:42:40
Indem man die Bewegung der letzten vergangenen Frames betrachtet und davon ausgeht dass diese gleich weitergehen, anstatt 1 Frame zurückzuhalten und aufgrund er Bewegungsvektoren zwischen diesen die "Mitte" auszurechnen.
Ok, das habe ich nicht bedacht. Gute Idee, wie es geht, aber der Fehler mit dem Richtungswechsel bleibt dann bei heutigen Engines. Es müssten dann mindestens 2 "echte" Bilder gerendert werden nach einem Richtungswechsel. Weil bei einem Richtungswechsel gibt es ja keine "vergangen Frames", die relevant sind. Somit brauch es wieder 2 Frames.
Das bedeutet, dass mindestens Frames interpoliert werden, die kacke aussehen, wenn man einen Richtungswechsel macht.
Und das könnte man noch damit erweitern, dass die Bewegung der Kamera davon abgezogen wird.
Aktuell ist die statische Referenz die Kamera, die steht virtuell still und die Bewegungsvektoren werden relativ zu dieser ermittelt.
Man könnte allerdings über den Input von Tastatur und Maus bzw. Gamepad auch die Kamera bewegen/rotieren lassen, und damit die Bewegungsvektoren der Frames anpassen. Das erfordert logischerweise eine Integration in die Gameengine selbst, weshalb man es aktuell nicht macht, die aktuelle FG funktioniert mehr oder weniger als PP-Effekt hinten dran.
Das ist auch keine Zukunftsmusik, sondern wird schon seit Jahren für VR-Headsets verwendet. Wenn dein PC die volle Refreshrate nicht schafft wird real nur mehr die halbe Refreshrate berechnet und jedes 2. Bild ist ein generiertes aus dem vorherigen Frame mit der aktualisierten Kopfposition.
Aber damit kann man ja trotzdem noch keine Richtungsänderungen "hervorsehen" ? Oder versteh ich da was falsch? Wenn ich die Richtung ändere, ist das unvorhersehbar, egal ob jetzt die Kamera gedreht wird oder alles relativ zur Kamera.
Ok, das habe ich nicht bedacht. Gute Idee, wie es geht, aber der Fehler mit dem Richtungswechsel bleibt dann bei heutigen Engines. Es müssten dann mindestens 2 "echte" Bilder gerendert werden nach einem Richtungswechsel. Weil bei einem Richtungswechsel gibt es ja keine "vergangen Frames", die relevant sind. Somit brauch es wieder 2 Frames.
So lange du nicht zwischen 2 echten Frames mehrmals die Richtung wechselst funktioniert das immer noch.
Aber damit kann man ja trotzdem noch keine Richtungsänderungen "hervorsehen" ? Oder versteh ich da was falsch? Wenn ich die Richtung ändere, ist das unvorhersehbar, egal ob jetzt die Kamera gedreht wird oder alles relativ zur Kamera.
Wenn du die die Inputs für die FG mit verarbeitest musst du nichts vorhersehen, du weißt genau wann sich die Richtung geändert hat, ganz ohne irgendwelches Raten.
OpenVMSwartoll
2023-09-27, 01:59:26
Verstehe ich das mit meinem simplistischen Weltbild richtig, dass die Generierung von Frames und die Verarbeitung der Eingaben asynchroner werden müssen für optimale Eignung?
Anders ausgedrückt: Hier wird nicht mehr aufeinander gewartet, sondern die Engine bekommt ein Gottvertrauen in die Funktion des NN implementiert und teilt diesem nur noch mit: "Hier sind die Objekte, die Perspektive, die Beleuchtung und hier kommt der Input. Mach mal..."
BlacKi
2023-09-27, 02:10:12
Wenn du die die Inputs für die FG mit verarbeitest musst du nichts vorhersehen, du weißt genau wann sich die Richtung geändert hat, ganz ohne irgendwelches Raten.genau.
gaming mäuse machen 1000hz. input ist da und muss nicht erraten werden.
vinacis_vivids
2023-09-27, 02:26:28
Verstehe ich das mit meinem simplistischen Weltbild richtig, dass die Generierung von Frames und die Verarbeitung der Eingaben asynchroner werden müssen für optimale Eignung?
"Performance is key. FSR 3 includes a highly-optimized optical flow technology, written in pure HLSL, which when combined with our Frame Interpolation pass allows us to generate a new 4K frame in less time than some upscale technologies. These workloads run in asynchronous compute as to not impact the main game render pipeline."
https://gpuopen.com/fsr3-announce/
Frame-Generation ohne Input-Lag kann nur AMD mit FSR 3.
Man nennt es auch "smooth".
Frame-Generation ohne Input-Lag kann nur AMD mit FSR 3.
Du hast wohl +-0 Ahnung von einer Render-Pipeline.
Man nennt es auch "smooth".
Smoothness hat nichts mit dem Input-Lag zu tun, FG erhöht schon heute die Smoothness, auf Kosten des Input-Lags.
TVs können sogar ein sehr smoothes Bild erzeugen, da diese teilweise ein vielfaches der Ausgangsframerate erzeugen, allerdings mit einem extremen Input-Lag von mehreren ms.
Verstehe ich das mit meinem simplistischen Weltbild richtig, dass die Generierung von Frames und die Verarbeitung der Eingaben asynchroner werden müssen für optimale Eignung?
Ich kann mich nicht ganz in dein Weltbild reinversetzen, aber ich würde es eher umgekehrt bezeichnen, die Inputs müssen besser mit den generierten Frames synchronisiert werden. Anstatt diese nur für echte Frames zu berücksichtigen, müssten die Inputs auch als Korrekturfaktor für generierte Frames verwendet werden.
Anders ausgedrückt: Hier wird nicht mehr aufeinander gewartet, sondern die Engine bekommt ein Gottvertrauen in die Funktion des NN implementiert und teilt diesem nur noch mit: "Hier sind die Objekte, die Perspektive, die Beleuchtung und hier kommt der Input. Mach mal..."
Dass ist eher was, was in die Richtung des hypothetischen DLSS10 geht, also wenn dann was für die sehr ferne Zukunft.
Kurz und mittelfristig, werden wir sohl eher Verbesserungen der schon vorhandenen Techniken sehen.
vinacis_vivids
2023-09-27, 09:46:47
Du hast wohl +-0 Ahnung von einer Render-Pipeline.
Input-Lag und Ruckeln von Nvidia kenne ich schon sehr sehr lange. Deswegen kaufe ich seit über 15 Jahren nix mehr von Huang.
Nvidia FG = InputLag = ruckeln
AMD FG = Smoth = flüssig
OpenVMSwartoll
2023-09-27, 19:14:17
Ich kann mich nicht ganz in dein Weltbild reinversetzen, aber ich würde es eher umgekehrt bezeichnen, die Inputs müssen besser mit den generierten Frames synchronisiert werden. Anstatt diese nur für echte Frames zu berücksichtigen, müssten die Inputs auch als Korrekturfaktor für generierte Frames verwendet werden.
Dass ist eher was, was in die Richtung des hypothetischen DLSS10 geht, also wenn dann was für die sehr ferne Zukunft.
Kurz und mittelfristig, werden wir sohl eher Verbesserungen der schon vorhandenen Techniken sehen.
Sorry, war unklar formuliert. Meine Gedanken kreisten des nachts um die Zielsetzung von DLSS10 und die Veränderung, die dafür nötig wäre.
Die Inputs müssen weniger mit generierten Frames synchronisiert werden, als die Frames mit dem User-Input.
Eventuell macht es auch Sinn, spekulativ mehrere Varianten der zukünftigen Frames zu erzeugen, je nach Handlung des Spielers und unnötige zu verwerfen. Also quasi Out of Order.
Aber ob das alles in absehbarer Zeit implementiert wird? Mit reinen Steigerungen der Packdichte rechnet NV wohl mittelfristig nicht mehr.
Allerdings ist vertikales Wachstum noch möglich.
Anders ausgedrückt: Hier wird nicht mehr aufeinander gewartet, sondern die Engine bekommt ein Gottvertrauen in die Funktion des NN implementiert und teilt diesem nur noch mit: "Hier sind die Objekte, die Perspektive, die Beleuchtung und hier kommt der Input. Mach mal..."
Ein bisschen mehr Input für das NN darf es schon sein: z.B. Bewegungsvektoren der Objekte im 3D Raum und die "zeitlich-räumliche Differenzbildung": Was hat sich wie verändert, und was nicht.
Aber ansonsten:
Sehr schön auf den Punkt gebracht, und mit "Vertrauen" genau eines der für neuronale Netze zentralen Stichworte getroffen.
Neurale Netze sind im gegensatz zu klassischen Algorithmen nichtdeterministisch. Es gibt eine Aufgabenstellung, eine (hoffentlich) dazu passende Topologie, und dann wird mindestens solange trainiert bis das Ergebnis ausreichend zufriedenstellend ist. Im Vertrauen (!) auf ausreichend gute Qualität und Diversität des Trainingsmaterials wird gehofft (!), dass fehlerhafte Outputs des NN ausreichend selten auftreten und möglichst keine fatalen Konsequenzen nach sich ziehen.
Nachtrag: Und falls doch muss mehr / besseres Trainingsmaterial beschafft werden und/oder das NN weiter trainiert werden, bis die beobachteten Fehler nicht mehr auftreten.
Also ja, Begriffe wie Vertrauen und Hoffnung sind integral mit der Verwendung von NNs verknüpft, auch wenn das meist wissenschaftlicher formuliert wird in Form von Statistiken, (erwartbaren) Wahrscheinlichkeiten, Anzahl erfolgreichen (Probe) Läufen, plakativen Erfolgen (KI besiegt weltbesten Go-Spieler), etc.
Verstehe ich das mit meinem simplistischen Weltbild richtig, dass die Generierung von Frames und die Verarbeitung der Eingaben asynchroner werden müssen für optimale Eignung?
Es gibt zwei Zeitachsen:
1) Die virtuelle In-Game-Zeit, also den Zeitablauf im Spiel den der Spieler subjektiv wahrnimmt (z.B. incl Frametime Spikes).
2) Real-Time, also
- benötigte Zeiten für CPU-seitige und GPU-seitige Berechnungen
- Latenzen und die Latenzkette (incl alle Arten von Datentransfers und den vielbeachteten Input-Lag)
- Zeitpunkte an denen Eingaben erfolgen (z.B. Sampling der Mausbewegung) und Zeitpunkte an denen Ausgaben erfolgen (Frame wird auf dem Monitor dargestellt).
Insbesondere User-Inputs betreffen beide Zeitachsen. Das ist das knifflige daran, ja.
Aktuelles bzw klassisches Setup vereinfacht dargestellt:
Die Game-Engine (z.B. Unreal, Unity, ...) verwaltet User-Eingaben und ist für die Synchronisation aller in-game-Ereignisse zuständig. Sie erstellt eine 3D Szene und übermittelt diese per Draw-Call an die Frame-Engine. Die Game-Engine läuft dabei hautsächlich auf der CPU, aber Teile (z.B. PhysX) können per Compute-API auch auf der GPU laufen.
Die Frame-Engine erstellt mit diesen Daten möglichst schnell ein Frame und übermittelt dieses an den Monitor. Die Frame-Engine läuft dabei hautsächlich auf der GPU (Renderpipeline, DLSS, NNs, ...), aber Teile (GPU Treiber) auch auf der CPU.
Die Reihenfolge ist dabei streng sequentiell. Der langsamere Part (Game-Engine im CPU Limit oder Frame-Engine im GPU Limit) bestimmt dabei die Gesamtgeschwindigkeit (FPS und Frametimes).
spekulatives zukünftiges Setup:
Game-Engine und Frame-Engine arbeiten weitgehend gleichberechtigt, parallel und asynchron zueinander. Beide haben Zugriff auf die User-Inputs (hier vor allem Mausbewegung = Kamerabewegung). Die User-Inputs werden auch kurzzeitig gebuffert, es kann also jederzeit deren Kurzzeit-Historie abgerufen werden. Durch eine gegenseitige Kommunikation zwischen Game-Engine und Frame-Engine stimmen sich diese detailliert ab. Synchronisation bezüglich der In-Game-Zeitachse erfolgt vor allem als Ergebnis dieser Abstimmung.
3D Szenen (Objekte, Kamera, Bildschirm) sind nicht mehr frame-relativ (jeder Frame bekommt sein eigenes räumliches Koordinatensystem) sondern absolut, so dass alle Bewegungen (3D Objekte, Kamera, Screen) nicht nur im Screen-Space sondern auch im 3D-Space historisch getrackt und bewertet werden können.
Game-Engine und Frame-Engine müssen jeweils eine Schätzung abgeben wie lange gemäß aktuellem Arbeitsstand es bis zum nächsten Datenpaket / Frame dauert. Dann wird ein Kompromiss ausgehandelt.
plakativ z.B. so
Game-Engine:
geschätzt 5.7msec bis zum nächsten Datenpaket
Frame Engine:
Passt. In der Zeit quetsche ich noch ein weiteres Frame aus dem aktuellen Datensatz, und kann dann in +5.7msec sofort mit der Verarbeitung des neuen Datensatzes beginnen.
oder:
Game-Engine:
geschätzt 5.7msec bis zum nächsten 3D-Datenpaket
Frame Engine:
sorry, brauche geschätzt noch 10.3 msec für das aktuell in Arbeit befindliche Frame
Game-Engine:
OK, verstanden.
Also nächstes Datenpaket dann in 10.3 msec, und ich nutze die zusätzliche Zeit schon mal für eine bessere Auswertung der 3D Bewegungsvektoren. Dann gehts bei dir schneller.
OpenVMSwartoll
2023-09-27, 22:19:27
Hat schon jemand zum Ausdruck gebracht, dass Du eine Bereicherung für das Forum bist?
Herzlichen Dank für Deine Mühe. Das regt zum Nachdenken an.
Also ist die Entzerrung von Game Engine und Frame Engine tatsächlich etwas, was Grundvoraussetzung für ein hypothetisches DLSS 10 darstellt.
Hat schon jemand zum Ausdruck gebracht, dass Du eine Bereicherung für das Forum bist?
Dankeschön :-)
Ich freue mich wenn meine Gedanken konstruktiv zu Diskussionen beitragen, und ich lerne dabei ständig Neues.
Also ist die Entzerrung von Game Engine und Frame Engine tatsächlich etwas, was Grundvoraussetzung für ein hypothetisches DLSS 10 darstellt.
Für mich war das eher eine gedankliche Aufspaltung der Funktionen, um meine Gedanken besser ordnen und darlegen / erklären zu können.
Aus technischer Sicht denke ich es geht eher in in Richtung einer engeren Verzahnung / Symbiose / Verschmelzung hin zu einer Art Gesamt-Engine.
Die Frage dabei ist IMHO, wie von Leo schon andiskutiert hatte, unter welcher Hoheit.
Setzt sich NV mit properitärem DLSS durch, und alle Spieleengines und jeder Spielentwickler müssen z.B. von NV bereit gestellte versionierte Softwaremodule in jedes Spiel einbauen, welches dann die komplette Kontrolle über Graphikgenerierung und Ausgabe übernimmt? Die jetzigen Spiele-Engines werden zu Zuträgern degradiert.
Oder macht jede Seite Ihren Part, und (properitäre, offene, standardtisierte) APIs ermöglichen eine ausreichend enge und gute Zusammenarbeit?
Oder folgen AMD und Intel mit DLSS ähnlichen Setups, und den Spieleentwicklern wird es dann irgendwann zu dumm für jedes Spiel drei Sonderlocken zu implementieren. Die Spiele-Engines stellen dann DLSS-like Funktionen zur Verfügung, per API Zugriff auf die NN-Rechenwerke die bis dahin alle Graphikkarten tragen, und alles Proprietäre (incl DLSS) verschwindet?
Oder vielleicht was ganz anderes?
Leonidas
2023-09-28, 04:52:08
Hat schon jemand zum Ausdruck gebracht, dass Du eine Bereicherung für das Forum bist?
+1
Die Frage dabei ist IMHO, wie von Leo schon andiskutiert hatte, unter welcher Hoheit.
Denkbarerweise sind genau das die Kämpfe der Zukunft. NV wird dieses Feld kaum kampflos räumen, wenn DLSS derzeit ein so gutes Pro-Argument für NV-Hardware ist.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.