Baseless Next Generation Rumors with no Technical Merits [post E3 2019, pre GDC 2020] [XBSX, PS5]

Status
Not open for further replies.
They won't be next-gen games though, or MS would be throwing money away if they let all their new XBSX owners play all those new XBSX games on a free three-month Game Pass.

All First Party Microsoft Studio games will be on GamePass. If they give away 3 months free with console, those will be included. However we know they are not targeting next-gen only titles and will be cross-gen targets for around 2 years from November 2019.
 
It doesn't matter if SSD is slower as long as it's fast enough, which is mostly about the access time. As discussed for 'megatexturing', the amount of data needed in RAM is actually very little. Let's say 4GB. You then have a couple GBs for cache and you can fill the whole world with varied detail on like 8 GBs. What everyone's used to is great gobs of RAM because HDDs are slow and can't stream effectively, but once storage is fast enough (which doesn't need to be as fast as RAM), the rendering paradigm can shift from 'everything in RAM' to 'ideal streaming'. Quite possibly we'll never need more than 16 GBs ever in a console because storage will be getting faster and faster.

As for whether Sony's solution can be faster in practice, possibly if the latency is that much slower on MS's solution, but given baseless rumours of MS having fabulous paging tech, I doubt there could be much in it.
Thats the thing, streaming textures from disk is how it will be done but even then, the textures are still used in RAM, they are just prefetched and streamed into RAM. Faster speed of moving things into the cache is nice but 2x faster caching is not 2x faster speed. Fast enough is all that matters in this case because once you reach a reasonable speed, the bottleneck would be back on accessing the texture in RAM.
 
I mean if they include them, giving away three months of Game Pass with each console is losing all those sales. Many millions of dollars of sales. Heck, they'll be losing many millions from subscribers as it is. Giving Game Pass away free will mean what, two games free for each console buyer? Two games at $50 apiece is $100 lost revenue from the first 10 million owners? What would MS get for losing $1 billion? If they don't give Game Pass away free, at least those XB owners who use it will be subscribers, losing far less money.
 
Thats the thing, streaming textures from disk is how it will be done but even then, the textures are still used in RAM, they are just prefetched and streamed into RAM. Faster speed of moving things into the cache is nice but 2x faster caching is not 2x faster speed. Fast enough is all that matters in this case because once you reach a reasonable speed, the bottleneck would be back on accessing the texture in RAM.
No. Look up how virtual texturing works. You only need a few MBs of texture info to texture the entire renderscene at native resolution. You have 8 million pixels at 4K. Technically you need 24 MBs of 24 bit RGB info to texture the screen with 1 texel : pixel clarity. Conventional texturing puts 2 MBs textures in RAM for each model and accesses a tiny fraction of the loaded asset data per frame - it's hideously inefficient. Once streaming is fast enough, you no longer need to use such a naive brute-force solution.
 
I mean if they include them, giving away three months of Game Pass with each console is losing all those sales. Many millions of dollars of sales. Heck, they'll be losing many millions from subscribers as it is. Giving Game Pass away free will mean what, two games free for each console buyer? Two games at $50 apiece is $100 lost revenue from the first 10 million owners? What would MS get for losing $1 billion? If they don't give Game Pass away free, at least those XB owners who use it will be subscribers, losing far less money.
Well even they include nothing, Game Pass is still 14 days free for new subs.
 
I'm still trying to reason on how having fast drives is going to shape up this gen.

The big question is if you were to have a drive that had infinite throughput, what would bottleneck your reads first: cpu, gpu, available RAM, bandwidth, optical disc capacity. Assuming the PS5 specs are real, ~9 TFLOPs RDNA, with something like 500 GB/s bandwidth and an 8-core Ryzen CPU around 3.6 GHz (no idea what the leaks are saying), what's the limit?

Starting at the optical disc, everything has to fit on disc. There are time and budget constraints to producing content (models, animations, textures, sounds) and there are limits to how much the data can be compressed. Once it's on your SSD, you have limits in terms of decompressing the content, which could impact the CPU or require a secondary processor to handle decompression. Assuming your cpu or decompression can work fast enough, bandwidth should not be an issue except for bus contention. Both the CPU and GPU are contending for memory, so you can't just hit the SSD non-stop to write into RAM.

