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


Mit alten CPU´s und Boards wird auch noch TPM 2.0 interessant, wenns net im Bios einzuschalten geht.
Falls man net aufrüsten möchte hilft dann nur ein Modul. (hier war ein 2700X@B450)
 

Anhänge

  • TPM-Modul.JPG
    TPM-Modul.JPG
    51,1 KB · Aufrufe: 24
Korrigiere mich, wenn ich falsch liege, aber Direct Storage ermöglicht KEINE direkten Transfer von SSD-Daten in den normalen RAM, sondern ausschließlich in den VRAM und ausschließlich mit Dekomprimierung via GPU, ohne Spezialeinheiten also via Shader. Dementsprechend kann es auch nur in Szenarien, in denen herkömmliche PC-Renderer an mangelnder RAM-Größe (respektive -Nutzung) oder CPU-Leistung leiden Vorteile bringen, während es bei mangelnder VRAM-Kapazität oder mangelnder Shader-Leistung sogar Nachteile schafft.
Aus dem MS Dev Blog:

direct-storage.png


Du sprichst von RTX IO welches die Daten, ohne Umweg über den RAM, direkt in den VRAM legt. DirectStorage an sich (ohne Nvidia Erweiterung) arbeitet über den oben zu sehenden "Workflow".

Die Dekomprimierung der Texturen findet bei beiden Techniken innerhalb der GPU statt. Aktuell weiss keiner genau ob dafür dedizierte Recheneinheiten bereits verbaut sind (wie es bei der Xbox der Fall ist), man geht aber davon aus.


rtx-io.jpg


Ich denke da werden sich Nvidia und AMD schon Gedanken zu gemacht haben. Immerhin wird DirectStorage ab RDNA1 / Turing unterstützt.

Es verringert auf jeden Fall die CPU Last durch parallele Bearbeitung und Batch-Calls von Assets. Mangelnde VRAM Kapazität muss man ja erst mal erreichen (aktuell geht das laut euch auch fast nur mit Extrem-Settings), außerdem enabled DirectStorage ja Sampler Feedback Streaming welches den VRAM Bedarf um bis zu 70% senken kann bei gleicher Grafikqualität.


x-times-more-memory.png

Was auf alle Falle falsch ist: Die Annahme einer um Faktor zwei erhöhten Datentransferrate durch die Aufrechterhaltung der doppelten Kompression bis in den VRAM. Das wäre nur gegeben, wenn der Kompressionsfaktor der zweiten Stufe exakt 2 beträgt und wenn die Datentransferrate zwischen RAM und VRAM im bisherigen System limitierend war. Das ist aber nicht der Fall. PCs haben zwischen Arbeitsspeicher und GPU seit längerem mindestens die vierfache Datentransferrate (×4- vs. ×16-Link), in ettlichen Fällen sogar die sechs- bis achtfache (NVME-SSD reizt ihren PCI-E-Standard nicht aus oder hat sogar einen niedrigeren als die Grafikkarte) und in Extremfällen bis zur 16-fachen (lahme 2-GB/s-SSD in einem System mit PCI-E-×16-4.0 zur GPU). Das heißt Direct Storage könnte die reine Transferrate nur steigern, wenn die zweite Komprimierungsstufe die Texturen auf 25 bis unter 10 Prozent der Größe nach der ersten Komprimierung reduzieren würde, was aber vollkommen utopisch ist. Somit ist der einzige Unterschied zwischen Systemen mit Direct Storage und ohne die Senkung der RAM- zu Lasten der VRAM-Anforderungen und die Entlastung der CPU von Entpackaufgaben zu Lasten der GPU.
Ein User hier im Forum hat den Test gemacht, je nach BCn Stufe, kombiniert mit zlib, wurde die Textur bis zu 70% kleiner.

Nvidia spricht von:
This removes the load from the CPU, moving the data from storage to the GPU in its more efficient, compressed form, and improving I/O performance by a factor of 2.
https://www.nvidia.com/en-us/geforce/news/rtx-io-gpu-accelerated-storage-technology/

Und Microsoft auch:
1624651130789.png


