Microsoft Direct Storage: Auch PCI-Express-3.0-SSDs und alle DX12-GPUs werden unterstützt

Sampler Feedback Streaming

Wenn man nur noch die Texturen lädt die man wirklich braucht, dann reduziert man die benötigte Speichermenge.
In den Dev Blogs und Folien wird ja auch aufgezeigt dass die Game-Devs von "großen Textur-Einzeldateien" zu "vielen kleinen Textur-Dateien" wechseln und somit hohe IOPS wichtiger geworden sind.

Durch DirectStorage wird der throughput von Einzeldateien beschleunigt, außerdem findet die Decompression auf der GPU statt da diese dafür deutlich besser geeignet ist als die CPU. Bei RTX IO soll es sogar ohne Umweg über den RAM laufen.

Durch Sampler Feedback Streaming spart man bis zu 90% der benötigten Texturen ein, siehe Link oben, hier ein Beispiel Screenshot (das ist eigentlich ein GIF, aber zu groß für das Forum):



Anhang anzeigen 1361548


Man erhöht also die IOPS und gleichzeitig lädt man nur noch das was man wirklich braucht.

Ob das bei einem Spiel wirklich soviel aus macht, wie in einem Tech-Demo, was extra dafür programmiert wurde? Ich erinnere mal was uns alles über DX12 versprochen wurde. Low-Level Engine usw. Am Ende gab es nur geringe Geschwindigkeitsvorteile gegenüber DX10/11/9, dafür stieg die Komplexität der Engine.
Im Grunde wird es wie immer viel Marketing sein. Das nur Teile einer Texture geladen werden, klingt für mich extrem komplex. Denn von einem Frame zum nächsten kann es sein, dass man plötzlich die Texturen in die GPU nachladen muß. Mit anderen Worten, wenn sich die SSD einmal verschluckt weil Windows seine defragmentierung laufen läßt oder der Virenscanner im Hintergrund an geht, hat man ein Daumenkino in 3D!
 
@raPid-81
Danke für den Link. :daumen:

Was ist aber wenn wir uns vorstellen dass das alles Hochhäuser sind aus Beton, Stahl und Glasfassaden? Wir bewegen und ja derzeit auch auf RT GI hin. Also globale Beleuchtung mit RT. Die braucht in Echtzeit meinem bisherigen Verständnis nach doch die Texturen auf den Seiten die wir nicht sehen, um korrekt zu spiegeln wo wir es sehen und für die Umgebungsbeleichtung. So wie ich es gerade verstehe (hoffe ich), geht das gar nicht zusammen. Bei der einen Technik lasse ich die Texturen samt Informationen (Material) weg, bei der anderen sind genau diese Infos aber zwingend erforderlich. Richtig?
Schließt sich das wirklich aus, oder übersehe ich etwas?
 
@raPid-81
Danke für den Link. :daumen:

Was ist aber wenn wir uns vorstellen dass das alles Hochhäuser sind aus Beton, Stahl und Glasfassaden? Wir bewegen und ja derzeit auch auf RT GI hin. Also globale Beleuchtung mit RT. Die braucht in Echtzeit meinem bisherigen Verständnis nach doch die Texturen auf den Seiten die wir nicht sehen, um korrekt zu spiegeln wo wir es sehen und für die Umgebungsbeleichtung. So wie ich es gerade verstehe (hoffe ich), geht das gar nicht zusammen. Bei der einen Technik lasse ich die Texturen samt Informationen (Material) weg, bei der anderen sind genau diese Infos aber zwingend erforderlich. Richtig?
Schließt sich das wirklich aus, oder übersehe ich etwas?
Guter Hinweis. Was man aber auf jeden Fall nicht braucht sind die Texturen der "abgewandten" Seite der Hochhäuser. Dann sind es vielleicht nicht mehr 90% Ersparnis, sondern nur 30-50%. Wäre trotzdem beeindruckend, 4K läuft ja jetzt schon fast immer mit 10 GB VRAM (oder sogar weniger).
Ob das bei einem Spiel wirklich soviel aus macht, wie in einem Tech-Demo, was extra dafür programmiert wurde? Ich erinnere mal was uns alles über DX12 versprochen wurde. Low-Level Engine usw. Am Ende gab es nur geringe Geschwindigkeitsvorteile gegenüber DX10/11/9, dafür stieg die Komplexität der Engine.
Im Grunde wird es wie immer viel Marketing sein. Das nur Teile einer Texture geladen werden, klingt für mich extrem komplex. Denn von einem Frame zum nächsten kann es sein, dass man plötzlich die Texturen in die GPU nachladen muß. Mit anderen Worten, wenn sich die SSD einmal verschluckt weil Windows seine defragmentierung laufen läßt oder der Virenscanner im Hintergrund an geht, hat man ein Daumenkino in 3D!
Defrag und Virenscanner als Argumente finde ich schwierig, das sind sehr selten auftretende, temporäre und auch abstellbare Dinge.

