Should this means real world SSD -> RAM: 2.1 GB/s, assuming this data is a memory dump so not so much compressible. 2.4 is theoretical, 2.1 real world transfer rate
edit: nevermind, it have to save 13.5 GB game A and read 13.5 GB Game B to switch, so it is 4.2 GB/s, compressor is working
I think that scheme looks so brute forced, it makes no sense. Why save data that's already on disk? The bulk of the data in memory is comprised of loaded assets and rendering buffers, and none of that needs to be saved let alone recompress it back to disk.
Because the data on disk doesn't represent the active game data. You might have a model on disc that you subdivide on load for later destruction. You might have a texture on disc that you've written to in game. The in-game objects need to be recorded exactly as they are. If you rebuild these assets, you just have an ordinary game save/load functionality that's as slow as your ability to process the world-building process. Also, saving out the memory in a contiguous memory dump makes it optimal to load.
Me either, saving everything in game space RAM to disc, then loading it all back exactly where it is along with CPU, cache and GPU states is the fastest way.
If those are BC titles then they don't take 13.5GB of space.
A system-level save strategy? Wouldn't that require games to have particular structures to have the restore work the system-approved way? And would that be any faster than existing save/restore methods? Take an offensive long-loader like Witcher 3. What is it doing that's taking so long? Part will be loading assets perhaps with dreadful seek times, which'll be solved with the next-gen storage. The rest will be world reconstruction. I don't see how a system-level save could be suitable for this for all games and faster than whatever the games are doing already. You'd have to somehow tag memory as whether it's a persistent file or volatile construct, and dump the constructs, and restore the two including pointers to all their memory addresses.
They can at least add hooks available to the game engine for resume/suspend, and some games will be much faster than others if they can manage their own data more efficiently. It doesn't have to be completely universal and hands-off like a VM would. Some games can simply save the whole ram if they can't be bothered or they have a really complex destructive world. (or in the case of BC titles, which is only 5GB or so)A system-level save strategy? Wouldn't that require games to have particular structures to have the restore work the system-approved way? And would that be any faster than existing save/restore methods? Take an offensive long-loader like Witcher 3. What is it doing that's taking so long? Part will be loading assets perhaps with dreadful seek times, which'll be solved with the next-gen storage. The rest will be world reconstruction. I don't see how a system-level save could be suitable for this for all games and faster than whatever the games are doing already. You'd have to somehow tag memory as whether it's a persistent file or volatile construct, and dump the constructs, and restore the two including pointers to all their memory addresses.
I'm sure a system could be devised, but it strikes me as a lot of work, perhaps hideously constraining on game design, and not really worth it. SD cards are moving towards 4 GB/s and beyond. In a few years, we can probably pick these up cheap and swap games back and forth on internal SSD without too much bother. I think this is one of those cases where it's actually okay to let the hardware do all the work.
