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

[ThePlayer]

Dazu kommt ja noch, dass es tatsächlich ein Windows 7 DX12 Update gegeben hat.

Deswegen habe ich das ja auch erwähnt. Es kam glaube ich letztes Jahr oder war das 2020 jedenfalls relativ spät. Habe mich wirklich gewundert.

 

[mibbio]

Wenn es danach ginge, könnten wir das aktuelle Windows auch Vista SP8 oder Windows 6.6 nennen können.

Ist es genau genommen ja auch, bis Windows 10 war die Versionsnummer ja 6.4 und erst mit einem der Halbjahresupdates wurde die Nummerierung auf 10.0 umgestellt (ist technisch aber immer noch 6.x).

 

[xexex]

Hier stand Quatsch

 

[chakko]

-Komplettzitat entfernt-

Kann man natürlich auch so verstehen, gemeint war es aber nicht so, weil die einschlägigen Aussagen ja eher in die Richtung laufen, dass jede neue Windows Version mal schlechter läuft als alles andere am Markt. Aber um es nochmal herauszustreichen, Windows 11 behindert mich in keinster weise und läuft butterweich. Bugs habe ich keine gefunden bzw. behindert mich nicht. Die 20 Minuten updatezeit werden sie sicher entbehren können, die Zeiten von Windows 98 sind vorbei, dass man alles neu Einstellen muss und logs und inis neu anlegen etc.

Das man alte Software nur noch mit dem nötigesten supported sollte auch klar sein, so lange Microsoft Win 10 nicht unbrauchbar patched, gibt es auch hier nichts zu jammern. Wer direct storage haben will, muss eben umsteigen.

 

[Wasserhuhn]

Du verstehst anscheinend einfach nicht wie Software entwickelt wird

Stimmt, ich mache das nicht beruflich, und mit meiner Zeit als Hobbyist noch dazuberechnet nicht schon seit 14 Jahren.
Das Thema ist damit für mich beendet. Die grundlegenden Abwägungsfragen nannte ich schon bereits.

 

[Piktogramm]

[...]
Schon alleine, dass die File API in Zukunft eine NVMe SSD wie eine NVMe SSD behandeln wird und dabei ihre Vorteile, massive Parallelisierung, nutzen wird, dürfte schon für einiges an Schub sorgen. Warum war denn bisher eine NVMe SSD ausserhalb von Benchmarks kaum schneller als eine SAT SSD, obwohl sie das zigfache an Rawpower hat? Weil sie (wie auch die SATA SSD) von der alten File API immer noch wie eine Festplatte angesprochen wird. Eine I/O Anfrage nach der anderen, da der Lesekopf früher nunmal nur an einer Stelle gleichzeitig sein konnte. So kommt eine NVMe SSD aber nicht auf den Speed, sondern durch parallele / gleichzeitige Aufrufe und damit einhergehend einer hohen Queue Depth.
[...]

Herje.. NVMe SSDs bringen kaum etwas außerhalb von Benchmarks, weil klassische PCs mit einem aktivem Nutzer schlicht und ergreifend keine Lasten erzeugen, bei denen viele Verbesserungen des Protokolls überhaupt wirken können. Mit der File API hat das auch wenig zu tun[1]

Ein NVMe read kann auf einen Schlag 2^15 Blöcke ansprechen[2]. Bei 512B logischen Blöcken sind das flockig 16MB auf einen Schlag. Bei 4K Blöcken entsprechend 128MB. Da kommen kaum Requests zusammen um die Warteschlange des Laufwerks zu füllen. Bei 4K Blöcken reichen 64 Requests in der Sekunde um 8GB/s Bandbreite zu sättigen (4x PCIe4)[3]. Selbst wenn man weniger, dafür viele Dateien anpacken will. Lass es 100 Dateien a 4MB sein. Das sind auch nur 100 Read Request.
Wo die größeren Warteschlangen etwas bringen sind jene Fälle, wo es massiv zu zufälligen Zugriffen kommt. Also extrem fragmentierte Dateisysteme, Datenbanken, Netzwerkspeicher, Hosts von VMs aber nicht an Rechnern, die nur von einer Person genutzt werden.

