News Nvidia: RTX IO kann Ruckelprobleme indirekt verbessern

Wer sagt denn was von Speicherüberläufe wegpuffern? Das ist doch gar nicht Sinn und Zweck.

Es geht darum, die CPU Last drastisch zu senken, indem man das Dekomprimieren der Assets für die GPU nicht mehr auf der CPU durchführt. Das ermöglicht es zudem die Datenraten massiv zu erhöhen, weil die GPU halt viel schneller ist.

Wenn es nur darum ginge, dann wäre es auf bestehenden Systemen erst recht sinnlos. Denn ein Großteil der CPU-Ressourcen gängiger Modelle langweilt sich die meiste Zeit, die ein Spiel läuft, zu Tode. Guck dir mal an, welchen Ernergieumsatz reines Dekodieren tatsächlich erreichen kann (z.B. 7zip) und mit was deine CPU beim Zocken im Schnitt rumidlet. Performance-Einbußen auf der CPU durch Entpacken spielen im realen Spielgeschehen nur eine Rolle, wenn viele Assets binnen kurzer Zeit plötzlich bereitgestellt werden sollen. Genau das kann man durch voraussschauendes Streaming vermeiden – oder man entwickelt extra eine Technik, die einen speziellen Co-Prozessor in der GPU erfordert und lässt ohnehin rumliegendes Silizium weiterhin ungenutzt. Mit letzterem kann man als Hardware-Verkäufer natürlich leichter Geld verdienen als ein Software-Entwickler mit einem Spiel, das "just works".

Ich glaube das was du meinst ist die Vorstellung, dass man den Grafikspeicher durch Direct Storage besser ausnutzen kann und Agressiveres Streaming betreiben kann, weil weniger Daten im VRAM vorgehalten werden müssen, weil man neue Daten schneller nachschieben kann. Das wird sicherlich noch kommen und mit Sampler Feedback Streaming vielfach effizienter, da man so zusätzlich den VRAM Footprint der Assets minimieren kann, aber auch das soll doch nicht dafür sorgen, dass ein vollaufen des VRAMs kompensiert werden soll.

Wenn nur 8 GB vorhanden sind und 10 GB gebraucht werden, wird es mit Direct Storage genauso ruckeln wie bisher auch.
Der Unterschied wird sein, dass man mit reduzierten Settings, welche in 8 GB platz finden deutlich bessere Grafik qualität erzielen wird, eben dank Sampler Feedback Streaming, Virtual textures und allgemein agressiveres Streaming.
Damit letzteres möglich ist und die CPU damit nicht ständig genervt wird, hilft hier eben Direct Storage mit GPU Dekomprimierung.

Letztendlich kann man also aus vorhandenen Systemen mittlefristig mehr herausholen, da die Effizienz des Speichermanagements erhöht wird. Die Symptome bei Speichermangel werden aber identisch bleiben.

Aber das ist alles noch ziemlich weit weg und beschreibt nur das Potenzial das hier besteht. Zuerstmal soll Direct Storage das CPU Bottleneck beim Streaming von Assets beheben. Denn das wird in immer mehr Spielen jetzt schon zum Problem, selbst bei noch vergleichsweise geringer Streaminglast. Der aktuelle Ansatz ist einfach veraltet und ineffizient und wird den künftigen Anforderungen nicht mehr gerecht.

"Sampler Feedback" als Schlagwort ist zwar mit Direct Storage assoziiert, aber die Grundidee "lade nur die benötigten Teile eines Assets" wurde spätestens mit Ids Megatexturing etabliert. So etwas einfach nur effizienter und feiner zu gestalten, wäre nicht weltbewegend. Das Versprechen der Entwickler ist es tatsächlich, Daten so schnell "on demand" zu streamen, dass sie nicht mehr im RAM vorrätig gehalten werden müssen. Erst und nur dadurch ergibt sich die Möglichkeit zu komplexeren Assets und einer schöneren Welt respektive zu einem flüssigeren Spielablauf mit einer solchen. Denn wenn ich ohnehin nur mit dem rendere, was schon seit ein paar Sekunden im VRAM bereit liegt, dann spielen (CPU-)Decoding & Co halt gar keine Rolle mehr – intelligentes Prefetching, siehe oben.

