News DirectStorage API: Windows 10* und 11 schließen zur Xbox Series X|S auf

joshy337 schrieb:
Ob mans glaubt oder nicht, Geld ist nicht das Maß aller Dinge.
Leute wie ich geben gerne kräftig Geld (gemessen an dem, was wir besitzen) aus, wenn sie dafür was Anständiges bekommen. Die Home-Versionen habe ich stets gemieden.

Und Windows 1x würde ich nichtmal benutzen wollen, wenn ich Geld dafür bekomme. Nein. Geiz ≠ geil. Und Geschenkt war bei Windows 10 damals noch zu teuer.

Oder um es mit den Worten eines Freundes auszudrücken:
Ich bin zu arm für schlechtes Werkzeug.

Edit: Und die Profis können Windows-Kauf auch von der Steuer absetzen.
Ich frage mich bei solchen Aussagen immer, was man denn so mit dem OS arbeitet?
Mit dem File Explorer Dateien verschieben?
Letztlich arbeitet man doch mit Programmen, die das OS nur als Unterbau brauchen.
 
  • Gefällt mir
Reaktionen: M@tze
Gerade wollte ich Microsoft fast noch gelobt haben, dass Windows 10 nicht außen vor ist. Man erinnere sich an Windows XP und DirectX 10. Naja, damals hat MS aber noch Geld mit den Lizenzen gemacht, heute kriegt man ja für jede Windows 7 Lizenz eine Windows 11 Lizenz geschenkt ...
 
Ohje, da kommen schlimme Zeiten auf uns zu. Mit dieser Technologie werden 100 GB Spiele schnell der Vergangenheit angehören und wir werden wohl deutlich größere Spiele in Zukunft installieren müssen. Ist wohl eher eine Technologie die dem Spielestreaming zugute kommt.
 
  • Gefällt mir
Reaktionen: Viper816
Malaclypse17 schrieb:
Ein großer Versionssprung wird nicht gemacht, weil es mal an der Zeit war, sondern weil er mit großen Änderungen einhergeht.
Und das ist ja auch passiert. Die gesamten Features aus 7 Jahre Windows 10 Entwicklung und jetzt der optisch große Sprung durch die Überarbeitung des optischen Stils.
https://docs.microsoft.com/de-de/windows/apps/design/signature-experiences/design-principles

So einen umfangreichen Wechsel des GUI Designs vorzunehmen ist kein kleiner Akt. Dazu gehörte ja auch ein Wechsel und eine Neuentwicklung des UI Toolkits und das Überarbeiten aller grafischen Elemente. Von den Fonts, Icons bis hin zu den Emojis. Zudem müssen die Oberflächen aller Systemanwendungen neu angepasst und implementiert werden. Das schüttelt man nicht so eben aus dem Ärmel.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: nazfalas
noxon schrieb:
So einen umfangreichen Wechsel des GUI Designs vorzunehmen ist kein kleiner Akt
Das wäre trotzdem keine neue Major-Version, wenn man auf die bisherigen Versions-Historie von WIndows zurückblickt.
Selbst der von Windows 2000 (NT 5.0) auf Windows XP (NT 5.1) war nur eine Minor-Version, trotz umfangreicher Änderungen. Eine neue Major-Version (NT 6.0) war dann Vista und ab da war jedes weitere Windows immer nur eine Minor-Version (Win7 = 6.1, Win8/8.1 = 6.2/6.3), obwohl es dort auch immer größere Änderungen gab. Die ersten Ausgaben von Windows 10 liefen noch als 6.4 und wurde später auf 10.0 umgestellt. Das hatte aber keine technischen Gründe, sondern man wollte ab da einfach die Versionsummer mit dem Namen synchron haben. Wobei Windows 11 als OS-Version auch noch 10.0 ausgibt.

https://docs.microsoft.com/en-us/windows/win32/sysinfo/operating-system-version
 
Wofür dieser Aufwand? Vieles davon wird doch durch die extremst nervigste, nicht übersprinbare, Spiele Start-Up Werbung und Zwangsgesundheitsbelehrung wieder vernichtet. Was nützt es mir, wenn das Spiel im Hintergrund längst geladen ist, aber ich erst zwangslesen muss, dass ich eventuell eine unentdeckte Epilpsie habe oder mein Meerschweinchen diese durch das Zuschauen triggern kann.
 
  • Gefällt mir