Eine andere Geschichte ist dann noch, dass Entwickler überhaupt mal darum kümmern müssten async I/O gescheit einzusetzen. Meist scheitert es ja daran, dass sich Programm Logik von I/O Request zu Request durchhangelt. Da kann ein Betriebssystem abgesehen von Prefetch auch nicht viel dagegen tun.

[1] Ich finde die bei Windows gruslig, habe aber auch ein Posixfetisch..
[2] Seite 33 https://nvmexpress.org/wp-content/u...et-Specification-1.0b-2021.12.18-Ratified.pdf
[3] Protokolloverhead vernachlässigt und die Annahme getroffen, dass Metadaten vom Dateisystem bereits im Ram sind und daher kein i/o auf dem Festspeicher bedingen

Texturen sind bereits komprimiert gespeichert, oben drauf nochmal eine Komprimierung anzusetzen kann bestenfalls geringe Vorteile bringen. Der Vorteil wäre früher vielleicht mit Festplatten höher gewesen, heute kann damit in erster Linie bestenfalls etwas Speicherplatz gespart werden.

Jain, Texturen werden in der Regel einmal komprimiert. Diese Kompression ist dabei so gewählt, dass die GPUs die Texturen im komprimierten Format in den Vram laden und verarbeiten können. Man spart Platz auf der Platte, Bandbreite zur GPU, Platzbedarf auf dem Vram und Bandbreite zwsichen GPU und Vram. Genutzt wird ASTC[4] oder Vergleichbare Algorithmen.
Kompression darüber hinaus gibt es nur, wenn sowas wie Kompression des Dateisystems erzwungen wird oder wenn Entwickler aus welchen Gründen auch immer vom Goldstandard abweichen..

Das hat mit DirectStorage aber alles nichts zu tun.. Eher damit, dass nach ewigen Streitereien über Patente und proprietäre Lösungen sich mal wieder ein Schwung modernere Compressionsalgorithmen im DirectX Standard wiederfinden.

[4]https://en.wikipedia.org/wiki/Adaptive_scalable_texture_compression

 

[Malaclypse17]

So sehe ich das jedenfalls und daher nehme ich an, dass wir auch viele Funktionen im Startmenü/Startleiste auch wieder bekommen, die wir in Windows 10 bereits hatten.

Da wären wir wieder bei dem Punkt, dass mit Windows 11 sogar nicht nur kaum Features dazu gekommen sind, es sind auch noch Features weggelassen worden, wie man das als Vorteil auslegen kann, erschließt sich mir nicht.
Was für einen Vorteil hat es, keine Dateien mehr per drag&drop in Programme auf der Taskleiste ziehen zu können, oder dass man nun gezwungen wird, diese total dämliche Gruppierung der offenen Programme in der Taskleiste zu nutzen, für mich ein "Produktivitätskiller". Vom Rechtsklick-Menü erst gar nicht angefangen.
Aber klar, kann man sich alles wieder durch viel Frickelei hinbasteln.
Nun aber genug OT, ist mein letzter Beitrag dazu, dies ist so eine Situation wo man erkennen muss, dass man verschiedener Meinung ist und es dabei belassen.

 

[noxon]

Da wären wir wieder bei dem Punkt, dass mit Windows 11 sogar nicht nur kaum Features dazu gekommen sind

Wohl eher dabei, dass du es immer noch nicht verstanden hast. Seit dem Release von Windows 10 in 2015 sind ja wohl eine Menge Features hinzugekommen oder willst du mir sagen, dass in den letzten sieben Jahren nichts passiert ist?
Bisher war noch keine andere Windows-Version so lange ohne Major Release-Wechsel auf dem Markt, wie Windows 10. Wann wäre ein Versionswechsel deiner Meinung nach denn angebracht. Nach zehn Jahren?

Im übrigen passt es auch ganz gut, weil das WDDM sonst eine zweistellige Minor-Versionsnumer hätte bekommen müssen. WDDM Versionierung
Ist also eine ganz gute Gelegenheit.