Um das Versprechen einzulösen braucht man aber eben nicht nur Direct-Storage-Software und zusätzliche Direct-Storage-Recheneinheiten in der GPU (entpacken über Shader wäre im weit verbreiteten GPU-Limit sogar negativ), sondern auch Hardware die ein passendes Problemszenario bietet: Relativ niedrige GPU-Leistung, ausreichend großer VRAM für komplexe Szenen, aber zu kleiner für komplexe Level, keinen Platz in weiteren Zwischenspeicherstufen (z.B. RAM), um die Level dort zwischenzuspeichern sowie relativ zum Datendurchsatz der GPU (respektive zur Anbindung des RAMs, falls vorhanden) sehr schnelle Laufwerke. Genau das bieten die aktuellen Konsolen, weil sie extra um dieses Paradigma herum konstruiert wurden: Gar kein extra RAM, sehr schnelle SSDs und überschaubare Qualitätsanforderungen an die Grafik, weil die Shader-Leistung eh limitiert.

Aber am PC haben wir genau die gegenteilige Situation: Die Laufwerke sind oft der älteste und lahmste Teil eines sich entwickelnden Builds, zusätzlich zu "bitte mehr als 8" GiB-weise VRAM sind mittlerweile 32 GiB RAM mit Trend zu 64 GiB verbreitet, deren Anbindung an unbeschnittene GPUs ist weitaus schneller als jedes Laufwerk (PCI-E 5.0 wäre zusätzlich verfügbar, wenn man es denn brauchen würde) und die GPUs sollen ein vielfaches der Bildqualität und Datenmenge verarbeiten, die auf Konsolen üblich ist. Da kommt eine SSD sowieso nicht hinterher, egal ob direkt oder indirekt, da muss man den RAM nutzen. Und wenn man das vernünftig macht, ist die (CPU-)Dekomprimierung ausreichend.

Das würde bedeuten dass man alle Assets des Spiels (Texturen, Geometrie, zu kompilierende Shader) in den RAM laden müsste. Wir sprechen hier von 80+ GB bei manchen Titeln. Wer hat so viel RAM? Und wieso sollte man so viel RAM verbauen wenn man effizienter streamen kann?

"Rechtzeitig streamen" in Deiner Formulierung würde bedeuten dass man wieder CPU Cycles benötigt zum Übertragen und Dekomprimieren, womit die GPU wieder auf Assets warten muss bis die CPU fertig ist.

Mach doch einfach mal den Avocado Test und schau Dir den Unterschied lokal auf Deinem System an. In der Demo wird bei CPU Decompression anscheinend keine Rücksicht auf andere Threads genommen, mein ganzes System hing 1-2 Sekunden bis die CPU fertig war.
Mit GPU Decompression habe ich den Ladevorgang gar nicht mitbekommen, er war innerhalb von 480ms erledigt (CPU 2420ms) und hat die Daten mit einer Bandbreite von knapp 12GB/s (was wohl meiner NVME PCIE3.0 Schnittstelle x Komprimierung entspricht) gestreamed, während die CPU knapp 2,3GB/s hinbekommen hat.

Deine "Problemlösung" verschiebt das Bottleneck nur zeitlich anstatt es nachhaltig zu lösen.

Wie oben beschrieben: Saubere Programmierung und intelligentes Streaming umgehen den vermeintlichen Flaschenhals komplett, weil dieser überhaupt nur zeitlich existiert. Klar kann man Tests programmieren, die massiv sinnlose Dekompressionslast auf die CPU packt und diese damit auslastet. Da brauche ich keine Avocado zu, da kann ich 7-Zip-Benchmarks von anno dazumal nehmen. Reale Spiele beweisen dagegen schon seit langem, dass jede 08/15-CPU weitaus mehr Daten schnell genug für die GPU bereitstellen kann, um ansehnlichere Grafik als dieses Gemüse zu produzieren.

Real limitiert die CPU erst hart, wenn über die Laufzeit eines Spiels von der GPU im Schnitt mehr neue Daten verarbeitet werden, als die CPU im Schnitt bereitstellen könnte. Alles andere als "im Schnitt" ist ein Problem, dass sich sowohl im kritischen Moment selbst durch schiere Rohleistung lösen ließe als auch durch eine Dehnung dieses Moments zu einem unkritischen Zeitraum – durch intelligentes Prefetching und Zwischenspeicherung. Deine CPU schafft "nur" 2,3 GB/s an Assets zu verarbeiten? Dann reicht sie für jedes Spiel, in dem 360°-Drehungen mit einer RTX4060 überhaupt möglich sind, ohne dass es abstürzt, und in dem du selbst bei deinen Speedruns mehr als knapp 4 Sekunden von einem Level, Tile, etc. in den nächsten komplett anderen Raum brauchst, in dem du diese 360°-Drehungen machen möchtest.

