Next-Generation NVMe SSD and I/O Technology [PC, PS5, XBSX|S]

The normal XBox process just downloads minimal patch files, right? IIRC Sony's system has been explained as being 'robust' to account for download issues potentially corrupting the patching process, but I can't say I've ever heard of a game update going wrong on XB, or PC for that matter.
 
The normal XBox process just downloads minimal patch files, right? IIRC Sony's system has been explained as being 'robust' to account for download issues potentially corrupting the patching process, but I can't say I've ever heard of a game update going wrong on XB, or PC for that matter.

Xbox only downloads what's required. There's a tweet or interview statement from Phil or Jason or some other Xbox person on this matter. (I don't have a link to it right now)

However, I think depending on how the newer revision of the game is built has an impact on how much is determined to be changed. Historically there have been download updates which were the entire game and there has also been relatively small downloads despite large updates to games. I don't know if the larger patches are if its simply a matter of some games using dynamically generated or processed files or filenames for game assets at the moment of build/compilation, where the entire universe is determined to be different when creating the download set.
 
It's my understanding that it requires more work to use the fast I/O on XS consoles then it does on PS5.

So it might be effort/reward just isn't worthwhile.
It could be a financial decision as well. Sony paid for a Kraken license for PS5, so every dev can use it royalty free. They would have to pay a fee to use the same compression on Xbox consoles. I know the loading times are double, but it's not like they are unbearable. So it might not be worth the money, especially if you are simply rereleasing an old title to generate quick and easy income.
 
Doesn't xbox still use delta updates. Hence the larger patches.
They still make delta updates. But the problem is the packaging. If you patch a game and just modify a config file and this file is included in all package files, than all package files must be redownloaded.
That is why we need different build paths for the old and the new gen. As long as they use the same packaging on series consoles like on xb1 you will always have to download big files, because big files are better for HDDs (bandwidth usage wise).

It does also not work to just "add"/"overwrite" the contents of the package-files (e.g. to think of a simple zip file). The files are encrypted and hashed with a certificate (well they have a signature). So if the file is manipulated it can no longer get decrypted and even than the hash (signature) has changed and the system would no longer accept to load that file.

So the only solution to that problem is, to make many, many small files, encrypt and hash those and than only replace the files that get patched. That would greatly decrease patch-sizes.
I guess there won't be many games that will do that as long as the old gen is still supported and the xbox makes it especially easy to just use the same build pipeline for one game. As long as this runs well enough, developers won't spend much time to solve this problem. Traffic doesn't cost must and as long as the game works and it is not needed, this won't change.
 
Last edited:
They still make delta updates. But the problem is the packaging. If you patch a game and just modify a config file and this file is included in all package files, than all package files must be redownloaded.
That is why we need different build path for the old and the new gen. As long as they use the same packaging on series consoles like on xb1 you will always have to download big files, because big files are better for HDDs (bandwidth usage wise).

It does also not work to just "add"/"overwrite" the contents of the package-files (e.g. to think of a simple zip file). The files are encrypted and hashed with a certificate. So if the file is manipulated it can no longer get encrypted and even than the hash has changed and the system would no longer accept to load that file.

So the only solution to that problem is, to make many, many small files, encrypt and hash those and than only replace the files that get patched. That would greatly decrease patch-sizes.
I guess there won't be many games that will do that as long as the old gen is still supported and the xbox makes it especially easy to just use the same build pipeline for one game. As long as this runs well enough, developers won't spend much time to solve this problem. Traffic doesn't cost must and as long as the game works and it is not needed, this won't change.
Thanks.
I did say in a previous post that packaging with previous gen doesn't help. But it's good to get a detailed explanation of why.
 
It could be a financial decision as well. Sony paid for a Kraken license for PS5, so every dev can use it royalty free. They would have to pay a fee to use the same compression on Xbox consoles. I know the loading times are double, but it's not like they are unbearable. So it might not be worth the money, especially if you are simply rereleasing an old title to generate quick and easy income.

Wasn't a lot of developers already using it on PS4 and XO anyway? So the license was likely that that big of a pull.

To me the the financial cost in terms of dev time to port the game over to Direct Storage and it being/not being worthwhile.

PS5's I/O and storage is way more hardware driven (And works like PS4) so shouldn't need much work to get it up to full speed imo.
 
PS5's I/O and storage is way more hardware driven (And works like PS4) so shouldn't need much work to get it up to full speed imo.
Don't want to get into console wars territory, but Sony and MS chose the same way of doing it in hardware. They just decided to use different formats & speeds, but it is more or less the same. Data access algorithms that work on PS5 should work the same on xbox series consoles, if the APIs allows it. So porting something between those consoles should not really be a problem from the data access view.
 
Don't want to get into console wars territory, but Sony and MS chose the same way of doing it in hardware. They just decided to use different formats & speeds, but it is more or less the same. Data access algorithms that work on PS5 should work the same on xbox series consoles, if the APIs allows it. So porting something between those consoles should not really be a problem from the data access view.
Are we sure on that ? Remember verified dev on resetera (Mat) said io on ps5 is generation ahead of xsx tough maybe he was exageratting
 
Are we sure on that ? Remember verified dev on resetera (Mat) said

Which Matt, the moderator or the one working at Roblox now? I think both are involved in game development.
 
Are we sure on that ? Remember verified dev on resetera (Mat) said io on ps5 is generation ahead of xsx tough maybe he was exageratting

That's not exactly contrary to what Allandor said. If the developer was particularly impressed by the raw speed of the SSD on PS5, then it's obviously going to be ahead for them. If they are particularly impressed by not having to pay to use Kraken on PS5, then it's obviously going to be ahead for them. But Allandor already accounted for that with his statement:

They just decided to use different formats & speeds, but it is more or less the same.

It's like back in the day you could say that Intel's Core lineup and AMD's Phenom lineup might perform at different speeds, but they are more or less the same. :p

So yes, given the relative immaturity of everything involved in the XBS IO subsystem (I think we still don't have a title out that utilizes SFS or other XBS IO related optimizations) prior to launch compared to PS5's it's easy to see why a developer would be more impressed with PS5's IO subsystem prior to the consoles launching.

Regards,
SB
 
  • Like
Reactions: snc
Don't want to get into console wars territory, but Sony and MS chose the same way of doing it in hardware. They just decided to use different formats & speeds, but it is more or less the same. Data access algorithms that work on PS5 should work the same on xbox series consoles, if the APIs allows it. So porting something between those consoles should not really be a problem from the data access view.

Well they didn't chose the same way, there's still things (like check-in) that's still done on the CPU in XSX but is done in hardware in the I/O block on PS5.

PS5's I/O is just far more hardware driven then XSX (It was designed to be after all) and as a result is likely far easier to implement and less dependent on the developer having to switch to and learn a whole new API (Direct Storage) to get the best from it.
 
Last edited:
  • Like
Reactions: Xen
Well they didn't chose the same way, there's still things (like check-in) that's still done on the CPU in XSX

What's this "check-in" aspect? Would appreciate a description or pointer to a place with details on this.
 
What's this "check-in" aspect? Would appreciate a description or pointer to a place with details on this.

It was talked about in the Road to PS5 at the 14 minute mark, this will still be done on the CPU in XSX, although it's more streamlined in Direct Storage.

Also an interesting note is the lack of a DRAM cache for XSX's SSD, PS5 has a separate memory chip for this where as XSX will have to use main RAM which isn't much of a disadvantage from a performance point of view it but does mean XSX will likely be loosing ~512mb of main RAM to this task that PS5 doesn't.
 
Last edited:
Are we sure on that ? Remember verified dev on resetera (Mat) said io on ps5 is generation ahead of xsx tough maybe he was exageratting
Yes he said that once (I can't find this post anymore, maybe he deleted it) but he praised PS5 I/O in others threads saying that multiplat devs mostly won't be able to fully use it in their games for other than traditionnal loadings. For perspective he is a multiplat developer more into Xbox ecosystem and back then he intended to make the XSX his main console this generation. There is an interesting thread where he talks about PS5 custom I/O and compares it to others solutions. He is making plenty of interesting posts in that thread, this is his first:

https://www.resetera.com/threads/vg...-ps5-ssd-in-mind.218778/page-21#post-35946333
 
Yes he said that once (I can't find this post anymore, maybe he deleted it) but he praised PS5 I/O in others threads saying that multiplat devs mostly won't be able to fully use it in their games for other than traditionnal loadings. For perspective he is a multiplat developer more into Xbox ecosystem and back then he intended to make the XSX his main console this generation. There is an interesting thread where he talks about PS5 custom I/O and compares it to others solutions. He is making plenty of interesting posts in that thread, this is his first:

https://www.resetera.com/threads/vg...-ps5-ssd-in-mind.218778/page-21#post-35946333

Surely PS5's SSD will still allow for streaming higher quality assets in multi platform games when engines finally get updated?
 
Yes he said that once (I can't find this post anymore, maybe he deleted it) but he praised PS5 I/O in others threads saying that multiplat devs mostly won't be able to fully use it in their games for other than traditionnal loadings. For perspective he is a multiplat developer more into Xbox ecosystem and back then he intended to make the XSX his main console this generation. There is an interesting thread where he talks about PS5 custom I/O and compares it to others solutions. He is making plenty of interesting posts in that thread, this is his first:

https://www.resetera.com/threads/vg...-ps5-ssd-in-mind.218778/page-21#post-35946333
https://www.resetera.com/threads/vg...tem-with-ps5-ssd-in-mind.218778/post-35885247
my fault, he didn't say generation ahead just
PS5’s IO is on another level
tough I only know he is verified and not sure his opinion was based on expierience working on both devkits etc
 
https://www.resetera.com/threads/vg...tem-with-ps5-ssd-in-mind.218778/post-35885247
my fault, he didn't say generation ahead just
tough I only know he is verified and not sure his opinion was based on expierience working on both devkits etc
Yes it is based on his own experience.
I have see it in action, first hand. Even if you as a consumer don’t consciously realize all the ways it will improve games on many levels, the difference for devs is striking.
 
  • Like
Reactions: snc
It was talked about in the Road to PS5 at the 14 minute mark, this will still be done on the CPU in XSX, although it's more more streamlined in Direct Storage.

Also an interesting note is the lack of a DRAM cache for XSX's SSD, PS5 has a separate memory chip for this where as XSX will have to use main RAM which isn't much of a disadvantage from a performance point of view it but does mean XSX will likely be loosing ~512mb of main RAM to this task that PS5 doesn't.

There are potentially some performance advantages possible by using system ram, as it could allow you to collapse a number of lookup tables down for various stages in physically addressing the flash. MS had at least one research paper showing that this could significantly reduce latency and also reduce the amount of work done per access at runtime (though latency is still orders of magnitude higher than from ram). You'd also be doing the work on a much faster processor, [edit] along with eliminating [/edit] some of the operations that are carried out on a typical SSD as used in PC / PS5.

Whether MS have done anything like this I have no idea. A cautious man would bet "probably not".

Surely PS5's SSD will still allow for streaming higher quality assets in multi platform games when engines finally get updated?

Higher quality assets within the same period of time yeah. One of MS's ways to maximise effective performance is SFS though, so you get the same perceived quality with less data transferred and less system memory used. PS5 could do something like this though, but perhaps a little less reliably and with a little more of a performance hit.

Game streaming workloads are typically very bursty, and based on movement of various kinds. This is where I expect the PS5 will excel. Typical movement through an environment e.g. walking or riding or driving through an environment should be fine on either. Like everything there are diminishing returns, but the hardware cost of Sony's IO seems to be fairly small so why not go nuts!

Unlike MS, Sony weren't worrying about dragging the PC into the future when they were designed the PS5.

Nanite in UE5 seems to be one possible approach to maximise model quality over time, while also making access more consistent and more directly related to movement, which (I think) may help lower peak-transfer rates from SSD for Nanite-d stuff.
 
Last edited:
Back
Top