News Diablo IV: Bisher kein DirectStorage, aber Einsatz geplant

Nolag schrieb:
Microsoft selbst spricht von einem VRAM Multiplikator durch DS um den Faktor 2-3.

Hach, ich liebe Marketing.

Die Leute sind noch wahre Idealisten mit überbordenden Phantasie, die sie voll ausleben. Und dazu vollkommen schamlos, und treten ihre kompletten Brainstorming-Ergüsse in der Öffentlichkeit breit.

Leider verwechseln sie immer öfter ihre Fantasy-Welt mit der Realität.

Es war doch ungefähr so: die neue 4060 ist 15x schneller als die 1060, und sparen tut man beim Kauf auch noch. Darauf muss man erst einmal kommen.

Da braucht es keinen Pratchett, Münchhausen, Tolkien, etc... mehr :)
 
@DevPandi also wenn ich die Spieledateien mit gdeflate (.cab - das ist der Algo von DirectStorage), lzo oder zstd mit niedrigem level komprimiere, dann ist auch so die CPU kein Bottleneck mehr. Die derzeit genutzten Algos sind ja auf maximale Speicherplatzersparnis, und so gar nicht auf schnelle Dekompression ausgelegt.

Das wäre eine "low hanging fruit", mit der sich ohne nennenswerten Aufwand und ohne DirectStorage die Ladezeiten bereits stark verbessern ließen - der trade off ist tlw. derselbe, wie bei DS, nur ohne den ganzen Mehraufwand: Die Spieldateien werden brauchen mehr Platz.
 
Nolag schrieb:
Microsoft selbst spricht von einem VRAM Multiplikator durch DS um den Faktor 2-3. Als die neuen Konsolen vorgestellt wurden haben MS und Sony in ihren Präsentationen darauf hingewiesen dass sie die SSD als VRAM Multiplikator verwenden und deshalb das VRAM im Vergleich zur vorherigen Generation nicht vergrößern müssen.
Also, wenn ich mir die aktuellen In formationen von MS und Sony ansehe, dann gehen beide Firmen aber nicht auf die Menge des VRAM in Zusammenhang mit dem direkten Laden der Daten in den VRAM ein - also dass hier ein VRAM-Multiplikator von 2 - 3 besteht - das würde nun bedeuten, dass sich 8 GiB wie 16 GiB verhalten könnten. Bei der Vorstellung der Velcocity-Architektur wird von ca. 2,5x bei der I/O-Bandbreite gesprochen.

Und auch in den Entwicklernhandbüchern zu DirectStorage wird nicht von Auswirkungen auf die "Menge" des VRAM wirklich gesprochen, sondern eher von Auswirkungen auf die Bandbreite, die man effektiver nutzen kann.

Auch jetzt - bei den neuen Versionen - spricht MS nicht damit, dass der VRAM-Bedarf durch DS "sinken" wird und auch die Spieleentwickler machen das nicht. Bei einer GPU müssen die Daten zum richtigen Zeitpunkt da sein, sind sie es nicht, hat sich das, daran kann auch DS nicht viel ändern. Man kann hier vielleicht das Streaming der Daten vereinfachen, weil man keinen Umweg mehr über die CPU einplanen muss, und auch gezielter die Daten laden.

Wenn der VRAM aber für die aktuellen Szenen nicht reicht, dann wird DS daran auch nicht viel drehen können. DS kann helfen mit dem VRAM effektiver umzugehen, aber nur bis zu einem gewissen Grad. Die zurendernden Szenen müssen aber eben bis zu "x-Frames" dennoch in den VRAM passen, dass wird auch DS nicht ändern.

DirectStorage ist halt eine API, die für das Laden von Daten verantwortlich ist. Die Daten dort liegen in einem "Format" vor, denn eine GPU und selbst eine CPU für die verwaltung von Daten im RAM so "überhaupt" nicht mag und dass erst entsprechend vorbereitet werden muss.

Um Probleme mit dem VRAM zu "umgehen", müsste eher die VRAM-Verwaltung als ganzes entsprechend darauf ausgelegt werden, die Daten selbst entsprechend effektiv zu verwalten. AMD hatte da bei Vega eine interessante Funktion "HBCC".

Das wäre eigentlich mal ein interessanter Test für Diablo 4. Schade, hab keine Vega64 hier, mit der man das mal testen könnten und wie sich das verhält in WQHD und 4K mit den Texturen.

