Velocity Architecture - more than 100GB available for game assets

It's the SSD coupled with compression. It's not truly instant; that's impossible (heck, even DRAM isn't instant, but the data access here will be orders of magnitude slower than DRAM). You'd need something like Intel's Optane to approach 'instant' load speeds. However, for streaming it'll be fast enough that you can cache relatively small amounts and effectively stream 100 GBs on demand.

PS5 will manage the same. PC will be able to manage the same at some point but not yet and there's no clear roadmap to enable these super low latency data-streamed solutions.

 

No, there are a ton of bottlenecks. It's essentially a 100Gb swapfile for games. PS5 has a faster implementation - because the SSD/controller is faster.

 

From my understanding that special 100GB area on the ssd will be entirely mapped and the apu will know exactly what asset are where automatically, similar to what was explained on the whole ssd for the PS5.
Sort of, at least.

 

It might solve a small latency in accessing certain data on the SSD. It won't speed of SSD transfer or any of the rest of the memory topology limits. As I understand it, it's more about making the developers' life easier by giving them a single access method for RAM and storage to make streaming seamless.

 

There's always a going to be a bottleneck. If you remove one another will appear somewhere else, but hopefully you'll have raised performance in the mean time.

It's perfectly possible to ask for more from the SSD than it can give you. The interesting things are i) under what circumstances will that happen and ii) what happens then?

For general movement in most games I can think of, I expect that the speed will be fine particularly if you're only loading in texture pages that you need. Fast travel, or maybe camera cuts between locations will probably require a pause if you haven't planned to do this seamlessly. But even on something as fast as the PS5 this still couldn't be instant. Maybe a Superman game or some trippy dream sequence or Sonic jumping between worlds through player triggered jumps would be able to really highlight the difference between SSD speeds, but this wouldn't be typical of most gameplay.

One of the cool things about XSX is Sampler Feedback Streaming. Sampler Feedback makes it possible to far more accurately know which texture pages you actually need and when, and the "Streaming" part particular to Xbox allows for texture loads that didn't make it in time to be blended in over the old mip-map to disguise the lod transition. I fully expect workloads that really push these new SSD to be highly variable in terms of requirements and often quite bursty, so anything that allows the system to automatically "catch up" without any impact to performance is a Good Thing.

PS5 SSD is a beast, no doubt about it. But I'm still expecting really good results from MS's setup, especially in general case movement around environments.

 

This part is really important and doesn't get enough play, IMO.

 

Part of the biggest wins this generation is the amount of polygons and textures that aren't created in the first place.
added: The Potemkin Villiaging of games is going to be a big win

 

The hardware is important but so is the software stack i.e. the OS.
On pc even fast ssds/m.2 storage is hugely limited by the OS.
The velocity engine is also about rectifying that.

 

Guacamelee has parallel world built into it's platforming system so maybe there is a gameplay addition that could be innovated there.

 

I think a more interesting question is how large of a scratch pad do we need for next generation consoles to deliver the type of experience gamers would expect.

Obviously the answer is dependent on the type of game but probably a good baseline could be approximated using current generation as a guide.

My hunch is this is precisely what Sony did to arrive at the requirements for their SSD implementation.

 

I don't think those approximations can ever work. That'd be like looking at how much GPU power is used this gen and scaling, or how much RAM and scaling. Devs will expand their workloads to use all available resources. The maximum limit on resources is infinite, so you'll never have an excess of something in isolation. It's only an excess if the system is imbalanced and can't use that resource. I think Sony went with 'as fast as possible' not because it was considered a balanced design, but because they felt there isn't an upper bound in usability based on the rest of the system resources and the more they could chuck in to begin with, the better the long-term value of the storage solution. So the mandate for the SSD was exactly the same as for the GPU and the CPU and the RAM - as much as possible.

 

Have to admit I never viewed it as a scratch pad per se.
As in its empty and the game uses it to read and write to.
I saw it as an extension of the page file, and the game installation would just be mappped to it.
Sure you could wrire and read to an unused memory location (ssd), but I see it as another method to access game data.

 

Although as you pointed out, it can become excess if other parts of the systen bottleneck it. Not sure if I'd use term excess, more so inefficient maybe?

 

Less than 9.5 GB of Ram.

 

The controller/ssd is faster, but the xsx has other tech as described by function to make up for it, or close the gap. They took different strategies for different reasons to achieve what they wanted.

 

Almost all software based. Cant be compared in hardware efficiency and results.

 

There's hardware blocks involved in the velocity structure, and as you say, software is just as important as the hardware. See the PC side of things regarding SSD's.

 

Yes, the decompressor is a hardware block as said before. The lack of other IO hardware takes you from the 100% SSD speed to the 20% real result. See Cernys slide. No software can overcome that 80% without eating many CPU resources.