Direct Storage in Windows 11: SSD-Turbo kommt nicht für Windows 10

120
News Benjamin Gründken Als bevorzugte Quelle auf Google hinzufügen
Direct Storage in Windows 11: SSD-Turbo kommt nicht für Windows 10 (1)
Quelle: Microsoft

Microsoft hat bekanntgegeben, dass die verbesserte Speicherverwaltung "Direct Storage" tatsächlich mit dem Launch von Windows 11 für PCs verfügbar gemacht wird. Die Technik, die bereits bei der Xbox Series X zum Einsatz kommt, hatte man anfangs noch mit Windows 10 in Verbindung gebracht.

Als wir vor einigen Monaten über Microsofts Direct-Storage-API berichteten, gingen wir davon aus, dass die verbesserte Speicherverwaltung für Windows 10 kommt. Ankündigungen blieben allerdings auch in den kommenden Wochen aus. Schließlich gingen Leaks um Windows 11 durchs Netz - zusammen mit der Vermutung, dass die verbesserte Speicherverwaltung als Teil des neuen Betriebssystems erscheint. Nun hat Microsoft Direct Storage für Windows 11 offiziell bestätigt.

Die Xbox Series X/S unterstützt bereits den optimierten I/O-Zugriff auf NVMe-SSDs, der als Direct Storage vermarktet wird und den CPU-Overhead reduzieren soll. Microsoft schreibt dazu in seiner Ankündigung: "Mit Direct Storage auf Windows 11 können Spiele Inhalte schneller auf die Grafikkarte laden, ohne die CPU zu belasten. Für Dich bedeutet das detaillierte Spielewelten, die blitzschnell gerendert werden - ganz ohne lange Ladezeiten."

Mit der Ankündigung von Direct Storage wird man vermutlich auch bald wieder etwas von RTX IO hören. Nvidia hatte die GPU-basierte Daten-Dekomprimierung, die Direct Storage voraussetzt, bereits im September 2020 im Zuge der Ampere-Vorstellung vorgestellt - bisher aber keine Taten folgen lassen.

Windows 11 mit "Auto HDR-Funktion" für Spiele

Microsoft stellt in seiner Ankündigung auch eine "Auto HDR-Funktion" heraus. Der Beschreibung nach fügt diese Funktion High Dynamic Range (HDR)-Erweiterungen automatisch zu Spielen hinzu, die auf DirectX 11 oder höher setzen, bisher aber nur Standard Dynamic Range (SDR) nutzten.

Darüber hinaus betonen die Redmonder in ihrer Ankündigung, dass Windows 11 "weiterhin die umfangreichste Hardwareunterstützung" weltweit bietet. Microsoft nennt an der Stelle Xbox Wireless Controller, mechanische Tastaturen, Gaming-Mäuse, Xbox Adaptive Controller, Surround Sound-Headsets, externe GPUs und "vieles mehr".

Auch sei die Xbox-App nun direkt in Windows 11 integriert. An der Stelle lässt es sich der Software-Entwickler nicht nehmen, auf seinen Game Pass für PC zu verweisen. Wer ihn abonniert, erhält unter anderem Zugriff auf Spiele von Bethesda.

Mehr zum Thema: Windows 11: Android-Apps, Gaming-Features und mehr angekündigt

Windows 11 soll Ende dieses Jahres erscheinen und für Besitzer von Windows 11 als kostenloses Upgrade zur Verfügung stehen. Teilnehmer des Windows-Insider-Programms können eine frühe Version des Betriebssystems laut Microsoft bereits in den kommenden Wochen ausprobieren.

Quelle:Microsoft

