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

Status
Not open for further replies.
@Silent_Buddha I think his point about guaranteed 2.4 GB/s is that it can't be for random accesses. That will likely be something around 800 MB/s because of how NAND-flash SSDs work. So the guarantee has to be something like sequential reads.

Normally this is true. But with MS redoing the entire storage interface stack from hardware through to software, it may not be the case. This isn't something that can be compared to anything in the PC or Linux world outside of very specific data center applications. For example, I think it was a Baidu data center that has been experimenting with NVME drives without controllers where performance characteristics for the NAND drives were DRASTICALLY different from any commercially available NVME drive.

Random access on PC is hampered by the OS not knowing where any given file is located. Hence time is required to locate the file prior to retrieving it. If the OS knows the location of every file in a given game when the game is launched, it's possible to bypass this and just directly transfer the file without having to search for it when the game asks for that file.

TL: DR - SSD performance on PC is hampered by the fact that the storage system and SSD controllers are designed around legacy rotational HDD protocols. Get rid of those and performance characteristics will be much different.

Regards,
SB
 
Last edited:
Normally this is true. But with MS redoing the entire storage interface stack from hardware through to software, it may not be the case. This isn't something that can be compared to anything in the PC or Linux world outside of very specific data center applications. For example, I think it was a Baidu data center that has been experimenting with NVME drives without controllers where performance characteristics for the NAND drives were DRASTICALLY different from any commercially available NVME drive.

Random access on PC is hampered by the OS not knowing where any given file is located. Hence time is required to locate the file prior to retrieving it. If the OS knows the location of every file in a given game when the game is launched, it's possible to bypass this and just directly transfer the file without having to search for it when the game asks for that file.

TL: DR - SSD performance on PC is hampered by the fact that the storage system and SSD controllers are designed around legacy rotational HDD protocols. Get rid of those and performance characteristics will be much different.

Regards,
SB


As far as I've read there are physical limitations to NAND flash because of read collisions that the memory controller has to queue. They'd have to have come up with something pretty remarkable to get Optane-like performance for random reads on their drive. I did the reading a while back when the rumours first started about the consoles having custom nvme drives, so I may be wrong, but I don't think even gen4 nvmes can reach that kind of performance right now.
 
As far as I've read there are physical limitations to NAND flash because of read collisions that the memory controller has to queue. They'd have to have come up with something pretty remarkable to get Optane-like performance for random reads on their drive. I did the reading a while back when the rumours first started about the consoles having custom nvme drives, so I may be wrong, but I don't think even gen4 nvmes can reach that kind of performance right now.