In realen Spielen kommen solche Sprünge aber fast nur an Portalen vor, deren Annäherung für deutlich mehr als vier Sekunden vorhersehbar ist. Phils Lieblingsbeispiel ist immer der Besenflug von Hogwarts nach Hogsmeade mit massivem Ruckler bei erreichen letzterem. Da wird zwar auch bei weitem nicht alles ausgetauscht, weil zum Beispiel Boden- und allgemein Materialtexturen gleich bleiben, aber sicherlich 50 Prozent oder mehr des Renderinhalts sind neu. Der Flug dauert allerdings 10-20 Sekunden und das Ziel des Spielers ist bereits bei der Richtungswahl kurz nach dem Abheben klar absehbar, zumal es eh keine andere Destination vergleichbarer Komplexität gäbe. Ziehen wir mal 50 Prozent CPU-Leistung für parallel laufende Spielprozesse ab, dann könnte die oben genannte 2,3 GB/s CPU in dieser Zeit also rund 20 GB an neuen Assets entpacken und wenn die 50 Prozent Recyclingquote alter Inhalte richtig geschätzt ist, reicht das für 40 GiB Renderinhalte. So viel dürfte eine aufpolierte, intelligente Version des Spiels verwenden, ehe deine CPU Nachladeprobleme bekäme. Aber was sagt wohl deine GPU zu einer Szene mit so vielen Details, dass 40 GiB VRAM belegt sind?

Eben. Real sind die Grafikkarten der meisten Spieler schon bei 10 GiB am Ende. Die Qualität des Spiels ist also durch komplett andere Faktoren auf ein Viertel der (halben) CPU-Leistung begrenzt. Da kann man sich natürlich überlegen, wie man das ändern kann. Aber es tatsächlich zu machen ist in etwa so hilfreich wie ein Upgrade von einem 1800X auf einen 7800X3D in einem System mit einer GTX 970.

Die Sache ist doch um einiges schwerwiegender als dargestellt. Mit Sampler Feddback Streaming brauchst Du auflösungsabhängig nurmerhr einen festen Speicherpool (VRAM), also nur das "active working set" auf Texelbasis.
Der VRAM ist also nurmehr in Framebuffer und vielleicht noch ein kleiner Streaming- Buffer.

VRAM in der jetzigen Form wäre überflüssig. Um ein 4K Bild mit 16K vollgekleisterten Texturen auf den Bildschirm darzustellen, wird auf der Grafikkarte dann Szenenunabhängig ungefähr ein Bereich von 500 Megabyte genutzt.
Und ja- Das war kein Vertipper. Megabyte, nicht Gigabyte.

Letztendlich ist Sampler Feedback Streaming der Horror für alle Grafikkartenhersteller, die meinen sich ihren VRAM auf den Karten mit dem Kaufpreis "vergolden" zu lassen. Und jetzt fragt sich nochmal einer, warum diese revolutionäre Technik noch keinen Einzug in die Spieleengines/Software findet ;)

Den VRAM kaufen die Grafikkartenhersteller auch nur ein. Ihn nicht mehr kaufen zu müssen und stattdessen die volle Gewinnspanne auf die GPU zu verschieben, wäre deren Traum. Genau deswegen pusht Nvidia die Technik doch.

Aber von 4K in 0,5G sind wir, nicht nur am PC, meilenweit entfernt. Rapid-81 berichtet oben, dass RTX IO die ab-Laufwerk-Streaming-Leistung von 2,3 GB/s auf 12 GB/s steigert. Das mag wie eine gigantische Leistungssteigerung klingen, aber bei intelligenter RAM-Nutzung werden Daten derzeit mit 32 GB/s nachgeliefert; ab der nächsten GPU-Generation hoffentlich mit 64 GB/s. Dagegen ist auch Rapid Storage so wenig, dass man andere, bestehende Lösungen nutzen muss, wenn man die Grafik weiterentwickeln möchte. (Ich befürchte, dass es einige Entwickler trotzdem sein lassen werden und uns eine Reihe von Konsolenports mit mieserer Performance und/oder Grafik als bislang erwartet.)

Und eine Reduktion des VRAMs auf Framebuffer ist komplett utopisch. Eine RTX 4090 rendert aus 1.008 GB/s, um das zu ersetzen müsste die Streaming-Leistung gegenüber jetzt um den Faktor 100 steigen und zusätzlich noch die Latenz extrem reduziert werden. Gegen solche Phantasien mutet ein Ersatz des Systems-RAMs durch ungepuffertes Streaming vom Laufwerk in den RAM geradezu plausibel an. In der Praxis kommt aber eben selbst da eine verkrüppelte Konsole bei raus und den RAM wegzulassen werden sehr viele PC-Anwendungen gar nicht mögen.
 