Also laut diesen beiden erhöht sich die Performance um Faktor 2 durch die komprimierte Übertragung (oder die gesamte Performance? Das geht nicht so ganz daraus hervor).
 
Hier sind zwei Dinge, die sich gegenseitig verstärken. Zum einen muß der Entwickler das ganze mühselig einbauen, damit es richtig funktioniert und zum anderen ist es nicht allen zugänglich. Weil es nicht allen zugänglich ist, machen sich wenige Entwickler die Mühe das ganze sinnvoll zu impelentieren. Weil es keinen großen Nutzen gibt, wechseln wenige auf Win 11, was das ganze nochmal verstärkt.
Spechen wir jetzt von DirectStorage oder von DLSS ? Weil bei DirectStroage habe ich keine Informationen bisher wie aufwendig eine Implementierung ist. Wenn die ähnlich einfach ist wie eine Library einzubinden und eine Anfrage umzuleiten kann das einen großen Einfluss auf die Implementierungswahrscheinlichkeit haben.
Wenn es aber so mühsehlig ist wie Du sagst, dann hast Du recht, dann ist das keine gute Sache. Mir wäre so oder so lieber gewesen es kommt auch für W10, denn eine breitere Unterstützung zu haben schadet definitiv nie.
 
Korrigiere mich, wenn ich falsch liege, aber Direct Storage ermöglicht KEINE direkten Transfer von SSD-Daten in den normalen RAM, sondern ausschließlich in den VRAM und ausschließlich mit Dekomprimierung via GPU, ohne Spezialeinheiten also via Shader. Dementsprechend kann es auch nur in Szenarien, in denen herkömmliche PC-Renderer an mangelnder RAM-Größe (respektive -Nutzung) oder CPU-Leistung leiden Vorteile bringen, während es bei mangelnder VRAM-Kapazität oder mangelnder Shader-Leistung sogar Nachteile schafft.

Was auf alle Falle falsch ist: Die Annahme einer um Faktor zwei erhöhten Datentransferrate durch die Aufrechterhaltung der doppelten Kompression bis in den VRAM. Das wäre nur gegeben, wenn der Kompressionsfaktor der zweiten Stufe exakt 2 beträgt und wenn die Datentransferrate zwischen RAM und VRAM im bisherigen System limitierend war. Das ist aber nicht der Fall. PCs haben zwischen Arbeitsspeicher und GPU seit längerem mindestens die vierfache Datentransferrate (×4- vs. ×16-Link), in ettlichen Fällen sogar die sechs- bis achtfache (NVME-SSD reizt ihren PCI-E-Standard nicht aus oder hat sogar einen niedrigeren als die Grafikkarte) und in Extremfällen bis zur 16-fachen (lahme 2-GB/s-SSD in einem System mit PCI-E-×16-4.0 zur GPU). Das heißt Direct Storage könnte die reine Transferrate nur steigern, wenn die zweite Komprimierungsstufe die Texturen auf 25 bis unter 10 Prozent der Größe nach der ersten Komprimierung reduzieren würde, was aber vollkommen utopisch ist. Somit ist der einzige Unterschied zwischen Systemen mit Direct Storage und ohne die Senkung der RAM- zu Lasten der VRAM-Anforderungen und die Entlastung der CPU von Entpackaufgaben zu Lasten der GPU.
Aha..
Also Brauch ich dann weniger RAM.. weniger CPU Leistung
Dafür wird der Vram voller
 
Windows 7 only SSD Trim Support
Windows 10 only DX12 Support
Windows 11 only Direct Storage Support

Ich sehe da ein Muster... :schief:
 
Aha..
Also Brauch ich dann weniger RAM.. weniger CPU Leistung
Dafür wird der Vram voller
Dass der VRAM dadurch voller wird ist erst mal Spekulation.

Was man bekommt durch DS ist schnellere Ladezeiten (ins Spiel rein, Schnellreisen, etc), der gesamte Asset-Austausch läuft schneller durch Batch-Bearbeitung anstatt serieller Einzel-Bearbeitung von Anfragen.
 
Hol Dir ein TPM 2.0 -Modul falls Dein Board das net per Bios-Software kann.(oder ersetzt einfach die dll)
Wichtig ist nur das Dein Board ein UEFI-Bios haben muss!