kiffmet schrieb:
also wenn ich die Spieledateien mit gdeflate (.cab - das ist der Algo von DirectStorage), lzo oder zstd mit niedrigem level komprimiere, dann ist auch so die CPU kein Bottleneck mehr. Die derzeit genutzten Algos sind ja auf maximale Speicherplatzersparnis, und so gar nicht auf schnelle Dekompression ausgelegt.
Sobald die Daten durch die CPU gehen müssen, kommt zusätzliche Latenz hinzu, es geht dabei also nicht mal umbedingt um die Bandbreite, sondern die Verzögerung. Man sparrt sich gewisse Wege und Rechenleistung, die man an andere Stelle besser verwenden kann.

Im Endeffekt geht es aber bei sowas eher darum, dass man den Entwicklern bessere Werkzeuge an die Hand gibt, die den Code vereinfachen.
 
Supie schrieb:
Wieviele Leute nutzen wohl noch Festplatten / SATA SSDs? Es wird ja immer für den kleinsten Nenner programmiert
Was passiert denn, wenn das Spiel auf DS greifen will, die Hardware das aber nicht kann? Dann läuft es doch so, wie bisher. Wir wollen doch nicht beim Status Quo verharren, sondern weiter gehen.
 
SavageSkull schrieb:
Was passiert denn, wenn das Spiel auf DS greifen will, die Hardware das aber nicht kann?
DirectStorage nutzt, abhängig von der konkreten Hardware, selbständig die bestmögliche Variante bzw. hat entsprechende Fallbacks integriert. Einzelne Aspekte kann der Entwickler auch aktiv vorcieren, bei anderen kann er zumindest abfragen, welche Variante DS gerade nutzt.
So lässt sich bei der API abfragen, ob die Dekompression über die CPU oder die GPU erfolgt, falls er die bei Optimierungen des Spiel unterschiedlich behandeln will.

https://devblogs.microsoft.com/directx/directstorage-1-2-available-now/
 
  • Gefällt mir
Reaktionen: Engaged
Ich fand diesen Post zum Thema Direct Storage erhellend: https://www.reddit.com/r/Games/comments/tlfqdk/clearing_up_misconceptions_about_directstorage/
Ist allerdings von März 2022, vor erscheinen von DS 1.1 mit GPU Dekompression.

  • Die CPU ist immer im Spiel und kümmert sich mindestens um das eigentliche I/O.
  • Dekompression macht heutzutage auch die CPU.
  • Irgendwann könnte die Dekompression die GPU übernehmen. Noch gibt es sowas nicht. NVidia hat dafür RTX IO im Feuer. Siehe DS 1.1 mit GPU-Dekompression.
  • Die Daten gehen immer auch durchs normale RAM. "Nicht" so bei der der Xbox Velocity Architecture, denn die Xbox hat unified memory, also RAM = VRAM.

TL;DR:
Wird vermutlich weder jetzt noch in Zukunft der große Heilsbringer sein.
 
DevPandi schrieb:
Auch jetzt - bei den neuen Versionen - spricht MS nicht damit, dass der VRAM-Bedarf durch DS "sinken" wird und auch die Spieleentwickler machen das nicht. Bei einer GPU müssen die Daten zum richtigen Zeitpunkt da sein, sind sie es nicht, hat sich das, daran kann auch DS nicht viel ändern. Man kann hier vielleicht das Streaming der Daten vereinfachen, weil man keinen Umweg mehr über die CPU einplanen muss, und auch gezielter die Daten laden.
Genau darum geht es. Es ist der just-in-time Aspekt von DirectStorage, der als RAM Multiplikator dient. Mark Cerny zeigt in seiner Präsentation grafisch einen Faktor von 2,5 ohne die Zahl zu nennen. Microsoft spricht aber von Faktor 2-3.
So if a game never had to load pages that are ultimately never actually used, that means a 2-3x multiplier on the effective amount of physical memory, and a 2-3x multiplier on our effective IO performance."
Bespoke hardware within the GPU is available to smooth the transition between mips, on the off-chance that the higher quality texture arrives a frame or two later. Microsoft considers these aspects of the Velocity Architecture to be a genuine game-changer, adding a multiplier to how physical memory is utilised.
Eurogamer: Inside Xbox Series X: the full specs

Den größten Multiplikator sieht Microsoft offensichtlich in SFS:
DS SFS Demo 1 (Faktor 3): Neogaf: Sampler Feedback Streaming appears to be the real deal.
DS SFS Demo 2 (Faktor 100): How Sampler Feedback Streaming Works In Tandem With Fast Storage To Reduce Memory Requirements
 
Schön und gut, aber weder haben PCs unified memory, noch dedizierte Hardware für Texturdekompression. Velocity Architecture ist einfach nicht dasselbe wie Direct Storage. Für PC-Spiele bleibt das also etwas zurück gegenüber den Konsolen.
 
