My point was the that NXGamer was a lot more accurate with his predictions prior to the release of official specs.
On the issue of the OS, he wasn't at all suggesting that the OS could be run from the SSD.
His suggestion was pure speculation and was the that the speed of PS5's SSD should technically allow Sony to free up the RAM for use in games. I think it was a quite a straightforward bit of speculation and there are a number of ways in which it could be implemented. Take a look at how iOS suspends applications for example, it takes a screenshot of the last state of the app and that is what is presented to the user first upon resuming the app and then the app resumes behind that. Cerny's point about 2GB transferring into in .27s was quite telling I feel. This is ultra-fast and might even be faster than the transition from game to home menu on current PS4.
Yep, some earlier were speculating that the whole of the OS could be shipped off into SSD, but this is impossible. The underlying OS would of course still need to be running to manage all the kernel tasks, but as it's unix based, I really feel this could be done in ~800MB, maybe 1GB tops. If Sony put some engineering behind it, they could probably get this figure down to ~500MB. I'm plucking these figures out of my ass, but I feel it's only at these levels that it would even make any sense to go down this path at all and they would need to implement this from the outset because...
There would need to be a certain portion of the RAM that is "shared" between the Game and OS, say ~3GB. When the game is active, it would have full access to 3GB of this ram, then when Home is activated, this RAM would get purged and replaced with the OS data from SSD. This 3GB figure could be reduced as the generation goes on and the OS gets more refined, like in this gen, or it could stay the same for the duration of the gen, because it shouldn't impede games anyway.
I don't remember NXGamer making any predictions on the next-gen systems actually. But maybe he did, I dunno.
Aside from that tho, I like general idea, and hopefully XSX implements something similar for its users as well. Given the limitations of NAND this is part of the reason I hoped even a small portion of persistent memory (like Optane) was featured in the systems, but given the time frame these systems began development (especially PS5, which IIRC was back in 2015 at least for the early pre-planning), and how no persistent memory was on the commercial market at that time (to my knowledge), I can understand why it as a feature didn't make the cut.
Yeah, your average for the XSX would need to take into account the proportion of reads to each range of memory.
E.g. if 90% of your reads/writes are from the 10GB of optimal ram, the "GB per TF" would be:
(560 x .9) + (336x.1) / 12.155 = 44.23 GB/TF. Very similar to the PS5 figure.
But this is a really simply calculation ignoring a lot of factors. For example cache sizes and cache hit rates, how effective access scheduling is etc.
Overall, per TF, the XSX and PS5 are in pretty much the the same ballpark with regards to bandwidth. Almost as if both MS and Sony kinda knew what they were doing ....
True, taking the potential proportion of that data usage does factor into it as well. Different games will have different needs and therefore different requirements of which of the two pools to draw from for any given average of time of the program's activity.
It still presents something of a quirk for developers on XSX that those on PS5 don't really need to consider, but it won't be too big a deal. It's MUCH simpler and easier than working with split memory pools running on completely different memory technologies, like how it used to be not even two console generations ago.
API and tools will help for sure as well as any unforeseen RDNA2 hw improvements but to get close to the level of utilization of the smaller card might still take fine grain control optimizations
Third parties aim for parity and the SEX already has the superior spec, i don't think they'll invest more in micromanaging asynchronous compute loads to get close to full utilization of the 52CUs. Just like i don't see them designing their games around PS5 SSD spec, they'll more likely target the SEX SSD.
First parties is were each console traits will show imo
BTW are lead consoles still a thing today? they were a thing during the PS360 gen, bust since most big studios have different teams in charge of each console now, i wonder if that is still in effect.
Honestly I don't know if they are and wouldn't be surprised if they aren't. Lead platform was also more important when the architectures between systems varied greatly on the biggest things like CPU and GPU, which isn't the case anymore since MS and Sony are using the same AMD tech (just customized here and there to their specific needs).
I agree that, unfortunately, that fuller type of GPU saturation (for something like GPGPU) won't get targeted for specific use by 3rd-parties on XSX, similar to how 3rd-parties probably won't target the PS5's specific SSD advantages in their games. The exceptions to that besides 1st-party titles would probably be 3rd-party exclusives and timed-exclusives. In both cases they'd have closer connection with resources by the platform holders plus more financial incentive to take advantage of those kind of features beyond just baseline level.
Overall though I can see SSD strengths being the more straightfoward of the two to target programming towards, and that'll be more beneficial to PS5. Streamlined tools for GPU saturation (for both graphics and non-graphics tasks) will require more work so while I can see regular 3rd-party releases maybe targeting PS5 SSD features for games with big enough budgets, there would probably be less 3rd-party titles targeting GPGPU capabilities on either system but that would be of particular disservice to XSX.
But hey as long as 1st-party titles leverage the most of these systems then I think everyone will be happy, and we'll still get at least some 3rd-party games that do such, as well.