Reaktionen: RogueSix und Czk666
Jedi123 schrieb:
Wir das auch gehen wenn nur die Spiele auf einer Nvme sind, aber Win auf SSD?
Du meinst, eine Sata SSD im M.2 Formfaktor, oder?
 
DirectStorage und vor allem DirectX sind die letzten Bastionen von MS, damit man weiterhin deren OS als Spieleplattform "genötigt" wird, zu benutzen. Daher wird mit allen Mitteln an DirectX festgehalten.
Im Grunde ist die DirectX-Bindung von Spielen einer der Hauptgründe, warum Gamer bei Windows bleiben (wobei hier höchstwahrscheinlich die usability und Einfachheit in der Benutzung weiterhin der ausschlaggebende Punkt sind).
Vor allem, wenn dann so announcements kommen (worst case), dass paar kommende Mega-Kracher ausschließlich das neueste DirectX vorraussetzen, welches natürlich nur Windows 12 (im Idealfall für MS) geboten wird.
DirectStorage setzt eins drauf: wer verzichtet denn gerne auf schnelle Ladezeiten und generell deutlich bessere Lese-/Schreib-Performance in Spielen. Somit ein weiterer Pluspunkt für Windows als Spiele-OS.
Ob sich DirectStorage auch unter Linux problemlos und einfach umsetzen lässt???

Interessanterweise hat MS in der Vergangenheit mit neunen DirectX-Features und Präsentationen die Gamer gelockt, auf das aktuelle Windows zu switchen. Doch dann ist gefühlt jahrelang nichts passiert, da die meisten Spiele (99%), wenn nicht gar 100% immer noch auf die alte DirectX-Version als Basis gesetzt haben.
Somit weiterhin kein Grund auf ein neueres Win zu wechseln.

Der Kauf von MS von Zenimax schmeckt mir überhaupt nicht, da mit diesem Kauf auch ein Spieleentwickler aufgekauft worden ist, der wie kein anderer die Vulkan-API beherrscht und mit den Doom-Teilen beeindruckend zur Schau gestellt hat, was technisch geht, wenn man eine potente API benutzt. Durch den Kauf könnte es passieren, dass Vulkan beim Entwickler ID Software eingemottet wird und das Studio auf Anraten von MS den Fokus auf DirectX 12 (whatever Version) legt...
Aber das alles muss man nicht so pessimistisch sehen und vielleicht beglückt uns ID Software mit einem weiteren Vulkan-Kracher :)
 
Ob sich DirectStorage auch unter Linux problemlos und einfach umsetzen lässt???
Ich würde gerne mal die komplette API-Referenz sehen, um mir mal ein Bild machen zu können, aber das, was bislang veröffentlicht wurde, sieht nach io_uring mit etwas D3D12-Integration aus, optional mit von der Anwendung selbst bereitgestellter Dekompression (GPU-Decoding hat man anscheinend noch nicht hinbekommen). Der Teil dürfte relativ problemlos umsetzbar sein.

Was mir eher Sorge bereitet ist die Möglichkeit, dass in Zukunft ein proprietäreres, undokumentiertes und möglicherweise patentverseuchtes Kompressionsverfahren fest in die API eingebaut werden könnte, das wir dann nicht nachbauen können.
 
5hred schrieb:
Vor allem, wenn dann so announcements kommen (worst case), dass paar kommende Mega-Kracher ausschließlich das neueste DirectX vorraussetzen, welches natürlich nur Windows 12 (im Idealfall für MS) geboten wird.
DirectStorage setzt eins drauf: wer verzichtet denn gerne auf schnelle Ladezeiten und generell deutlich bessere Lese-/Schreib-Performance in Spielen. Somit ein weiterer Pluspunkt für Windows als Spiele-OS.
Ob sich DirectStorage auch unter Linux problemlos und einfach umsetzen lässt???

