Current Generation Hardware Speculation with a Technical Spin [post GDC 2020] [XBSX, PS5]

[PSman1700]

weird, I thought dust 514 was released? This is the EVE FPS linked to the persistent world right ?

I'm almost sure i played it somewhere, or im confusing with another game. MAG was actually released and seems similar?

 

[iroboto]

On what kind of SSD setup was that GIF running anyway? Can't imagine it's anything less then some blazing fast NVME or even optane drive, seeing what they achieve. Would be fun if they tried the same thing with an mechanical hard drive

@Dictator tested this in a DF video. I don’t believe it was an NVMe drive, but I’ll let him provide the details; my memory is fuzzy.

edit: it was nvme; but I don’t know which speed he was running for that particular model of nvme drive

 

[JoeJ]

weird, I thought dust 514 was released?

TBH, i don't know! Just assumed it did not.

What if it never will actually release?

hmmm.. i get it: You, as an actual funder of the game, do not expect the release at all and you are fine with that. The journey was worth it, even if it did not reach the goal.
So it does not necessarily mean the downfall of crowdfunding even if things go wrong.

 

[iroboto]

TBH, i don't know! Just assumed it did not.

hmmm.. i get it: You, as an actual funder of the game, do not expect the release at all and you are fine with that. The journey was worth it, even if it did not reach the goal.
So it does not necessarily mean the downfall of crowdfunding even if things go wrong.

https://en.wikipedia.org/wiki/Dust_514

Yea I recall it coming out for PS3. I was eyeing this because I was playing eve online lol

 

[PSman1700]

The journey was worth it, even if it did not reach the goal.

Yeah, about it. Havent funded the game though

 

[Inuhanyou]

One must not forget, SC is a very Singular game. Not every game needs such a traversal mechanic of course!
The Potential most definitely, but not the norm of what to expect I think.

Very true alex, but that makes me even more excited at the possibilities. You say not every game will use high speed traversal of course, but boiling down the mechanic to its base set, isnt it just loading tons of data in and out or scenes super fast?

Devs will able to do a lot with something like that just on the face of it that they werent with HDD. And then we get into indirect benefits like saving on ram to use for other parts of the game because caching tons of data in order to load assets quicker isnt required...

That demo iirc was shown off sometime in 2016 iirc in a star citizen presentation in found on youtube. Surely at this point even better technologies are feasible for gaming. Just what was that demo running on? I assumed SATA but...

 

[Deleted member 11852]

Very true alex, but that makes me even more excited at the possibilities. You say not every game will use high speed traversal of course, but boiling down the mechanic to its base set, isnt it just loading tons of data in and out or scenes super fast?

Plenty of games break their massive worlds into smaller pieces but engineer a way to hide a slow load time, or in the case of Bethesda, sometimes a long-load time. Even if you discount games needing such traversal mechanics, the loss of door animations, elevators and any other number of animations designed to hide - or just amuse while waiting - will be very welcome. Nextegn can't come soon enough..

 

[Inuhanyou]

You turn around and entire enviorments are loaded behind you.


Objects and items can be more dynamic and come in and out of the game near instantly as opposed to our current reality of games being relatively static affairs with everything being relatively bolted down in place or non interactable as fixed assets until the player is ready to interact with them to save as much on resources as possible. This ties into cpu as well and what thatll be able to do in world spaces..

Game developers are no amatuers, they are gonna do some incredible things

 

[Frenetic Pony]

You turn around and entire enviorments are loaded behind you.


Objects and items can be more dynamic and come in and out of the game near instantly as opposed to our current reality of games being relatively static affairs with everything being relatively bolted down in place or non interactable as fixed assets until the player is ready to interact with them to save as much on resources as possible. This ties into cpu as well and what thatll be able to do in world spaces..

Game developers are no amatuers, they are gonna do some incredible things