@joshy337
Man kann sich einige dieser Probleme aber auch ersparen, wenn man mal etwas Geld für das Betriebssystem ausgeben würde. Auf die Nutzungsdauer von 10 Jahren kostet das ja immerhin nicht viel und dennoch will keiner dafür was bezahlen. Wer also so knauserig ist und nur mit der Home-Edition arbeiten will, der muss die Software halt dadurch finanzieren, indem er weniger Kontrolle über das System bekommt und Versuchskaninchen für die anderen spielen muss..

 

[Malaclypse17]

Wohl eher dabei, dass du es immer noch nicht verstanden hast. Seit dem Release von Windows 10 in 2015 sind ja wohl eine Menge Features hinzugekommen oder willst du mir sagen, dass in den letzten sieben Jahren nichts passiert ist?

So funktionieren Versionen nur leider nicht.
Ich mache doch aus Version 1.0 nicht Version 2.0 weil es in Version 1.0 so viele Änderungen und Verbesserungen gab, sondern weil ich mit dem Release von 2.0 einen großen Sprung markieren will, welcher an sich viele Verbesserungen und Änderungen mibringen soll, sonst würde das Konzept auch keinen Sinn ergeben.
Ein großer Versionssprung wird nicht gemacht, weil es mal an der Zeit war, sondern weil er mit großen Änderungen einhergeht.

 

[M@tze]

Herje.. NVMe SSDs bringen kaum etwas außerhalb von Benchmarks, weil klassische PCs mit einem aktivem Nutzer schlicht und ergreifend keine Lasten erzeugen, bei denen viele Verbesserungen des Protokolls überhaupt wirken können.

Und genau das wird sich ja eben mit dem Sample Feedback Streaming auch ändern, wenn nicht mehr ganze Texturen am Stück sondern nur noch tausende kleine Bruchstücke davon geladen werden. Für die andere Software läuft es dann ja auch darauf hinaus, dass diese entsprechend vom Anbieter überarbeitet werden muss, um die Möglichkeiten überhaupt zu nutzen. Bisher waren diese einfach nicht gegeben, also fehlt da auch noch die Anpassung.

Das jetzt bei einem simplen Outlook/Browser/... Workflow große Sprünge zu erwarten sind, habe ich ja nicht gesagt.

 

[sadofia]

da werden sicherlich einige spielebenchmarks neu sortiert, wenn die cpu dadurch nicht mehr/weniger limitiert.
werden cpu- und gpu-tests dann zusätzlich mit unterschiedlichen ssds gemacht?

 

[Piktogramm]

@M@tze
Es würde mich wundern, wenn in realen Anwendungen das Ganze derart feingranular eingesetzt wird. Genauso wie die Techdemo alles aus dem (Grafik-)Speicher zu werfen scheint, was für ein paar Bilder nicht gebraucht wird. Normalerweise nutzt man ja schon Caching, einfach weil Arbeitsspeicher immer schneller und Festspeicher tendenziell immer ein Flaschenhals ist.
Schön ist der Ansatz allemal.

 

[M@tze]

Schön ist der Ansatz allemal.

Absolut, ich fand auch die Tech Demo wirklich gut gemacht, da hat man sogar ohne großes Hintergrundwissen gut erkannt wie das technisch gehandelt wird. Klar, ob das dann wirklich jemals zu 100% so genutzt wird, steht natürlich auf einem anderen Blatt, aber ich habe die Hoffnung das da nicht Entwicklungsressourcen reingesteckt wurden ohne einen praktischen UseCase in der Hinterhand zu haben.

 

[Mimir]

@M@tze
Es würde mich wundern, wenn in realen Anwendungen das Ganze derart feingranular eingesetzt wird. Genauso wie die Techdemo alles aus dem (Grafik-)Speicher zu werfen scheint, was für ein paar Bilder nicht gebraucht wird. Normalerweise nutzt man ja schon Caching, einfach weil Arbeitsspeicher immer schneller und Festspeicher tendenziell immer ein Flaschenhals ist.
Schön ist der Ansatz allemal.