Was ändert das an meiner Aussage?
Ob die CPU oder die GPU die Dekompression macht, der Aufwand lässt sich nicht auf dedizierte Hardware abwälzen.
Ebenso kann die GPU nicht die Daten direkt von der SSD lesen, das macht die CPU, und die (dekomprimiert es ggf. und) kopiert es vom RAM ins VRAM.
Das sind die nicht schließbaren Lücken zwischen PC und Konsole.

Dass SFS trotzdem was bringt, habe ich nicht bestritten.
Verwechselst du mich mit @DevPandi? ;-)
 
Zuletzt bearbeitet:
Gnarfoz schrieb:
Das sind die nicht schließbaren Lücken zwischen PC und Konsole.
Deshalb erwähne ich das alles auch nicht. Die proprietären Sachen werden sicher nur von den First-Party Games unterstützt werden. Sampler Feedback und just-in-time Laden von Assets braucht nur eine SSD und SF Support.
 
  • Gefällt mir
Reaktionen: Gnarfoz
Gnarfoz schrieb:
Ob die CPU oder die GPU die Dekompression macht, der Aufwand lässt sich nicht auf dedizierte Hardware abwälzen.
Ebenso kann die GPU nicht die Daten direkt von der SSD lesen, das macht die CPU, und die (dekomprimiert es ggf. und) kopiert es vom RAM ins VRAM.

Dafür haben GPU und CPU eines Oberklasse-PCs deutlich höhere Rohleistungen, als die Konsolenchips.

Außerdem kann man für die höchste Texturdetailstufe problemlos 32 GB RAM voraussetzen (die Mehrkosten sind schon seit Jahren vernachlässigbar), und hat dann noch mehr Freiheitsgrade, z.B. Nutzung als Cache für dekomprimierte Texturen.
 
  • Gefällt mir
Reaktionen: Gnarfoz
Gnarfoz schrieb:
Dass SFS trotzdem was bringt, habe ich nicht bestritten.
Ich muss an der Stelle aber zugeben, dass ich nur DirectStorage gelesen habe und das SFS überlesen habe. Und genau das ist auch das eigentliche Problem an dieser Sache. SFS ist nicht Direct Storage.

Nolag schrieb:
Genau darum geht es. Es ist der just-in-time Aspekt von DirectStorage, der als RAM Multiplikator dient.
Da ein Teil der Diskussion auf das "überlesen" von mir zurück geht, muss ich erst mal zum Teil mich entschuldigen. Ich habe überlesen.

Gleichzeitig bleibt das eigentliche Problem aber bestehen und deine Beiträge zusammen mit meinem Überlesen des initialen Beitrages zeigen relativ gut das Problem:

Du sprichst von (1.) Direct Storage in Verbindung mit (2.) DirectX 12 Sampler Feedback. Beide Bausteine bilden dann das Sampler Feedback Streaming (with Direct Storage). Und das ist der entscheidene Punkt. Weder das Sampler Feedback aus DirectX12 noch Direct Storage alleine sind hier ausreichend, sondern erst die Kombination von beiden Techniken bringen hier eine Besserung.

Das heißt an der Stelle: Du hast mit deinem ursprünglichen Beitrag nicht unrecht und ich muss mich dafür entschuldigen, dass ich es überlesen habe.

Gleichzeitig sollten wir aber an der Stelle möglichst "genau" bleiben, damit wir eben keine falschen Erwartungen in DirectStorage wecken. Wird DirectStorage nur zum befüllen des VRAM verwendet und die Verwaltung bleibt so, wie sie aktuell ist, wird DirectStorage nicht viel bringen, was den VRAM entlasen kann oder garnichts. Wenn Entwickler aber die verschiedenen Techniken aus DirectX12 zusammen mit Direct Storage nutzen, dann kann es bei Techniken wie dem SFS so kommen, wie du es geschrieben hast.

Oder kurz: DS kann dabei helfen, den VRAM-Bedarf zu senken, muss es aber nicht.
 
  • Gefällt mir
Reaktionen: Naitrael
CloudConnected schrieb:
Dafür das D4 am Anfang mit Problem mit schnellen NVMEs hatte bin ich da en bischen skeptisch.
Verstehe die Ladezeiten sowieso nicht bei D4 bei den kleinen Dungeons.
Ergänzung ()


Also ich hatte in keiner Beta RTX
Ich rede hier über die closed beta. Die wo es noch ein NDA gab. Da gab es in den Optionen Raytracing Einstellungen. Ob die funktioniert haben weiß ich leider nicht, da ich nur beim Nachbarn gespielt habe.
 
Zurück
Oben