Edit: Und Defrag auf einer SSD? Das ist doch im Standard eh deaktiviert soweit ich weiss.

Was es am Ende bringt werden wir sehen. Deine Argumente bezüglich "es wird viel versprochen aber nicht gehalten" verstehe ich und bin da komplett bei Dir. Aber WENN DirectStorage + Sampler Feedback Streaming + Mesh Shader so funktionieren wie gedacht (und das hoffe ich), dann sind wir bald bei fotorealistischen Games die weniger als 16 GB VRAM benötigen. Das wäre doch wünschenswert.
 
Zuletzt bearbeitet von einem Moderator:
Bitte nicht abwertend verstehen. Aber ihr sprecht hier immer die absolut offensichtlichsten "Probleme" an. Probleme auf die jeder halbwegs denkfähige Mensch nach spätestens 10 Sekunden Bedenkzeit kommen würde. ;-)

Glaubt ihr denn wirklich, dass sich die Hersteller da keine Gedanken gemacht haben? Es geht hier nicht darum, ein paar GB Speicher zu sparen und mit Kompromissen mit der SSD zu arbeiten, um den mangelnden Speicher irgendwie auszugleichen. Es geht eher darum, dass dank der SSD Dinge möglich sein werden, die zuvor Unmengen an RAM und VRAM benötigt hätten, wenn man sie denn umgesetzt hätte, weil die HDDs, auf die man immer rücksicht nehmen musste, so unfassbar lahm waren.

DX12 Ultimate ist nicht nur Microsoft Marketing sprech sondern wird auch von Intel, AMD und Nvidia getrieben.
Nvidia unterstützt die ganzen Features sogar schon seit Turing, nur konnten sie bisher nicht genutzt werden.

Die beiden Konsolen sind nun komplett darauf ausgelegt. Eine ganze Industrie baut ihre Produkte um, mit Features, die der Ottonormalverbraucher nichtmal ansatzweise versteht und daher auch nicht effektiv damit beworben werden kann (wobei es ja selbst hier im Forum wohl Probleme gibt) und ihr denkt es wäre nur ein Marketinggag?


Ihr habt grundsätzlich alle recht mit dem was ihr sagt, nur sind das eben meist Sichtweisen, die dem bisherigen altbekannten Memorymanagement entsprechen und dort ihre Gültigkeit hatten.
Dieses Memorymanagement wird nun aber komplett umgebaut, da sich durch die SSDs und die enorm kurzen Zugriffszeiten nun Möglichkeiten ergeben, die vorher überhaupt nicht da waren. Sämtliche aktuellen Spiele nutzen ein Memorymanagement das auf HDDs (!) ausgelegt ist. Es sollte im Interesse von jedem Enthusiasten mit PCIe4.0 SSDs sein, dass sich das schleunigst ändert.

In einer der Präsentationen wird auch gesagt, dass nvme SSDs bis zu 40x schneller seien, z.B. Ladezeiten von Spielen aber nur um den Faktor 1,5 bis 3 (oder so, nagelt mich jetzt nicht fest) beschleunigt werden.
Warum? Weil das aktuelle Memorymanagement so aufgebaut ist, um mit dem Bottleneck, das sich HDD nennt umzugehen. Entfernt man dieses Bottleneck und tauscht die HDD durch ne schnelle SSD, dann ist das alte Memorymanagement plötzlich völliger Murks und höchst ineffizient und man rennt u.A. schnell ins CPU Limit und bekommt die SSDs nichtmal ansatzweise ausgelastet weder beim laden des Spielstands noch beim Streaming. Deshalb muss sich vieles ändern. Das sollte doch verständlich sein?!

