SmartAccess Storage: Auch AMD hat keine Lust auf lange Ladezeiten
AMD hat im Rahmen seiner Computex-Keynote das Feature "SmartAccess Storage" vorgestellt. Dieses wurde auf Basis von Microsofts DirectStorage-API entwickelt und beschreibt ein Verfahren zur GPU-basierten Daten-Dekomprimierung, welches in einer Entlastung für die CPU und kürzeren Ladezeiten in Spielen resultieren soll.
Vor fast zwei Jahren stellte Nvidia seine GPU-basierte Daten-Dekomprimierung "RTX IO" für die DirectStorage-API vor, zusammen mit den Grafikkarten Geforce RTX 3070, 3080 und 3090. Nun ist auch AMD damit an der Reihe. SmartAccess Storage heißt die neue Technologie der Konkurrenz aus Santa Clara, wie bereits im Vorfeld gemunkelt, und soll den Anwender schneller als je zuvor aus dem Ladebildschirm heraus in sein Gameplay bringen, wie AMDs Chefarchitekt Frank Azor versichert. Aber auch das Textur-Streaming werde dadurch verbessert.
Kürzere Ladezeiten durch GPU-basierte Daten-Dekomprimierung
SmartAccess Storage macht sich laut AMD die Leistung der GPU zunutze, um alle Asset-Komprimierungs- und Dekomprimierungsaufgaben zu erledigen. "Herkömmliches Laden von Spielen erfordert eine erhebliche Menge an Rechenleistung, um die Daten des Spiels zu dekomprimieren", erklärt Frank Azor, "dadurch muss die CPU die Dekomprimierung und Datenübertragung durchführen, was zu Latenzen führt, und dies nimmt erhebliche Systemressourcen in Anspruch."
Bildergalerie
AMDs SmartAccess Storage auf Basis von Microsofts DirectStorage-API soll die CPU erheblich entlasten und gleichzeitig die volle Leistung von modernem NVMe-Speicher ausschöpfen können. So ähnlich präsentierte auch Nvidia das bereits thematisierte RTX IO, welches verglichen mit herkömmlicher CPU-Komprimierung den hundertfachen Durchsatz und eine 20 Mal geringere CPU-Auslastung bieten soll.
Passend dazu: Ryzen 7000: AMD mit Details zu Kernen, Cache, RDNA 2 und Release
Bislang wurden noch keine Spiele mit der DirectStorage-API veröffentlicht, die für SmartAccess Storage vonnöten wären. Eines der ersten PC-Spiele, welches die Vorteile von Microsofts Schnittstelle nutzen wird, ist Forspoken, das ursprünglich zur aktuellen Zeit, am 24. Mai, hätte erscheinen sollen. Der Release wurde allerdings auf den 11. Oktober 2022 aufgeschoben. Zu anderen PC-Spielen, die DirectStorage unterstützen werden, sei bislang noch nichts bekannt.
Quelle: AMD via PC Gamer
Bis zu massenhaftem "on-the-fly-Streaming" und der direkten Integration in die Game-Mechanik wird jedoch wohl absehbar noch einige Zeit vergehen, da man hier voraussichtlich abwarten wird, bis der Marktschnitt über ausreichend moderne Hardware verfügt.
*) Aber selbst schon bei SATA-SSDs einen deutlichen Mehrwert bieten soll.
**) DX Storage ist gemäß Micrsoft auf dem PC übrigens kein simpler Port der Xbox-Lösung, sondern ein speziell auf den PC zugeschnittenes API (das auch nicht das CPU-lastige general purpose Win32 I/O ersetzen soll, sondern speziell für diesen HighPerf-Streaming/Gaming-Workload ausgelegt wurde. Die Windows 10-Variante setzt mit einer Zwischenschicht auf dem Win32 I/O auf und kann daher nicht alle Performancezugewinne realisieren.)
***) So etwas wie ein Peer-2-Peer PCIe-Transfer von einem Device direkt zum anderen am RAM vorbei scheint in der aktuellen DX Storage-Definition (ggf. gar aus Sicherheitsgründen?) auch gar nicht vorgesehen zu sein. - Wie später die GPU-basierte Dekompression hier eingehängt wird und ob die Daten zurück ins RAM geschrieben und dann über den Staging Buffer regulär hochgeladen werden oder ob es eine Art direkten Pass-Through durch die GPU geben wird, weiß ich aktuell nicht.
[Ins Forum, um diesen Inhalt zu sehen]: DX Storage gibt keine (De)Kompression vor und definiert keine Datenformate und Algorithmen diesbezüglich. Was hier Zwischengeschaltet wird bestimmt der Entwickler, der hier natürlich immer Kompressionsstärke gegen Rechenlast abwägen muss.
Mit der später folgenden Erweiterung für eine GPU-basierte Dekompression kann man leichter höherwertige Algorithmen verwenden, da die GPU potentiell über weitaus mehr freie und vor allem spezialisierte Ressourcen als die CPU verfügt.
Bis zu massenhaftem "on-the-fly-Streaming" und der direkten Integration in die Game-Mechanik wird jedoch wohl absehbar noch einige Zeit vergehen, da man hier voraussichtlich abwarten wird, bis der Marktschnitt über ausreichend moderne Hardware verfügt.
*) Aber selbst schon bei SATA-SSDs einen deutlichen Mehrwert bieten soll.
**) DX Storage ist gemäß Micrsoft auf dem PC übrigens kein simpler Port der Xbox-Lösung, sondern ein speziell auf den PC zugeschnittenes API (das auch nicht das CPU-lastige general purpose Win32 I/O ersetzen soll, sondern speziell für diesen HighPerf-Streaming/Gaming-Workload ausgelegt wurde. Die Windows 10-Variante setzt mit einer Zwischenschicht auf dem Win32 I/O auf und kann daher nicht alle Performancezugewinne realisieren.)
***) So etwas wie ein Peer-2-Peer PCIe-Transfer von einem Device direkt zum anderen am RAM vorbei scheint in der aktuellen DX Storage-Definition (ggf. gar aus Sicherheitsgründen?) auch gar nicht vorgesehen zu sein. - Wie später die GPU-basierte Dekompression hier eingehängt wird und ob die Daten zurück ins RAM geschrieben und dann über den Staging Buffer regulär hochgeladen werden oder ob es eine Art direkten Pass-Through durch die GPU geben wird, weiß ich aktuell nicht.
[Ins Forum, um diesen Inhalt zu sehen]: DX Storage gibt keine (De)Kompression vor und definiert keine Datenformate und Algorithmen diesbezüglich. Was hier Zwischengeschaltet wird bestimmt der Entwickler, der hier natürlich immer Kompressionsstärke gegen Rechenlast abwägen muss.
Mit der später folgenden Erweiterung für eine GPU-basierte Dekompression kann man leichter höherwertige Algorithmen verwenden, da die GPU potentiell über weitaus mehr freie und vor allem spezialisierte Ressourcen als die CPU verfügt.
... hat der Spiele-Entwickler Pfusch gebaut.
Mehr gibt es dazu eigentlich nicht zu sagen.
Drawcalls werden durch die angesprochenen Techniken eigentlich nicht beeinflusst.
Dieses Schema hat einiges an Geschmäckle. Den Schritt "Prozessor lädt gepackte Daten aus seinem Speicher und schreibt sie entpackt zurück" gibt es zum Beispiel bei beiden Vorgehensweisen. Aber in dieser Darstellung wird er nur bei GPU-basierter Dekomprimierung unterschlagen. Ebenso irreführend ist die Darstellung mit Dateitransport über eine zentrale Zwischenstufe "PCI-E". Die gibt es nicht. Es gibt getrennte PCI-E-Verbindungen von der SSD zur CPU und von der CPU zur Grafikkarte. Die Daten erst in den Arbeitsspeicher zu packen, verdoppelt also weder die Wegstrecke, wie hier dargestellt, noch führt es zu doppelt belastendem hin und her in der Hälfte des Systems. Vor allem wird aber der weitaus schnellere Transfer zwischen RAM und GPU im Vergleich zu SSD und GPU ebenso unterschlagen, wie die Möglichkeit Schritt 1 und 2 bei herkömmlichem Vorgehen asynchron im Voraus durchzuführen.
Solange ein Spiele-Entwickler den letztgenannten Punkt nicht vermasselt, sieht der Datenfluss im unmittelbaren Rendervorfeld wie folgt aus:
- dekomprimierte Daten im RAM
- werden mit 50-80 GB/s vom IMC an den PCI-E-Root-Port transferiert
- der sie mit bis zu 32 GB/s (künftig: 64 GB/s) an die GPU weiterleitet
- die sie in den VRAM schreibt
- und damit rendert
versus
- komprimierte Daten im Flash
- werden mit bis zu 3-7,6 GB/s vom Controller an den PCI-E-Root-Port transferiert (ggf. indirekt, je nach System)
- der sie mit diese 3-7,6 GB/s an die GPU weiterleitet
- die sie in den VRAM schreibt
- dann Stück für Stück in den Cache lädt
- entpackt
- und zurück in den VRAM schreibt
- und damit rendert
Mehr gibt es dazu eigentlich nicht zu sagen.
[Ins Forum, um diesen Inhalt zu sehen]
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.
Solange ein Spiele-Entwickler den letztgenannten Punkt nicht vermasselt, sieht der Datenfluss im unmittelbaren Rendervorfeld wie folgt aus:
- dekomprimierte Daten im RAM
- werden mit 50-80 GB/s vom IMC an den PCI-E-Root-Port transferiert
- der sie mit bis zu 32 GB/s (künftig: 64 GB/s) an die GPU weiterleitet
- die sie in den VRAM schreibt
- und damit rendert
versus
- komprimierte Daten im Flash
- werden mit bis zu 3-7,6 GB/s vom Controller an den PCI-E-Root-Port transferiert (ggf. indirekt, je nach System)
- der sie mit diese 3-7,6 GB/s an die GPU weiterleitet
- die sie in den VRAM schreibt
- dann Stück für Stück in den Cache lädt
- entpackt
- und zurück in den VRAM schreibt
- und damit rendert
Also ich finde die Ansetze spannen, aber auch gut erklärt.
Gute Diskussion [Ins Forum, um diesen Inhalt zu sehen] [Ins Forum, um diesen Inhalt zu sehen] & [Ins Forum, um diesen Inhalt zu sehen] !