Das Caching braucht man ja aktuell nur, weil die HDDs bisher viel zu lahm waren um just in Time Daten nachzuliefern. Die SSDs sind da eben schnell genug.

Zudem brauchst du den schnellen VRAM ja ansonsten primär nicht dazu, um da irgendwelche Daten zu cachen, sondern die Hauptaufgabe ist ja in erster Linie dass der VRAM der "Arbeits"speicher für die GPU ist.
Also damit arbeitet die GPU ja direkt und aktiv und muss dementsprechend schnell angebunden sein. Mit dem Caching von Daten die nicht aktiv gebraucht werden, zweckentfremdend man den VRAM ja auch aktuell ein Stückweit.

Wenn man nicht aktiv genutzte Daten aber schnell wieder aus dem VRAM rauswirft und sich das Caching spart, haben im VRAM eben künftig mehr aktiv genutzte Daten platz. Sprich man kann mit einer gegebenen Menge VRAM aufwändigere bzw. mehr Assets verarbeiten als zuvor.


Klar könnte man langsamen Speicher auch weiterhin einfach durch mehr VRAM kompensieren. Aber um das zu erreichen, was Direct Storage und Sampler Feedback Streaming in der Praxis an Durchsatz erreichen müsste man wohl auf GPUs mit 64 GB VRAM und mehr setzen. Das ist halt einfach nicht wirtschaftlich.

Der Ansatz mit Direct Storage und SFS ist natürlich aufwändig und komplex, aber ich denke, dass dadurch die Ressourcen unterm Strich deutlich effizienter genutzt werden und eben auch endlich die SSDs ihren sinnvollen Beitrag leisten können. Potenzial das bisher eben komplett ungenutzt bleib.

Am Ende schlägt man mehrere Fliegen mit einer Klappe. Man behebt das Bottleneck zum Storage, über die CPU was schon seit langem ein Problem ist, man umgeht die VRAM Knappheit und man kann die Geschwindigkeit von SSDs eben sinnvoll nutzen.


Mich würde mal interessieren, ob die Unreal Engine 5 auch Direct Storage und SFS nutzt. Soweit ich das verstanden habe machen die praktisch das gleiche, nennen es aber "Textur Virtualisierung" oder "Geometrie Virtualisierung". Da wird dann eben auch nur noch das in den Speicher geladen, was wirklich aktiv gerade im Moment zur Verarbeitung auf der GPU gebraucht wird, was eben zur Folge hat, dass man irrsinnig große Assets performant verarbeiten kann, weil man sie nicht wirklich vollständig laden muss. Die Anwendung "tut" nur so bzw. virtualisiert den Vorgang eben. Wenn ich jetzt nur wüsste, wo ich das gelesen habe...

Auf jeden Fall ein wahnsinnig spannendes Thema.

 

[0x8100]

Da wird dann eben auch nur noch das in den Speicher geladen, was wirklich aktiv gerade im Moment zur Verarbeitung auf der GPU gebraucht wird, [...] Wenn ich jetzt nur wüsste, wo ich das gelesen habe...

das wurde z.b. hier gesagt:

Since the first debut of the Lumen in the Land of Nanite demo, there has been the perception that the mass bandwidth of the SSD in PlayStation 5 is what makes the Nanite system possible. However, the whole point of the virtualised texturing system used by Nanite is that it's actually very lightweight in bandwidth - the only detail streamed in is that which is required onscreen at any given point. "This distinguishes it from traditional engines... [with Nanite] it's very gradual," says Michal Valient. "As you move around, it hovers at like 10MB per frame, because we stream bits of textures, bits of Nanite data... we stream textures or small tiles as you need them. As you render them, Nanite picks the actual little clusters of triangles you need to render that particular view. And we stream just that, so we don't over-stream too much. And that actually allows it to be really swift when it comes to just I/O and that throughput."

dieser ansatz zeigt allerdings auch, dass gar nicht so ein grosser datendurchsatz benötigt wird.

 

[Piktogramm]