Then you have to consider that everything has to fit into RAM. The SSD isn't going to be fast enough to unload everything that's not visible. You can turn a 180 degree view in a frame. So at 30 fps, with an infinitely fast drive you would never have to worry about streaming in an entirely new set of meshes, textures for all of the things within your view. In reality you'll probably be able to read 230 MB/frame max (assuming 7GB/s) drive, but whatever is read won't be decompressed instantaneously, so you probably have some fraction of 230 MB/frame (7 GB/s * 0.033s) multiplied by whatever your compression ratio is (assuming you can decompress within 33ms). I don't know what those numbers would be. There's some limit to how much data you can swap on the fly within a frame. Then you end up back into a coarser streaming scenario, where you're back to streaming in tiles with a caching strategy.

Then you have to understand what the occupancy of your memory looks like. You have 16GB of RAM, minus some system reservation (or maybe not if there's dedicated system memory). Within the game engine there's going to be some percentage of RAM that's lost to the things that we cannot see on screen or hear. It should be on the very small side, but it is a loss. On top of that you need to track things persistently in most games. So the character that walks off screen needs to be there if you turn around. The world simulation does not end outside the view port (in most 3D games). It may be reduced, but not erased. So for every ai, sound, physics object, statistic, the state must remain even if you do not see it on screen. If you increase the density of your world tiles, you're reserving more RAM for the things you can't see yet. Yes there's LODs and whatever, but it's pretty clear that even with an incredibly fast drive, there's going to be some limit to how much data you can stream in per frame, so they'll still have to worry about keeping things resident in memory ahead of its use. There are probably other things to consider in terms of what could actually fit in RAM, but that's what comes to mind off the top of my head.

As for the gpu and cpu, almost everything you'd want to increase in visual density will come with other costs in terms of physics or ai. Unless we get the same static games we always got, you'll have to have some combination of physics and intelligence for every new object you add into the scene. On top of that, you can't just add infinite meshes into your scene before the gpu starts to choke because it hits some kind of vertex processing limit. Something like Nvidia mesh shaders could help massively here. CPU and GPU could both be responsible for physics. Ai is probably still on the cpu, but we've seen a large bump and not all games require huge numbers of ai actors or sophisticated ai.

It'll be really interesting to see what developers come up with, because I think this will be the first time that streaming performance from the drive will not be a huge bottleneck. We went from slow optical discs to 20 MB/s to now potentially many GB/s.

Oh, and I've never mentioned the impact on cpu and gpu caches.
 
It doesn't matter if SSD is slower as long as it's fast enough, which is mostly about the access time. As discussed for 'megatexturing', the amount of data needed in RAM is actually very little. Let's say 4GB. You then have a couple GBs for cache and you can fill the whole world with varied detail on like 8 GBs. What everyone's used to is great gobs of RAM because HDDs are slow and can't stream effectively, but once storage is fast enough (which doesn't need to be as fast as RAM), the rendering paradigm can shift from 'everything in RAM' to 'ideal streaming'. Quite possibly we'll never need more than 16 GBs ever in a console because storage will be getting faster and faster.

As for whether Sony's solution can be faster in practice, possibly if the latency is that much slower on MS's solution, but given baseless rumours of MS having fabulous paging tech, I doubt there could be much in it.

The more you rely on streaming from the SSD, the more you are limited by the SSD performance. Even with a PCIe 4.0 nvme SSD, access speeds and throughput are incredibly slow compared to RAM. Even a custom Sony SSD will not change that. And RAM will be incredibly slow compared to CPU, GPU caches unless new memory technology is brought to market.
 
Arthur C Clarke was famously quoted for saying "Any sufficiently advanced technology is indistinguishable from magic."

But it's not magic if your storage system, filesystem, controller and I/O chain are optimised to read massive amounts of smaller assets individually and decompress them ready for use by CPU and GPU compared to the convention of games being bundled as lots of massive packs of compressed assets, where there is an overhead of reading the pack, then picking the assets you want from it, then decompressing the asset before it can be used. What Mark Cerny has said supports this, as does some of Sony's own patents.