btw.
Für den frühen Status funzt W11 schon ganz gut: mit nem UWP-Treiber schneller als mit dem 21.6.1
Tattoo: "Also ich würde jetzt mal sagen Win 11 hat ca 50 Gfx Punkte gebracht in Verbindung mit dem 21.6.1. Mit dem Dev Treiber war ich bei 24.300 . Konnte den aber nicht Validieren ." Bild ist mit dem W10-Treiber 21.6.1 wg. valide

edit: inzwischen ging mit dem 21.6.1 ein mue mehr
 

Anhänge

  • Tattoo@W11.JPG
    Tattoo@W11.JPG
    96,1 KB · Aufrufe: 15
  • TPM-Abfrage_dll.JPG
    TPM-Abfrage_dll.JPG
    45,9 KB · Aufrufe: 14
  • Tattoo@W11.JPG
    Tattoo@W11.JPG
    99 KB · Aufrufe: 11
Zuletzt bearbeitet:
Um das zu beantworten muss man ziemlich ausholen. Ich mach eine hoffentlich kurze Liste:
[...]
Danke, so war das sehr verständlich!

Demnach bleibe ich bei der Meinung, dass DirectStorage zwar große Vorteile bietet, eine bessere Ausnutzung des RAMs aber auch ordentlich helfen würde da eben die Anbindung vom RAM zu GPU immer noch schneller/breiter ist und eine Station (die SSD) in der Kette fehlt. Wie du sagst quasi DirectStorage mit RAM Disk ;)
Auch wenn das natürlich nur in Nischenszenarien mit VIEL RAM was bringt.

So Videoschnitt- und 3D-Workstations haben den Vorteil, dass sie extrem viel VRAM, RAM und GPU-Leistung brauchen und damit zufällig auch perfekt für's Gaming sind. Außer dass da der RAM leider wirklich untätig bleibt - so kam ich auf die ganze Geschichte :)
 
i7 7820HK nicht mit Windows 11 kompatibel,
es werden weiterhin Windows 10- Updates abgerufen. :wow:
Du brauchst ein aktiviertes TPM 2.0

Es müsste bei dir im Bios eine Einstellung für "TPM" (fTPM / PTT) geben.
In meinem MSI Bios habe ich eine Option dafür. Das muss man dann erstmal Aktivieren.

Erst dann erkennt die Windows 11 update "Überprüfung" das es vorhanden ist.
( Blöd programmiertes MS-"Tool". Microsoft sollte genauere Infos anzeigen und Hilfe geben)

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.

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.

ggf. auf ein Bios update warten / bzw. auf die finale Win 11 version (PTT1.2)


Windows 11 Supported Intel Processors

 
Zuletzt bearbeitet:
Aus dem MS Dev Blog:

Anhang anzeigen 1367666

Du sprichst von RTX IO welches die Daten, ohne Umweg über den RAM, direkt in den VRAM legt. DirectStorage an sich (ohne Nvidia Erweiterung) arbeitet über den oben zu sehenden "Workflow".

Die Dekomprimierung der Texturen findet bei beiden Techniken innerhalb der GPU statt. Aktuell weiss keiner genau ob dafür dedizierte Recheneinheiten bereits verbaut sind (wie es bei der Xbox der Fall ist), man geht aber davon aus.

Danke für den Hinweis. Der Unterschied war mir in der Tat bislang nicht geläufig. Die meisten bisherigen Direct-Storage-Aussagen gingen von der Xbox oder RTX I/O aus, also ohne Umweg über den Arbeitsspeicher. Wenn man das weglässt, verkommt Direct Storage ja im Prinzip zu einer neuen Texturkompression, sonst nichts: Weiterhin ist nichts "Direct", sondern alles wird über drei Speichersysteme bereitgestellt (Massen-, Arbeits- und Grafikspeicher), nur der Ort der Dekomprimierung wird verlagert. Damit ähnelt PC-Direct-Storage den diversen Texturkomprimierungsintiaitven der GPU-Hersteller, die es in den letzten 20-25 Jahren gab und die dafür gesorgt habe, dass Texturen bereits heute relativ gut gepackt zur Grafikkarte vorliegen. Dem nochmal Faktor 2 oben drauf zu setzen ist nett, aber keine Weltrevolution. Insbesondere Latenzvorteile wird es somit gar eine geben. Spannend bleibt, wie schnell (und wie stromhungrig) das Entpacken durch die GPUs im Vergleich zu den Vorteilen einer effektiv verdoppelten PCI-E-Transferrate und eines effektiv halbierten RAM-Bedarfs wird.