Das klingt bei Dir jetzt aber so, als wäre der einzige oder größte Benefit nur, dass Spiele schneller laden. Dabei ignorierst Du aber, meiner Meinung nach, dass diese Mechanismen erst neue Spiele oder Features in Spielen ermöglichen (werden). Nimm doch zum Beispiel "Ratchet & Clank - Rift Apart" (ok, PS5 und kein Direct Storage, aber ebenfalls die Möglichkeit den Speed der NVMe SSD voll auszunutzen) mit seinen fliessenden Levelübergängen ohne Ladezeiten. Das würde ohne das "einfache" Feature "schnelles laden" nicht funktionieren. Deswegen ist es eben auch ausschliesslich für die PS5 erschienen, da nur dort (auf Sony Seite) eine NVMe SSD sicher verbaut ist.

Und natürlich kann es sein, dass ein paar kommende Mega-Kracher ausschließlich das neueste DirectX voraussetzen, weil es Sinn macht. Wenn jetzt ein Hersteller ein Spiel explizit für DX12 mit DirectStorage entwickelt, kann dieser sich darauf verlassen, dass im Zielsystem eine NVMe SSD verbaut wurde, welche bestimmte Mindestanforderungen (das langsamste Modell am Markt oder sowas in der Art) erfüllt. Wenn der Entwickler jetzt weiss, das System kann schnell laden und beherrscht Sample Feedback Streaming, kann er doch ganz andere Dinge im Spiel einbauen, als bisher möglich waren.
 
M@tze schrieb:
Nimm doch zum Beispiel "Ratchet & Clank - Rift Apart" (ok, PS5 und kein Direct Storage, aber ebenfalls die Möglichkeit den Speed der NVMe SSD voll auszunutzen) mit seinen fliessenden Levelübergängen ohne Ladezeiten.
Lass dir von der Werbung nicht aufschwatzen, dass dieses Feature dafür unbedingt notwendig war, denn das war es definitiv nicht. Man hätte halt sonst eine Ladesequenz einbauen können oder auf dem PC die Daten halt im RAM vorhalten können und beides wäre kein Beinbruch. In erster Linie diente der Titel doch genau dazu, damit Leute rumplappern wie toll Feature A oder B einer Konsole ist und was damit alles möglich ist, schlichtweg damit mehr PS5 verkauft werden.

Es klingt nicht nur so, sondern es ist auch so, mit DirectStorage können die Assets besser komprimiert und schneller geladen werden. Es ist schön sowas zu haben, es stört aber auch kaum jemanden wenn es nicht da ist.
 
@xexex Das kann gut sein, da bin ich technisch aussen vor, aber wenn das alles so problemlos machbar ist, warum wurde es dann bisher nie genutzt?
 
M@tze schrieb:
Das kann gut sein, da bin ich technisch aussen vor, aber wenn das alles so problemlos machbar ist, warum wurde es dann bisher nie genutzt?
Was wurde bisher nie genutzt, ein schneller Szenewechsel zwischen verschiedenen Szenarien? Wo unterscheidet sich das zum Beispiel von einem Spiel wie Forza Horizon wo du aus dem Dschungel in die Wüste fährst? Letztendlich geht es nur darum in kurzer Zeit viele neue Texturen in den VRAM zu laden und ist vor allen Dingen ein "Konsolenproblem", weil hier VRAM=RAM ist, während du auf dem PC alle benötigten Texturen bereits im RAM vorhalten kannst.

Machbar wäre das ganze letztlich auch ganz ohne eine SSD und ohne die Technik, dann würde man wie sonst auch bei jedem Wechsel irgendeine Animation (Warptunnel) für ein paar Sekunden einblenden, während im Hintergrund die Szene geladen wird.

Verstehe mich an dieser Stelle nicht falsch, ich finde die Technik gut, nur verliert man ohne diese Technik nichts, auch wenn Sony das gerne anders verkauft. Es ist ja nicht so wie beim Raytracing, wo es dann ohne Hardwareunterstützung gar kein Ratraycing gibt, es gibt ohne DirectStorage schlichtweg längere Ladezeiten und/oder höhere Speicheranforderungen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: StylishChiller
5hred schrieb:
[...]
Ob sich DirectStorage auch unter Linux problemlos und einfach umsetzen lässt???
[...]
GPUDirect RDMA (Remote Direct Memory Access) kommt aus der Großrechner, Linux-Ecke. Weswegen bei Nvidias Materialien auch immer noch NICs, also Netzwerklösungen abgebildet waren/sind.
https://docs.nvidia.com/cuda/gpudirect-rdma/index.html
Entsprechende Patches im Kernel gibt es auch schon (anno 2020):
https://www.phoronix.com/scan.php?page=news_item&px=Linux-RFC-P2PDMA-NVMe-Drives
Grundlegend kann Linux sowas und die GPU-Treiber sind dafür (teils) bereits vorbereitet. In der Vulkanspezifikation ist es noch nicht vorgesehen, wird aber wohl derzeit verhandelt.
Einzig wird es wohl nicht DirectStorage heißen, da dass Begriffe sind, die Microsoft geprägt und im Zweifelsfall mit Schutzrechten registriert hat.

