Baseless Next Generation Rumors with no Technical Merits [post E3 2019, pre GDC 2020] [XBSX, PS5]

Status
Not open for further replies.
I believe this has been confirmed for XSX but not PS5.

Given how previous SSD storage space will be, I'd hope they aren't dumping the entire contents of RAM for every game suspended. They need an API for preserving critical game state data so that when you resume, it fasts loads the game then recreates exactly where you were from the saved state. It doesn't need to be instant like traditional low-power suspend/resume - just fast.
That's not going to happen. That would be too much work for devs. And we all know how they are. :mrgreen:
 
Given how previous SSD storage space will be, I'd hope they aren't dumping the entire contents of RAM for every game suspended. They need an API for preserving critical game state data so that when you resume, it fasts loads the game then recreates exactly where you were from the saved state. It doesn't need to be instant like traditional low-power suspend/resume - just fast.
That's quite a big ask IMO. Realistically, I think a memory dump is the best solution as it'll work with everything, from the biggest first-party title to the next GTA to the smallest Indie. At best, perhaps an optional optimised solution? But in the time it takes a dev to design and implement a data-structure that identifies key-states and world-reconstruction around those, price for NAND will have halved again. ;) Just ride out the first couple of years of constrained storage until capacious storage is cheap, same as the original PS360 consoles and their paltry 20 GB HDDs.
 
That's quite a big ask IMO. Realistically, I think a memory dump is the best solution as it'll work with everything, from the biggest first-party title to the next GTA to the smallest Indie.
You say that a million+ apps work like this on iOS - including games like Civ VI. I assume Android does something similar. If Apple can make this that easy, Sony have too.
 
It was required from the get go on android and ios or at least at one of the major milestone releases. A bit harder to do once the programs have already been written and released. Sure they could add an api and tie it to terms, but that's only going forward.
 
It was required from the get go on android and ios or at least at one of the major milestone releases. A bit harder to do once the programs have already been written and released. Sure they could add an api and tie it to terms, but that's only going forward.
Good point, although for backwards compatibility, you're talking smaller RAM sizes to begin with.

Going forward we're likely looking at 12-16Gb of useable RAM per game. It guess it depends how much solid state storage they include but assuming 16Gb a game, six games will eat almost 100Gb of space. Yikes.

It doesn't have to be complicated. The OS can automatically save any RAM flagged as 'state' on allocation and the OS will save that the user switches games. It would be wasteful if gigabytes of textures (which already exist on the SSD) are saved again - especially as Mark Cerny made a concerted point about elimiating dupe data to get the most out of the SSD space.

Games would require an API for boot and load the state (skipping any menu) but is this really that much different to existing loading code?
 
It was required from the get go on android and ios or at least at one of the major milestone releases.
Really? Every game has to be able to save and restore its game state, so all physics objects need their motions, collisions, etc. saved, all animations saved at their frame count, all audio saved in its part-played state, and recovered? I've never heard of such a thing in Unity and AFAIK games are either suspended in memory or more normally closed. Have you a link to any of this?

Save games, saving all the necessary data to reconstruct your play, happen by and large at given points. I'd expect a suspend/resume to be different. Presently, that's done by keeping the memory state exactly as is through a low-power mode. Suspend/resume for multiple games working the same way would need a memory dump. The alternative is a fast load/save but that's not quite the same.
 
Save games, saving all the necessary data to reconstruct your play, happen by and large at given points. I'd expect a suspend/resume to be different. Presently, that's done by keeping the memory state exactly as is through a low-power mode. Suspend/resume for multiple games working the same way would need a memory dump. The alternative is a fast load/save but that's not quite the same.

This is certainly how it works on iOS but it could be realtime except, I assume Apple's motivations for not doing this is for experience immediacy e.g. if the user wants to open a new app, any old app could be flushed from RAM immediately. That said, UIKIt does this for he UI if the system terminates your app. The inconsistency is Apple's.

What I was really referring too was the concept of clearly defined save state and API to allow near seemless suspemd/resume. This does require a little effort as not all iOS apps support this. But on a device primarily designed for playing and switching games, I'd expect Sony to not make the same compromises as Apple.
 
That would be desirable. I expect they'll brute force it to begin with - since it's essentially suspend/resume with copying to/from the SSD - and gradually work towards it. As said, textures and audio don't need to be included in the savestate, so I suppose that'd be quite an easy first step.
 
This is certainly how it works on iOS but it could be realtime except, I assume Apple's motivations for not doing this is for experience immediacy e.g. if the user wants to open a new app, any old app could be flushed from RAM immediately. That said, UIKIt does this for he UI if the system terminates your app. The inconsistency is Apple's.

What I was really referring too was the concept of clearly defined save state and API to allow near seemless suspemd/resume. This does require a little effort as not all iOS apps support this. But on a device primarily designed for playing and switching games, I'd expect Sony to not make the same compromises as Apple.
What you are asking is already there in almost all games: it's the standard save feature. Remember, HDDs will be gone on nextgen so a loading from a save should be sufficiently quick for most people.

I think on PS5 they plan to load only one specific part of the game to make the loadings even shorter.
 
What you are asking is already there in almost all games: it's the standard save feature.

Save is a different problem because only the game needs to know where in RAM the save state data is, but for suspend and resume the OS needs to know. You don't want every game needing to have its own save-state implementation on top of whatever save/quick-save mechanics it already has - if any. Some games want to you live with the consequences of your actions.
 
Can I just get one thing clear, especially you Proelite? The 9.2 TF PS5 is purely deduced from the Github leak not some internal target specs people have heard from their sources right? Because that would make quite a difference in the root of its believability.
 
Can I just get one thing clear, especially you Proelite? The 9.2 TF PS5 is purely deduced from the Github leak not some internal target specs people have heard from their sources right? Because that would make quite a difference in the root of its believability.
I think it was around gdc 2019 that he 9.216 rumor started. That would've been 2-3 months before github became public. The talks picked up again when 5700 and xt were announced and specs were leaked.
 
I think it was around gdc 2019 that he 9.216 rumor started. That would've been 2-3 months before github became public. The talks picked up again when 5700 and xt were announced and specs were leaked.
That same GDC leak by Josh also mentioned 12Gig of GDDR6 + 4Gig DDR4 which I think is total bogus. No way in hell PS5 has this little amount of usable ram for games, pretty sure the 4 Gig DDR4 is for OS.
 
Can I just get one thing clear, especially you Proelite? The 9.2 TF PS5 is purely deduced from the Github leak not some internal target specs people have heard from their sources right? Because that would make quite a difference in the root of its believability.

Reveal is few weeks/months away.
 
Status
Not open for further replies.
Back
Top