Nur um mal ein Beispiel zu nennen. Watch Dogs Legion ist aktuell selbst unter DX12 beim Fahren durch die Stadt extrem stark CPU limitiert, wenn man die maximale Texturstufe nutzt. Eine aktuelle HighEnd CPU packt das ganz gut, eine etwas ältere CPU bricht hier aber komplett zusammen. Und nein, das Spiel streamt hier Daten vom Storage nach und muss sie in der CPU entpacken. Die ganzen Texturen werden vorher NICHT in den RAM geladen, weil das Spiel nicht berücksichtigt, wie viel RAM du hast.
Dem Spiel ist es scheiß egal ob du 64 GB RAM und ne Nvme SSD hast. Das Streaming arbeitet trotzdem als hätte man ne HDD verbaut und malträtiert permanent die CPU. Das ist totaler Mist...

Und selbst wenn man jetzt sagen würde, wir haben mehr als genug VRAM und RAM am PC und den Konsolen und wir nutzen diesen aus - selbst dann bräuchte man DirectStorage, um die SSDs endlich mal vernünftig nutzen zu können. Und auch dann würden sich trotz reichlich RAM und VRAM die gleichen Vorteile durch das stärkere mit einbeziehen der SSD ergeben. Es macht also keinen Unterschied. DirectStorage ist ein Muss! Das ist praktisch die Optimierung von DirectX und Spielen speziell für SSDs. Etwas was es bisher nicht gab.

Dass manche Leute es nicht schaffen, sich zumindest ein wenig in den notwendigen Umbau hineinzudenken und verstehen, warum die Entwickler nun mit SSDs vieles anders machen müssen und welche Vorteile sich daraus ergeben ist schade. Aber hier empfehle ich wie gesagt die verlinkten Videos vom Microsoft GameStack, da werden die grundlegenden Sachverhalte gut erklärt.

Ich hab auch ehrlich gesagt keine Lust hier weiter zu argumentieren. Mir ist das zu mühselig und da ich kein Entwickler bin, will ich mir auch nicht anmaßen, auf jede Frage oder jedes Gegenargument eine korrekte Antwort geben zu können.

Warten wir einfach ab. In 1-2 Jahren kann ich dann ja sagen "ich habs euch gesagt". Oder auch nicht. Wir werdens sehen.

Vor ca. zwei Jahren haben die Leute auch nicht geglaubt, dass in den neuen Konsolen ne 8 Core/16 Threads ZEN2 CPU oder ne 12 TFLOPS GPU, geschweige denn ne Nvme SSD steckt. Kumpel hat mich damals ausgelacht, als die ersten Leaks kamen, weil das ja völlig unrealistisch sei und die Konsole 1500€ kosten müsse.

Jetzt gehts damit weiter, dass die Leute den Nutzen von Features in Frage stellen, die von allen relevanten Hardwarepartnern getrieben werden und grundlegende Probleme lösen. Probleme vor denen ENTWICKLER stehen, nicht die Konsumenten. Im Grunde kann es ja Microsoft egal sein, ob die User kapieren, was hier passiert. Großartiges Marketing für den Konsumenten ist da eigentlich gar nicht interessant und findet ja auch nicht wirklich statt. Die Entwickler müssen damit arbeiten und denen werden nun die Lösungen angeboten.
 
Zuletzt bearbeitet von einem Moderator:
Das heutige Live-Streaming von hochkprimierten Daten ist eigentlich das genaue Gegenteil einer HDD-Optimierung. Mittlerweile sind Festplatten zwar komplett abgeschlagen, aber noch bis vor ein paar Jahren war es keine Seltenheit, dass eine Spieleinstallation 20 GiB groß war und davon 5 GiB in den RAM geladen und zu 10 GiB entpackt. Die Daten wurden und werden (heute in insgesamt größerer Menge) also so ablegt, dass sie möglichst wenig Platz benötigten, aber wegen Limitierungen im System am Ende nur mit effektiv 50 MB/s (heute vielleicht auch mal 100 oder 150 MB/s) geladen werden, weil viel SSD-Speicher vergleichsweise teuer ist. Eine Optimierung für HDDs, als pro GiB sehr billige Laufwerke mit 100 bis 200 MB/s Transferrate, hätte dagegen in niedrig komprimierten, zwecks Burst-Zugriffen gegebenfalls sogar mehrfachen Speicherung bestanden, die 10 GiB RAM-Inhalt binnen in zwei Dritteln der Zeit geladen hätte. Vergleichbare Techniken wurden bei Konsolen zum Streaming von BluRays angewandt.