Unter Linux gibt es ansonsten ähnliche Probleme wie unter Windows. Kompression von Dateisystemen verhagelt das Ganze und das Betriebssystem/die CPU muss immer noch allerhand Verwaltungsaufgaben behandeln (Rechteverwaltung, Journaling, Snapshots, Accesstimes, Locks, Kollisionsvermeidung).

xexex schrieb:
Es klingt nicht nur so, sondern es ist auch so, mit DirectStorage können die Assets besser komprimiert und schneller geladen werden. Es ist schön sowas zu haben, es stört aber auch kaum jemanden wenn es nicht da ist.
DirectStorage hat nichts mit Kompression zu tun. Es sind in DirectX bessere Verfahren für Texturkompression aufgenommen wurden, mit der Art und Weise wie Festspeicher verwaltet/angesprochen wird hat das aber nichts zu tun.
Abgesehen von dem Umstand, dass Texturkompression sowieso derart ausgelegt wird, dass jeder Block eine feste Größe hat, damit ohne großen Aufwand die Texturen im Speicher (Fest, Ram und Vram) angesprochen werden können.
Ergänzung ()

xexex schrieb:
Letztendlich geht es nur darum in kurzer Zeit viele neue Texturen in den VRAM zu laden und ist vor allen Dingen ein "Konsolenproblem", weil hier VRAM=RAM ist, während du auf dem PC alle benötigten Texturen bereits im RAM vorhalten kannst.
Es ist Imho am aller wenigsten ein Problem der Konsolen. Wenn Konsolen Daten vom Festspeicher in flüchtigen Speicher geladen haben, können Daten mittels ZeroCopy ja nahezu ohne Aufwand zwischen dem Kontext von CPU und GPU übergeben werden.
Bei PCs mit dediziertem Ram und Vram ist das Problem weit größer, dass Daten vom Festspeicher in den Ram und dann erst in den Vram kopiert werden müssen. Da spart DirectStorage allerhand sinnloses Daten kopieren.
 
Zuletzt bearbeitet:
Piktogramm schrieb:
DirectStorage hat nichts mit Kompression zu tun. Es sind in DirectX bessere Verfahren für Texturkompression aufgenommen wurden, mit der Art und Weise wie Festspeicher verwaltet/angesprochen wird hat das aber nichts zu tun.
Falsch! Die Texturkompression hat damit rein gar nichts zu tun, die reinen Texturen werden damit nicht besser komprimiert, sondern die Assets werden nochmal zusätzlich auf der Festplatte komprimiert gespeichert und in dem Zustand geladen.
1647432753892.png


Zusätzlich dazu hat man den Storagepfad in Bezug auf NVMe SSDs optimiert.
1647432850103.png

Ergänzung ()

Piktogramm schrieb:
Es ist Imho am aller wenigsten ein Problem der Konsolen.
Doch es ist ein Konsolenproblem, weil auf der Konsole man mit dem Speicher haushalten muss. Die Xbox Series X hat gerade einmal 13,5GB Speicher für Spiele, ein potenter Gaming PC 8-24GB VRAM und 32GB RAM. Die Konsole muss die Daten von der Platte holen, auf dem PC ist hingegen meist mehr als genug RAM vorhanden, um die Daten dort zwischen zu speichern.