But we'll see. :yep2:

I'm curious which access pattern is better: lots of small files fast, a few large files slow. From what I understand a lot of nvme ssd latency comes from queuing IOPs, which occurs when you get collisions from trying to two or more pieces of data on the same NAND device.
 
Starting at the optical disc, everything has to fit on disc.

I'm not entirely sure this has to be true. I don't like destruction as an example, but for lack of a better idea...in the process of fighting through a city block you've left it a bit knackered.* That particular blend of assets are essentially new data that's been processed over a significant period of time, relative to a single frame. If it's saved down to stream back, the game size is growing beyond that 100Gb cap. A degree of persistence we've no seen in 3d games before might be possible.

* Some games have boasted limited base building. You could really go nuts with this in a way slow storage doesn't allow.
 
I'm not entirely sure this has to be true. I don't like destruction as an example, but for lack of a better idea...in the process of fighting through a city block you've left it a bit knackered.* That particular blend of assets are essentially new data that's been processed over a significant period of time, relative to a single frame. If it's saved down to stream back, the game size is growing beyond that 100Gb cap. A degree of persistence we've no seen in 3d games before might be possible.

* Some games have boasted limited base building. You could really go nuts with this in a way slow storage doesn't allow.

That's a good point. Essentially the disc contains the building blocks for other things that can later be stored on the SSD, or in memory.
 
A degree of persistence we've no seen in 3d games before might be possible.

...in AAA games. There are a few indie games already with massive levels of world (pretty much all are open world games) persistence and base building on the level of player made towns and cities.

These have existed for well over a decade now with constant advancements. It goes so far in some games as to have the entire game world be terraformable.

But to the point, it would be interesting to see a AAA developer attempt something on those levels, as indie games can be a bit janky. I just feel that it will inevitably be watered down or otherwise limited in some way as graphics are far more important for AAA developers and some AA developers.

Which means that AAA devs are incredibly limited in what they can do due to having to push X level of graphics fidelity. Something smaller developers can ignore to an extent when designing their game.

So, as I mentioned a long time ago in one of these threads, the storage subsystem of these consoles is the only thing that really interests me for this upcoming generation. Will we finally see AAA devs attempting to do things that indie devs have been doing for years?

Regards,
SB
 
For user generated content at AAA visual quality, storage speed seems the lesser issue to me than preprocessing times.
Ofc. both is slovable doing the proper compromise. Dreams is very impressive here, allowing to generate rich content without much waiting? (I wonder how long it takes to upload stuff, or to save on disc.)

Maybe the points you mention are also a typical difference of console vs. PC games culture.
You know, console players just mashing buttons and eating chips, while PC master race dictating armies and building civilizations. :)
 
Power differential probably does exist but with most games appearing on both platforms, I struggle to see how a significant technical deficiency on one platform would result in anything other than both versions of the game being largely coded to the lowest common denominator. Level design, ai, basic user interface all will largely be interchangeable.

We will see differences in power show up with RT, fps, texture quality, loading times and resolution but fundamentally games on platform A versus B will be more similar than not.
 
This thread gets boring without new rumors. Here's one of a supposed ubisoft dev talking about for honor 2 and how the new hardware allows for battles on a different scale etc.:

http://boards.4channel.org/v/thread/493868810

This is what he had to say about the consoles:

on next gen i can say they are pretty much same and thats good. PS5 SSD is kinda faster but i assume thats for some OS feature that is not available to us currently.
 
I'm curious which access pattern is better: lots of small files fast, a few large files slow. From what I understand a lot of nvme ssd latency comes from queuing IOPs, which occurs when you get collisions from trying to two or more pieces of data on the same NAND device.
In a conventional setup, yes. Mark Cerny has made big on the whole stack - storage, I/O and software working differently. We've seen patents (EP 3 561 678 A1) for a custom Sony SSD controller that arranges data differently so writes, addressing and reads are faster. The differences are intended to boost throughput. On most devices (PCs, consoles STBs) we fundamentally still address information on SSDs as we do HDDs and that makes no sense. I assume this is what Mark Cerny was getting at when he said "The raw read speed is important, but so are the details of the I/O mechanisms and the software stack that we put on top of them".