Not quite that, read speed isn't enough to even get fully decompressed assets out in time even with lower mips loaded in as backup, you'd have bad pop in if you turned around too quickly. Even the quoted SSD benchmarks are all from sequential reads, and those would still take over a second just to fill out a prototypical reserve space for materials. Certainly I'd expect streaming systems to get much finer grained, ditch higher mips of distant backfacing stuff, maybe a voxellized energy/ditance map so you can ditch models and mips of interiors you can't see unless the camera is close enough. But I'd expect non sequential reads to hit something like 1500-2000 mbps at most, since your assets will be compressed that's still a good amount, but not quite a free virtual texturing replacement.

 

[MrFox]

Not quite that, read speed isn't enough to even get fully decompressed assets out in time even with lower mips loaded in as backup, you'd have bad pop in if you turned around too quickly.

Cerny did say in the GDC presentation that it's fast enough to keep assets loaded based on the viewing frustum, and load as you turn. At over 1 million iops and 5.5GB/s decompressed at wire speed up to 22GB/s, it does add up to enough bandwidth and latency.

 

[chris1515]

Not quite that, read speed isn't enough to even get fully decompressed assets out in time even with lower mips loaded in as backup, you'd have bad pop in if you turned around too quickly. Even the quoted SSD benchmarks are all from sequential reads, and those would still take over a second just to fill out a prototypical reserve space for materials. Certainly I'd expect streaming systems to get much finer grained, ditch higher mips of distant backfacing stuff, maybe a voxellized energy/ditance map so you can ditch models and mips of interiors you can't see unless the camera is close enough. But I'd expect non sequential reads to hit something like 1500-2000 mbps at most, since your assets will be compressed that's still a good amount, but not quite a free virtual texturing replacement.

He said in a half second you can load 4GB of data.

 

[Scott_Arm]

He said in a helf second you can load 4GB of data.

That's higher than the 5.5 GB/s, so are they expecting something like 8 GB/s to be typical? Honestly, talking about ssd access in 1s or 500ms is not particularly useful in the rendering world. Frames are on the scale of ms, and rendering devs tend to work on the scale of clock cycles or micro seconds, ms at worst.

1000ms / 33ms = 30 frames
500ms / 33ms = 15 frames

4 GB / 15 frames = 266 MB / frame.
5.5 GB / 30 frames = 183 MB / frame

So you're looking at maybe 183 - 266 MB/frame assuming 30 fps. And that's assuming you're loading for the full frame, so you essentially have a full frame of latency for loading assets. A 60 fps game with fast turning like COD or Doom would probably allow players to turn 180 very quickly, so you'd probably see much less than 500ms 180 speed.

If you're turning 180 degrees in 500ms @ 30fps, that's about 12 degrees per frame. Doom Eternal has a 90 degree fov, so you're loading assets to draw about 13% of the new scene per frame as you turn. If you turn 90 degrees, that's a full redraw of the screen. So you only have 7.5 frames to load the data for a completely new scene. If you have a full frame of latency for loading, you can load 183 - 266 MB for that 13%. Because of the fish-eye effect the higher the fov the larger the percentage of the screen that 13% is going to take up as it'll be alone one of the outer edges of the screen.

The lower your fov, the larger percentage of the screen that's going to change assuming the same turn speed. The faster the turn speed, the larger the percentage of the frame that's going to change. Assuming the same turn speed, 60fps will be fewer degrees per frame, but half the time to load data, so IO latency will have more of an impact the higher the fps. Worst case will be low fov, fast turn speed for ssd access.

The worst case is complete scene redraw in one frame. A good candidate for this is the rear-view mirror in a racing game, or GTA. Any game that allows you to press a button to quickly look behind you will have to have to fit a full scene in 183 - 266 MB of data, or hide the camera change with more additional frames. Press button to switch to rear view -> delay switching view for x num of frames -> draw new view -> button to switch to forward view -> delay switching view for x number of frames - draw forward view. Now, if the player has control of the character as it's switching and the view is moving, that will complicated loading even more. The more frames of latency you add the worse it's going to feel for the player.

