I don't think a cold boot is a good measure of load times. How much memory are you actually going to be loading for a closed OS? Cold boot is dominated by the CPU turning on devices, initializing their state, doing integrity and security checks, and spawning any background tasks. I doubt the actual amount of data moved from the SSD is significant for either system during cold boot.
Next-Generation NVMe SSD and I/O Technology [PC, PS5, XBSX|S]
- Thread starter Shortbread
- Start date
I don't think a cold boot is a good measure of load times. How much memory are you actually going to be loading for a closed OS? Cold boot is dominated by the CPU turning on devices, initializing their state, doing integrity and security checks, and spawning any background tasks. I doubt the actual amount of data moved from the SSD is significant for either system during cold boot.
good point, sorry I should clarify - cold boot game and fast travel load tests.
Johnny Awesome
Veteran
I'm not so sure.
From a strict IO standpoint the XSX can fill it's game memory in 5.5 seconds. The PS5 can do this in 2.5 seconds. That 3 second advantage is the best that PS5 can outperform. Once you add CPU world-building, decompression etc... you might see this almost vanish or reduce to a second or two.
From a strict IO standpoint the XSX can fill it's game memory in 5.5 seconds. The PS5 can do this in 2.5 seconds. That 3 second advantage is the best that PS5 can outperform. Once you add CPU world-building, decompression etc... you might see this almost vanish or reduce to a second or two.
5.5 seconds vs 2.5 seconds is a lifetime of difference in computer speed.
30 frames per second is 33.33ms, that's nearly 80ish frames rendered in 2.5 seconds.
If computational power wipes out that 2.5second advantage I would be shocked, there's not that much computational difference to warrant such a large divide.
If you said 3 seconds vs 2.5 seconds. Okay you've got a race. But 2.5 seconds is a lifetime.
Johnny Awesome
Veteran
We were talking about loading games.
I'm betting XSX next gen games are going to load in 13 seconds and PS5 games will load in 10 or 11 seconds. It's not going to matter much.
I'm betting XSX next gen games are going to load in 13 seconds and PS5 games will load in 10 or 11 seconds. It's not going to matter much.
D
Deleted member 86764
Guest
I doubt that's true, I'd hazard a guess that next gen optimised loading will be 6/3seconds for the two machines.
Microsoft can't close the gap in cold booting of games, but they can more than make up the deficit with QuickResume. If Sony don't have an equivalent to QuickResume then the time-to-game may be a lot quicker on Xbox.
PS5 - load to menu - select mode - load level
XSX - QuickResume
Online games will work in Sony's favour though.
Some patent shown save directly loadable from the OS menu without going inside the game or access to multi from the OS.
It is not like the CPU must wait until everything is loaded into memory. Normally you just load a few things (like a DLL) and execute the code in it for world building.
Before you are at the rendering part, more data is already loaded etc etc.
You won't fill the memory with stuff just to fill it. A big chunk of the memory should be free to actually calculate/compute stuff.
More IO bandwidth only helps up to a certain point and everything more might be a bit faster but not much, because there are now other bottlenecks that needs time to complete. But it is not like everything must wait for that. Still data can be loaded in parallel etc...
The only thing I can see is, that loading screens will be shorter a bit on one platform, but nothing more. Only in some rare edge-cases, IO could get a bottleneck.
Online games will always be a "problem" because server connections seem to always be really slow. E.g. even though the loading screen on my xbox or PC is already complete, than a message occures "waiting for server". Really odd how long something like this can last
I agree but the difference in CPU is not such a massive gulf between the two that it can make up the differential in loading time. Assuming the code is the same, they're going to be grinding though, the SSD as fast as it may be, is still the slowest part of the computer by far, except when you bring 'online' into play; network speeds are atrocious.
the advantage of PS5s SSD will mainly be around cold loading.
Streaming is a small advantage they may be able to exploit (over XSX further) by freeing up some more memory. So a streaming pool is 768MB on PS5, and 1.5GB on XSX. I'm not sure how big of a savings 768MB is though in terms of improving asset quality.
PS5 would have benefitted largely moving to something like 24GB of memory. Though unfeasible from a price perspective.
The XBSX SSD fast travel times (3-5 seconds) for Division 2 is quite similar to current NVMe SSD fast travel speeds for PC, and almost 10-11 seconds faster than current-generation consoles with SSD. Nice, very nice indeed!
I don't mean the difference in CPU-power. I mean the difference in world-building etc. We are just at a point where more IO bandwidth does not bring much more to the table.
Just as a example (I know it is not the best, but a current). Current BC games:
- Loading speed from an external SSD limited to ~500MB/s (USB) and the internal with 2.4GB/s. Difference in the end is ~0.5s (~10.2s vs ~10.7s). There is just a CPU bottleneck. I know hardware decompression is not used, but even if that is used, we still have a cpu-bottleneck here. There is just always a limit what IO can bring to the table. In the end it is just a small difference because somehow the data must also get processed. And if the processing of the data needs 5s (building the world, placing NPCs and their behavior, a bit AI, ...). That is something were more IO does not do anything after the logic has been loaded. Reading textures etc for rendering can also be done in parallel while the system just loads the game world.
Only if you have many prebaked materials you have a big loading advantage. But for something like the the SSD is a bit small.
Also the streaming pool is another thing. Memory has more than doubled for games (from PS4 Pro -> PS5) but bandwidth is still very rare. If you now quickly swap in and out data you exchange memory for memory bandwidth. So yes we have theoretical more memory available, but it is more relevant than in the current gen to look on the bandwidth. RT is also quite bandwidth intensive. So even though we could reduce the cache, I don't see it is really done, just to save the bandwidth for a better use.
Hopefully it doesn't go that high. I'd probably reduce those numbers in half.
I don't think we'll ever get to that for level loading. Loading of 15 seconds at 5.5 GB/s is 49.5 Gigs or 135 Gigs at 9 GB/s with compression! The systems only have ~ 14 GB of memory for games. So what will they be doing with all this massive amount of data required for loading -- it surely won't ever be stored in memory.
At least it won't be IO limited, but worldbuilding/gamelogic limited.
Yes, at that point the limiter will not be I/O, so the time differential will not be 2:1 ratio.
Well the bottleneck is on the API side of things. That much is known. So games leveraging the 'correct' API should open the lanes for full performance from the SSD drives. What you're seeing from BC I believe is a few threads pulling from the SSD when it can handle much more whilst tacking the API.
With games supporting DirectStorage and Sony equivalent, I expect there to be full pumping. I think what we saw with the games showcased at Sony's events alludes to this. I agree there is still CPU, world building etc. And the longer that takes, the less the nvme drive speed story has an impact. ie 2.5s faster loading, but if game loading time is 28s and the other is 30s. Not much a change. But 5s to 2.5s is 50% faster for instance.
Yea I'm not saying IO will be the be all and end all. I just see things going back in that direction (of baked assets) as the consoles mature and they have no where else to extract power.
So if there is a poorly optimized game the 2:1 ratio would not be relevant?
Similar threads