The controller is as important as quality of the NAND array itself.
 
I'm still trying to reason on how having fast drives is going to shape up this gen.

The big question is if you were to have a drive that had infinite throughput, what would bottleneck your reads first: cpu, gpu, available RAM, bandwidth, optical disc capacity. Assuming the PS5 specs are real, ~9 TFLOPs RDNA, with something like 500 GB/s bandwidth and an 8-core Ryzen CPU around 3.6 GHz (no idea what the leaks are saying), what's the limit?

Starting at the optical disc, everything has to fit on disc. There are time and budget constraints to producing content (models, animations, textures, sounds) and there are limits to how much the data can be compressed. Once it's on your SSD, you have limits in terms of decompressing the content, which could impact the CPU or require a secondary processor to handle decompression. Assuming your cpu or decompression can work fast enough, bandwidth should not be an issue except for bus contention. Both the CPU and GPU are contending for memory, so you can't just hit the SSD non-stop to write into RAM.

Then you have to consider that everything has to fit into RAM. The SSD isn't going to be fast enough to unload everything that's not visible. You can turn a 180 degree view in a frame. So at 30 fps, with an infinitely fast drive you would never have to worry about streaming in an entirely new set of meshes, textures for all of the things within your view. In reality you'll probably be able to read 230 MB/frame max (assuming 7GB/s) drive, but whatever is read won't be decompressed instantaneously, so you probably have some fraction of 230 MB/frame (7 GB/s * 0.033s) multiplied by whatever your compression ratio is (assuming you can decompress within 33ms). I don't know what those numbers would be. There's some limit to how much data you can swap on the fly within a frame. Then you end up back into a coarser streaming scenario, where you're back to streaming in tiles with a caching strategy.

Then you have to understand what the occupancy of your memory looks like. You have 16GB of RAM, minus some system reservation (or maybe not if there's dedicated system memory). Within the game engine there's going to be some percentage of RAM that's lost to the things that we cannot see on screen or hear. It should be on the very small side, but it is a loss. On top of that you need to track things persistently in most games. So the character that walks off screen needs to be there if you turn around. The world simulation does not end outside the view port (in most 3D games). It may be reduced, but not erased. So for every ai, sound, physics object, statistic, the state must remain even if you do not see it on screen. If you increase the density of your world tiles, you're reserving more RAM for the things you can't see yet. Yes there's LODs and whatever, but it's pretty clear that even with an incredibly fast drive, there's going to be some limit to how much data you can stream in per frame, so they'll still have to worry about keeping things resident in memory ahead of its use. There are probably other things to consider in terms of what could actually fit in RAM, but that's what comes to mind off the top of my head.

As for the gpu and cpu, almost everything you'd want to increase in visual density will come with other costs in terms of physics or ai. Unless we get the same static games we always got, you'll have to have some combination of physics and intelligence for every new object you add into the scene. On top of that, you can't just add infinite meshes into your scene before the gpu starts to choke because it hits some kind of vertex processing limit. Something like Nvidia mesh shaders could help massively here. CPU and GPU could both be responsible for physics. Ai is probably still on the cpu, but we've seen a large bump and not all games require huge numbers of ai actors or sophisticated ai.

It'll be really interesting to see what developers come up with, because I think this will be the first time that streaming performance from the drive will not be a huge bottleneck. We went from slow optical discs to 20 MB/s to now potentially many GB/s.

Oh, and I've never mentioned the impact on cpu and gpu caches.

Such a Console is full of Limitation from 9Tflop to 16 Gbyte Ram and a 256 Bit Bus, a Shame for a multi billion Dollar Company.
 
...in AAA games. There are a few indie games already with massive levels of world (pretty much all are open world games) persistence and base building on the level of player made towns and cities.
And none have the scale or density as the open worlds of GTA or WACTH DOGS. Its' easier to manage persistence when you're juggling 100,000 fewer things in realtime.
 
Status
Not open for further replies.
Back
Top