Basically no current non-console NVME drive will be able to match what MS and likely Sony will be able to do. Just like no current NVME drive can match what Baidu (I hope I'm getting the company correct) has been doing with their experiements with controllerless NAND based NVME drives.

All current consumer NVME drives have controllers that have to deal with storage APIs that are designed around the characteristics of rotational HDDs.

That said, it's always possible that Andrew Goossen didn't intend for guarantee to apply to random reads, however, considering their aspirations WRT games reading directly from SSD instead of memory for some texture accesses, I find this doubtful.

Regards,
SB
 
Last edited:
As far as I've read there are physical limitations to NAND flash because of read collisions that the memory controller has to queue. They'd have to have come up with something pretty remarkable to get Optane-like performance for random reads on their drive. I did the reading a while back when the rumours first started about the consoles having custom nvme drives, so I may be wrong, but I don't think even gen4 nvmes can reach that kind of performance right now.
Xbox isn’t a typical OS however. They want all their game data packed tight and packed very specifically for high performance. It’s entirely possible that random reads are seldom ever used unlike typical windows usage.

extending that thought; Xbox has its own file system. So it should not be writing it’s data everywhere of performance is important.
 
Xbox isn’t a typical OS however. They want all their game data packed tight and packed very specifically for high performance. It’s entirely possible that random reads are seldom ever used unlike typical windows usage.

extending that thought; Xbox has its own file system. So it should not be writing it’s data everywhere of performance is important.

If they're using it to stream pieces of textures on a per-frame basis, I really don't see how that's possible.
 
Consider today's console situation;

Once it's loaded into resident memory, it shouldn't be accessing the hard drive.

And that can be accounted for in most games, linear story games where graphics are the focus, they are streaming new textures in as you progress forward to the next area and they bog you down with QTE.

For fast twitch MP games, the quality of everything is generally lower to load everything into memory for fast arc changes. But they can still do things like limit your FOV, running speed and turning speed.

Provided you're in a specific area the developers can theoretically recopy textures in related blocks of the drive to be picked up with surrounding textures.

Apparently with SSD we won't need to do that anymore, duplication will no longer be necessary because it's fast enough, in theory. And if it's not fast enough, you're just going to do what you've always been doing for consoles anyway.

anyway, if the read speed is good enough, confirmed or not etc, we should expect game installs to drop in theory through the removal of asset duplication.
 
Normally this is true. But with MS redoing the entire storage interface stack from hardware through to software, it may not be the case. This isn't something that can be compared to anything in the PC or Linux world outside of very specific data center applications. For example, I think it was a Baidu data center that has been experimenting with NVME drives without controllers where performance characteristics for the NAND drives were DRASTICALLY different from any commercially available NVME drive.

Random access on PC is hampered by the OS not knowing where any given file is located. Hence time is required to locate the file prior to retrieving it. If the OS knows the location of every file in a given game when the game is launched, it's possible to bypass this and just directly transfer the file without having to search for it when the game asks for that file.

TL: DR - SSD performance on PC is hampered by the fact that the storage system and SSD controllers are designed around legacy rotational HDD protocols. Get rid of those and performance characteristics will be much different.

Regards,
SB
Load times on PC are also hampered by the fact that in many games - machine code such as shader binaries are being compiled during these loading screen. Whereas with consoles game makers can ship a handful of shader binary "blobs" on the disc/download for the various models (eg X,S) and various render modes (eg quality mode & performance mode), and then install them onto the HDD/SSD. On PC this GPU machine code isn't precompiled due to the countless GPU architectures, driver revisions, and graphic setting possibility in any given scenario as it creates countless thousands of possible shader 'blob' permutations that devs would need to precompile taking up TBs of data.
Some gpu vendors and some game devs allow for shader caching so long as settings, hardware and drivers arent changed. Then the shader cache can be accessed reducing load times on the 2nd play through.
 
http://industrial.adata.com/en/technology/74

What's the logic in having tiered storage with faster SLC but then you can only use it for writes? Your claims don't make much sense to me.

Because those things don't do what you think they do. The link you posted is about using exactly the kind of cheap commodity flash I am talking about, but using part of it as SLC instead of TLC to help buffer writes.

It's a write/read cache in the sense that if there is some data that is currently in the slc portion, reads will be served from it. However, nothing will ever be written to the slc just to make reads faster, because reads from it are in fact not any faster than reads from the TLC part. The reason the cache exists is that the garbage collection system used to keep eraseblocks clean is very slow, and so if you provide a linear log/buffer to write to, which you then write back to the main pool when you are able, you can serve random writes a lot faster. And having that buffer be SLC helps make writes to it faster, and reduces wear concerns. All of this is irrelevant to a console, because only read speed really matters.

It means something impossible AFAICS. You can't just guarantee a minimum 2.4GB/s on solid state storage.

Sure you can, you just cannot offer an interface that makes 2.5M 1byte files possible. For example, force aligned transfers with 64kB minimum. I think this is extremely likely, because that's the block size of modern commodity NAND. I think their new DirectStorage API will in practice be like mmap, but with additional operations possible (such as, this area is compressed on the drive, uncompress it into memory on load), and with a larger than 4kB page size. It's certainly not read()/write() if it's supposed to bring cpu demand down.
 
Did we get any details about the inner workings of the RT acceleration system? The absence of such info among the flood of info covering other parts is not a good sign IMO.
 
Did we get any details about the inner workings of the RT acceleration system? The absence of such info among the flood of info covering other parts is not a good sign IMO.
stock AMD, same as MS. Cerny saw a game with RT reflections with decent frame rate so forget about lighting and shadows.
 
I really didn't expect to have my cake and eat it too with the storage.

5.5GB/s raw
22GB/s uncompressed (max)
10% better compression than LZ
Custom 12ch controller

That's 2.3x raw and 4.6x compressed over xbsx (if we compare max to max figures, real world wlll vary), and they still managed to allow standard nvme expansion. It's not clear how they will deal with the missing QoS queues.

He said the gpu is expected to operate at 2.23ghz most of the time. We are missing real world metric here. What's the average?

Also said they get better performance from fewer CUs at higher clock for equivalent ALU TF sum, because of better occupancy. And he was a strong believer of higher clocks for that reason. (so this was a design goal from the start) Again, missing real world metrics.

It explains why it's complicated to compare performance.
 
Last edited:
No clue and he has wrong numbers there anyway, PS5s numbers are 5.5GB/s raw, 8 - 9 GB/s compressed (which would mean their compression stuff is actually worse than what MS does with DirectStorage but they more than make up for it by offering over twice the raw bandwidth
I have to watch it again, I was reading the CC at work. :runaway:
 
Status
Not open for further replies.
Back
Top