Aber am PC wird die Lesegeschwindigkeit auch in Zukunft von der Dekomprimierung bestimmt werden. Bei heute üblichen Ladezeiten von 30 Sekunden und realen Datentrasferraten ließe sich bereits 200 GB übertragen, wenn die Datenverarbeitung nicht limitieren (und der RAM reichen) würde. Aber niemand will heutzutage Spiele, die schon für Engine + erstes Level 200 GB verbraten, insgesamt also schätzungsweise über 1 TB Gesamtinstallationsgröße haben. Daher sind wir am PC meilenweit davon entfernt, transferlimitiert zu sein, selbst SATA-SSDs sind selten messbar langsamer. Aufgrund des Cachings im RAM spielt bei einer intelligenten Engine auch die Latenz einzelner Zugriffe keine Rolle und um Daten erst auf der GPU zu entpacken braucht es auch kein Direct Storage, sondern Engines und Treiber, die genau das machen. Sowie genug überschüssige GPU-Leistung, woran es heutzutage am ehesten mangelt.

Zwar ist es nett, mit DirectStorage gewisse Standards zu schätzen und damit auch den Fokus der Entwickler auf einen oftmals mäßig gelungenen Teil ihrer Engine zu lenken. Aber niemand sollte sich Performance-Sprünge erhoffen, denn wer ein vernünftiges Datenmangement programmiert, hängt bei heutigen PC-Spielen entweder im Speicherplatz- oder im Rechenleistungslimit, woran sich mit DirectStorage nichts ändert. Und wer ein schlechtes Datenmanagement programmiert, der kann auch DirectStorage verpfuschen – vermutlich sogar leichter als bisher.
 
Aber niemand sollte sich Performance-Sprünge erhoffen, denn wer ein vernünftiges Datenmangement programmiert, hängt bei heutigen PC-Spielen entweder im Speicherplatz- oder im Rechenleistungslimit, woran sich mit DirectStorage nichts ändert. Und wer ein schlechtes Datenmanagement programmiert, der kann auch DirectStorage verpfuschen – vermutlich sogar leichter als bisher.
Und genau da setzt doch, in Kombination, VRS + Sampler Feedback Streaming + Mesh Shading an, oder nicht? Es können mehr kleinere Assets geladen werden, somit sinkt der VRAM Bedarf, das Streaming läuft trotz begrenztem Speicher flüssiger. Und wenn das alles per DX12 API und den Game-Engines bereits ab Werk funktioniert, dann sollten die Game-Devs das doch auch weniger verhunzen können. So zumindest mein Verständnis.
 
Du jedoch hast das direkt als eine Art hinterfragen deiner Qualifikation wahrgenommen wie mir scheint.
nein - es hat nur keine Relevanz. Aber ja - ich bin Programmierer, derzeit nicht im Grafikbereich aber noch sehr viel Kontakt damit.
Aber egal ob man Programmierer ist oder nicht - es bleibt nun mal so das PCIe Geräte seit jeher direkten Zugriff auf den Arbeitsspeicher besitzen ohne das dafür Treiberupdate oä gebraucht werden - und Arbeitsspeicher ist noch um Größenordnungen flotter als SSDs.

Die Frage nach dem was die Entwickler antreibt war als objektive Gegenfrage anzusehen.
Das kam mir eher wie das hier leider sehr weit verbreitete "Ihr seit nur neidisch" vor. Wenn das nicht deine Absicht wahr - Sorry, mein Fehler.

Edit
Bitte sieh über die Formatierung hinweg. Ich hab das am Handy nebenbei geschrieben.
Das ist mir sowas von Schnuppe. ich mach genug Schreibfehler - so lange man noch versteht was gemeint ist.