Anhang anzeigen 1367667

Ich denke da werden sich Nvidia und AMD schon Gedanken zu gemacht haben. Immerhin wird DirectStorage ab RDNA1 / Turing unterstützt.

Was nahelegt, dass man mit einer Shader-Implementation arbeitet, denn die Entwicklung dieser Chips muss deutlich vor der von Direct Storage begonnen haben.

Ein User hier im Forum hat den Test gemacht, je nach BCn Stufe, kombiniert mit zlib, wurde die Textur bis zu 70% kleiner.

Nvidia spricht von:

https://www.nvidia.com/en-us/geforce/news/rtx-io-gpu-accelerated-storage-technology/

Und Microsoft auch:
Anhang anzeigen 1367669

Also laut diesen beiden erhöht sich die Performance um Faktor 2 durch die komprimierte Übertragung (oder die gesamte Performance? Das geht nicht so ganz daraus hervor).

Komprimierung um "bis zu" Faktor 3 laut Userbericht und 1,5-4 in anderen Quellen, die ich gesehen habe, passt gut zu einer Steigerung der Übertragungsgeschwindigkeit um Faktor 2. Eine allgemeine Ansage zur Gesamtperformance für alle Spiele und alle GPUs ist dagegen praktisch unmöglich, das Direct Storage nur einen kleinen Teil der Renderpipeline adressiert und somit je nachdem, wie stark der limitiert, kann sich irgendwas zwischen 0 und 100 Prozent Durchschlag auf die Fps geben.


Zum Sampler Feedback: Intelligente Nachladesysteme sind erst einmal unabhängig davon, wie nachgeladen wird. Desweiteren habe ich dazu auch noch keine Beispiele mit realistischen Spiele-Szenen gesehen. Microsofts X-Box-Demo legt nahe, dass es passend zum Namen Feedback vor allem die Eviction nicht benötigter Texturen beschleunigt, was bei exklusiv der GPU zur Verfügung stehendem RAM aber egal wäre.
 
Was nahelegt, dass man mit einer Shader-Implementation arbeitet, denn die Entwicklung dieser Chips muss deutlich vor der von Direct Storage begonnen haben.
RDNA1 / Turing vielleicht per Shader, RDNA2 / Ampere dann in Hardware. Werden wir sehen wenn es verfügbar ist.

Komprimierung um "bis zu" Faktor 3 laut Userbericht und 1,5-4 in anderen Quellen, die ich gesehen habe, passt gut zu einer Steigerung der Übertragungsgeschwindigkeit um Faktor 2. Eine allgemeine Ansage zur Gesamtperformance für alle Spiele und alle GPUs ist dagegen praktisch unmöglich, das Direct Storage nur einen kleinen Teil der Renderpipeline adressiert und somit je nachdem, wie stark der limitiert, kann sich irgendwas zwischen 0 und 100 Prozent Durchschlag auf die Fps geben.
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.

Zum Sampler Feedback: Intelligente Nachladesysteme sind erst einmal unabhängig davon, wie nachgeladen wird. Desweiteren habe ich dazu auch noch keine Beispiele mit realistischen Spiele-Szenen gesehen. Microsofts X-Box-Demo legt nahe, dass es passend zum Namen Feedback vor allem die Eviction nicht benötigter Texturen beschleunigt, was bei exklusiv der GPU zur Verfügung stehendem RAM aber egal wäre.
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.
 
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.
 
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/t/a-more-detailed-insight-about-sampler-feedback-streaming/3543/3

Da wird auf jedes Streaming-Verfahren eingegangen und Sampler Feedback Streaming erklärt.
 
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.
 
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.

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?".

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.

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.
 
Zurück