The 6GB/s on the XSX, like 9GB/s on the PS5 is an actual attainable throughput not some theoretical one used for marketing purposes.
- Status
Thank you. All this talk of 22GB/s throughput reminds me of the 2.18 Teraflop PS3 figure. It was honestly not fair to the consumers to spread such information.
SonGoku
Member
Not sure if you are right but you could be since English isn't my native tongue
What i mean by that is 22GB/s is the theoretical max throughput of the decompression block, how close it gets to that depends of the SSD raw ouput and how well data compresses. Typical figures given by Cerny are 8-9GB/s
For what its worth i used the same wording to refer to XSX decompression block max theoretical throughput (6GB/s) as evidenced in the quote of my post you used.
Last edited:
SonGoku
Member
Not sure if you are joking but i don't see what's funny about this. Why mock him for correcting another member?
Ass of Can Whooping
Member
Cerny himself stated that's the limit of the decompression block
The Mad Draklor
Member
So how come 6 GB/s was not mentioned in the actual spec sheet on Eurogamer? It says 2.4 GB/s raw & 4.8 GB/s compressed. The 6 GB/s figure was only mentioned in a quotation.
Stuart360
Member
Slim chance of it happening i know but after all the 'power dont matter anymore, its all about SSD's and speed' talk since the specs reveal, i dont think i'll ever stop laughing if XSX ends up loading games faster. Who knows what they can do software wise over the next 6 months.
SonGoku
Member
6GB/s is the max theoretical throughput of the hardware block, just like PS5s is 22GB/s
There's no PR about this, its describing the physical limit of the respective decompressing blocks
It is you who is using a theoretical limit as a typical figure. When MS already gave the typical compression numbers including BCPack-> 4.8GB/s
Last edited:
You're grasping at straws because in their videos at DF they mention the 6GB/s. On top of it, we still haven't heard other things like the DMA controller in the XSX. A developer working on XSX game engine has mentioned that it has one as well. Let's wait and see what the throughput will be on paper in a month or two.
icerock
Member
It's hilarious to see you guys still feed the trolls, both companies have given out raw, compressed and peak figures for respective SSDs. Why would anyone want to make predictions when that information is already laid bare? Just report them and move on.
And then you have the gall to laugh at Sony fanbois for believing in secret sauce API/Software to help close the 1.8TF gap, go figure.
And then you have the gall to laugh at Sony fanbois for believing in secret sauce API/Software to help close the 1.8TF gap, go figure.
Last edited:
Hobbygaming
has been asked to post in 'Grounded' mode.
That's a good question, it seems like devs are much more hyped to work on the PS5 and there's that whole GDC survey
The 6GB/s is not the theoretical max throughput for the XSX. Thats not true.
SonGoku
Member
Yes as the max theoretical throughput of the hardware decompression block
Stuart360
Member
When?, i didnt even know there was a 'secret sauce' rhetoric going around about that lol.
PaintTinJr
Member
The GPU (hardware) extension that BCpack (Block Compress Pack) will utilise, along with shaders to sample BCpack encoded textures is called DXT, with DXT1 dating back to the time of Quake 3 (IIRC).
The DXT lossless decoder with lossy encoder works on the basis that you offset the loss of data by quadrupling the texture size (or going even bigger), so that a higher precision lossy texture yields better IQ than a smaller lossless uncompressed texture (overall) while occupying the same memory footprint as the lower resolution texture (or less).
Prior to shaders the quality of the lossy DXT textures could be crudely done on the fly by the GPU or exhaustively done with a CPU software encoder that measured error rate while searching for the best end point values (for the line of best fit gradient); and a search to find the best indexs on the gradient to represent the colour values – yielding optimal results.
Since the addition of shaders, quality compression of render targets can be achieved in real-time at little overhead, making DXT compression(along with 3Dc) well suited to being used and created at runtime for use in games. Despite widespread differences in how DXT compression gets used in a game by game basis, the simplicity of the decoder remains consistent with all previous decoders – with changes of use being handled in shader programs – making any technique compatible across the widest range of GPUs, and with room to improve beyond the current usage. Back at DX9 or DX10 Microsoft added their own Direct3D Block compression formats – both renaming DXT formats in their own list, naming and standardizing superior DXT uses in DirectX, and adding new techniques they wished to be widely adopted.
(AFAIK) none of the techniques that leverage DXT/3Dc require a further royalty to use (although will be interested if that isn't the case), and even if they did, this cost would be middleware library addon small, and probably more to do with using the technique by name.
So, why have I listed all that? Well from a GPU decoding point of view, it is highly unlikely that BCpack (if good) will be limited to XsX use. It is possible that only the XsX would utilise the encoder benefits for in-game render targets if specific ASIC hardware is required to BCpack encode in real-time for cache out render-target BCpack textures to the SSD. But even then, if the benefit was important, PS5 devs would likely take a tiny GPU workload hit for the benefit.
In the Xbox tweets about BCpack compared to Kraken it was mentioned that a Block compressed (DXT) texture would losslessly compress by 20-30% with kraken. Where as the same DXT texture could lossy block compress with BCpack by 50%. Now, the problem I see with this statement as a benefit to IQ, is that 50% is merely a 2 – 1 compression ratio, and by default 4 -1 ratio has been historically been needed(for the texture size increase 2x2) to accommodate the increased errors from lossy compression.
The DXT lossless decoder with lossy encoder works on the basis that you offset the loss of data by quadrupling the texture size (or going even bigger), so that a higher precision lossy texture yields better IQ than a smaller lossless uncompressed texture (overall) while occupying the same memory footprint as the lower resolution texture (or less).
Prior to shaders the quality of the lossy DXT textures could be crudely done on the fly by the GPU or exhaustively done with a CPU software encoder that measured error rate while searching for the best end point values (for the line of best fit gradient); and a search to find the best indexs on the gradient to represent the colour values – yielding optimal results.
Since the addition of shaders, quality compression of render targets can be achieved in real-time at little overhead, making DXT compression(along with 3Dc) well suited to being used and created at runtime for use in games. Despite widespread differences in how DXT compression gets used in a game by game basis, the simplicity of the decoder remains consistent with all previous decoders – with changes of use being handled in shader programs – making any technique compatible across the widest range of GPUs, and with room to improve beyond the current usage. Back at DX9 or DX10 Microsoft added their own Direct3D Block compression formats – both renaming DXT formats in their own list, naming and standardizing superior DXT uses in DirectX, and adding new techniques they wished to be widely adopted.
(AFAIK) none of the techniques that leverage DXT/3Dc require a further royalty to use (although will be interested if that isn't the case), and even if they did, this cost would be middleware library addon small, and probably more to do with using the technique by name.
So, why have I listed all that? Well from a GPU decoding point of view, it is highly unlikely that BCpack (if good) will be limited to XsX use. It is possible that only the XsX would utilise the encoder benefits for in-game render targets if specific ASIC hardware is required to BCpack encode in real-time for cache out render-target BCpack textures to the SSD. But even then, if the benefit was important, PS5 devs would likely take a tiny GPU workload hit for the benefit.
In the Xbox tweets about BCpack compared to Kraken it was mentioned that a Block compressed (DXT) texture would losslessly compress by 20-30% with kraken. Where as the same DXT texture could lossy block compress with BCpack by 50%. Now, the problem I see with this statement as a benefit to IQ, is that 50% is merely a 2 – 1 compression ratio, and by default 4 -1 ratio has been historically been needed(for the texture size increase 2x2) to accommodate the increased errors from lossy compression.
If BCpack is worthwhile it will likely be used ubiquitously in PC/console gaming middleware engines and already supported for 'decoding' by all hardware through DXT/shaders, so wouldn't be a dark horse to offset ps5's CPU free use of kraken via the IO complex. The only comparative part of BCpack in terms of SSD bandwidth is if XsX has a ASIC to 'encode' uncompressed textures to BCpack prior to saving them out to the SSD, and then the benefit is only on the way out of the GPU or for keeping BCpack render targets in RAM
Last edited:
SonGoku
Member
Last edited:
I was surprised Sony didn't go for higher throughput up to 12-13GB/s compressed. But with such high raw read write speeds, they didn't have to. The RAM for games is only about 13-14GB. It seems MSFT can at best hit 6GB/s and they have the time to do it. But at those speeds there are few differences in terms of actual gameplay
You should compare the 6GB/s to the 9GB/s. MSFT has not spoken about any theoretical throughput. All figures they presented are what users will experience. You're grasping at straws and honestly I'm done even responding.
icerock
Member
If you have been paying attention since PS5 Cerny keynote, plenty of Sony fans had their hopes pinned on some secret sauce customization Sony have done to help close the GPU gap. There are certain hardware capabilities no amount of software magic can overcome. It applies to Series X in the instance of always possessing a more capable GPU, the same applies for PS5 with its SSD. So, it was funny for me to see you hope for some secret software magic to make Series X load games faster than PS5.
Both boxes have their strengths and weaknesses (which have been discussed in detail I might add) So its getting tedious to see same repeat concern cycle for one of the new components every week. It adds nothing to the conversation, just more trolling and name-calling, and eventually banning.
Ass of Can Whooping
Member
If users were going to experience 6GB/s they'd have put it in their official spec sheet.
ethomaz
Banned
Last edited:
It's partly implemented in a hardware block. So like SFS, the XSX will have highly custom hardware not available in PCs. PCs gamers will have to buy GPUs with other implementations of SFS hardware built into their GPUs and get extra core CPUs for decompression.
They're still optimizing the compression algorithms because of their software/hardware based approach!! How hard is that to understand? Thats why Andrew Gossen gave out different figures of above 6GB/s.
SonGoku
Member
Different metrics: the former is a theoretical peak the later is a typical figure
What is this?
Andrew Goossen said:
Theoretical max throughput of the hardware decompressing block
For reference mark cerny
Mark Cerny said:
Last edited:
ethomaz
Banned
4.8GB/s.
Ass of Can Whooping
Member
Both consoles are using a software/hardware approach
How do you honestly manage to twist reality this much when all he said was 'our hardware unit is capable of x amount of throughput'. It's not different what so ever to what Cerny said.
Once again, if this was a number they were actually confident in hitting, they'd have put it in the spec sheet.
PaintTinJr
Member
What part is in a hardware block? It is very high risk committing changes to DXT to hardware for decoding in the event artefacts that weren't known about started happening. They also claim they are still working on the algorithm, so that isn't fixed ASIC hardware. If I was a betting man I would be confident that BCpack will work on everything down to the Xbox 360... maybe with a slightly higher decoding cost, and much higher encoding cost on everything but the XsX. The technique that idsoftware did a paper on a decade or so ago, shows that simple DXT hardware is exploited by newer techniques. Fair play to Xbox if they've commited to hardware a very specfic DXT decoder.
Last edited:
I think they are using an API called XBTC in tandem with the decompression block! That was my understanding.
Lossy compression of render targets will waste bandwidth and probably introduce pixel crawl. I don't think it was ever viable.
The 6GB/s number is just an arbitrary number thrown by Andrew Goossen. The XSX compression will sometimes achieve 6GB/s in scenarios of very compressible data, but that isn't the average/typical value. That value is 4.8GB/s, in the official specs sheet.
And yes, 4.8GB/s is already taking into account BCpack, otherwise it would be much lower with just zlib.
And yes, 4.8GB/s is already taking into account BCpack, otherwise it would be much lower with just zlib.
bitbydeath
Member
PaintTinJr
Member
I'm thinking things like cubemaps and shadowmaps you might only want to generate @ 15fps and want as big as possible with as little RAM occupied by them - but I'm not sure if they do those maps without 3Dc. Your point seems very valid.
SonGoku
Member
6GB/s is the max theoretical throughput of the decompression ASIC.
IntentionalPun
Ask me about my wife's perfect butthole
Man how many pages can y'all go back and forth on about compression?
MasterCornholio
Member
If I understand it correctly. If the compression is optimal the physical drive itself should be able to obtain those speeds.
But this is assuming that everything is perfect and should not be considered as the average performance.
Last edited:
I would have believed this if Gossen hadn't said:
"Our second component is a high-speed hardware decompression block that can deliver over 6GB/s,"
I'm giving you the benefit of the doubt that you didn't lie but you just don't know what you're talking about.
THE:MILKMAN
Member
4.8 to 8-9.
As much sounds like a theoretical max. One which we don't know for the XSX and don't even need to know tbh. The 9GB/s is more realistic from Sony. And for now 4.8-6GB/s is realistic for the XSX.
Mr Moose
Gold Member
Press play on the video. "that typically becomes 8-9GB, but the unit itself is capable of outputting as much as 22GBs..." Your 6GB number is their 22GB number.
We have seen the specs, its 4.8GB/s and 8-9GB/s for PS5. These are facts, stop saying it's 6GB/s.
Thirty7ven
Banned
I just think it's amazing that people here are now posting higher figures than MS themselves.
Last edited:
Shmunter
Member
Never owned a Cayenne, but have driven them before. Definitely a big SUV that shrinks around you, handles sporty like a car.Had a Porsche Cayenne in the mid 00's and man there was nothing like it that I drove before or after. What a sweet ride. Such power and stability. Compared to the Range Rover for example, even though it was comfortable, it felt like I was driving a bus
Last edited:
MasterCornholio
Member
Well untill Microsoft changes that number it's 4.8 gb/s. If it was that now they would have already updated it to close the gap with Sonys numbers.
I'm pretty sure sites like Windows Central won't hesitate to update their numbers the moment that Microsoft changes theirs.
Xbox Series X tech specs list
While Xbox Series X hits store shelves later this holiday, we already have a glimpse inside the box.
www.windowscentral.com
Last edited:
I made a mistake earlier of claiming the 4.8 figure doesn't include BCPack. But what we do know is MSFT(James Stanard) is still optimizing their texture compression. The 4.8 GB/s is most likely a lower range. Otherwise we can't take the 4.8 figure as final.
PaintTinJr
Member
What type of decompression is it doing? I'm assuming some form of Zlib if it is attached to the IO for the SSD. BCpack is a form of compression, but as I already mention earlier, its main aim is to allow higher resolution textures (with loss errors) to reside in place of a loseless texure 1/4 of the size. A decompression of lossy textures at the IO doesn't make any sense (IMHO) if that's what they were referring to.
"As much" means that's the max. Unless he misspoke of course. Gossen specifically said "over 6GB/s". I don't think it makes sense even discussing anything above 6GB/s for XSX and over 9GB/s for the PS5.
Mr Moose
Gold Member
Xbox Series X: A Closer Look at the Technology Powering the Next Generation - Xbox Wire
A few months ago, we revealed Xbox Series X, our fastest, most powerful console ever, designed for a console generation that has you, the player, at its center. When it is released this holiday season, Xbox Series X will set a new bar for performance, speed and compatibility, all while allowing...
news.xbox.com
It's 4.8 just the same as it's 8-9 for PS5.
SonGoku
Member
Not the SSD, the SSD can't go over its raw output
6GB/s is the max amount the decompressor block can output in a ideal scenario where 6GB compresses to 2.4GB
uh? how does that change his statement? I only quoted the relevant bit, did the same for Cerny
Why would I lie? you provided the quote before me and its on eurogamer for anyone to see
Yes the hardware block can handle over 6GB that's its theoretical limit.
Its no different than Cerny statement.
Now if you wanna argue over a few decimals we can round it up to 6.5GB/s happy?
Last edited:
- Status