Zum Thema Sampler-Feedback-Streaming:
Da wäre ich sehr sehr vorsichtig. SFS ist reaktiv - es greift erst nachdem etwas gerendert wird. Heist bei einem Spiel das die Texturen und den Speicher schon halbwegs managed so das man nicht erst das Nachladen von Texturen sieht bringt es exakt 0 - da es erst nach dem Rendern der Bilder funktioniert.
Was es machen kann ist nachladen von sichtbaren Texturen beschleunigen bzw Speicherbedarf verringern (setzt auch ein entsprechendes Texturformat voraus). Man startet in eine Szene mit schlechten (niedrigste Auflösung) Texturen, berechnet 1 Bild, bekommt dann vom Textursampler das Feedback welcher Teil der Texturen wie oft verwendet wurde und ladet dann von diesen die besseren Texturen.
Wenn das Spiel viele unterschiedliche Texturen gleichzeitig in Verwendung hat und von denen nur wenige überhaupt sichtbar sind oder große Teil überall verdeckt sind und nicht gesampelt wurden dann KANN man das laden der prominenten Texturen priorisieren und andere eventuell komplett ignorieren.
Die Tech-Demos dazu sind entsprechend simpel und statisch gehalten - hier kann man dann auch leicht zu 90% Einsparungen kommen.
Aber natürlich hat das ganze dann auch einige Hacken: Man hat nicht mehr alle Texturen geladen und muss sich darum dann extra kümmern. Wenn sich die Kamera bewegt/dreht sieht man dann vielleicht die Seite eines Hauses die zuerst nicht sichtbar war und die Texturen müssen neu geladen werden. Also entweder deutlich bemerkbares Nachladen oder extra Aufwand im Code. Es kommt auch sehr auf das Spiel bzw die gerenderte Umgebung an. Spiele die ihre Texturen schon je nach Entfernung/Sichtbarkeit laden werden wenig Vorteile sehen, spiele die viele kleine Texturen verwenden und diese oft wieder verwenden und kombinieren sehen quasi nur extra Aufwand ohne Vorteile. Spiele die unterschiedliche aber große Texturen verwenden die lange Zeit nur zu kleinen Teilen sichtbar sind und ohne schnelle Veränderungen können dafür stark profitieren.

Es kann also durchaus bei der Texturverwaltung helfen, aber wenn man sieht das Spiele mittlerweile die 8GB VRAM ausfüllen und dabei dann gut die hälfte der Texturen nicht gezeigt werden - einfach weil sie genug Speicher haben und sich um die Verwaltung nicht kümmern müssen.... Es könnte also die Texturqualität deutlich verbessern, die meisten Spiele sind aber dort noch nicht annähernd an den Grenzen der Hardware sondern durch die eigene Engine/Shader limitiert.



Aber am PC wird die Lesegeschwindigkeit auch in Zukunft von der Dekomprimierung bestimmt werden. Bei heute üblichen Ladezeiten von 30 Sekunden und realen Datentrasferraten ließe sich bereits 200 GB übertragen, wenn die Datenverarbeitung nicht limitieren (und der RAM reichen) würde.
Jein - es ist nicht wirklich die kosten des Dekomprimierens sondern das die Daten vor und nach dem Entpacken dann nochmal durchgeschaut und überprüft werden - sprich Manipulations/Kopierschutz.
Sieht man auch sehr deutlich wenn dann Spiele DRM entfernen und sich die Ladezeiten vor allem bei schwächeren Systemen dramatisch verbessern.

Aufgrund des Cachings im RAM spielt bei einer intelligenten Engine auch die Latenz einzelner Zugriffe keine Rolle und um Daten erst auf der GPU zu entpacken braucht es auch kein Direct Storage, sondern Engines und Treiber, die genau das machen.
Jop. Und genauso wie Buffern im RAM muss auch für Direkt-Storage die Engine und das Spieledesign entsprechend angepasst werden. Und wenn es um solche Themen geht dann sind leider fast alle Entwicklungsabteilungen gleich: Man entscheidet sich eventuell noch 1 davon zu machen wenn sie gerade viel Zeit haben, sonst hofft man einfach drauf das die Engine das schon macht weil sie dafür keine Zeit hergeben wollen.
 