Actually in a racing game your car could be hit in a collision that would force the camera to turn very abruptly, maybe much faster than the player can move the camera on their own, and then you have the same issue, but even worse because you can't hide it behind a button press.Then you have the same issues with games where you could move incredibly fast. The faster you move the more of the scene that needs to be changed per frame, and you're still within the 183 - 266 MB/frame limit.

I'm not particularly excited at the idea of games adding a full frame of latency just for loading from ssd, and I'm not particularly excited about the games intentionally capping turn speed to cap ssd read bandwidth. Games right now are smartly caching things into RAM before they're needed, so they don't have to eat a part of a frame, or a full frame just on loading data for their view frustrum. If you switch to loading assets for the view frustrum as needed you're either going to add a frame of latency, or have some part of your frame where the GPU, CPU may idle because it's waiting on data.

It'll be interesting to see if caching the world in tiles will work out to be the superior strategy. I think it probably will. Potentially you cache the world in chunks so you can smartly load things in the background without curing a frame of draw latency, and only load the higher resolution textures on the fly. The xbox solution appears to assume textures will be loaded on the fly, but delayed, so they've built it so the lowest resolution mip is loaded first and then they can stream the needed piece of the higher resolution mip based on sampler feedback streaming, and then blend it with what they say is custom hardware so you don't notice pop-in. I don't know if Sony has the hardware to blend between mip levels the same way, but they have a large IO advantage and a raw bandwidth advantage, so they maybe limited streaming to only particular things like textures or animation will work out to be superior.

Edit: And if you want to know why I think 500ms for a 180 is a long time, there are games that let you play like this ...

... and then there are bad games

Edit: A pro playing COD warzone on a controller for good measure

 

[Karamazov]

But all those issues already exist in actual games, and they do not pose any problem, it's just that with next gen speed, ram + SSD, it will be a lot faster and easier for devs to add complexity to every scene at any given time.

 

[Scott_Arm]

But all those issues already exist in actual games, and they do not pose any problem, it's just that with next gen speed, ram + SSD, it will be a lot faster and easier for devs to add complexity to every scene at any given time.

Edit: I totally disagree. Current games do not load and unload data based on the view frustum because the drives are far too slow. They do level based loading or the stream levels based on smart preemptive loading. I’m just posting about the idea of loading and loading scene data based on the view frustum, which is one of the things Mark Cerny suggested and where the idea of 500ms to turn around came from. Games could load and unload based on view frustum if the drives are fast enough but we know how much data the drives could ideally load per frame based b on the specs. I’m expecting many games or most would still do some preemptive loading but there could be some data that’s streamed based on the view frustum. Texture and animation data maybe. Latency could be an issue for animation data.

 

[Globalisateur]

That's higher than the 5.5 GB/s, so are they expecting something like 8 GB/s to be typical? Honestly, talking about ssd access in 1s or 500ms is not particularly useful in the rendering world. Frames are on the scale of ms, and rendering devs tend to work on the scale of clock cycles or micro seconds, ms at worst.

...

That's exactly that. 8/9 GB/s is their typical speeds as Cerny specified in his presentation. But speeds of 20GB/s are already confirmed if the data compress well. But devs can expect 8/9 in most cases.

 

[Deleted member 11852]

The worst case is complete scene redraw in one frame. A good candidate for this is the rear-view mirror in a racing game, or GTA. Any game that allows you to press a button to quickly look behind you will have to have to fit a full scene in 183 - 266 MB of data, or hide the camera change with more additional frames. Press button to switch to rear view -> delay switching view for x num of frames -> draw new view -> button to switch to forward view -> delay switching view for x number of frames - draw forward view. Now, if the player has control of the character as it's switching and the view is moving, that will complicated loading even more. The more frames of latency you add the worse it's going to feel for the player.

A rear-view mirror isn't something that I think the SSD specifically will help with. If you need to be able to render the view behind instantly then you are still going to need to keep that detail in RAM. But the SSD will help improve the variety and diversity of trackside objects and provide far greater detail of cities that you are racing through because you have more time to load in more detail faster, i.e. load-in where the player might be in 5 seconds rather than 20. Rather than the same 100 generic shopfronts you can load-in far more, or build them procedurally in a pipeline designed to render environments a little-way ahead of where the player is.

