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

[pjbliverpool]

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.

We already have 1 second (or near enough) complete reloads of content in the form of Ratchet moving through the dimensional portal. The question here though is whether that would happen as part of normal gameplay from a simple camera turn at any given point in the game which would imply a 360 degree turn of the camera consumes a very large percentage of the games art content - around 25% of the content in a game the size of R&C for example.

So while not technical impossible, it's practically extremely unlikely unless the game is going to be extremely unvaried in art content. Essentially one environment that repeats over and over again.

 

[Shifty Geezer]

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.

A short-coming of that analysis is we don't have burst rate. The theory here is the game is streaming lots in the time it takes to turn around. The actual granularity and timeframe for 'just in time' isn't given though so it's not a very exacting reference. Given the game is chunked as is typical for streaming, the impact of the IO system above and beyond the simple lower latency, higher BW of SSD, isn't identifiable.

I think equally importantly, if not more so, there's only one game doing this that isn't ported. Sony's other games have gotten or are getting PC ports. If it's such a significant advantage, why aren't other 1st party titles built the same way? Could it even be that PS5 IO is so fast games can't be ported, and so it won't be used for economic reasons? That's the kind of thing that can gimp a tech.

 

[Shifty Geezer]

We already have 1 second (or near enough) complete reloads of content in the form of Ratchet moving through the dimensional portal. The question here though is whether that would happen as part of normal gameplay from a simple camera turn at any given point in the game which would imply a 360 degree turn of the camera consumes a very large percentage of the games art content - around 25% of the content in a game the size of R&C for example.

So while not technical impossible, it's practically extremely unlikely unless the game is going to be extremely unvaried in art content. Essentially one environment that repeats over and over again.

As I understand it R&C on PC supports 360 turnaround loading without problems, plus with wider FOV too?

 

[DavidGraham]

Some extreme situations of the PS5 IO system could be in designing something like Doctor's Strange portal rooms in the sanctum, where each door leads to a completely different biome that is visible through the door/portal. And you can go into each one instantly, maybe even go back and forth.



Another interesting concept is the Tesseract scene in Interstellar where you can quickly scroll through space and time of a region in space.



However all of these things are doable just fine with enough RAM, or with a combination of RAM and fast SSD. Or some clever data planning and management.

 

[pjbliverpool]

As I understand it R&C on PC supports 360 turnaround loading without problems, plus with wider FOV too?

I'm not sure anything significant in the current view fustrum is getting unloaded and reloaded into VRAM from disk from an on the spot turn in R&C PC or else the game would likely see much bigger issues on an HDD. I think the small physical size of the game coupled with the variety of environments and characters makes it unlikely they need to do that.

 

[iroboto]

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.

Absolutely, but its a little more than just economic. It's fast enough that we can now have persistent state worlds. There's a lot of reasons to get excited about SSD tech as being a core part of games and game engines, but JIT is probably the lowest on my list of things to actually be excited about. Which is sad, because among the discussions we could have about what SSD actually enables for games, we're stuck debating how much more 'graphics' SSD enables.

Which is weird, because its technically not part of the rendering pipeline. If you don't have enough VRAM, you just can't render. So the speed of the SSD, the latency, should probably in some format, scale in ratio with the size of VRAM. Being able to fill about 30-40% of VRAM with SSD is probably the speed you need, and anything faster is probably useless.

But we' haven't even scratched the surface about discussing writing back to SSDs. And that's a big area I think we could massively improve games by doing. Think of Creation Engine and add steroids.

 

[cwjs]

4gb of textures is an extremely large amount. At the standard format for compression, that's ~60 8192x8192 RGBA textures. A 8192 texture is about 8 times as many pixels as a standard 4k screen, so if you're doing any kind of mip based streaming the maximum size you need for visual quality is 1/4th or 1/8th of that.

It's good to separate numbers that demonstrate the hardware is cool from numbers that are going to practically constrain how a game runs on one platform or another, so let's think about whether 4gb of textures per frame is a constraint for a real game.

As a rough rule of thumb lets say every unique object needs two unique rgba textures (rgb channels for color, an alpha channel for height or transparency, another set of two channels for normals, and another set of two channels for reflectivity.) Average size of a texture needed this frame, let's say is 1024x1024. So you can load 2000 completely unique objects that re-use no textures in 4gb. You just aren't ever going to be loading that much texture data in a given frame.

The fact that you have that kind of head room is good, you might sweat less about getting your 0.5gb of texture memory loaded to prevent texture pop-in during a cutscene camera change, and maybe other platforms will be out of luck and show slightly lower resolution textuers for one frame, but there's just not going to be a situation where Only The Ps5 can run your game.

 

