I'm sure Sony would have quoted the higher peak number if it was realistic especially when they did so for the GPU and CPU speeds.
Don’t those scenarios still miss very crucial information like what type of format it is being talked about? Texture can be compressed to like 8:1(without Alpha) audio 200:1. Your capability will appear to be much bigger if you are talking about a peak performance using less demanding format (audio) than more demanding texture. So we are really missing the context of “in some instance reached 22GB/s.” It could even be talking about textures or mixed data, we just don’t know until we see more in depth information on both consoles to be able to put it into context of what’s possible.From what dobwal is saying, the number (22 BG/s) is the performance of the data, not the processor. There's no point saying your processor can handle 25 GB/s theoretically if it'll never receive data fast enough to decompress that much.
So it could be that there's two stats:
The decompression block is capable of processing 25 GB/s
The amount of data coming out of the IO system through the decompression block is up to 22 GB/s
The former isn't as meaningful as the latter. I don't know where dobwal gets this info from though.
different strong points for two different approachs, UE5 and others engines can use both no needs to SSD-war on internet forums.
Yeah, Mark Cerny said:They did. Cerny stated the figure when giving the tech talk.
They did. Cerny stated the figure when giving the tech talk.
So Cerny stated 25-27 GB/s and not the 22 GB/s figure?
He's talking about the current data games use. Audio is already compressed with MP3 or OGG or somesuch. Textures are already compressed DXTCs. These are the files being transferred that are seeing up to 4:1 compression with Kraken. Raw text files likely get well over, and are meaningless examples in a talk designed to describe the system. That's why Cerny stuck with ball-parks for real-world data - 8-9x typically, up to 22 GB/s. I guess conceptually there's a real hardware limit 4:1 on the decompressor, so perhaps, 22 GB/s is the literal hardware limit and a plain text file compresses down only 4:1, but I think that very unlikely.Don’t those scenarios still miss very crucial information like what type of format it is being talked about? Texture can be compressed to like 8:1(without Alpha) audio 200:1. Your capability will appear to be much bigger if you are talking about a peak performance using less demanding format (audio) than more demanding texture. So we are really missing the context of “in some instance reached 22GB/s.”
So Cerny stated 25-27 GB/s and not the 22 GB/s figure?
I was thinking it could be the ASIC having a 4:1 local buffer size ratio. So if the data goes above 4:1 ratio it's the block input cycle that stalls, because it needs two passes to decode more than 4 times the input block size. So it creates a cap of 4x the data input rate, and they would have sized the input rate of the ASIC exactly what they need, which their design goals was 5GB, and the final product was 5.5GB.He's talking about the current data games use. Audio is already compressed with MP3 or OGG or somesuch. Textures are already compressed DXTCs. These are the files being transferred that are seeing up to 4:1 compression with Kraken. Raw text files likely get well over, and are meaningless examples in a talk designed to describe the system. That's why Cerny stuck with ball-parks for real-world data - 8-9x typically, up to 22 GB/s. I guess conceptually there's a real hardware limit 4:1 on the decompressor, so perhaps, 22 GB/s is the literal hardware limit and a plain text file compresses down only 4:1, but I think that very unlikely.
So you are saying that Audio is already sitting on Disc in MP3 format or something like that and gets further compressed 4x by Kraken? I didn’t think of it like that because I read somewhere how over the years audio and textures have grown and their proportions. They were saying that sometimes up to 60% of entire game data is uncompressed audio files. My thought was that if it’s raw audio file it would be compressed something like 8x, texture would be compressed 1.5x using Kraken for PS5 game disc and using Zlib/BCPack for XSX with plus/minus set compression profiles. Then you have different game sizes due to different compression algorithms for each and everything on SSD sits in compressed state as opposed to uncompressed/lowcompressed current gen. When file is needed it is hwdecompressed into ram using the dedicated engine, amount of uncompressed data reaching ram is your bandwidth. When wanting to suspend a game and launch the next one your entire game data loaded in ram is compressed again into the temporary manner on SSD.He's talking about the current data games use. Audio is already compressed with MP3 or OGG or somesuch. Textures are already compressed DXTCs. These are the files being transferred that are seeing up to 4:1 compression with Kraken. Raw text files likely get well over, and are meaningless examples in a talk designed to describe the system. That's why Cerny stuck with ball-parks for real-world data - 8-9x typically, up to 22 GB/s. I guess conceptually there's a real hardware limit 4:1 on the decompressor, so perhaps, 22 GB/s is the literal hardware limit and a plain text file compresses down only 4:1, but I think that very unlikely.
It was my understanding the XSX SSD is 2.4GB/s (Raw), 4.8GB/s (Compressed) and the "over 6GB/s" referred to the speed at which the decompression block ran.
What is unclear to me at this point is whether or not the 4.8GB/s Compressed figure is a hard limit somewhere in the I/O pathway and the decompression block's >6GB/s simply provides overhead. Or if it is an average and the entire pathway can actually move >6GB/s end to end in ideal circumstances. I'd hope and assume it's the latter for the sake of Xbox devs and end users.
If it is the latter; I'm surprised MS didn't capitalise on it and state "2.4-6GB/s", or more honestly "2.4GB/s (RAW), 4.8GB/s (Average Compressed), 6.0GB/s (Peak Compressed)"..... saying that, their official spec sheet only says 12TF when they have 12.15TF, so perhaps they're playing it a little more reserved.
Regarding Sony and PS5, the way it was worded makes me pretty sure it's 5.5GB/s (Raw), 8-9GB/s (Average Compressed) & 22GB/s (Peak Compressed); that 22GB/s being peak end to end throughput in what are likely very rare circumstances and as a result of a limit in the decompression block. Cerny said "..the unit itself [kraken decompression block] is capable of outputting as much as 22GB/s if the data happened to compresses particularly well".
-------
Now for a bit of levity, according to youtube closed captions -- while checking for the quote -- it turns out the unit can move over 5GB of crack a second; not to mention "format input data"..! =P
the unit itself [kraken decompression block] is capable of outputting as much as 22GB/s if the data
He's talking about the current data games use. Audio is already compressed with MP3 or OGG or somesuch. Textures are already compressed DXTCs. These are the files being transferred that are seeing up to 4:1 compression with Kraken. Raw text files likely get well over, and are meaningless examples in a talk designed to describe the system. That's why Cerny stuck with ball-parks for real-world data - 8-9x typically, up to 22 GB/s. I guess conceptually there's a real hardware limit 4:1 on the decompressor, so perhaps, 22 GB/s is the literal hardware limit and a plain text file compresses down only 4:1, but I think that very unlikely.
@RDGoodla They actually say over 6 GB/s, but I imagine if it were much more than that they'd said 7 GB/s or whatever.
That's why Cerny stuck with ball-parks for real-world data - 8-9x typically, up to 22 GB/s. I guess conceptually there's a real hardware limit 4:1 on the decompressor, so perhaps, 22 GB/s is the literal hardware limit and a plain text file compresses down only 4:1, but I think that very unlikely.
If PS5 can only render 1440p for UE5 demo, Xsx may only render 1550p~1600p images.
XSX might go for higher settings instead of higher resolution, or a combination of both.