Empfohlener redaktioneller Inhalt [EMBED_URL] An dieser Stelle finden Sie externe Inhalte von [PLATTFORM]. Zum Schutz Ihrer persönlichen Daten werden externe Einbindungen erst angezeigt, wenn Sie dies durch Klick auf "Alle externen Inhalte laden" bestätigen: Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit werden personenbezogene Daten an Drittplattformen übermittelt. Mehr dazu in unserer Datenschutzerklärung.
Externe Inhalte Mehr dazu in unserer Datenschutzerklärung.
120

    • Kommentare (120)

      Zur Diskussion im Forum
      • Von PCGH_Torsten Kokü-Junkie (m/w)
        Zumindest bei der X-Box-Demo war deutlich zu sehen, dass SFS während Kameraschwenks drastisch erhöhten Speicherbedarf hatte. Es werden also zunächst viele unbenötigte Daten geladen und erst später evicted, nicht der Bedarf vorhergesagt. Der von dir zitierte Satz ist in meinen Augen auch weder schlüssig noch etwas wofür man Sampler Feedback benötigt: Welche Texturen in der Szene sind ergibt sich aus deren Geometrie, in welcher Auflösung sie benötigt werden aus der Entfernung zur Kamera. Beides ist lange vor dem Sampling schon dem auf der CPU laufenden Teil der Engine bekannt. Dementsprechend beginnt der Satz auch mit "... request of Mip 0 ...". Das heißt die gewünschte Qualität ist von Anfang an bekannt, aber wegen einem zu lahmen Speichersubsystem (DirectStorage von SSD statt Texturepool im RAM?) zeigt das beschrieben Systeme eine zeitlang trotzdem Matsch an. Neuerung ist gegebenfalls, dass es das automatisch macht – wobei die Differenzierung zwischen bestehenden automatischen Systemen, die Entwickler in ihre Engines integriert haben und einem neuen Automatismus, den Entwickler in ihre Engine integrieren müssen, nicht nachvollziehen kann. Wenn die Devs nichts machen, haben sich auch kein SFS.

        Was ich und auch dein vorangehender Link dagegen beschrieben haben sind Mechanismen, um Teile einer Mip-Map nie in hoher Qualität zu laden, weil man dank Shader Feedback im zweiten Renderingpass weiß, welche Texturteile unsichtbar sind, was sich aus der Geometrie nicht ohne weiteres im voraus ableiten lässt. Aber das geht, wie geschrieben, nur bei hohe Frameraten sinnvoll. Mit 60 Fps oder gar 30 Fps sind zu viele Bildteile zu oft in Pass 1 zu sehen, wären also ständig sichtbar matschig. Selbst bei 120 Fps würde ich temporale Artefakte erwarten, beispielsweise einen mehrere Pixel breiten schmierigen Streifen wenn man um eine Ecke strafed, weil eben nur der bereits sichtbare Teil der dahinter liegenden Texturen im Speicher liegt, während sichtbar werdende Teile erst nachladen müssen. Da sind prognostizierende Ansätze, die einem sagen, was gebraucht werden wird, die deutlich bessere Alternative zu einem Feedbacksystem, das einem sagt, was gebraucht wurde.

        (Gilt, wie gesagt, alles nur für PCs/System mit exklusivem VRAM. Wenn man Texturspeicher dynamisch vom Systemspeicher abzwackt, kann es sich dagegen gerade bei niedrigen Frameraten lohnen, einiges davon kurzzeitig freizuschaufeln, weswegen ich die Technik für Konsolen auch spannend finde.)
        Zitieren
      • Von PCGH_Torsten Kokü-Junkie (m/w)
        Zumindest bei der X-Box-Demo war deutlich zu sehen, dass SFS während Kameraschwenks drastisch erhöhten Speicherbedarf hatte. Es werden also zunächst viele unbenötigte Daten geladen und erst später evicted, nicht der Bedarf vorhergesagt. Der von dir zitierte Satz ist in meinen Augen auch weder schlüssig noch etwas wofür man Sampler Feedback benötigt: Welche Texturen in der Szene sind ergibt sich aus deren Geometrie, in welcher Auflösung sie benötigt werden aus der Entfernung zur Kamera. Beides ist lange vor dem Sampling schon dem auf der CPU laufenden Teil der Engine bekannt. Dementsprechend beginnt der Satz auch mit "... request of Mip 0 ...". Das heißt die gewünschte Qualität ist von Anfang an bekannt, aber wegen einem zu lahmen Speichersubsystem (DirectStorage von SSD statt Texturepool im RAM?) zeigt das beschrieben Systeme eine zeitlang trotzdem Matsch an. Neuerung ist gegebenfalls, dass es das automatisch macht – wobei die Differenzierung zwischen bestehenden automatischen Systemen, die Entwickler in ihre Engines integriert haben und einem neuen Automatismus, den Entwickler in ihre Engine integrieren müssen, nicht nachvollziehen kann. Wenn die Devs nichts machen, haben sich auch kein SFS.

        Was ich und auch dein vorangehender Link dagegen beschrieben haben sind Mechanismen, um Teile einer Mip-Map nie in hoher Qualität zu laden, weil man dank Shader Feedback im zweiten Renderingpass weiß, welche Texturteile unsichtbar sind, was sich aus der Geometrie nicht ohne weiteres im voraus ableiten lässt. Aber das geht, wie geschrieben, nur bei hohe Frameraten sinnvoll. Mit 60 Fps oder gar 30 Fps sind zu viele Bildteile zu oft in Pass 1 zu sehen, wären also ständig sichtbar matschig. Selbst bei 120 Fps würde ich temporale Artefakte erwarten, beispielsweise einen mehrere Pixel breiten schmierigen Streifen wenn man um eine Ecke strafed, weil eben nur der bereits sichtbare Teil der dahinter liegenden Texturen im Speicher liegt, während sichtbar werdende Teile erst nachladen müssen. Da sind prognostizierende Ansätze, die einem sagen, was gebraucht werden wird, die deutlich bessere Alternative zu einem Feedbacksystem, das einem sagt, was gebraucht wurde.

        (Gilt, wie gesagt, alles nur für PCs/System mit exklusivem VRAM. Wenn man Texturspeicher dynamisch vom Systemspeicher abzwackt, kann es sich dagegen gerade bei niedrigen Frameraten lohnen, einiges davon kurzzeitig freizuschaufeln, weswegen ich die Technik für Konsolen auch spannend finde.)
        Zitieren
      • Von raPid-81
        Zitat von PCGH_Torsten
        Die Engine weiß nicht, welche Daten noch im VRAM liegen, dass stimmt, weil überschüssiger VRAM vom Treiber selbst in Eigenregie als Cache verwaltet wird. Aber das spielt eben genau deswegen keine Rolle, denn der Treiber ist auch an allen anderen Schritten beteiligt. Die Engine muss nur sagen, was gerendert werden soll – die Daten organisiert sich die GPU dann selbst. (Zumindest solange sie im RAM vorliegen, aber das tun sie auf dem PC eben, wenn der Entwickler keinen Fehler gemacht hat.)
        Das ist doch genau der Punkt, wenn die Game-Devs ihr Streaming perfekt optimiert haben dann liegen die passenden Texturen immer dann im RAM wenn sie benötigt werden. SFS optimiert das nun automatisch, immer, ohne Ratespiel.

        Zitat von PCGH_Torsten
        Zum Raten sagt dein eigener Link alles:
        "Before Sampler Feedback, the developers lack the ability to optimize things to the absolutely last drop. They could only make some guesses about visibility, importance or so".
        Die Entwickler mussten nie raten, welche Mip-Stufe sie von welcher Textur brauchen. Im Gegenteil, das gibt es meinem Wissen nach sogar noch die Engine bevor beziehungsweise sie kann zumindest Vorgaben machen, bis zu welcher Empfehlung der Treiber welche Mip-Stufe wählt. Unbekannt ist nur das "letzte" Detail: Wieviel der geladenen Textur ist überhaupt sichtbar?
        Zum "vorladen" in den RAM/VRAM müssen die Game-Devs aber weiterhin raten, eben weil sie mit alten Streaming-Techniken kein Feedback vom Sampler erhalten und somit wissen könnten was gebraucht wurde. Es geht auch nicht nur um "Wieviel der geladenen Textur ist überhaupt sichtbar?" sondern auch "Wieviel der geladenen Textur ist überhaupt sichtbar und in welchem MIP-Level wird sie benötigt?".

        Zitat von PCGH_Torsten
        Aber das weiß auch SFS erst nachdem die Szene gerendert wurde. Dann können mit SFS Texturteile, die im Moment nicht benötigt werden, wieder aus dem VRAM geschmissen werden, aber zunächst wird die volle Kapazität benötigt. Eventuell kann das mal in Kombination mit hohen Fps-Raten und verzögertem Streaming genutzt werden, um die VRAM-Anforderungen allgemein zu senken (man rendert die Szene einmal in Qualität "Matsch", damit man die sichtbaren Texturbereiche kennt, und lädt diese dann in HD nach). Aber im Moment ist der Trend am PC genau das Gegenteil: Es wird VRAM weit über das für das aktuelle Bild benötigte und sogar über der von der Engine gemeldeten Bedarf hinaus mit alten Texturen als Cache gefüllt, um bei der nächsten Bewegung möglichst nichts über den lahmen PCI-E-Slot nachladen zu müssen.
        Soweit ich SFS+DS verstanden habe wird genau das gemacht, Frame 1 wird beispielsweise (wie Du sagtest) mit höherem MIP-Level ausgegeben, SFS streamt die Texturen die in einem niedriger benötigten MIP-Level zu sehen sind nach (also detaillierter) und gibt sie schnellstmöglich mit automatischem Filter zur besseren Überblendung in Frame 2-3-4-usw aus.

        Zitat

        As we have stated, the Sampler knows what it needs. The developer can answer the request of Mip 0 by giving Mip 0.8 on frame 1, Mip 0.4 on frame 2, and eventually Mip 0 on frame 3.
        Zitieren
      • Von PCGH_Torsten Kokü-Junkie (m/w)
        Die Engine weiß nicht, welche Daten noch im VRAM liegen, dass stimmt, weil überschüssiger VRAM vom Treiber selbst in Eigenregie als Cache verwaltet wird. Aber das spielt eben genau deswegen keine Rolle, denn der Treiber ist auch an allen anderen Schritten beteiligt. Die Engine muss nur sagen, was gerendert werden soll – die Daten organisiert sich die GPU dann selbst. (Zumindest solange sie im RAM vorliegen, aber das tun sie auf dem PC eben, wenn der Entwickler keinen Fehler gemacht hat.)

        Zum Raten sagt dein eigener Link alles:
        "Before Sampler Feedback, the developers lack the ability to optimize things to the absolutely last drop. They could only make some guesses about visibility, importance or so".
        Die Entwickler mussten nie raten, welche Mip-Stufe sie von welcher Textur brauchen. Im Gegenteil, das gibt es meinem Wissen nach sogar noch die Engine bevor beziehungsweise sie kann zumindest Vorgaben machen, bis zu welcher Empfehlung der Treiber welche Mip-Stufe wählt. Unbekannt ist nur das "letzte" Detail: Wieviel der geladenen Textur ist überhaupt sichtbar?
        Aber das weiß auch SFS erst nachdem die Szene gerendert wurde. Dann können mit SFS Texturteile, die im Moment nicht benötigt werden, wieder aus dem VRAM geschmissen werden, aber zunächst wird die volle Kapazität benötigt. Eventuell kann das mal in Kombination mit hohen Fps-Raten und verzögertem Streaming genutzt werden, um die VRAM-Anforderungen allgemein zu senken (man rendert die Szene einmal in Qualität "Matsch", damit man die sichtbaren Texturbereiche kennt, und lädt diese dann in HD nach). Aber im Moment ist der Trend am PC genau das Gegenteil: Es wird VRAM weit über das für das aktuelle Bild benötigte und sogar über der von der Engine gemeldeten Bedarf hinaus mit alten Texturen als Cache gefüllt, um bei der nächsten Bewegung möglichst nichts über den lahmen PCI-E-Slot nachladen zu müssen.
        Zitieren
      • Von raPid-81
        Zitat von PCGH_Torsten
        Habe das nie systematisch getestet, aber in den meisten Spielen scheinen mir die Ladezeiten beim Schnellreisen deutlich länger zu sein, als für die Kopie des minimalen/aktiv genutzten VRAM-Inhalts aus dem RAM oder gar von der SSD benötigt werden würde. Das gilt um so mehr als wenn zwischen Gebieten mit ähnlichem Texturset gereist wird. Witcher 3 zum Beispiel benutzt meiner Erinnerung nach maximal 3 GiB VRAM und typischerweise weniger als 2 GiB (ohne Mods), von denen beim Schnellreisen zwischen zwei Punkten in der gleichen Gegend 1,5 GiB identisch zu bestücken sind. Es müssen also weniger als 500 MiB über die 32-GB/s-Verbindung zwischen GPU und CPU transportiert werden, nicht einmal für die Einblendung eines Ladebildschirms reichen würde.

        Meine Vermutung: Da werden eher die gesamten anderen Informationen, vor allem die Position diverser Objekte in der Gegend, gespeichert.

        Zum Nachladen von Auflösungsstufen: Das wird meinem Wissen nach seit AGP 1.0 unterstützt.
        Also ich habe z.B. während ich Division 2 gezockt habe eine NVME in mein System eingebaut, das Schnellreisen hat sich alleine dadurch massiv beschleunigt. Ich denke da kommt es auf die Engine an, beim Schnellreisen könnte ich mir einen "complete VRAM flush" vorstellen. Immerhin weiss die Engine (ohne Sampler Feedback) nicht genau welche Texturen in welchem MIP Level gerade im VRAM liegen.

        Ja, das Streaming von benötigten MIP-Leveln gibt es schon ewig. Allerdings ist es bis einschließlich PRT (Partial Resident Texture / Virtual Texture) ein "raten" was geladen werden muss. Ich empfehle dazu folgenden Link: https://forum.xboxera.com...

        Da wird auf jedes Streaming-Verfahren eingegangen und Sampler Feedback Streaming erklärt.
        Zitieren
      • Von PCGH_Torsten Kokü-Junkie (m/w)
        Zitat von raPid-81
        RDNA1 / Turing vielleicht per Shader, RDNA2 / Ampere dann in Hardware. Werden wir sehen wenn es verfügbar ist.

        Mehr FPS wird es dadurch eher gar keine geben, aber generell schnellere Ladezeiten (ins Spiel rein, Schnellreisen). Immer dann wenn ein kompletter Asset-Austausch stattfindet sollte die Batch-Bearbeitung und komprimierte Übertragung bis zum Endpunkt das Laden beschleunigen.

        Das sehe ich anders, wenn Sampler Feedback Streaming die niedrigeren MIP-Level eines Assets on-the-fly nachlädt (und so ist es ja erklärt worden), dann geht es hier nicht ohne Verbesserung der IO Rates. Und genau da setzt ja DirectStorage an, ich wiederhole mich: Reduzierung des CPU Overheads und Batch-Bearbeitung von Asset-Calls.
        Habe das nie systematisch getestet, aber in den meisten Spielen scheinen mir die Ladezeiten beim Schnellreisen deutlich länger zu sein, als für die Kopie des minimalen/aktiv genutzten VRAM-Inhalts aus dem RAM oder gar von der SSD benötigt werden würde. Das gilt um so mehr als wenn zwischen Gebieten mit ähnlichem Texturset gereist wird. Witcher 3 zum Beispiel benutzt meiner Erinnerung nach maximal 3 GiB VRAM und typischerweise weniger als 2 GiB (ohne Mods), von denen beim Schnellreisen zwischen zwei Punkten in der gleichen Gegend 1,5 GiB identisch zu bestücken sind. Es müssen also weniger als 500 MiB über die 32-GB/s-Verbindung zwischen GPU und CPU transportiert werden, nicht einmal für die Einblendung eines Ladebildschirms reichen würde.

        Meine Vermutung: Da werden eher die gesamten anderen Informationen, vor allem die Position diverser Objekte in der Gegend, gespeichert.

        Zum Nachladen von Auflösungsstufen: Das wird meinem Wissen nach seit AGP 1.0 unterstützt.
        Zitieren
      Direkt zum Diskussionsende
Hoch
  • Print / Abo
    Apps
    PCGH Magazin 07/2026 PC Games 07/2026 play5 07/2026 N-Zone 07/2026 Linux Magazin 07/2026 LinuxUser 07/2026 Raspberry Pi Geek 07/2026
    PC Games Hardware PC Games Linux Magazin Raspberry Pi Geek Computec Kiosk
Die Redaktion Datenschutz Artikel-Archiv Datenschutz-Optionen Mediadaten Impressum Utiq verwalten Abo kündigen Vertrag widerrufen AGB Inhalt melden Newsletter