[Shifty Geezer]

Absolutely, but its a little more than just economic. It's fast enough that we can now have persistent state worlds. There's a lot of reasons to get excited about SSD tech as being a core part of games and game engines, but JIT is probably the lowest on my list of things to actually be excited about. Which is sad, because among the discussions we could have about what SSD actually enables for games, we're stuck debating how much more 'graphics' SSD enables.

We've discussed that in the past! Presently the only momentum to the discussion, from two opposed sides, is around PS5's IO stack and what difference that does for loading assets. We could do with a new game doing something new!

 

[fehu]

Some extreme situations of the PS5 IO system could be in designing something like Doctor's Strange portal rooms in the sanctum, where each door leads to a completely different biome that is visible through the door/portal. And you can go into each one instantly, maybe even go back and forth.

Basically Portal already did it, in its own way, around the limitations of the time. In my opinion, it's not something undoable without crazy fast ssd because you are limited by the rest of the hardware, slowed down by the rest of the rendering pipeline, and in particular because developers will find a way.
Fast ssd's advantages will be more about the mundane than revolutionizing.

 

[iroboto]

We've discussed that in the past! Presently the only momentum to the discussion, from two opposed sides, is around PS5's IO stack and what difference that does for loading assets. We could do with a new game doing something new!

Yea lol, for me, as people we don't really realize why games look so gamey? Movies as well, they just all look so unrealistic, until we see something gory, like in slasher films, or gore porn.. The reality is, shooting guns and knives etc, it's a bloody affair with blood gushing everywhere. And it's stays there. Bullet holes, stay there. I want to a game, where combat occurs, the carnage stays forever there. Right now, the carnage always disappears. From my perspective, if we're unloading everything out of the viewpoint, it's sort of crazy, because you lose that level of persistence, and I would prefer to have more and not less. I don't want to see the rag dolls go away. I want to enter a room and see how the carnage unfolded, all blast marks and damaged pots etc, all those pieces still laying there.

There are a ton of reasons why we would not unload everything from the viewport, ray tracing, and RTGI absolutely require persistence for things look both better and correct. If you're unloading from your viewport, suddenly reflections don't work so well, or bounce lighting doesn't work anymore. There are a tons of reasons why we would keep things resident in memory, and that if we are unloading and loading things into memory for the viewport, it's likely to be the items well occluded.

 