I can see the SSD doing as much, if more more, for visuals than delivering revolutionary gameplay changes - other than virtually removing loading. The Star Citizen situation is probably not going to be something most games need because your GTA, Call of Duty and Battlefield just don't have those mechanics and it would be difficult to imagine how they could be woven into these games. But being about to switch from one massively detailed environment to another, really quickly will help flesh out each and every game world.

I'm not particularly excited at the idea of games adding a full frame of latency just for loading from ssd, and I'm not particularly excited about the games intentionally capping turn speed to cap ssd read bandwidth. Games right now are smartly caching things into RAM before they're needed, so they don't have to eat a part of a frame, or a full frame just on loading data for their view frustrum. If you switch to loading assets for the view frustrum as needed you're either going to add a frame of latency, or have some part of your frame where the GPU, CPU may idle because it's waiting on data.

I agree and I don't think buffering of 'may-need' assets is going to be eliminated in most games but what these console SSDs will allow is for [relatively] smaller buffers. I.e. you don't need to buffer the higher-detailed/res assets of where the player may be in 10-20 seconds, you do that nearer the time. E.g. In GTA in Los Santos when you're driving up to an intersection the game has no idea if you'll turn left, right, drive straight on or u-turn so it has to keep all of the assets of the immediate vicinity that it may need in RAM. If you u-turn, because I/O is so slow, it can't flush those assets that were just ahead, to the left and to the right of you just in case you u-turn again and decide to turn left this time because there's not enough time to re-load them from the HDD.

The fact that SSDs will make Star Citizen-like mechanics possible is fantastic and maybe games like Wipeout can have better immediate 'track'-side detail. But I think that for the most part, it'll make current game environments look better.

Going from PS2-era games to PS3-era games, we saw an order-of-magnitude improvement in world detail that we didn't see going from PS3/360-era games to PS4/XBO. But I think we'll get this in the next generational transition and the SSD will be the system component most directly responsible.

edit: typos/grammar.

 

[Karamazov]

Edit: I totally disagree. Current games do not load and unload data based on the view frustum because the drives are far too slow. They do level based loading or the stream levels based on smart preemptive loading. I’m just posting about the idea of loading and loading scene data based on the view frustum, which is one of the things Mark Cerny suggested and where the idea of 500ms to turn around came from. Games could load and unload based on view frustum if the drives are fast enough but we know how much data the drives could ideally load per frame based b on the specs. I’m expecting many games or most would still do some preemptive loading but there could be some data that’s streamed based on the view frustum. Texture and animation data maybe. Latency could be an issue for animation data.

But the idea is not to load/unload everything, but maybe parts of it, it can still be done at a way higher rate than this gen.
There are already game doing this to some extent, and you can see it break apart a bit sometimes, when you turn fast, some geometry or texture work loads in front of you as you may have moved a bit too fast for it to load properly.
And remember that gif from horizon dev talk about similar tech used, at least for terrain geometry rendering.

https://giphy.com/gifs/linarf-xUPGcgiYkD2EQ8jc5O

 

[chris1515]

A rear-view mirror isn't something that I the SSD is specifically going to help with. If you need to be able to render the view behind instantly then you are still going to need to keep that detail in RAM. But the SSD will help improve the variety and diversity of trackside objects and provide far greater detail of cities that you are racing through because you have time to load in more detail with in less time, i.e. in 5 seconds rather than 20. Rather than the same 100 generic shopfronts you can load-in far more, or build the procedurally in a pipeline designer to render environments a little-way ahead of where the player is.

I can see the SSD doing as much, if more more, for visuals than delivering revolutionary gameplay changes - other than virtually removing loading. The Star Citizen situation is probably not going to be something most games need because your GTA, Call of Duty and Battlefield just don't have those mechanics and it would be difficult to imagine how they could be woven into these games. But being about to switch from one massively detailed environment to another, really quickly will help flesh out each and every game world.



