A lot of people here don't quite seem to get what this is all about.
Previously, a PC or a console might have 4-8 cores (or hyperthreads, or cell processors, or whatever). Typically, you'd want to be doing sequential I/O from just one of those processor cores, because more than likely be a mechanical disk. At most you could do asynchronous or threaded I/O so that the CPU core could also do other computation while waiting for textures to stream in (or whatever), but that's about it.
More than one concurrent I/O at a time (even from other programs!) would cause the disk head to seek, killing your performance. You'd get stuttering in the game or texture popping as the I/O fell behind. You could budget on maybe 20-30 MB/s if you're lucky, or less than 5 MB/s random I/O if unlucky.
It made no difference if you had a PC with an SSD, as zero games were written for it.
So now, with SSDs in consoles as standard you would automatically assume, that we can finally utilise all the CPU threads and throw 8 cores worth of I/O at the SSD. Maybe increase the queue depth a bit more, have some asynchronous and overlapped I/Os or something.
But that's crazy difficult. The models and textures being streamed in are actually used on the GPU, not the CPU. Each texture is typically mip-mapped, building up a "pyramid" of lower and lower resolution versions to prevent moire when viewed at a distance. The "currently used set" of each texture is a complicated angled 'slice' through this sort-of-3D texture 'volume'! This is used asynchronously by the GPU, and ideally you'd somehow want to track this, figuring out which parts are used by the GPU, which aren't, from which mip-map layer, etc.. and then predict ahead the next set of 32x32 tiles or whatever you'd want to load. In parallel. Across 8 CPU cores. While the GPU is doing its own thing.
Just no. That's not happening. The synchronisation alone would be a nightmare. It's crazy talk. No human can write code like this, and certainly not optimally and efficiently.
So the brilliant thing about the GPU on the PS5 is that the GPU can make direct I/O calls. No CPU involvement. Whatever it "needs", as and when it decides, it can simply directly fetch.
It's not going to do this with 8 cores, or 16 threads. No, it's going to do it with thousands of cores. The I/O queue depths that used to be "exactly 1" for literally 100% of all previous games are not going to be 8. They're going to be tens of thousands! This is massive. This isn't "a couple of random I/Os done a little bit better", it's four or five orders of magnitude.
Previously, a PC or a console might have 4-8 cores (or hyperthreads, or cell processors, or whatever). Typically, you'd want to be doing sequential I/O from just one of those processor cores, because more than likely be a mechanical disk. At most you could do asynchronous or threaded I/O so that the CPU core could also do other computation while waiting for textures to stream in (or whatever), but that's about it.
More than one concurrent I/O at a time (even from other programs!) would cause the disk head to seek, killing your performance. You'd get stuttering in the game or texture popping as the I/O fell behind. You could budget on maybe 20-30 MB/s if you're lucky, or less than 5 MB/s random I/O if unlucky.
It made no difference if you had a PC with an SSD, as zero games were written for it.
So now, with SSDs in consoles as standard you would automatically assume, that we can finally utilise all the CPU threads and throw 8 cores worth of I/O at the SSD. Maybe increase the queue depth a bit more, have some asynchronous and overlapped I/Os or something.
But that's crazy difficult. The models and textures being streamed in are actually used on the GPU, not the CPU. Each texture is typically mip-mapped, building up a "pyramid" of lower and lower resolution versions to prevent moire when viewed at a distance. The "currently used set" of each texture is a complicated angled 'slice' through this sort-of-3D texture 'volume'! This is used asynchronously by the GPU, and ideally you'd somehow want to track this, figuring out which parts are used by the GPU, which aren't, from which mip-map layer, etc.. and then predict ahead the next set of 32x32 tiles or whatever you'd want to load. In parallel. Across 8 CPU cores. While the GPU is doing its own thing.
Just no. That's not happening. The synchronisation alone would be a nightmare. It's crazy talk. No human can write code like this, and certainly not optimally and efficiently.
So the brilliant thing about the GPU on the PS5 is that the GPU can make direct I/O calls. No CPU involvement. Whatever it "needs", as and when it decides, it can simply directly fetch.
It's not going to do this with 8 cores, or 16 threads. No, it's going to do it with thousands of cores. The I/O queue depths that used to be "exactly 1" for literally 100% of all previous games are not going to be 8. They're going to be tens of thousands! This is massive. This isn't "a couple of random I/Os done a little bit better", it's four or five orders of magnitude.