@PCGH_Torsten
@raPid-81

Hier eine Demo zum Sampler Feedback Streaming mit Timestamp.

Viel Spaß beim staunen.
Das sollte die meisten Fragen, die hier aufgekommen sind beantworten.

Eingebundener Inhalt
An dieser Stelle findest du externe Inhalte von Youtube. Zum Schutz deiner persönlichen Daten werden externe Einbindungen erst angezeigt, wenn du dies durch Klick auf "Alle externen Inhalte laden" bestätigst: Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit werden personenbezogene Daten an Drittplattformen übermittelt.
Für mehr Informationen besuche die Datenschutz-Seite.
 
Das finde ich jetzt etwas wenig von deiner Seite.
Dieses Video ist ja nun wirklich nicht unbekannt und auch schon in dem einen oder anderen thread vorgekommen.
Du kannst also davon ausgehen dass sie das schon kennen. Sind sie dennoch nicht deiner Meinung, haben sie es nicht, oder anders verstanden und genau deshalb wäre es angebracht wenn du herausschreibst was denn nun die Antworten wären die du darin ausmachst.
 
@Cleriker

Das Video ist vom 21.04.2021 also von dieser Woche von der Microsoft Game Stack.

Bisher gab es meines Wissens nach aus dieser gezeigten Demo nur wenige Sekunden zu sehen, die in irgend nem Xbox Trailer eingearbeitet wurden. Hier hast du die komplette Präsentation mit vielen Beispielen und Erklärungen.

Und nein, die Antworten werde ich sicher nicht rausschreiben, wenn sie im Video beantworten werden. Das wäre redundant. Zumal mir dafür meine Zeit zu schade ist.
 
Worüber soll man da jetzt staunen? "Loading faster on X-Box"? 22 Sekunden Ladezeit für 2,6 GiB Daten? Auch 0,2 Sekunden für Netto 565 MiB, also 2,6 GiB/s sind wenig im Vergleich zu Nachladeprozessen aus dem RAM eines PCs. Und die gerenderte Grafik lächerlich simpel; in Anbetracht von durchgängig über 600 Fps auch für das verwendete System. Hier wird eine Software vorgeführt, die die Speichertransferrate einer 2020er NVME-SSD nutzt, um den RAM-Bedarf eines 2010er Renderers von 4 GiB auf 2 GiB zu senken. Wie bereits angesprochen ist das ein valider Ansatz, wenn für System mit RAM-Mangel entwickelt, so wie die hier im Fokus stehenden Konsolen. Aber übertragen auf einen PC entspricht die Techdemo erstaunlich exakt dem Low-End-Einsatz, der mir als einziges plausibles Szenario eingefallen ist, in dem DirectStorage einen großen Unterschied machen könnte.

Übrigens ist das Grundprinzip, Speicher durch nur teilweises Streamen von Texturen zu sparen, auf dem PC seit mindestens 1,5 Jahrzehnten bekannt. ids MegaTexture Rendering hätte anders nie funktioniert, ich glaube die Idee wurde aber auch schon vorher eingesetzt. Neu in dieser Techdemo ist nur die Steuerung des Systems über einen reaktiven Mechanismus, der Daten gleich wieder aus dem (V)RAM schmeißt, die nicht darsgestellt werden. Gegenüber bisherigen händisch optimierten, vorausschauenden Systemen, die die Daten gar nicht erst geladen hätten, spart das viel Entwicklerzeit. Technisch ist es in meinen Augen aber ein enormer Rückschritt, der nicht nur zusätzliche Transferrate und Decoding-Leistung gegenüber einer guten proaktiven Engine braucht, sondern gerade bei niedrigen Frameraten, wo man mehr Performance bräuchte, kaum noch anwendbar ist. Denn schon im nächsten oder übernächsten Frame (V)RAM freizuschaufeln funktioniert vielleicht in einer 600-Fps-Tech-Demo gut, in der man sich gar nicht so schnell bewegen kann, dass der große Bildteile von einem zum nächsten Frame ausgetauscht werden. Aber wie wird die Engine damit fertig, wenn ich bei 30 Fps in Cyperpunk aus einem Raum ins freie springe? Wie stark kann sie den Speicherbedarf des Streaming Monsters Fligh Simulator reduzieren, bei dem es kaum unsichtbare Gebäude-Rückseiten gibt? Der größte VRAM-Fresser müsste aktuell Minecraft RT sein – viel Glück dabei, dort durch Texture eviction Speicherplatz freizuschaufeln. :-D
 