Zuletzt bearbeitet:
Das ist kein anderer Betrachtungswinkel, das ist eine falsche Information.
Ich versuch hier einen Vergleich zu machen welcher vielleicht verstanden werden kann.

So ala "Ein Automotor ist quasi ein Zugpferd".

Es geht rein um das Verständniss das Directstorage/GDeflate nicht das Produkt ist.

Auch wenn ich meinen Motor bei Ferrari kaufe kann ich den als Mazda verkaufen.
 
In realen Spielen kommen solche Sprünge aber fast nur an Portalen vor, deren Annäherung für deutlich mehr als vier Sekunden vorhersehbar ist.

Diese Annahme als allgemein gültig zu erklären ist falsch. Solche Sprünge kommen bei jedem Fast-Travel vor, da ist 4 Sekunden vorher überhaupt nicht absehbar wohin die Reise geht.

Und selbst wenn man das vorhersehen könnte, wie soll man den fast voll belegten VRAM denn bereits austauschen für "in 4 Sekunden"? Die GPU braucht die aktuellen Daten ja noch. :schief:

Edit: Ah wait, Du meinst die Daten schon mal in den RAM laden, dort von der CPU entpacken, und das für alle Daten die "in 4 Sekunden" nötig sein könnten. Wo wir wieder beim Thema "How much RAM do you need? - Everything." wären...
 
Letztendlich ist Sampler Feedback Streaming der Horror für alle Grafikkartenhersteller, die meinen sich ihren VRAM auf den Karten mit dem Kaufpreis "vergolden" zu lassen. Und jetzt fragt sich nochmal einer, warum diese revolutionäre Technik noch keinen Einzug in die Spieleengines/Software findet ;)
Wenn du demnächst quietschende Reifen vor deiner Haustüre hörst, hat Jensen seine Kontakte spielen lassen um dich von "freundlichen", vermummten Herren zu einer kleinen Ssspritztour abzuholen:D

Gruß
 
Du kannst das immer weiter wiederholen, es wird dadurch nicht wahr.
Ja und du kannst weiterhin so tun als würde das Komprimierungsformat das Nvidia mit Microsoft entwickelte nicht schon längst Teil von Direct Storage 1.1 sein. :ka:
https://devblogs.microsoft.com/directx/directstorage-1-1-coming-soon/

Die Dekomprimierung findet immer noch auf der GPU statt und wird NICHT durch DirectStorage sondern den Treiber des Herstellers bewerkstelligt.
Sicherlich, hat auch nie jemand etwas anderes behauptet.:ka:
Die Dekomprimierung findet auf der GPU statt, genauso wie vorher auch, nur jetzt gibt es ein neues Dekomprimierungsverfahren das GDeflate heißt, welches in Direct Storage längst integriert wurde.
Mit DirectStorage 1.1 präsentieren wir ein neues Komprimierungsformat, das von NVIDIA beigesteuert wurde und GDeflate genannt wird.
Das ist doch nicht so schwer zu verstehen. RTX IO ist nur eine Marketingbezeichnung, dass Nvidias GPUs damit treiberseitig umgehen können, mehr nicht.


Könnte man alles "temporale Upscaler" nennen: Intel XeSS, AMD FSR, Nvidia DLSS
Könnte man alles "GPU Control" oder so nennen: MSI Afterburner, Radeon Wattman
Du hast schon verstanden, worauf ich hinaus will. Sonst würdest du ja nicht permanente Strohmänner auffahren. Es ist Werbung die niemand braucht, punkt.
XeSS, FSR oder DLSS sind Eigenentwicklungen, für die man auch werben kann. Es gibt keinen Upscaler den Microsoft zusammen mit Nvidia, AMD oder Intel entwickelt hat.
Du fragst "wie oft noch" obwohl Du die Zusammenhänge offensichtlich nicht verstehst. Schon witzig. :ugly:
Du lenkst ja ständig von dem Punkt ab, den ich ausführe und versuchst etwas anderes zu diskutieren, was längst klar ist. Mach da lieber mal alleine für dich weiter. ;)