I agree and I don't think buffering of 'may-need' assets is going to be eliminated in most games but what these console SSDs will allow is for [relatively] smaller buffers. I.e. you don't need to buffer the higher-detailed/res assets of where the player may be in 10-20 seconds, you do that nearer the time. E.g. In GTA in Los Santos, when you're driving up to an intersection the game has no idea of you'll turn left, right, drive straight on or u-turn so it has to keep all of the assets of the immediate vicinity that it may need in RAM. If you u-turn, because I/O is so slow, it can't flush those assets that were just ahead, to the left and to the right of you in case you u-turn again and decide to turn left this time because there's not enough time to re-load them from the HDD.

The fact that SSDs will make Star Citizen-like mechanics possible is fantastic and maybe games like Wipeout can have better immediate 'track'-side detail. But I think that for the most part, it'll make current game environments look better.

Going from PS2-era games to PS3-era games, we saw an order-of-magnitude improvement in world detail that we didn't see going from PS3/360-era games to PS4/XBO. But I think we'll get it this next generational transition and the SSD will be the system component most directly responsible.

For GTA if they have multiple character like in GTA 5, it will help to do a fast transition between the character.

But the idea is not to load/unload everything, but maybe parts of it, it can still be done at a way higher rate than this gen.
There are already game doing this to some extent, and you can see it break apart a bit sometimes, when you turn fast, some geometry or texture work loads in front of you as you may have moved a bit too fast for it to load properly.
And remember that gif from horizon dev talk about similar tech used, at least for terrain geometry rendering.

https://giphy.com/gifs/linarf-xUPGcgiYkD2EQ8jc5O

They talked about view frustrum culling for the gif not how they load the element.They generate the terrain procedurally and everyone can easily see some problem of big popin when the player is near meridian in HZD if you turn too fast from the jungle to see the Meridian city. It will help here. And the streaming is a big limitation about what they can do in a city.

That's higher than the 5.5 GB/s, so are they expecting something like 8 GB/s to be typical? Honestly, talking about ssd access in 1s or 500ms is not particularly useful in the rendering world. Frames are on the scale of ms, and rendering devs tend to work on the scale of clock cycles or micro seconds, ms at worst.

1000ms / 33ms = 30 frames
500ms / 33ms = 15 frames

4 GB / 15 frames = 266 MB / frame.
5.5 GB / 30 frames = 183 MB / frame

So you're looking at maybe 183 - 266 MB/frame assuming 30 fps. And that's assuming you're loading for the full frame, so you essentially have a full frame of latency for loading assets. A 60 fps game with fast turning like COD or Doom would probably allow players to turn 180 very quickly, so you'd probably see much less than 500ms 180 speed.

If you're turning 180 degrees in 500ms @ 30fps, that's about 12 degrees per frame. Doom Eternal has a 90 degree fov, so you're loading assets to draw about 13% of the new scene per frame as you turn. If you turn 90 degrees, that's a full redraw of the screen. So you only have 7.5 frames to load the data for a completely new scene. If you have a full frame of latency for loading, you can load 183 - 266 MB for that 13%. Because of the fish-eye effect the higher the fov the larger the percentage of the screen that 13% is going to take up as it'll be alone one of the outer edges of the screen.

The lower your fov, the larger percentage of the screen that's going to change assuming the same turn speed. The faster the turn speed, the larger the percentage of the frame that's going to change. Assuming the same turn speed, 60fps will be fewer degrees per frame, but half the time to load data, so IO latency will have more of an impact the higher the fps. Worst case will be low fov, fast turn speed for ssd access.

The worst case is complete scene redraw in one frame. A good candidate for this is the rear-view mirror in a racing game, or GTA. Any game that allows you to press a button to quickly look behind you will have to have to fit a full scene in 183 - 266 MB of data, or hide the camera change with more additional frames. Press button to switch to rear view -> delay switching view for x num of frames -> draw new view -> button to switch to forward view -> delay switching view for x number of frames - draw forward view. Now, if the player has control of the character as it's switching and the view is moving, that will complicated loading even more. The more frames of latency you add the worse it's going to feel for the player.