Ich weiß zu schätzen, dass du so viel dazu schreibst, trotzdem würde ich dir bei nahezu allen Punkten widersprechen.

Aber ich seh schon, dass es nicht zielführend ist, weiter zu diskutieren, da du sogar versuchst, die DirectX devs mit deinen Ansichten in Frage zu stellen und denkst es besser zu wissen, was soll ich dann noch dazu sagen, außer die Erkenntnisse zu wiederholen. Ich bewundere natürlich dein Selbstbewusstsein :ugly: aber gut...

Ich enthalte mich jetzt dazu.
Ich habe versucht, hier den Leuten etwas näher zu bringen, was in bisherigen Diskussionen leider untergegangen ist oder mangels weiterer Informationen nur mit vielen Fragezeichen eine Erwähnung wert war und war extrem froh darüber dass Microsoft endlich mehr Infos dazu bereitgestellt hat.
Wer es interessant findet, kann was dazulernen, wer meint, das alles sei für den PC nicht relevant, der kann ja bei seiner Meinung bleiben, bis er eines besseren belehrt wird.
 
Versteh mich nicht falsch: Ich will mich nicht behaupten, dass ich mehr von der Sache als Microsofts Entwickler verstehe. Aber diese beschäftigen sich mit Speicheroptimierungen für Systeme, die zwischen SSD und VRAM keinen Puffer haben, nicht mit PCs.

Wenn du eine Verknüpfung zu Systemen mit anderen Flaschenhälsen siehst, dann ist es sehr wohl an dir, diese rauszuschreiben. Die X-Box-Entwickler haben damit nämlich zunächst genauso wenig zu tun wie ein Video über Geschwindigkeitssteigerungen in der Formel 1 mit der Transportkapazität des ICE-Netzes. Nicht jede interessante Technik ist auch eine passende Lösung für ein bestimmtes technisches Problem.
 
Und die Entwickler bei Microsoft bekommen ja nicht mal Windows auf die Reihe.

Auf DX12 für den FS2020 wartet man auch noch ewig.
 
Das Video ist vom 21.04.2021 also von dieser Woche von der Microsoft Game Stack.

Mal ganz abgesehen davon das du nicht mal annähernd versucht hast zu verstehen was bisher geschrieben wurde - schau dir das Video doch nochmal an - was sie dort WIRKLICH zeigen:
Ein absolut STATISCHES Bild benötigt weniger Speicher. Was passiert wenn man ein Object Rotiert? Die Daten müssen bei SFS neu geladen werden, sind bei den anderen Techniken aber noch im Speicher.
Auch ist SFS - wie sie auch im Video sagen - nicht ohne Performance-Kosten und hat auch hohe Entwicklungskosten. Es kommt eben doch sehr auf das spezifische Spiel an.
So wird in der Demo-Szene ein simpler, statischer Raum mit hunderten von Texturen die nur ein einzelnes Mal verwendet werden dargestellt - das ideale Szenario für SFS.
Jetzt mach das Gegenteil - zB ein Strategie-Spiel bei dem sagen wir mal 10 verschiedene Einheiten-Typen â 50 Man unterwegs sind. SFS wird dort kaum Speicher sparen können aber merkbar Rechenleistung kosten. Weil es eben nur ein Feature von vielen ist das für die Konsolen stark vermarktet wird - so wie jedes mal versucht wird die Konsolen als PC-killer darzustellen um den Verkauf anzukurblen.
 
Offtopic@Konsole -> PC-Killer
Meine ersten Erfahrungen mit Linux habe ich damals auf der Playstation 2 gemacht. Mit Maus, Tastatur, HDD-Modul und Modem... und einem Drucker der mich Tage der Einrichtung gekostet hat. Anfangs konnte ich so auch Half Life damit spielen. Irgendwann ging das dann nur noch mit Controller.
Damals hab ich meine ersten Stundenzettel darauf mit Open Office getippt und war sicher, dass wird den Standard-PC ablösen. Wir hatten zu der Zeit noch einen Pentium 2 MMX mit 266 MHz (oc auf 333) und einen AMD mit 500 MHz (oc auf 555). Die Playstation fühlte sich deutlich flüssiger an und konnte alles was ich brauchte.
 
