Quick Resume between Multiple Titles [2020] [XBSX]

Assuming all those games reserved maxium 13.5GB. they also could have been smaller ram images, doesnt base models of current gen have like 5.5GB of ram for games? And that 360 game wont need that much either.

Imo that switch between games looked just slow. Too slow to be much different than what current gen offers, still better but kind of slow.

0.5-3 seconds would be nice

 

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.

6.5 secs is not good. I would have expected 2 secs, unless the suspend scheme doesn't have the proper hooks given to the game for an efficient suspend/resume.

 

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.

I don't think there's a faster way to do it.

 

I expect that to be adressed eventually. Untill then, the brute force way is a good first effort to get the foot out the door. 6 secs is not great, but isn't terrible either. If that is the wort case scenario, god damn that's a whole lot better than what we've had for the past 20 years.

 

They're backwards compatibility titles. It's probably the easiest way to do it. Maybe their solution will be different for Series X titles.

 

I agree that this is disappointing that it may not be smarter and I'm not expecting PS5 to be do anything different. But it is a shame that each game swap is potentially the whole RAM buffer rather than an approach where swapping back to a game doesn't just load the engine immediately followed by the game save state. They could have had an API for this, just define memory here to here as everything the game uses and save it when you swap out. The whole RAM buffer is probably not going to be an insignificant data sizes for nextgen games.

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.

Maybe down the line there will be the option to have a slightly slower restore where the game engine effectively loads super quick then the actual game save state is restored. A little slower, but lighter on SSD space. The low SSD space - particularly PS5's 825gb (IIRC) is my only reservation about nextgen consoles. Maybe games will be a lot smaller, not having to install the multiplayer modes/maps which I never play will probably save a load of space for me. Likewise, mot installing foreign language voice packs - we always get a bunch of these in European game distributions.

 

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.

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.

 

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)

*infomercial* "There has be another way!"

 

Yah, it would be write 5.5 GB and read 5.5 GB. I'm assuming write performance will be slower than the 2.4 GB/s read.

 

It's at least 8 GB of ram written then read with Xbox One X enhanced games. It probably also includes device driver states and other aspects, so probably a bit more than just a raw game memory dump. Anyways, you're doing a lot more IO than most think.

 

I guess it doesn't look that fast because it's not a 100x faster than the suspend/resume on current gen, but it's apples and oranges, since we're just powering down to rest mode, which keeps the ram refreshed.

So it's a challenge that cannot be compared technologically, and the consumer's impression is a usability one that it "didn't improve as much as hoped" compared to previous gen, however we will have more than one saved state, which is a very big deal.

 

The next step after a simple full ram and state dump, is to have a OS level system to flag eaxh portion of ram that is just caching data from the game file as is to it's respective source.

Ex: The current player character on screen is sitting in RAM, but is just a unmodified dump of the same character that is sitting on the SSD already, so it could have a flag telling the OS "you can find all this data on the game's data itself at adress XYZ." Saves the OS from burning a whole copy of that into the save-state during the switch.

With that method, the state only has to contain dynamic data and adresses for the static stuff. This could reduce their size on disk AND write time significantly. As stated previously, in most games, more than three quarters of data in RAM is often just copies of static data from the game itself.

Additionally, that can also potentially speed up read speeds on load, since the data on disk will probably be better compressed.

 

I still don't see the point really, how much longer would it take just to load your game and click continue. Unless everyone is lying about no more loads or imperceptible loads.

 

That's both pretty impressive, but also I feel pointless. Who keeps jumping in and out of games slap bang in the middle like that?! Also, why's this in the UE5 thread? Does it need clean-up again?

 

UE5 would need to add support for a suspend/restore flagging of it's data.

(I'm a little on topic!)

 

The only reason it feels jumping in and out is because they didn't want the video to take hours or days to show normal use of their system to switch between games.

 

Timed it.

Forca 6 sec gameplay starts
Ori 5 sec gameplay starts
The Cave 4.5 sec freeze but 5.5 sec gameplay starts
Hellblade 5.5 sec freeze 6.5 sec gameplay starts
State of decay 6.5 sec freeze 8 sec gameplay starts