@W0dan
Volatiler Speicher ist gerade in Bezug auf Latenzen auch den besten NVMe Laufwerken überlegen und es besteht immer die Gefahr, das konkurrierende Zugriffe auf ein Laufwerk gibt, was die Latenzen inkonsistent werden lässt. Da wäre es einfach unsinnig ohne Caches zu arbeiten, vor allem da Caching quasi zum Nulltarif implementierbar ist[1]. Ein Mehrbedarf an Speicher kommt auch nicht zustande, es wird ja sowieso nur Speicher genutzt, der vorher belegt war und als "kann freigegeben werden" markiert wurde.

[1]Ob man nun komplett die Referenz aus der Speicherverwaltung entfernt oder nur einen "kann weg vermerkt" setzt ist schlussendlich vom Aufwand her gleich.

 

[mibbio]

So funktionieren Versionen nur leider nicht.

Auch das Argument mit der 2-stelligen Minor-Version bei WDDM ist Quatsch. Versionsnummer zählt man ja nicht wie normale Dezimalzahlen, indem man die Zehnerstelle auf die Major-Nummer draufrechnet, sondern nach 2.9 kommt halt 2.10, 2.11 usw. Es gibt also gar keine Notwendigkeit, die Major-Version zu erhöhen, nur weil die Stelle dahinter sonst 2-stellig wird.

Das erlebe ich aber auch öfter in Diskussionen (nicht hier), dass die Zählweise von Versionsnummer mit der mathematischen Zählweise gleichgesetzt sitzt. Da wird sich dann gerne mal gewundert, warum nach x.8.9 nicht nich x.9.0 sondern x.8.10 kommt.

 

[janeeisklar]

Wo hast du diese Information gefunden? Weil das wäre absolut kontraproduktiv, wenn die Daten vom Datenträger zur GPU fließen und zum entpacken wieder zur CPU und erneut zurück.

Außerdem ist es meiner Meinung nach unsinnig etwas zu komprimieren, das nicht nativ so auf der GPU weiterverwendet werden kann. Einige mögen ja PNG, JPEG und Co nutzen, das erklärt dann auch die langen Ladezeiten.
Abgesehen von ein paar Ausnahmen, sollten die Daten immer in einem von der GPU nativ unterstützten Format abgelegt werden.

Auch bei AMD GPUs können Daten (es sind ja eigentlich Objekt "blobs") ohne den "umweg" über das SystemRAM zum VRam geschaufelt werden, wird bei 3D aber idR nicht besonders effizient sein, da man diese sowieso immer wieder mal braucht, deshalb ist das SystemRAM die deutlich bessere Lösung da immer noch zichfach schneller.
Die Komprimierung ist eine Transit-komprimierung, man schaufelt durch die komprimierung immer noch mehr Daten/Sek in das VRam (inc dekomprimierung!) als ohne komprimierung.

 

[joshy337]

@joshy337
Man kann sich einige dieser Probleme aber auch ersparen, wenn man mal etwas Geld für das Betriebssystem ausgeben würde. Auf die Nutzungsdauer von 10 Jahren kostet das ja immerhin nicht viel und dennoch will keiner dafür was bezahlen. Wer also so knauserig ist und nur mit der Home-Edition arbeiten will, der muss die Software halt dadurch finanzieren, indem er weniger Kontrolle über das System bekommt und Versuchskaninchen für die anderen spielen muss..

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.

Edit: Bitte nicht falsch verstehen, das soll keine Kritik sein.
Eher eine Beobachtung. Ein Kumpel bei den Stadtwerken wollte damals beispielsweise unbedingt Windows XP Pro haben, obwohl es bereits nicht mehr im Handel war.
Da spielte Geld keine Rolle. Er wollte einfach was seriöses.
Wäre Windows 2000 damals nicht so veraltet bzw. inkompatibel gewesen, hätte er ggf. auch das genommen.
Windows NT 5.x war zurecht ein ehrwürdiges System.
Selbst Linuxer hatten Windows NT 5 (Win2000) Respekt gezollt.

 

[onkel_axel]

Dann muss ich ja doch auf Windows 11 Upgraden.
Naja erst mal eine neue CPU nach der Hammer AMD news