Es hat schon seinen Grund wieso man das Feature als erstes auf den Konsolen sieht und erst jetzt langsam auf dem PC. Die Dringlichkeit auf dem PC ist schlichtweg nicht gegeben, man möchte den Entwicklern aber eine ähnliche Basis geben, damit sie sowas nicht doppelt, einmal für Konsolen und einmal für PC entwickeln müssen. Wer kennt sie nicht, die ewigen Ladezeiten im Aufzug bei Mass Effect, weil die damaligen Konsolen mit mickrigen Speicher ausgerüstet waren und die Entwickler einfach ein Konsolenport auf dem PC geliefert haben.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Herdware
DirectStorage hat nichts mit Kompression zu tun. Es sind in DirectX bessere Verfahren für Texturkompression aufgenommen wurden
Genau das Gegenteil ist der Fall, neue Texturkompression gibt es nicht (BC7 wurde mit D3D11 eingeführt, vor 13 Jahren, jegliche Innovationen auf dem Sektor sind aus irgendwelchen Gründen dem Mobilsektor vorbehalten), DirectStorage erlaubt aber sehr wohl Dekompression des Datenstroms. Macht MS ja sogar in den eigenen Samples.
 
  • Gefällt mir
Reaktionen: StylishChiller und xexex
@VikingGe @xexex
PS5 nutzt Kraken und die Xbox BCpack. BCpack ist nicht offiziell dokumentiert, bei Kraken ist jedoch bekannt, dass es BC7 mit zlib ist und die Gerüchteküche zu BCpack lässt auch vermuten, dass ebenfalls eine Runde zlib zum Einsatz kommt. Wobei die Neuerung bei beiden Konsolen ist, dass zlib nicht auf der CPU ausgeführt wird, sondern auf dedizierter Hardware. Genau dem dem Punkt wird es möglich, dass man die GPU direkt Daten von der NVMe laden lassen kann, eben weil sie die Daten direkt verarbeiten kann, ohne dass die CPU sich um zlib bzw. älteren Formaten deflate kümmern muss. An der Stelle spart man selbst bei Konsolen allerhand Kopiervorgängen von Daten ein.
Ich erwarte, dass GPUs in PCs demnächst auch zlib direkt dekomprimieren können und/oder ASTC seinen Weg in DirectX finden.

Schauen wir uns nun mal Microsoft DirectStorage Beispiel an:
https://github.com/microsoft/Direct...142692242d84/Samples/MiniEngine/DirectStorage

Da kann die GPU direkt Texturen laden, ohne dass die CPU Daten erst in den Ram schaufeln muss, um die dann zur GPU zu übermitteln. Soweit so gut, das was ich als Killerfeature von DS verstanden habe, als direkten Weg NVMe -> GPU ganze ohne den Umweg über die CPU.

Was Microsoft aber im eigenen Beispiel auch hat sind Texturen, die zusätzlich mittels zlib komprimiert wurden. Die Dekompression erfolgt da im Kontext der CPU, man hat also genau wieder Pfad NVMe -> CPU/Ram ->GPU . Die Compression wird dabei jedoch separat implementiert und ist kein API Call von DS. Die entpackten Daten werden jedoch mittels DS in Richtung GPU exponiert[1].

Ich bleibe dabei, DS und Kompression sind zwei paar Schuhe. Man muss aber darauf achten, dass man Formate die die GPU direkt verarbeiten kann und Formate, die die präprocessing durch die CPU benötigen getrennt behandelt werden, sodass die GPU nur kompatible Formate direkt vom Festspeicher laden kann[2]

[1] Mit etwas Unsicherheit, bin zu faul um den Quellcode komplett durchzugehen.
[2] Captain Obvious ist stolz auf diesen Satz :D
 
Die Compression wird dabei jedoch separat implementiert und ist kein API Call von DS.
Das ist aber auch nur halb wahr, denn a) DStorage kann zukünftig Standard-Kompressionsverfahren ermöglichen, die dann meinetwegen auch GPU-seitig decodiert werden können (siehe DSTORAGE_COMPRESSION_FORMAT), und b) selbst für die von der Anwendung bereitgestellte Kompression existieren Helfer (IDStorageCustomDecompressionQueue).

Ich hätte wie gesagt gerne mal richtige Dokumentation vor Augen, damit man sieht, wie das alles zusammen spielt, aber ich würde jetzt nicht von zwei Paar Schuhen reden, wenn Kompression fest als Konzept in die API eingebaut ist.
 
Zurück
Oben