[I'mDudditz!]

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.

You're right. Sorry.

 

[davis.anthony]

Tere are a ton of reasons why we would not unload everything from the viewport, ray tracing, and RTGI absolutely require persistence for things look both better and correct. If you're unloading from your viewport, suddenly reflections don't work so well, or bounce lighting doesn't work anymore.

How so?

The BVH is a separate source of data that can contain the data required for RT even if the data required for the player view port is ejected from ram.

I'm also fairly certain Insomniac have said they do this with R&C (eject items from RAM not in view) and when the issue of RT was bought up they said they got around it so the two are not that tied together.

Edit: Added source.

 

[I'mDudditz!]

The work done in UE5 is what makes Reyes realized. They didn’t need a ps5 to do it.

Not quite. Nanite solved a portion of the Reyes equation with it's software rasterization for sub pixel geometry. But the PS5 i/o concept helps to realize other aspects of REYES with virtual texturing. Yes, virtual texture is a UE5 (and other engines) feature, but the desired texture quality and variability can't be realized even without having a JIT i/o similar to PS5. Yes, eventually we will be playing much richer, multi TB sized games, maybe not so much in this generation, but the next. And system memory will not scale economically and timely.

When I think REYES concept in its entirety I am thinking beyond visuals to include streaming animations, audio, etc. ultimate goal of the i/o is to consider all game data needed at any point in time, not just the visuals

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.

Only? 100gb of compressed data is a LOT depending on the number of requests throughout the 30min. For example if request from storage occurs every 30 seconds, that's 1.6gb of data that needs to come in JIT to avoid stall. We're basically talking data request and transfers equivalent or maybe higher than the Ratchet Portals every 30sec. That's impressive/demanding.

 

[iroboto]

How so?

The BVH is a separate source of data that can contain the data required for RT even if the data required for the player view port is ejected from ram.

I'm also fairly certain Insomniac have said they do this with R&C (eject items from RAM not in view) and when the issue of RT was bought up they said they got around it so the two are not that tied together.

My general feel is if you are having dynamic real time GI, if you dynamically shine a light on a set of objects behind the viewport, and that bounce lighting makes it back to the viewport. Are we going to skip the materials calculation on the items behind to bounce the light forward?

 

[pjbliverpool]

Only? 100gb of compressed data is a LOT depending on the number of requests throughout the 30min. For example if request from storage occurs every 30 seconds, that's 1.6gb of data that needs to come in JIT to avoid stall. We're basically talking data request and transfers equivalent or maybe higher than the Ratchet Portals every 30sec. That's impressive/demanding.

1.6GB of data every 30 seconds is worlds away from refreshing the full VRAM as you turn the camera. It's a couple orders of magnitude less.

In any case, a far more realistic scenario is that they stream the world in ahead of the character in a more traditional fashion at a more consistent rate averaging around 50MB/s. Or well within the capabilities of a spinning HDD. I've no doubt they have some instances where they stream more, perhaps much more than the average, but again, that's nothing remotely like the original claim of storing the next 1 second of data in VRAM and basically refreshing the entirety of VRAM every second.

 

[iroboto]

Not quite. Nanite solved a portion of the Reyes equation with it's software rasterization for sub pixel geometry. But the PS5 i/o concept helps to realize other aspects of REYES with virtual texturing. Yes, virtual texture is a UE5 (and other engines) feature, but the desired texture quality and variability can't be realized even without having a JIT i/o similar to PS5. Yes, eventually we will be playing much richer, multi TB sized games, maybe not so much in this generation, but the next. And system memory will not scale economically and timely.

I'm not sure I understand your point around why PS5 I/O concept changes anything in the PC space with respect to virtual texturing, we can run Nanite on standard PC SSDs and it was designed to support a variety of devices.

 

[I'mDudditz!]

1.6GB of data every 30 seconds is worlds away from refreshing the full VRAM as you turn the camera. It's a couple orders of magnitude less.

Because the game hasn't been made yet? You can't fault the hardware or judge the claim as bogus because you haven't seen it yet. Has your argument been that their hasn't been a game that refreshed the PS5 entire 16gb memory at a turn? I don't disagree with this. I would say that's a bizarre argument to make. If a developer doesn't want or need to make such a game or game engine that doesn't take away from the world designs PS5 i/o enables.

But the concept is actually playing out today the way the developers have been describing how their game works. It has been so with Ratchet and Demon Souls. That's really all I've been saying here.

In any case, a far more realistic scenario is that they stream the world in ahead of the character in a more traditional fashion at a more consistent rate averaging around 50MB/s. Or well within the capabilities of a spinning HDD. I've no doubt they have some instances where they stream more, perhaps much more than the average, but again, that's nothing remotely like the original claim of storing the next 1 second of data in VRAM and basically refreshing the entirety of VRAM every second.

That's not practical if you have spliced the world into a large multiple of distinct and rich areas. You would inevitably resort to pre cache and ultimately limited by memory. How would this work for a 500gb game (I do think we will see a healthy number of these) with world design that prioritizes seamless continuity and player agency? That was the point Cerny is making.

 

[Shifty Geezer]

The BVH is a separate source of data that can contain the data required for RT even if the data required for the player view port is ejected from ram.

Pretty sure that's not the case. The BVH provides a spatial hierachy of which triangle models to load and trace against. It's 'small and lean' for the purposes of rapid traversal, but contains no object or material data. As such, if you are looking at a reflection of what's behind the camera, the rays tell you what model to load but the model data is still needed to be rendered. It's not possible to draw a dinosaur in a battle car with chrome exhausts behind you without the assets being in memory.

 

[cwjs]

Pretty sure that's not the case. The BVH provides a spatial hierachy of which triangle models to load and trace against. It's 'small and lean' for the purposes of rapid traversal, but contains no object or material data. As such, if you are looking at a reflection of what's behind the camera, the rays tell you what model to load but the model data is still needed to be rendered. It's not possible to draw a dinosaur in a battle car with chrome exhausts behind you without the assets being in memory.

You will however probably only have lower LODs and lower mips of the textures for the things off screen, might be something like a tenth of the data you need to display the object at full detail on screen .

 

[davis.anthony]

Yes, eventually we will be playing much richer, multi TB sized games, maybe not so much in this generation, but the next. And system memory will not scale economically and timely.

Next generation is 5-6 years away and we won't be anywhere close to having games that large in size.

The machines won't have the storage space for them and 90% of the planet won't have the internet speed to download them within a 'reasonable' time frame.

The average download speed in the UK is currently 10.8MB/s

Using an online calculator it puts the average download time for 1TB game at 1 day 4hrs.

If they manage to double the average download speed in the next 5-6 years consumers still aren't going to wait 12hrs+ for most AAA games to download.