The two things that have been bugging me a little about the hardware side of things with XsX and PS5 is the importance of bcPack to XsX for consistent compression/throughput – with it being built into the texturing units and predictable compression because it is lossy– and the constant vagueness of compression expected from the IO complex in the PS5 – which then just gets discussed as being 5.5GB/s (IMHO)..
As much as I'm completely behind the benefits of 360 audio from the Tempest Engine in PS5 games, I have this nagging feeling that a compression R&D arms race has already began between the two consoles and the Tempest Engine will be repurposed in multi-platform games to provide BcPack support on PS5. So even though the XsX will be much higher latency and less efficient with its 2 CPU cores trying to do the work of the I/O complex, overall throughput will still be important contest for loading times.
For example, I could see on the Xbox side BcPack being used with other tricks to up the throughput by heavily compressing a texture signal at 8:1, then measuring the noise/error of that signal to create a texture for that error signal. If the error texture was then independently compressed, either by minification, zlib or even higher BcPack compression ratio – or some combination of those methods – then reconstruct of the BcPack texture from the signal texture and error texture could be achieved on the GPU with minimal overhead and probably result in a 5 or 6 to 1 compression without the peak errors of such a high lossy compression ratio..
On PS5 side of things, I could see Playstation mimic bcpack – as previously mentioned using Tempest Engine – but I could also see playstation's SDK provide options to manipulate or interleave the data (blocks) sent to kraken in optimal ways (chosen from a list of algorithms) so that kraken always yielded more than 2:1 compression – with the only downside being that the Tempest Engine would then be needed to reverse the garbled decompressed data (blocks) for the data to be usable..