Warum so kompliziert? Entsprechend brauchbare Schemazeichnungen zur Funktionsweise gibt es doch schon länger:
Bisher:
(1) Die CPU initiiert das Laden einiger (komprimierter) Assets, die über den PCIe-Bus in den RAM geladen werden.
(2) Die CPU läd die Assets aus dem RAM und dekomprimiert diese aufwändig, was relativ viel Rechnenleistung auf einem Teil der CPU-Kerne in Anspruch nimmt und schreibt die dekomprimierten Assets zurück ins RAM.
(3) Die CPU initiiert den Ladceprozess auf die GPU. Die dekomprimierten nun größentechnisch deutlich umfangreicheren Assets werden erneut über den PCIe-Bus transfgeriert in die GPU.
(4) Die GPU hat hier keine nennenswerte Last, da die Assets direkt in den VRAM durchgereicht werden können.
Im Endeffekt sind die Latenzen (
sowie die CPU-Last) hoch da die Daten mehrfach zwischen CPU und RAM hin und hergeschoben werden, bevor sie in der GPU ankommen.
Mit DX Storage (mit vollem Funktionsumfang):
(1) Die CPU initiiert den Ladeprozess der komprimierten Assets und diese werden nun unmittelbar via PCIe in die GPU geladen.
(2) Die Last auf der GPU steigt etwas, da hier nun der Dekompressionsprozess (
optional mit Spezial-HW) erfolgt und dann werden die Assets direkt ins VRAM geschrieben.
Insgesamt bleibt die Last auf der GPU jedoch relativ gesehen dennoch vergleichweise klein, sodass die das quasi so nebenbei miterledigen kann und für einen derartigen Task eine Vielzahl an vollwertigen general purpose CPU-Rechenkerne gemäß altem Schema ersetzen kann (
und natürlich die Latenzen ebenso signifikant reduziert).
Zu berücksichtigen:
Die aktuelle Implementation von Microsoft ist noch ein Zwischenschritt, denn obwohl bspw. nVidia sein RTX IO mit Ampere ankündigte, scheint man zusammen mit Microsoft noch nicht so weit zu sein die Daten direkt über die GPU zu dekomprimieren. Ampere wird das absehbar können aber der Treiber ist vermutlich noch nicht soweit in Verbindung mit der notwendigen Abstimmung mit dem API von MS. Aktuell dekomprimiert immer noch die CPU die Assets jedoch hat bereits das optimierte und verbesserte Storage API zu deutlichen Durchsatzverbesserungen ggü. dem angestaubten Alt-API *) geführt, sodass man schon beträchtliche Verbesserungen beim regulären Laden von Szenen demonstrieren konnte.
In der oben skizzierten finalen Implementation wird man dann das haben, was Cerny damals vollmundig zur PS5 vorstellte, also das dynamische Ein- und Ausladen von Assets in Echtzeit in Abhängigkeit des Viewports, was man am Ende als eine Art virtueller VRAM-Vergrößerung ansehen kann.
Der Knackpunkt, wie ich es schon zuvor erklärte, wird jedoch sein, dass Games die Vollimplementation nicht so schnell in ihre Gamemechanik als essentiellen Bestandteil integrieren können, da man sonst Alt-(PC-)Hardware kategorisch ausschließen würde, was wiederum dem Vertrieb mit Blick auf die Umsätze nicht schmecken wird. Hier wird man abwarten müssen, wann erste PC-Titel damit erscheinen werden. Im ersten Schrritt werden erst mal nur die Ladebalken kleiner.
*) Das alte Windows-I/O-API ist natürlicherweise auf HDDs mit vergleichsweise wenigen parallelen Requests und bestenfalls 50 - 100 MB/s ausgelegt, vielleicht gar noch weniger als Maximum, denn ich kann mich nicht erinnerern, dass Microsoft, seitdem HDDs sich auch in Bereichen von 100 bis etwa maximal 200 MB/s bewegen können, da in der Zwischenzeit mal nennenswert dran geschraubt hat und entsprechend wurde es höchste Zeit für eine größere Überarbeitung mit Blick auf GB-schnelle NVMe's mit Millionen IOPS.
