Trelor schrieb:
dass du die Daten vom NAND Flash in den VRAM über 4 DMA Kerne und 4 PCI-E Busse und einmal durch den RAM schleifst.
Genau das. Vor allem das was ich in deiner Aussage fett markiert habe.
Trelor schrieb:
Da sind die ~100ns-250ns Latenz je nach Blöckgröße (verglichen mit 50-125ns bei JEDEC DDR4/5) des GDDR6 teilweise schon limitierend. Der Flashspeicher und die Ausleselogik liegt da bereits deutlich drüber.
Das stimmt natürlich und ist ungünstig für die CPU. Hörte auch das dort Latenz oftmals entscheidender ist als Bandbreite. Kommt halt auch auf den Fall an.
Gerade aber auf der Konsole wäre mir als Entwickler das mit der SSD Reaktionszeit für wenigstens das Menü und OS egal.
Dann schaufelt die SSD den größten gefreezten Teil halt aus der NVME SSD wenn es aufgerufen wird.
Ebenso würd ich es mit dem VRAM halten.
Am PC müssen Entwickler damit rechnen das Leute mit einer SATA SSD oder gar HDD herum gurken.
Wie lange soll das dauern bis die Grafikkarte mal etwas in den VRAM bekommt?
Also mal schön den RAM vollholzen und vieles doppelt vorhalten. Das ganze RAM zu vram getransfere spart man sich ja an Konsolen (ok maybe XBOX hat ein bisschen davon, aber die hat ja auch schnelleren und "langsameren" GDDR6.
Um die Kurve zu kriegen:
Plötzlich wundert sich die Welt, wie bei Lords of the Fallen, welches neben dem eigentlichen Level, noch ein abweichendes mit weiteren unterschiedlichen Texturen vollgezimmertes Level/Welt darstellt, rumstottert.
Ja weil es Speicherlecks gibt die so in der uniformen Konsolenspeicherverwaltung nicht auftauchen und man am PC wortwörtlich nur am hin und her schubsen der Daten ist, weil 8-12GB Grafikkarten sind ja so toll...
Es sei den man braucht in unter einer Sekunde mal eben andere Assets im Preload und muss erstmal von einer bsp. SATA SSD in den RAM und dann in den VRAM-.- Macht die CPU natürlich dann auch happy wenn der RAM so mit weiterleiten belastet wird das diese vlt. mal einige Millisekunden verhungert-.-
Natürlich das alles während man da in 1440p oder höher herumeimert.