Next-Generation NVMe SSD and I/O Technology [PC, PS5, XBSX|S]
- Thread starter Shortbread
- Start date
Really. So you are claiming that the PS5 with an HDD swapped in in place of the NVMe drive, but everything else equal would have a higher performing IO system than the existing PS5 setup minus it's hardware decompression unit?
Perhaps go back and re-read my post with careful attention to this line:
"With the PS5's CPU, that decompression could be done on the CPU - perhaps with some limitations at extremely high throughputs, but nothing to pressure the 'modest' streaming requirements of say R&C."
I already acknowledged that the PS5's CPU might be limited at very high throughputs. But it is plenty fast enough for the most extreme real world use case we to date, and perhaps that we will ever have in R&C.
The bottom line here is that without the decompression block, throughput speeds may be somewhat constrained by CPU decompression capability in extreme cases (of which we have no existing real world example). You still get massively faster throughput than a HDD affords though, and you get all the benefits of the orders of magnitude better latency memory access which is fundamental to enabling true "next gen" software techniques like Nanite.
In terms of console design, it is "special". Hardware decompressors in consoles aren't new. Both the PS4 and XBO have them for the exact same purpose as the PS5 and XS with the biggest difference being the level of data that can be decompressed. The rest of the I/O was additionally designed to allow the consoles to handle a high level of IOPS without drowning the console cpus with work. Without the SDD the rest of the design is for naught.
Instead of Cerney's IO presentation we got presented with the XBO DMEs (Data Movement Engines) two gens ago. The DMEs purpose were to mitigate the impact on CPU cycles and bandwidth when moving data from memory unto the GPU. The defining difference is now we are talking an SSD with its massive throughput.
Last edited:
I think the big thing about console IO units is that they take bursty work off the relatively modest console CPUs (PS5 a little more so than Xbox) and get the job done for a fraction of the power. And the PS5 is a pretty power constrained device where drawing more power on the CPU may result in a downclock of the GPU. A small silicon block to reduce CPU workloads and reduce system power / heat is a smart move, even if games don't progress much beyond Ratchet and Clank's requirements this gen.
"PS5 IO" probably isn't necessary to enable view frustum based/derived streaming of high quality current gen assets, in a suitable engine, with a relatively performant PC. In a console though you can see where "PS5 IO" and "XB Velocity Architecture" will still be paying dividends in 2, 3, 4 years.
Last edited:
I guess the arguments here boil down to
1) Will gaming this gen end up with 1 second complete reloads of content?
2) How dependent will that be on PS5's particular IO features and will other platforms attain it another way (ideally without just gobs of RAM!)?
I think most of us believe 1 isn't going to happen due to production limitations on generating and storing that much content, and 2 is covered by CPU and GPU and a chunk more cacheing maybe. I've personally yet to read compelling arguments against either of these views, particular a rationalisation on the content and delivery of the "1 second" content stream. Indeed, it'd be interesting to look at the engineers' calculations and forecasts and to see how they arrived at that future!
1) Will gaming this gen end up with 1 second complete reloads of content?
2) How dependent will that be on PS5's particular IO features and will other platforms attain it another way (ideally without just gobs of RAM!)?
I think most of us believe 1 isn't going to happen due to production limitations on generating and storing that much content, and 2 is covered by CPU and GPU and a chunk more cacheing maybe. I've personally yet to read compelling arguments against either of these views, particular a rationalisation on the content and delivery of the "1 second" content stream. Indeed, it'd be interesting to look at the engineers' calculations and forecasts and to see how they arrived at that future!
It usually takes some time before the utility of a tech become clearly evident and essential. Look at super resolution technology. The utility of DLSS wasn't initially obvious to a lot of gamers at its release in 2018 mainly due to the artifacts that it produced. But now that RT is more prevalent, super resolution tech evolved to remove a lot of the obvious artifacts and its become necessary to turn on the tech to run these new RT titles at high resolution with high framerates on even high-end GPUs, the tech has become widely embraced.
Furthermore, you don't need gobs of texture data to justify these new IO technologies. But you do need massive pressure on VRAM to show up in some form. Either an explosion of data outside of textures that needs to fit into VRAM or slow growth of the amount of VRAM on future GPUs. If you have an IO system that capable of delivering massive amounts of texture data in a timely fashion, you can alleviate that VRAM pressure by extremely limiting the amount of VRAM dedicated to texture storage (1 second worth of storage). You don't need aggressive prefetching and gobs of dedicated VRAM if the IO system and backing memory can accommodate.
Once we see a better/more performant PC version of DirectStorage (2.0 or above), with a more direct path to VRAM (less hoop jumping) and probably dedicated decompressors on GPUs (I haven't seen any indication that they require a lot of transistors), the viability of 8 GBs on midrange to 4070 like wares may reappear.
Last edited:
To be particular, the claim made was somethng like one second of content being flushed every second. I don't know what the exact quote is though. The value of overhead to deal with extreme IO demands is obvious and not disputed.
It’s a great marketing tool, but I think development realities are different. The closer you get to JIT the closer you are asking SSD to act as an extension of VRAM. And we know today VRAM is so slow that GPUs have been designed with thousands of threads so that it can switch back and forth while it waits for new information to arrive.
Now we introduce SSD latency that is massively less bandwidth and significantly slower than VRAM and you’ve sort need yo ask yourself why.
What value do you gain? Is it not more reasonable to have a slightly larger streaming pool and to avoid the headache of all sorts of race conditions with the SSD that could result in a stall?
This is where I see the land of diminishing returns, the trade off for streaming of SSD is ultimately to reduce VRAM footprint, there’s nothing else to really discuss. If you are so desperate for VRAM I think most developers would look elsewhere before asking themselves to make a near JIT system with SSD constantly flushing memory out for it.
It just makes for an incredibly expensive to develop and port for to get it right. I think they are better off optimizing elsewhere and keeping the steaming pool slightly larger.
This is really the difference between a video game and a tech demo.
I'mDudditz!
Newcomer
Look at this, Sony is spending millions of dollars on custom cloud server infrastructure to further push the SSD i/o marketing gimmick. You guys saw right through them.
I'm not exactly sure how this is to further push the SSD i/o gimmick?
They have to ensure with 100% that anything that can be done on PS5 should be able to be done on cloud.
No one here is saying that PS5 cannot recall assets on demand within a frame. It certainly can, and should a developer take advantage of it, the code would fail on cloud. So it has to be supported.
The best use case for SSD right now, is opening up game and level design. We limit effects, sounds, how many weapons that can be shot, etc, because we need to put a finite limit on the number of assets we want to load into a screen. We have a limit on how NPC enemies look because if each one was unique looking, we'd run out of memory quickly. So to be able to say, we can make millions and just call them up when we need them, is an excellent use case for fast I/O streaming. You want to drop in 1 weapon of a thousand unique looking ones, you can just call it on demand, it's not something that needs to be preloaded. You want to allow users to have more than a couple unique looking items in their inventory - also not a problem.
You want to design levels that don't require these weird slow down quick time events that clearly are for level loading, also not a problem.
You want to design dynamic things in a level that can occur, also not a problem.
But it's very different thing to say that you're going to flush your memory at every turn and minimize your streaming pool such that every turn you're constantly loading in graphics just before it happens.
Not because someone couldn't make it happen, I'm sure someone could just to say they could, but because it just doesn't make sense to and the industry would never move to that. No developer or Mark Cerny has ever talked about the real benefit of being able to load all your assets in Just in Time; other than to say that the hardware could potentially pull it off.
And if I'm wrong about that, please source me where a developer explains the absolute benefits of a just in time system versus the same system with a larger streaming pool that does exactly the same thing, but has a much larger buffer.
I'mDudditz!
Newcomer
Again, this isn't true. Bluepoint explains exactly why JIT streaming benefits Demon Souls, not some hypothetical game destined to release in the future. As they say, each level is divided into multiple sub-level areas and the assets for these sub-levels is streamed in on a JIT basis just as the player reaches the zone. The benefit being they can have more and higher resolution textures. It's all stated here. I bookmarked it for you, you don't even have to seek. The thing you said developers haven't said, was said at 19:13 - 20:04; three years ago. Actually now that I think about it, maybe that is why there is no news of a Demon Souls port yet. They're still trying to figure out how to deal with a game completely designed around significant asset streaming. A much more difficult task than Ratchet was.
Chunking a world up is par for the course for level streaming. That is not the same as streaming in only what you can see.
The SSD allows them to be more aggressive with the streaming. You can load more assets of higher resolution because when you leave the area these can be unloaded for the next.
this is all great and we need to head in this direction because memory is a finite resource and we don’t want to wait forever loading memory with things.
Last edited:
They didn't say they loaded all their assets just in time.
You continue to not understand what anyone is saying, while making blanket, singular statements about what "B3D" is saying (while always being wrong).
You're killing the signal to noise ratio, again, like always.
I'mDudditz!
Newcomer
Wait a minute you're moving the goalpost here. Remember this started in the DF thread and this particular DF Direct question is where we began.
The patreon member is referring to this where Cerny says you can load 4gb texture as the player turns. This is what I'm saying bluepoint has done and they said it. Splicing the world is common, but not streaming anywhere near the levels of PS5. Prior to PS5 I do not know of a game that has streaming 3gb/s compressed assets ~6gb raw to be used as a player turns a corner. I'm not talking about boots or respawns here. If you show me a game that has done this I will rest but that is what I've been saying.
Reyes is related but ultimately different and will rely on how ambitious of a game developer wants to make their game and the game engine will need to evolve to match. Yes PS5 makes REYES realized because that is where Cerny is talking about hot memory for the next second of gameplay.
But Can you point to where BP says they loaded a 4GB texture JIT for demonsouls? They indicated breaking the game into smaller submodules. Mark Cerny is suggesting here to toss assets except what is in the viewport according to that clip above. Once again I’m a suggesting that tech demos are not the same as real dev work. Just because it’s feasible to do in a tech demo, that doesn’t make it feasible to do in a game.
The work done in UE5 is what makes Reyes realized. They didn’t need a ps5 to do it.
well maybe sony investing for the third time in this space will be the charm for them to get it right ?
I hope so. Night Trap did that on Sega CD every time you switched cameras/rooms using a 150KB/s CD drive. Load times and asset management are a design choice.
For me, the smartness here is economic. Moving storage from (V)RAM to SSD saves a truckload of cash. I totally want the pursuit and completion of perfect streaming engines and to see how small and slight a computer is actually needed when work is 100% efficient. The difference between what such a minimal computer and what a monster computer will be no different though, as you'd expect.
As a mod, I'm gettting annoyed with your unproductivev stance. We're engaging with you civilly. If you can't extend your debate beyond "I'm right as proven by a reference to seniority", you should'nt really be posting here.
Please adjust your posting style to debate the points.
Demon's Souls doesn't read nearly as much data as you think. I've already tested the game in this post here and it only read ~100GB from disk over the course of 30 minutes of playtime.
Similar threads