Actually in a racing game your car could be hit in a collision that would force the camera to turn very abruptly, maybe much faster than the player can move the camera on their own, and then you have the same issue, but even worse because you can't hide it behind a button press.Then you have the same issues with games where you could move incredibly fast. The faster you move the more of the scene that needs to be changed per frame, and you're still within the 183 - 266 MB/frame limit.

I'm not particularly excited at the idea of games adding a full frame of latency just for loading from ssd, and I'm not particularly excited about the games intentionally capping turn speed to cap ssd read bandwidth. Games right now are smartly caching things into RAM before they're needed, so they don't have to eat a part of a frame, or a full frame just on loading data for their view frustrum. If you switch to loading assets for the view frustrum as needed you're either going to add a frame of latency, or have some part of your frame where the GPU, CPU may idle because it's waiting on data.

It'll be interesting to see if caching the world in tiles will work out to be the superior strategy. I think it probably will. Potentially you cache the world in chunks so you can smartly load things in the background without curing a frame of draw latency, and only load the higher resolution textures on the fly. The xbox solution appears to assume textures will be loaded on the fly, but delayed, so they've built it so the lowest resolution mip is loaded first and then they can stream the needed piece of the higher resolution mip based on sampler feedback streaming, and then blend it with what they say is custom hardware so you don't notice pop-in. I don't know if Sony has the hardware to blend between mip levels the same way, but they have a large IO advantage and a raw bandwidth advantage, so they maybe limited streaming to only particular things like textures or animation will work out to be superior.

Edit: And if you want to know why I think 500ms for a 180 is a long time, there are games that let you play like this ...

... and then there are bad games

Edit: A pro playing COD warzone on a controller for good measure

For games at 60 fps or where you can turn very fast it will be possible to load less details and he speaks about been able to load some data during the current frame or the frame after. If I understand well too, SSD latency are in the ms. In some benchmark where they measure the latency it is often under 1 ms.

 

[Shifty Geezer]

I’m just posting about the idea of loading and loading scene data based on the view frustum, which is one of the things Mark Cerny suggested and where the idea of 500ms to turn around came from.

Games aren't going to compromise the gameplay for the purposes of streaming assets. They'll just use a cache. I think Cerny's examples were just illustrative, that you could stream everything in just half a second, and not a recommendation for how games should do it. There'll be some cases where you could turn in half a second and it'd be okay, like vehicle/animal travel, which is where streaming would be more appropriate anyhow as you are covering a larger area.

 

[chris1515]

Games aren't going to compromise the gameplay for the purposes of streaming assets. They'll just use a cache. I think Cerny's examples were just illustrative, that you could stream everything in just half a second, and not a recommendation for how games should do it. There'll be some cases where you could turn in half a second and it'd be okay, like vehicle/animal travel, which is where streaming would be more appropriate anyhow as you are covering a larger area.

If you can turn in less than half a second there will be less details like in a 60 fps game and there will be some limit in the GPU too like always 60 fps game will have two times less details than 30 fps one. I don't know why there will be a one frame lateny when latency in SSD benchmark for random 4k read are under 1 ms.

Mark Cerny talk about loading something during the current frame.

EDIT: Here some latency benchmark for SSD with 4k read, this will not be the use case for streaming in game and Sony SSD has more queue it probably help for latency. And the Sony patent describe the possibility of a read request linked to the file archive to block demand from the OS request for example, they will be treated after. This is probably the reason he called latency of SSD instantaneous in the case of a game.

https://www.anandtech.com/show/8104...ew-the-pcie-ssd-transition-begins-with-nvme/3

https://www.thessdreview.com/featured/ssd-throughput-latency-iopsexplained/2/

The final row we’ll look at is Access time, which is latency. A single access time figure is very simplified, as it varies depending on many things, in this case it must be an average. The HDD’s Read Access Time of 15.785 millisecond sounds quick, and it is, but the SSD’s Access Time of 0.031 milliseconds is 509 times faster!