Am besten finde ich dieses Zitat zu SAM/ R-BAR von dir:
Wenn AMD jetzt ein Feature aktiviert welches für alle zur Verfügung steht, dann ist das natürlich nice. Trotzdem ist es nicht ihre eigene Entwicklung.
 
Zuletzt bearbeitet:
Die Sache ist doch um einiges schwerwiegender als dargestellt. Mit Sampler Feddback Streaming brauchst Du auflösungsabhängig nurmerhr einen festen Speicherpool (VRAM), also nur das "active working set" auf Texelbasis.
Der VRAM ist also nurmehr in Framebuffer und vielleicht noch ein kleiner Streaming- Buffer.

VRAM in der jetzigen Form wäre überflüssig. Um ein 4K Bild mit 16K vollgekleisterten Texturen auf den Bildschirm darzustellen, wird auf der Grafikkarte dann Szenenunabhängig ungefähr ein Bereich von 500 Megabyte genutzt.
Und ja- Das war kein Vertipper. Megabyte, nicht Gigabyte.

Letztendlich ist Sampler Feedback Streaming der Horror für alle Grafikkartenhersteller, die meinen sich ihren VRAM auf den Karten mit dem Kaufpreis "vergolden" zu lassen. Und jetzt fragt sich nochmal einer, warum diese revolutionäre Technik noch keinen Einzug in die Spieleengines/Software findet ;)
Würde das nicht aber die GPU Last massiv anheben, wenn diese fortwährend mit Dekompression beschäftigt wäre?

Edit: Erst lesen, dann posten. Torsten hat die Antwort quasi gegeben.
 
Zuletzt bearbeitet:
Diese Annahme als allgemein gültig zu erklären ist falsch. Solche Sprünge kommen bei jedem Fast-Travel vor, da ist 4 Sekunden vorher überhaupt nicht absehbar wohin die Reise geht.

Und selbst wenn man das vorhersehen könnte, wie soll man den fast voll belegten VRAM denn bereits austauschen für "in 4 Sekunden"? Die GPU braucht die aktuellen Daten ja noch. :schief:

Edit: Ah wait, Du meinst die Daten schon mal in den RAM laden, dort von der CPU entpacken, und das für alle Daten die "in 4 Sekunden" nötig sein könnten. Wo wir wieder beim Thema "How much RAM do you need? - Everything." wären...

Ja, exakt letzteres meine ich. Dein in der Mitte genanntes Problem besteht ja grundsätzlich, auch mit Direct Storage – es sei denn, man könnte so schnell streamen, dass Render-from-SSD möglich wird. Aber dafür bräuchte man eben viele 100 GB/s bis über 1 TB/s und das schaffen weder die Laufwerke noch der PEG. Dafür müsste neben dem Decoding auch der Speicher selbst auf die Grafikkarte wandern (und sehr, sehr viel schnell werden als bislang üblich).

Und ja, Caching im RAM braucht eine entsprechende Menge desselben – wenigstens so groß wie der VRAM sollte der Arbeitsspeicher schon sein, eher das Doppelte. Aber genau dieses Verhältnis haben PCs halt sowieso. Nicht (nur) für Spiele – guck in einen x-beliebigen Thread zu Notebooks mit verlötetem RAM und du wirst jemanden finden, der 16 GiB als schon heute zu wenig empfindet und 32 GiB mit Upgrade-Option auf 64 GiB verlangt. In einem System, dass aktuelle Spiele mangels Shader-Leistung maximal in 320p rendern könnte und dafür vermutlich weniger als 8 GiB verbrauchen würde. Der RAM wird für Anwendungen ohnehin angeschafft und gute Praxis ist es eben, ihn dann auch für Spiele einzusetzen.

Deren Bedarf ist schließlich auch nicht unbegrenzt. PCI-E arbeitet bidirektional, das heißt Daten im VRAM können 1:1 ausgetauscht werden und müssen nie in beiden Speichern vorliegen. Rechenbeispiel für eine 12-GiB-Grafikkarte und relativ dazu mickrigen 16 GiB RAM:
- 6 GiB VRAM sind mit Daten gefüllt, die in mehreren Szenen genutzt werden (Material-Texturen, etc.)
- 6 GiB VRAM sind mit Szenen-abhängigen Daten gefüllt, die gegebenenfalls ausgetauscht werden müssen.
- 4 GiB RAM sind mit Betriebssystem und dauerhaft benötigten, nicht GPU-bezogenen Spiele-Daten gefüllt.
- in die verbleibenden 12 GiB RAM passen zwei weitere komplette 6-GiB-Szenen-Pakete.
Zusammen mit dem dritten, dass im VRAM ist, kannst du eine aktuell aktive Szene plus den Raum hinter dem nächstbesten Portal plus eine beliebiges Fast-Travel-Ziel bereithalten, das wegen Hotkey ASAP aufrubar sein muss. Mit plausibleren 32 GiB RAM sind es schon gut fünf Szenen insgesamt respektive, da sich zwischen diesen weitere Datenüberschneidungen ergeben werden, eher 6-7-8. Das reicht doch eigentlich locker? Der Inhalt pro Szene wird klar durch die VRAM-Größe limitiert, da maximal mit 12 GiB gerendert werden kann, nicht durch den RAM, in dem Szenen geparkt werden.

