Thanks, I appreciate your clarification. So from your description, those textures are arranged into 64 KB portions on the storage itself. The texture is still stored as a contiguous asset but since it's in a format SFS can understand, the system can access the portions needed.
I can see the advantages, for sure. But there are probably some disadvantages as well. For example, any accesses of data to storage still incur magnitudes more latency access than in RAM, which incur magnitudes more than data in the caches. If you're going to be using SFS for parts of a texture that effectively result in the whole texture being used in a given scene (at some point), you're probably better off storing the whole texture in RAM anyway and that's where the advantage of SFS would end (for that particular texture).
If that repeats for a group of unique textures, then you're just better off keeping that group of textures in RAM anyway, rather than incur the access latency penalty of the SSD. I can also see how, at least in theory, the concept of SFS might be at odds with how artists actually tend to make their texture assets; they aren't making them as 64 KB blocks, but at 4K-quality (or larger) sizes. So work on the artist's end stays the same in terms of load.
Meanwhile managing the feedback stack on the programmer's end probably involves a bit of work, and that may explain why SFS isn't being readily used in a lot of games yet. Though I'm sure at least a few games have to be using it, rather on Xbox or PC. I'm still not convinced it totally resolves some of the concerns I listed in the OP though, for reasons I mention in this specific post.
I'm pretty sure Forspoken is utilizing it, at least on PC, since it's also using DirectStorage there. But really, if no game's using these, that's no one's fault but Microsoft's. They should have had their 1P games making use of these things instead of waiting and hoping for 3P to do so.
Don't think this is actually the case. When devs make games for say PS5, they have to use Sony's APIs, because Sony doesn't use Microsoft's APIs or their SDKs. The high-level language that devs might write their applications in runs on all the different platforms, that's true, but for closed boxes like consoles, typically you are using specific APIs and tools designed for that box by the platform holder.
Certain things like commercial viability of the platform versus difficulty in the APIs and tools able to extract optimal performance in a reasonable time frame can impact the rate of adoption, but this is Xbox we're talking about here. It's not some little add-on like Sega CD or some obscure dead-end like the Jaguar. The brand still sells better than a lot of other consoles, in fact only Sony and Nintendo consoles have generally outsold Microsoft ones. When you consider all of the platform holders that have been in the industry (Sega, NEC, Matsushita/Panasonic/3DO, Atari, FM Towns, Phillips, Apple, etc.) and the gap between even the best selling consoles among some of them and the lower-selling Microsoft ones, it's a pretty big gap.
If something's not being used, chances are it's because the opportunity cost is not worth the headaches in working with getting optimal performance. What you're suggesting, I think, is misguided because having APIs and tools that scale to a wide net of configurations actually seems like it causes problems in settling on very specific approaches that target one particular hardware spec to optimize for it to get the best performance. Which is something Digital Foundry were touching on in their latest podcast.
Maybe it's too high, maybe not. It's not just about CPU tapping the RAM for data to calculate on the game's end. If the CPU needs to be used for helping along transfer of data from storage to RAM or vice-versa, that's also time spent occupying the bus. As it's doing so, the GPU won't be able to access RAM contents.
It's a bit more of a sticking point for Series systems because I don't think they have off-chip silicon with DMA to the RAM the way the PS5 does. If they did I think we'd of learned of it at Hot Chips a few years ago. So at the very least the CPU for Series consoles is more involved in that process.
As so, maybe you're right that my example is too high on CPU and audio's end accessing the bus, at least in terms of doing so for game data to be processed (and only processed, not moved in/out of RAM <-> storage). But my main intent was to look into situations where Series X would need more than 10 GB of data to access, and if so, any data in the slower pool would drag down effective bandwidth proportional to the amount of time data in that slower pool is being accessed.
The thing is, that is going to vary wildly from game to game, and even situation to situation, moment to moment. I'm just exploring a possibility that could become more regular as the generation goes on. The worst-case you bring up assumes the CPU is only occupying the bus for maybe 7.5% of a given second. But then say there's a situation a game needs 11 GB of data that is GPU-bound, and the last GB may need to be accessed say 33% of that time. It still creates a situation where total bandwidth is dragged down, and in that case, it'd be by a lot more than the CPU itself.
You probably still get a total bandwidth higher than PS5's (I got 485.2 GB/s), but how much does that counterbalance PS5 needing to access RAM less often because of the cache scrubbers? That it doesn't need the CPU to do as much heavy lifting for cache coherency because it has dedicated silicon that offloads the requirement? Stuff like this, I think should be considered as well.