He's PR'ing the hell out of his tech! Here is the blurb direct from Microsoft about SFS:
You still haven't explained, if the RAM is being bypassed, how GB's of data fits in KB's to MB's of GPU cache? It doesn't make sense to me but I'll continue to hope a dev will chime in and explain all in a clear way we all can understand.
To clarify... The RAM is not being bypassed all the time. If that was the case, you would have no RAM at all, but only SSD and the APU. This is clearly not the case. RAM is still needed, because the SSD is still too slow to be used as RAM for everything.
Obviously you cannot fit GBs of data into a small cache. Cache doesn't really hold "files" either. They hold snippets of data that are accessed the most, with a certain level of hierarchy.
Going back to the whole bike & car thing... Look at it this way...
You have 100 bikes.
You have 10 cars.
You want to build a house as fast as possible, and you are currently at the store to buy everything you need.
Obviously you're going to want to put as much building materials as possible in the cars, because they can reach the location faster for the house to be built.
While the 10 cars are full and busy, the bikes can also transport little things to assist the house being built.
They are putting it directly in memory. They are using a pool of memory which stores recently used textures and other data. What the SSD allows them to do is quickly swap data in and out of this pool. Because they can do this quickly, they do not need a lot of data preloaded until it's time for it to be used. This allows them to reduce the size of the pool, not only improving performance but reducing occupancy.
This is all true. And it's the exact same thing that the PS5 will do. But unless MS has been lying, they are doing something different here. And it also shows in the design of the console; the philosophy and priority is quite different.
Now, GPU caches that live within a cache hierarchy (Registers -> L1 -> L2 -> L3) have their data written to depending on the code running on them at the time. The control a developer has over these caches is mainly from the data structures and operations performed on those data structures (i.e:. Aligned arrays of a certain size are more cache friendly, certain types of loops are more cache friendly, adding memories barriers or grouping writes and reads, are more cache friendly). The developer can basically only hint what actually ends up in these caches, they really don't have much to go on.
Agreed.
These caches are also very small. You cannot jump dump texture data into them, especially from an SSD. Your CPU can just dump any cache it doesn't like (usually using some sub-process to scrub cache based on age or usage) , a developer doesn't do this.
Still true.
You cannot put anything into the cache directly, because it always has to be loaded via RAM, programmers do not, in any way, interact with CPU caches. It just isn't something that happens. This is why I can dismiss it so easily.
All was true, but I have to question the bolded part. But I think we've already had this discussion in the past. If the SSD works as a form of slower RAM, what is there to stop the data from being loaded from it into cache?