Und beispielsweise in Rollenspielen hat die Mehrheit der Fast-Travel-Ziele sogar weit mehr als 50 Überlappung von Vegetation, Gebäuden, Boden, etc.. Da muss nur die jeweilige Geometrie einzeln vorrätig gehalten werden und es passen die Daten für dutzende Ziele in das genannte RAM-Volumen. Da dem Spieler in der Regel Fast-Travel aus komplexen Kämpfen heraus verwehrt wird, kann man brachliegende VRAM-Teile sogar spekulativ füllen und da die schiere Masse aus Zielen ein Auswahlmenü nötig macht, steht sogar etwas Zeit zum Dekodieren frischer Daten zur Verfügung, wenn man sich komplett verplant hat. (Was einem guten Spiel aber gar nicht erst unterlaufen sollte. Wenn ein Fallout-Spieler die am wenigsten wertvollen Gegenstände aus dem Inventar schmeißt und dann bis aufs letzte Gramm vollgepackt losschleicht, dann wird er in 99,9 Prozent der Fälle nicht zur nächsten Kampflocation fast traveln, sondern zu seinem Lieblingshändler, um den Schrott zu versilbern. Da kann der Preload schon eien Minute früher anfangen, bevor überhaupt die unterste Ebene des Vaults verlassen wird.)


P.S.: Sorry, dass ich dir gegenüber von dir in der dritten Person gesprochen habe. Muss beim korrigieren des Posts mit dem Antworteil an dich und dem an Zerozerp durcheinander gekommen sein.
 
Ja und du kannst weiterhin so tun als würde das Komprimierungsformat das Nvidia mit Microsoft entwickelte nicht schon längst Teil von Direct Storage 1.1 sein. :ka:
https://devblogs.microsoft.com/directx/directstorage-1-1-coming-soon/


Sicherlich, hat auch nie jemand etwas anderes behauptet.:ka:
Die Dekomprimierung findet auf der GPU statt, genauso wie vorher auch, nur jetzt gibt es ein neues Dekomprimierungsverfahren das GDeflate heißt, welches in Direct Storage längst integriert wurde.

Das ist doch nicht so schwer zu verstehen. RTX IO ist nur eine Marketingbezeichnung, dass Nvidias GPUs damit treiberseitig umgehen können, mehr nicht.



Du hast schon verstanden, worauf ich hinaus will. Sonst würdest du ja nicht permanente Strohmänner auffahren. Es ist Werbung die niemand braucht, punkt.
XeSS, FSR oder DLSS sind Eigenentwicklungen, für die man auch werben kann. Es gibt keinen Upscaler den Microsoft zusammen mit Nvidia, AMD oder Intel entwickelt hat.

Du lenkst ja ständig von dem Punkt ab, den ich ausführe und versuchst etwas anderes zu diskutieren, was längst klar ist. Mach da lieber mal alleine für dich weiter. ;)

Am besten finde ich dieses Zitat zu SAM/ R-BAR von dir:

https://www.pcgameshardware.de/Port...ls/Prelude-RTX-IO-im-Test-Nvidia-GPU-1425161/

Diese bietet neben neuen Leveln obendrein eine neue Unterstützung für Nvidias RTX IO. Im Grunde handelt es sich hierbei um eine Nvidia-Version von Direct Storage. Im Gegensatz zu Microsofts Streaming-beschleunigender Technologie unterstützt RTX IO allerdings auch die Vulkan-API, die in Portal RTX genutzt wird.

Noch mal für Dich, RTX IO ist mehr als DirectStorage...
Ja, exakt letzteres meine ich. Dein in der Mitte genanntes Problem besteht ja grundsätzlich, auch mit Direct Storage – es sei denn, man könnte so schnell streamen, dass Render-from-SSD möglich wird. Aber dafür bräuchte man eben viele 100 GB/s bis über 1 TB/s und das schaffen weder die Laufwerke noch der PEG. Dafür müsste neben dem Decoding auch der Speicher selbst auf die Grafikkarte wandern (und sehr, sehr viel schnell werden als bislang üblich).

