Of course it doesn't and I never claimed this. I am talking about system latency from storage to VRAM.
I never said it can or will replace VRAM. I am strictly talking about latency from storage to main memory. It's also strange for you to describe tech that serves to reduce latency a "nice trick".
You keep mentioning latency while ignoring earlier posts that have specifically explained why there should be no appreciable latency difference between a PC and PS5 in getting data from SSD into VRAM. And in fact how their can be considerably less latency when properly using the sys RAM to pre-cache data from the SSD.
It absolutely increases effective bandwidth because effective bandwidth considers latency into the equation. Games like Demon Souls, Ratchet with specific portal transitions, and Last of Us Pt. 1 would be impossible to run on PS5 at that level of fidelity without the hardware decompression; the CPU would get demolished. Perhaps you meant to say "it doesn't do anything to increase bandwidth" - and my response would be: I never said it did.
Ok, so we seemingly now agree that the decompression block does nothing to increase the PS5's peak IO capability. But what it does do, is offload work from the CPU, meaning that when used, there is more CPU power available for other things when data transfers are taking place. So as a system, it does increase the PS5's overall capability.
So I hope that you can agree that if the work being done on the PS5's decompression block were to be done on some other unit in a PC that has a sufficient surfeit of performance vs it's PS5 counterpart, then that would not result in any specific peak IO performance advantage for the PS5 vs said PC. It would however give the PS5 an efficiency advantage in terms of the level of compute resources needed to reach that peak IO performance.
General observation - It is very strange to see people's excitement about the future possibilities of DirectStorage, while simultaneously downplaying the PS5's i/o architecture.
I don't think anyone here is downplaying the PS5's IO at all. Everyone is quite aware of how it works and what it can do. The issue is with it being overplayed relative to what PC's can be capable of (seemingly based on a single bad port) and because this is a technical forum which deals in facts rather than hyperbole, you get people trying to restore technical balance back into the discourse. At no point for example has anyone challenged the PS5's peak throughput of ~11GB/s (with RDO), or the fact that it's decompression block offloads the decompression work from the CPU which potentially frees up a lot of CPU performance, or how relatively easy the PS5 is to develop for.
The issues start when people begin using the above facts to make misleading or outright inaccurate claims about what "can't be done on PC's" because of "fundamental architectural inferiorities" while ignoring technologies in the PC space that address those shortcomings and alternate way's of doing things on the PC which are better suited to it's particular architecture.
You're wrong and I would be mildly surprised if many others here agree with you on this. I don't care if you have 1,000gb of VRAM, preloading would still be a wasteful practice if you had a capable memory subsystem and engine to ensure data can be sent to VRAM when it's needed. You talk as if memory, specifically VRAM, is infinite. As if decently spec'd GPUs haven't been incapacitated by sizeable increase in VRAM requirements. At the core, the idea behind PS5 i/o is to ensure the GPU is the bottleneck and not the ability to move data around as needed. You need not look further than the 3070 to determine whether this was a smart design choice.
You seem to be operating under the misapprehension that the PS5 does not need to cache data in VRAM/main memory. And that it's IO is fast enough to call data directly from the SSD when it's needed by the GPU. That's wrong. The bandwidth and latency from the SSD are no where near sufficient to allow this, and the PS5, just like the PC needs to anticipate what will be needed and then pull data in from storage to cache it in VRAM ready for it to be brought in from there into the GPU's caches and ultimately registers to be worked on.
Obviously the faster you can bring data in from storage, the less you have to cache, for a given scenario, but you're still going to be limited to what is available in your VRAM (and GPU's caches at any given time). For example if the PS5 had 200GB of VRAM and could literally store the entire uncompressed game in VRAM, that would open possibilities that simply aren't available to it in it's current form.
Your comments above about the 3070 are a great example of your misapprehension. The issue with the 3070 is nothing to do with IO, it's to do with it's lack of VRAM. The 3070 can bring data into it's VRAM from system memory far faster than the PS5 can bring data into it's VRAM from the SSD. Yet when it runs out of VRAM, that doesn't help it, and the same applies to the PS5 which is why having larger caches closer to the GPU is always a good thing
Oh I see now, you're talking about system RAM. Well since you've already written me off as some sort of die-hard console fan, perhaps you will accept the messaging if it's coming from the Godfather of Digital Foundry, for which this thread is dedicated to:
I'm really not sure what you're trying to say with this. Remji was talking about the benefits of having more VRAM (which in the PS5 is equivalent to it's unified ram) and yet you're linking to a video explaining why System RAM can't replace VRAM?
That video is literally reinforcing what he's arguing because it's saying you can't replace VRAM with a larger, slower memory pool further up the IO chain..... you know... like an SSD. So you still need that fast VRAM to cache data, and if you run out of it, the larger slower pool isn't going to be able to substitute.
You can however speed up how quickly you can get data into VRAM which in turn reduces the amount of data you need to cache in VRAM. The PS5's IO can do that pretty quickly. The system RAM in a PC can do it even faster. What Richard is saying though, is that it still doesn't replace the need to have enough VRAM for whatever you're trying to render.