Zuletzt bearbeitet:
Ein absolut STATISCHES Bild benötigt weniger Speicher. Was passiert wenn man ein Object Rotiert? Die Daten müssen bei SFS neu geladen werden, sind bei den anderen Techniken aber noch im Speicher.

Wo denn? In Bewegung gehen alle drei Balken hoch, das Verhältnis zwischen SFS on/off bleibt aber gleich. Oder hab ich was übersehen. Zeig mir bitte die Stelle an der du das beobachtest?

Und nein, mit SFS werden sogar weniger Daten gestreamt, weil nur noch die benötigten Teile einer Mip nachgeladen werden müssen und nicht gleich immer die komplette.

Ihr wisst was Mip Maps sind? Ja. Dann sollte auch klar sein, warum man auch bei nem Strategiespiel genauso davon profitieren würde, wenn man die Mips in Rechtecke aufteilt und nur die benötigten lädt.


Ich wollte ja nicht mehr antworten, aber mich interessiert jetzt schon die Stelle im Video wo du siehst, dass bei SFS off nix mehr nachgeladen werden muss, bei SFS on aber schon.

Und nein, niemand versucht hier die Konsole als PC Killer hinzustellen, da das eh alles für PC kommt. Ich nutze auch nur den PC, weshalb mich die Xbox in der Hinsicht nichtmal interessiert.


Problem sind nur die Leute, die das ganze als Unsinn abtun, als wäre das für PC alles irrelevant.
Wie irrelevant das alles ist sieht man ja gut daran, wie heftig das Streaming z.B. CPU limitiert ist, so dass ne NVME SSD nur ca. 3x so schnell wie ne kack HDD arbeiten kann. Ja, alles super irrelevant, was Microsoft da macht. Wir lassen alles so wie es ist, weil man kann ja eh nix besser machen. :lol:
 
Zuletzt bearbeitet von einem Moderator:
Wo denn? In Bewegung gehen alle drei Balken hoch, das Verhältnis zwischen SFS on/off bleibt aber gleich. Oder hab ich was übersehen. Zeig mir bitte die Stelle an der du das beobachtest?
........ Wenn du dich absichtlich so stellst hat es keinen Sinn Zeit mit dir zu verschwenden - also viel Spaß noch.:lol:
 
@-THOR-: Abgesehen davon, dass sich die Speicherauslastung bei Kamerabewegungen durchaus von bis zu 1:10 auf 1:2 Vorteil für SFF gegenüber normalem Rendering verringert, fragte Casurin nach Objektbewegungen und Einsatz multipler Objekte. Die Bewegungen halte ich dabei zwar für weniger relevant, da sich schnell drehende Objekte sowieso mit Unschärfe dargestellt werden sollten, aber in der Demoszene ist die in Spielen übliche Wiederverwendung von Texturen. Sie besteht fast nur aus einzigartigen Objekten, deren Oberflächen vermutlich jeweils eine eigene Textur darstellen werden. Somit hat man jede Menge unterschiedlicher Rückseiten, die SFF wieder aus dem Speicher werfen kann.

In einem realen Spiel werden Texturen dagegen fast immer vielfach verwendet. Der auf der Rückseite von Objekt A versteckte Texturteil ist dann auf der Vorderseite von Objekt B trotzdem sichtbar. Fairerweise sei gesagt, dass die Entwickler mit ihrer untypischen Szene auch die Nachteile ihrer Technik betonen, denn so kommen beim gezeigten Kameraschwenk eben auch mehr Texturen in den Viewport, die vorher gar keine Rolle spielten. Das in meinen Augen größere Fragezeichen schwebt daher über der Skalierung: Wie schlägt sich die Technik in einem echten (PC-)Spiel, wenn doppelt so viele Daten zwanzigmal so viel Grafiklast erzeugen und das Nachladesystem sechsmal schneller arbeitet?
 
Zurück