Und ja, Caching im RAM braucht eine entsprechende Menge desselben – wenigstens so groß wie der VRAM sollte der Arbeitsspeicher schon sein, eher das Doppelte. Aber genau dieses Verhältnis haben PCs halt sowieso. Nicht (nur) für Spiele – guck in einen x-beliebigen Thread zu Notebooks mit verlötetem RAM und du wirst jemanden finden, der 16 GiB als schon heute zu wenig empfindet und 32 GiB mit Upgrade-Option auf 64 GiB verlangt. In einem System, dass aktuelle Spiele mangels Shader-Leistung maximal in 320p rendern könnte und dafür vermutlich weniger als 8 GiB verbrauchen würde. Der RAM wird für Anwendungen ohnehin angeschafft und gute Praxis ist es eben, ihn dann auch für Spiele einzusetzen.

Deren Bedarf ist schließlich auch nicht unbegrenzt. PCI-E arbeitet bidirektional, das heißt Daten im VRAM können 1:1 ausgetauscht werden und müssen nie in beiden Speichern vorliegen. Rechenbeispiel für eine 12-GiB-Grafikkarte und relativ dazu mickrigen 16 GiB RAM:
- 6 GiB VRAM sind mit Daten gefüllt, die in mehreren Szenen genutzt werden (Material-Texturen, etc.)
- 6 GiB VRAM sind mit Szenen-abhängigen Daten gefüllt, die gegebenenfalls ausgetauscht werden müssen.
- 4 GiB RAM sind mit Betriebssystem und dauerhaft benötigten, nicht GPU-bezogenen Spiele-Daten gefüllt.
- in die verbleibenden 12 GiB RAM passen zwei weitere komplette 6-GiB-Szenen-Pakete.
Zusammen mit dem dritten, dass im VRAM ist, kannst du eine aktuell aktive Szene plus den Raum hinter dem nächstbesten Portal plus eine beliebiges Fast-Travel-Ziel bereithalten, das wegen Hotkey ASAP aufrubar sein muss. Mit plausibleren 32 GiB RAM sind es schon gut fünf Szenen insgesamt respektive, da sich zwischen diesen weitere Datenüberschneidungen ergeben werden, eher 6-7-8. Das reicht doch eigentlich locker? Der Inhalt pro Szene wird klar durch die VRAM-Größe limitiert, da maximal mit 12 GiB gerendert werden kann, nicht durch den RAM, in dem Szenen geparkt werden.

Und beispielsweise in Rollenspielen hat die Mehrheit der Fast-Travel-Ziele sogar weit mehr als 50 Überlappung von Vegetation, Gebäuden, Boden, etc.. Da muss nur die jeweilige Geometrie einzeln vorrätig gehalten werden und es passen die Daten für dutzende Ziele in das genannte RAM-Volumen. Da dem Spieler in der Regel Fast-Travel aus komplexen Kämpfen heraus verwehrt wird, kann man brachliegende VRAM-Teile sogar spekulativ füllen und da die schiere Masse aus Zielen ein Auswahlmenü nötig macht, steht sogar etwas Zeit zum Dekodieren frischer Daten zur Verfügung, wenn man sich komplett verplant hat. (Was einem guten Spiel aber gar nicht erst unterlaufen sollte. Wenn ein Fallout-Spieler die am wenigsten wertvollen Gegenstände aus dem Inventar schmeißt und dann bis aufs letzte Gramm vollgepackt losschleicht, dann wird er in 99,9 Prozent der Fälle nicht zur nächsten Kampflocation fast traveln, sondern zu seinem Lieblingshändler, um den Schrott zu versilbern. Da kann der Preload schon eien Minute früher anfangen, bevor überhaupt die unterste Ebene des Vaults verlassen wird.)


P.S.: Sorry, dass ich dir gegenüber von dir in der dritten Person gesprochen habe. Muss beim korrigieren des Posts mit dem Antworteil an dich und dem an Zerozerp durcheinander gekommen sein.

Ja, das könnte man so machen. OOOder man verbessert einfach das Streaming. :D

1. Sind die Konsolen der kleinste gemeinsame Nenner. Zu erwarten dass ein Entwickler Studio doppelt so viel Zeit aufwendet für eine PC Anpassung ist unrealistisch.
2. Nicht jeder PC hat 64GB RAM. Standard aktuell ist eher 16GB.
3. Mit 4-5 Locations auf Abruf kommt man nicht weit, wenn man eine Map aufmacht und 30 Fast-Travel Locations zur Auswahl hat.

Ich verstehe schon Deinen Ansatz. Allerdings bringt der DirectStorage Ansatz für alle etwas (Konsole + PC). Eine NVME SSD mit PCIE3.0 ist eher Standard als 64+GB RAM. Optimalerweise sollte also beides kommen, sowohl ein verbessertes Asset-Streaming als auch die höhere Auslastung vorhandener Systemressourcen.

Was ich nicht verstehe ist Deine "Anti-Haltung" einer neuen Technologie gegenüber.
 
Zuletzt bearbeitet von einem Moderator:
Ich spiele halt gerne den Spielverderber, wenn jemand eine neue Technologie hyped, die Probleme löst, welche es gar nicht gibt. :-)

Zu den Systemen kann man einfach mal den Preisvergleich befragen.
Komplettsysteme mit M.2 und aktueller Speicher- und Grafiktechnik und ...
... mit 6 GiB Grafikkarte haben 16 GiB RAM, aber halt auch nur eine ARC 380
... mit 8 GiB Grafikkarte haben in 89 Prozent der Fälle 16+ GiB RAM, in 8 Prozent 32 GiB (8-GiB-Systeme: RX 6650 XT)
... mit 12 GiB Grafikkarte haben in 55 Prozent der Fälle 32+ GiB RAM, in 5 Prozent 64+ GiB
... mit 16 GiB Grafikkarte haben in 66 Prozent der Fälle 32+ GiB RAM, in 4 Prozent 64 GiB
... mit 24 GiB Grafikkarte haben in 90 Prozent der Fälle 32+ GiB RAM, in 30 Prozent 64 GiB

Also mit 16 GiB braucht man für die Grafik-Blockbuster der kommenden Jahre meiner Meinung nach nicht mehr planen. Wo die GPU-Leistung für große Datenmengen vorhanden ist, gibt es auch mehr RAM. Und wie bereits erwähnt bedeuten 30 Locations auf einer Map weder, dass eine beliebige von 30 Locations gewählt wird, noch das grundverschiedene Daten für 30 verschiedene Szenarien bereitgehalten werden müssen. Über 95 Prozent der Sprünge werden sich auf eine Handvoll Ziele konzentrieren, deren Assets zusammen weniger als zwei volle Szenen entsprechen. Und innerhalb dieser 95 Prozent geht sind 32 GB/s latenzfrei aus dem RAM dann auch schneller als 12 GB/s effektiv von der 3.0-SSD.

Einzig wenn man Konsolenspiele 1:1 ohne Anpassungen auf dem PC verkaufen will, dann ist Direct Storage natürlich klar der bessere Weg – für die Publisher. Spieler werden dann aber bis zum Release von Playstation 6 + kreativ neubenannter Konkurrenz gar keine Grafikverbesserungen zu Gesicht bekommen, sondern eben 1:1-Konsolenqualität.


P.S.: Unter "verbessertem Streaming" würde ich genau das verstehen, was ich beschreibe – intelligente, vorausschauende Bereitstellung von Daten als eigener Prozess. Direct Storage dagegen nutzt ganz banale, blöde Loads von einem halt besonders schnell gestallteten Massenspeicher und somit eigentlich gar kein Streaming mehr, sondern einfach Zugriff nach Bedarf.
 
Wenn die Ruckelprobleme von ner zu schwachen CPU her rühren wirds auch weiterhin Unterschiede zw.
AMD und NV-Grakas bezgl. passender CPU geben, ... sieht in RC so aus.
(zu schwache CPU weil NV mehr Overhead hat)

RC@13100.JPG
 
Jetzt weichst du aus, aber was solls. =)
Wo weiche ich aus? Darüber ist doch das Zitat vom PCGH Artikel???

Diese bietet neben neuen Leveln obendrein eine neue Unterstützung für Nvidias RTX IO. Im Grunde handelt es sich hierbei um eine Nvidia-Version von Direct Storage. Im Gegensatz zu Microsofts Streaming-beschleunigender Technologie unterstützt RTX IO allerdings auch die Vulkan-API, die in Portal RTX genutzt wird.

Ein Unterschied zwischen RTX IO und DirectStorage ist: Vulkan Unterstützung! Und Du beharrst weiter auf DirectStorage = RTX IO? :schief:
 
Zurück