• Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.

Xbox Velocity Architecture - 100 GB is instantly accessible by the developer through a custom hardware decompression block

D.Final

Banned
COD-Mobile.jpg

Welp
 

oldergamer

Member
The people who say the Xbox IO is faster have no idea what they’re talking about and should be ignored. It’s as ludicrous as those saying the PS5 SSD will make PC gaming obsolete. The fact that you’re getting riled up by trolls says more about you than anything.
Not a single person has said the xbox IO is faster, that's not true. This has been 50pages (well mostly) of people trying to figure out what the xbox hardware is doing, and in every single suggestion on what it could be, its more about clarifying if there is a smaller real world difference then what shows on paper. We already know people from MS has said the numbers they put out were conservative when we compared to what sony put out. We just don't know what that will end up like in usage.
 

Vognerful

Member
Your comment is so ignorant I won't even bother addressing most of it, but wanted to add something:

Sony can't make any decent cooling, but Xbox produced a console that basically killed itself because of heat. 50+% fail rates by 2009.

ign.com/articles/2009/08/17/report-xbox-360-failure-rate-reaches-54
My ps3 YLOD disagrees with you.
 

Dodkrake

Banned
My ps3 YLOD disagrees with you.

Ad Hoc statements disagree with you. I never had a smartphone have an hardware fault, doesn't mean all smartphones are fault proof.

Same with the YLOD: less than 7% PS3's by 2009 (still too many compared to other consumer electronics) vs over 50% for Xbox (which shows that they probably fudged QA)
 

Vognerful

Member
Ad Hoc statements disagree with you. I never had a smartphone have an hardware fault, doesn't mean all smartphones are fault proof.

Same with the YLOD: less than 7% PS3's by 2009 (still too many compared to other consumer electronics) vs over 50% for Xbox (which shows that they probably fudged QA)
Doesn’t matter to me what other people faced if my own hardware had to face this issue.
 

Dodkrake

Banned
Doesn’t matter to me what other people faced if my own hardware had to face this issue.
Right, and to end the off topic, what I'm saying is: You or me saying the Fan on the PS4 is noisy or the Xbox had a RROD are both adhoc statements, while statistics translate to actual data we can use to infer and get a conclusion out of.

End of off-topic, my apologies
 

oldergamer

Member
hmmm interesting. I have a feeling any sort of data striping isn't going to be possible, otherwise you could not remove the expansion drive when added. i guess if sampler feedback would work on data before it had to be copied to ram, you could pull some texture data from SSD if it was small enough. This sounds pretty cool. I want to see it in action beyond that AMD demo ( i watched that video and it was a night and day difference ).
 

Bernkastel

Ask me about my fanboy energy!
Larry Hryb:
Yeah. That's ties into something else that we've talked about you and I talked about this in the past is this Xbox velocity architecture. Explain to us what that is, because a lot of folks may not remember.
Jason Ronald:
Sure. The Xbox velocity architecture is really our way of rethinking and re-revolutionizing how an IO pipeline works. There's really four major components of the Xbox velocity architecture. At its core is our custom NVMe SSD. That really is the foundation that everything builds on top of. On top of that, we have dedicated hardware decompression blocks, so that we can stream data off the disk as fast as possible. Then we provide developers with a brand new API called direct storage, that gives them direct low level access to the hardware, so they have a lot more fine grain controls.
Then the real tech brings that all together is sampler feedback for streaming, which actually is really the ultimate solution for game asset streaming, which will really allow developers to work beyond the limitations of technology, and really have instant access to the full collection of assets of their game.
What about Games that take advantage of this technology ?
Announce on Inside Xbox May 2020, this Silent Hill inspired Game will have the player seamlessly switch between 2 worlds.
You should think of The Medium as Bloober Team's largest and most ambitious game to date. The team isn't creating one world, but two: a version of our own, and a reflection of it in the spirit realm. You'll be able to shift seamlessly between the two in The Medium with – Bloober promises – no discernible load times or impact to game performance and graphics, thanks to the power of the Xbox Series X.
 
Last edited:

Panajev2001a

GAF's Pleasant Genius
Reposting it here:

Summary: “I think XVA’s BCPack HW decoder is a HW implementation of something like BC7Prep (but MS proprietary, Oodle does not seem involved there) + standard zlib (XSX is not using Kraken).”, but please read the rest for context and especially the article I quoted there from one of the devs behind it.
 
Last edited:

Panajev2001a

GAF's Pleasant Genius


A lot of interest in how BCPack could work and XVA yet... not even a comment when others find something oldergamer oldergamer Bernkastel Bernkastel :p...?

 

Bernkastel

Ask me about my fanboy energy!
A lot of interest in how BCPack could work and XVA yet... not even a comment when others find something oldergamer oldergamer Bernkastel Bernkastel :p...?

  1. I dont post on the Next Gen Speculation thread, I never have. I dont know what goes on there.
  2. This is XVA thread, not PS5 SSD/Kraken thread, so ofcourse people will talk about the former rather than the latter.
  3. I am not a validation bot.
 

Panajev2001a

GAF's Pleasant Genius
  1. I dont post on the Next Gen Speculation thread, I never have. I dont know what goes on there.
  2. This is XVA thread, not PS5 SSD/Kraken thread, so ofcourse people will talk about the former rather than the latter.
  3. I am not a validation bot.

Hehe, it is not a PS5 SSD thing, but things are related (and I posted the link here earlier as I think it is relevant to this discussion in a non console warrior way). Which is what my point investigating that and trying to understand the information presented.
It is a link in the same forum, not that big of a stretch not posting of tweets without context or to drive a console superiority point either. This thread was not about marketing / hyping XSX over other consoles right? It is a thread designed to discuss info and theories around BCPack and other bits of XVA right?
To talk about BCPack is to talk about Kraken, which is not PS5 proprietary nor it is Oodle Texture... not that you have problems to bring in PS5 in the discussion though. Not sure what your point was there.

The problems with basic zlib (hence it is good to read the post by the oodle engineer describing both Kraken and especialy Oodle Texture) , the problems with Kraken itself, Kraken (or zlib) with Oodle Texture and no GPU decompressor, Kraken (or zlib) with Oodle Texture with an added GPU async decompression...

The latter, imagine a custom encoder (not Oodle Texture BC7Prep, which on PS5 and other platforms needs async compute decoding per block) and imagine instead of having GPU async decoding you build that logic in a HW block... hence the BCPack HW decoder block. There is no word of MA licensing Oodle tech, likely they have their own.

Of course the blog post and tweets linked in the post above connects the dots a bit better than this summary...

The tweets you linked about being the answer to BCPack miss the fact that they claw back some efficiency (need it less as they have a much faster baseline), but for the full hog they need GPU async compute shaders to do per block decoding which BCPack seemingly does in HW. Then again we knew BCPack was more efficient for textures and roughly by how much, but how they were doing that and what it meant in terms of efficiency.

(For textures) Kraken without Oodle Texture << BCPack, Kraken with Oodle Texture ~< BCPack, Kraken with Oodle Texture and BC7Prep ~== BCPack in terms of compression efficiency but it wastes “some” GPU performance decoding the tiles.
 
Last edited:

SaucyJack

Member
Am I missing something, but why is this a big deal?

“So SSD can instantly provide the necessary data (via the Sampler Feedback Streaming) to the GPU without having to go through system RAM.”

On the PS5 side isn't one of the big benefits with I/O pipeline that the SSD can stream data into system memory without going via the GPU?
 

Panajev2001a

GAF's Pleasant Genius
Am I missing something, but why is this a big deal?

“So SSD can instantly provide the necessary data (via the Sampler Feedback Streaming) to the GPU without having to go through system RAM.”

On the PS5 side isn't one of the big benefits with I/O pipeline that the SSD can stream data into system memory without going via the GPU?

Both systems have, compared to PC’s, no difference between main RAM and GPU memory. SFS is a way to manage GPU’s view of tiled resources/virtual textures automatically and prefetch the data (pages) you are likely to need so that they become available to it (these SSD’s could both be used to DMA data straight in the GPU caches, but unlikely that nothing is cached in RAM as cache is meant to reflect GPU‘s coherent view of it).
 
Last edited:

SaucyJack

Member
Both systems have, compared to PC’s, no difference between main RAM and GPU memory. SFS is a way to manage GPU’s view of tiled resources/virtual textures automatically and prefetch the data you are likely to need so that they become available to it (these SSD’s could both be used to DMA data straight in the GPU caches, but unlikely that nothing is cached in RAM as cache is meant to reflect GPU‘a coherent view of it).

Thanks.
 

jimbojim

Banned
Reposting it here:

Summary: “I think XVA’s BCPack HW decoder is a HW implementation of something like BC7Prep (but MS proprietary, Oodle does not seem involved there) + standard zlib (XSX is not using Kraken).”, but please read the rest for context and especially the article I quoted there from one of the devs behind it.

Good


This is XVA thread, not PS5 SSD/Kraken thread, so ofcourse people will talk about the former rather than the latter.

Yes it is. In your very first post you provided tweets with Kraken comparison. For some reason you did on purpose. And in the end all these BCPack crap backfired heavily.
 

martino

Member
(For textures) Kraken without Oodle Texture << BCPack, Kraken with Oodle Texture ~< BCPack, Kraken with Oodle Texture and BC7Prep ~== BCPack in terms of compression efficiency but it wastes “some” GPU performance decoding the tiles.
i want receipt of that :)
we don't even have XBCT for now. It's possible it's worst than oodle alone who knows.
Also in case of crunch codec adding compression on top of it add near to nothing for example
 

Panajev2001a

GAF's Pleasant Genius
i want receipt of that :)
we don't even have XBCT for now. It's possible it's worst than oodle alone who knows.
Also in case of crunch codec adding compression on top of it add near to nothing for example

Hehe, well I assume they went through the trouble of designing a HW decoder for a fixed console platform to get better efficiency than zlib + pre-processing.

I think that kraken itself is not as efficient as BCPack (based on the info we have available), not sure if Sony’s equivalent compressed bandwidth included Oodle Texture pre-processing (if yes, it makes BCPack very impressive compared to zlib, kraken is like 10-15% more efficient than zlib not much more according to Cerny) or not though.

In the case of, admittedly controlled scenarios, Oodle Texture (not BC7Prep) does allow Kraken and zlib to increase compression a lot (reminds me a bit of Apple inverting encryption and compression of app binaries and discovering a good deal more compression efficiency there).
 
Last edited:

Bernkastel

Ask me about my fanboy energy!
Yes it is. In your very first post you provided tweets with Kraken comparison. For some reason you did on purpose. And in the end all these BCPack crap backfired heavily.
I am not saying I am against discussion involving comparisons between BCPack and Kraken, but
A lot of interest in how BCPack could work and XVA yet... not even a comment when others find something oldergamer oldergamer Bernkastel Bernkastel :p...?

Why do I have to validate what he says ?
 

Panajev2001a

GAF's Pleasant Genius
I am not saying I am against discussion involving comparisons between BCPack and Kraken, but

Why do I have to validate what he says ?

You do not have to, but it comes off as that way and thus as disingenuous (especially seeing the content in the thread, even your last quoted tweets... c’mon) and make it as a console thing which is not. It makes it sound like an excuse to hype each disguised as research and discussion.

Take it as zlib vs BCPack, it does not change what I posted and why. You are trying to make it a console fight... whatever... 🤷‍♂️...
 
Last edited:

martino

Member
Hehe, well I assume they went through the trouble of designing a HW decoder for a fixed console platform to get better efficiency than zlib + pre-processing.

I think that kraken itself is not as efficient as BCPack (based on the info we have available), not sure if Sony’s equivalent compressed bandwidth included Oodle Texture pre-processing (if yes, it makes BCPack very impressive compared to zlib, kraken is like 10-15% more efficient than zlib not much more according to Cerny) or not though.

In the case of, admittedly controlled scenarios, Oodle Texture (not BC7Prep) does allow Kraken and zlib to increase compression a lot (reminds me a bit of Apple inverting encryption and compression of app binaries and discovering a good deal more compression efficiency there).
kraken adds ~40% on texture compression (it's why 5.5 -> 9 is representative since texture are most of data).
crunch codec adds 200% or more + (it's why if ms solution is anywhere like it 4.8gb/s is conservative)
(a crunch example in a presentation i linked at least 4x times show a crunch texture is 50%+ of same texture compressed with zlib (kraken add ~10% on that))
But there is a drawback : crunch is lossy.
Ms probably don't want that and in this case the solution could be less impressive than crunch.
For now difficult to see what it will be without the actual info....output of possibilities is still wide.

also all textures are not compress well too even with crunch (bump mapping textures familly if i remember well) but if nanite do it on the fly (we need to know what this means) it's possible we won't need them anymore.

another question is why would ps5 needs that ? imo ramdom IOPS for both platform is an info lacking atm (rumors would put ms ssd at 750K)

edit : you can not like kirby but it remains his question about random reads is a legitimate one that can put lot of speculation/uncertainties to bed.
 
Last edited:

Bernkastel

Ask me about my fanboy energy!
You do not have to, but it comes off as that way and thus as disingenuous (especially seeing the content in the thread, even your last quoted tweets... c’mon) and make it as a console thing which is not. It makes it sound like an excuse to hype each disguised as research and discussion.

Take it as zlib vs BCPack, it does not change what I posted and why. You are trying to make it a console fight... whatever... 🤷‍♂️...
Why not? Well, the same way you have validated Louise Kirby's tweets :
Well the original OP and post #11 did not have any tweets, but the thread quickly drifted to PS5 SSD talk. Eventually MHK and another guy started talking about how devs prefer PS5 over XSX, so I posted tweets from Richard Geldreich(and put them on OP) and even from Louise Kirby. At that time people were making posts too fast to post anything meaningful. Although today I removed tweets from Richard Geldreich from OP to keep all sources official like the Ray Tracing and Audio thread.
A lot of interest in how BCPack could work and XVA yet... not even a comment when others find something oldergamer oldergamer Bernkastel Bernkastel :p...?

But that does not mean I will validate your opinions. No need to do back seat moderation either on what people can post.
 

Panajev2001a

GAF's Pleasant Genius
kraken adds ~40% on texture compression (it's why 5.5 -> 9 is representative since texture are most of data).
crunch codec adds 200% or more + (it's why if ms solution is anywhere like it 4.8gb/s is conservative)
(a crunch example in a presentation i linked at least 4x times show a crunch texture is 50%+ of same texture compressed with zlib (kraken add ~10% on that))
But there is a drawback : crunch is lossy.
Ms probably don't want that and in this case the solution could be less impressive than crunch.
For now difficult to see what it will be without the actual info....output of possibilities is still wide.

also all textures are not compress well too even with crunch (bump mapping textures familly if i remember well) but if nanite do it on the fly (we need to know what this means) it's possible we won't need them anymore.

another question is why would ps5 needs that ? imo ramdom IOPS for both platform is an info lacking atm (rumors would put ms ssd at 750K)

edit : you can not like kirby but it remains his question about random reads is a legitimate one that can put lot of speculation/uncertainties to bed.

My point about kraken was vs zlib, but yes fair points :). Nothing I think we disagree on.

My points stemmed from these two articles:
(Oodle Texture, which does offer a comparison of zlib/kraken vs the oodle data reordering + zlib/kraken) http://cbloomrants.blogspot.com/2020/06/oodle-texture-slashes-game-sizes.html

127 MB BCN GPU textures, mix of BC1-7, before any further compression

78 MB with zip/zlib/deflate

70 MB with Oodle Kraken

40 MB with Oodle Texture + Kraken
(the only really kind of cheeky bit here is not giving the slightly bigger number for Oodle Texture + zlib)

and

(BC7Prep which needs GPU decompression... BCPack is to me something similar to this but implemented in the HW decompression block... the pipeline can be pure zlib -> raw/GPU native or zlib -> BCPack decoding -> raw/GPU native): http://cbloomrants.blogspot.com/2020/06/oodle-texture-bc7prep-data-flow.html

w5dthPK.jpg



I0hkfja.png
 
Last edited:

Panajev2001a

GAF's Pleasant Genius
Well the original OP and post #11 did not have any tweets, but the thread quickly drifted to PS5 SSD talk. Eventually MHK and another guy started talking about how devs prefer PS5 over XSX, so I posted tweets from Richard Geldreich(and put them on OP) and even from Louise Kirby. At that time people were making posts too fast to post anything meaningful. Although today I removed tweets from Richard Geldreich from OP to keep all sources official like the Ray Tracing and Audio thread.

But that does not mean I will validate your opinions. No need to do back seat moderation either on what people can post.

You do what you want, but I am not sure you are acting with such disgust if people do talk about it... I thought that it was what you wanted in the thread (and was trying to move the discussion here because of that) and not just hype it for console warring purposes... 🤷‍♂️...
 

martino

Member
My point about kraken was vs zlib, but yes fair points :). Nothing I think we disagree on.

My points stemmed from these two articles:
(Oodle Texture, which does offer a comparison of zlib/kraken vs the oodle data reordering + zlib/kraken) http://cbloomrants.blogspot.com/2020/06/oodle-texture-slashes-game-sizes.html


(the only really kind of cheeky bit here is not giving the slightly bigger number for Oodle Texture + zlib)

and

(BC7Prep which needs GPU decompression... BCPack is to me something similar to this but implemented in the HW decompression block... the pipeline can be pure zlib -> raw/GPU native or zlib -> BCPack decoding -> raw/GPU native): http://cbloomrants.blogspot.com/2020/06/oodle-texture-bc7prep-data-flow.html

w5dthPK.jpg



I0hkfja.png
Crunch is only DXT texture (and old at this point)
here an example


37 MB texture is 4.27MB with zlib and 2.4MB with crunch. (my previous math was wrong i add 1.8 in mind)
Using the two examples, in fact oodle+kraken if a little better than crunch and it works for BCN and is not lossy (not sure)
fun fact those examples give ~exact same saving in case of super-compressed + zlib
 
Last edited:

Bernkastel

Ask me about my fanboy energy!
You do what you want, but I am not sure you are acting with such disgust if people do talk about it... I thought that it was what you wanted in the thread (and was trying to move the discussion here because of that) and not just hype it for console warring purposes... 🤷‍♂️...
I am just making it clear that I am not the one who drifted it to comparisons, otherwise it would have been like the Ray Tracing and Audio thread. Its also kind of disingenuous to label people as being disgusted after trying to get your opinion validated for atleast 40 pages. Usually I am mean in my posts because thats just my personality, does not mean I hold anything against anyone. If I am interested I will reply, if not I wont. This thread is already 50 pages long and the OP is not obligated to reply to every opinion.
 

Panajev2001a

GAF's Pleasant Genius
I am just making it clear that I am not the one who drifted it to comparisons, otherwise it would have been like the Ray Tracing and Audio thread. Its also kind of disingenuous to label people as being disgusted after trying to get your opinion validated for atleast 40 pages. Usually I am mean in my posts because thats just my personality, does not mean I hold anything against anyone. If I am interested I will reply, if not I wont. This thread is already 50 pages long and the OP is not obligated to reply to every opinion.

...nobody called you disgusted and lol about making it about others trying to feel validated. I guess we are stuck with posting spec sheets and official interviews posing as if they were discussion threads from the various sides with this attitude.

Not sure why comparisons and references between compressors and techniques. You want to see console warring in this maybe? Considering you are posting a slightly different side from what I posted the “get over yourself it was not interesting to me” bit seems disingenuous :p.
 
Last edited:

geordiemp

Member
Hehe, well I assume they went through the trouble of designing a HW decoder for a fixed console platform to get better efficiency than zlib + pre-processing.

I think that kraken itself is not as efficient as BCPack (based on the info we have available), not sure if Sony’s equivalent compressed bandwidth included Oodle Texture pre-processing (if yes, it makes BCPack very impressive compared to zlib, kraken is like 10-15% more efficient than zlib not much more according to Cerny) or not though.

In the case of, admittedly controlled scenarios, Oodle Texture (not BC7Prep) does allow Kraken and zlib to increase compression a lot (reminds me a bit of Apple inverting encryption and compression of app binaries and discovering a good deal more compression efficiency there).

They are similar if both use RDO preparation on textures before you store them on blu ray / disk from reading all the blogs and info.

I understand it as Ps5 is RDO + Kraken/zlib, XSX is RDO + Zlib (both use different vendors so squabble about differences if you must). RDO is lossy and an OPTION on textures right at creation stage.

BC1-7 is standard GPU texel format on both consoles it is NOT uncompressed in memory, its a standard GPU format that is already BC1-7 compressed the GPU cache reads natively. BC1-7 is how GPUs read textures in their cache, so they stay BC1-7 compressed all the way to the GPU cache on both consoles.

This is all to save IO bandwidth on consoles.

The Bc7 prep is different again, its own thing, and is more forcussed on memory bandwidth.......

BC7prep is playing around with BC7 for an extra OPTIONAL 5-15% compress just on that format. and the iMPORTANT part people are missing is it can keep that compression all the way to the GPU cache and unpacked and used there (source dev tweet on ps5 GPU unpack low cost).

The benefit of Bc7 prep is saving up to 15 % on memory bandwitth for BC7 textures at a cost of unpacking at GPU. We dont know if this is an RDNA2 feature, but its affecting memory bandwidth requirement + IO bandwidth and is optional.
 
Last edited:

jimbojim

Banned
I am just making it clear that I am not the one who drifted it to comparisons, otherwise it would have been like the Ray Tracing and Audio thread. Its also kind of disingenuous to label people as being disgusted after trying to get your opinion validated for atleast 40 pages. Usually I am mean in my posts because thats just my personality, does not mean I hold anything against anyone. If I am interested I will reply, if not I wont. This thread is already 50 pages long and the OP is not obligated to reply to every opinion.

Sure, you have no obligation to reply to every opinion. But it's a really disingenuous from you to say that this thread is only XVA thread, but it's not. You posted in your very first post tweets about Kraken and also later just provide or better to say, validated a tweets about PS5 SSD and Kraken ( like Louise Kirby tweets ). You started it.
 

Panajev2001a

GAF's Pleasant Genius
They are similar if both use RDO preparation on textures before you store them on blu ray / disk.

I understand it as Ps5 is RDO + Kraken/zlib, XSX is RDO + Zlib (both use different vendors so squabble about differences if you must).

BC1-7 is standard GPU texel format on both consoles it is NOT uncompressed in memory, its a standard GPU format the chache reads. BC1-7 is how GPUs read textures in their cache, so they stay BC1-7 compressed all the way to the GPU cache on both consoles.

This is all to save IO bandwidth on consoles.

The Bc7 prep is playing around with BC7 for an extra OPTIONAL 5-15% just on that format. and it cna keep that compression all the way to the GPU cache and unpacked and used there (source dev tweet on ps5 GPU unpacklow cost).

The benefit of Bc7 prep is saving that up to 15 % on memory bandwitth for BC7 textures at a cost of unpacking at GPU. We dont know if this is an RDNA2 feature, but its affecting memory bandwidth + IO bandwidth and is optional.

I think XSX has the equivalent of BC7Prep in HW... so XSX having the two
Following I/O decompression paths:
  • pure zlib -> raw/GPU native
  • zlib -> BCPack decoding -> raw/GPU native
 

geordiemp

Member
I think XSX has the equivalent of BC7Prep in HW... so XSX having the two
Following I/O decompression paths:
  • pure zlib -> raw/GPU native
  • zlib -> BCPack decoding -> raw/GPU native

BC7 textuire is not uncompressed in RAM, it remains that way all the way to GPU cache on both consoles..

There is no BC1-7 unpacking in hardware decoders on either console, as BC1-7 is the native format for GPU Caches, that is the bit people are mixing up. Thats why I posted earlier a tutorial into what BC1-7 are and how they are created then used by the GPU..

No on your XSX BCpack understanding, it does not unpack BC1-7 as its native GPU. Nor does it unpack Bc7 prep., that would be saving on IO but not memory bandwidth to cache, purpose defeating...

BC7 prep is a special case,. if it is unpacked by XSX in memory, then that would be pointless as your adding 15 % requirement to get it into the GPU cache than you needed...does not compute :messenger_beaming:

OPTIONAL BC7prep is saving memory bandwidth and unpacked at the GPU, might be a RDNA2 thing, its unfair to say its a Ps5 thing as there has only been 1 tweet on Bc7prep.

And no way would you ever want to decode Bc7prep using a hardware decoder, its pupose is saving memory bandwidth as well all the way up to the GPU cache.
 
Last edited:

Bernkastel

Ask me about my fanboy energy!
Sure, you have no obligation to reply to every opinion. But it's a really disingenuous from you to say that this thread is only XVA thread, but it's not. You posted in your very first post tweets about Kraken and also later just provide or better to say, validated a tweets about PS5 SSD and Kraken ( like Louise Kirby tweets ). You started it.
I am pretty sure I did not start anything.
Well the original OP and post #11 did not have any tweets, but the thread quickly drifted to PS5 SSD talk. Eventually MHK and another guy started talking about how devs prefer PS5 over XSX, so I posted tweets from Richard Geldreich(and put them on OP) and even from Louise Kirby.
The tweets were posted around page 8(I think) and then the OP was updated, the tweets in the current OP were posted much later.
...nobody called you disgusted and lol about making it about others trying to feel validated. I guess we are stuck with posting spec sheets and official interviews posing as if they were discussion threads from the various sides with this attitude.

Not sure why comparisons and references between compressors and techniques. You want to see console warring in this maybe? Considering you are posting a slightly different side from what I posted the “get over yourself it was not interesting to me” bit seems disingenuous :p.
Considering I post in this thread way less frequently then you do(and that too only when there is some new info), are you just projecting yourself on others now ?
 

Panajev2001a

GAF's Pleasant Genius
I am pretty sure I did not start anything.

The tweets were posted around page 8(I think) and then the OP was updated, the tweets in the current OP were posted much later.

Considering I post in this thread way less frequently then you do(and that too only when there is some new info), are you just projecting yourself on others now ?

Nope :).
 

martino

Member
OPTIONAL BC7prep is saving memory bandwidth and unpacked at the GPU, might be a RDNA2 thing, its unfair to say its a Ps5 thing as there has only been 1 tweet on Bc7prep.
that is the lossless solution
but the lossy solution needs transcoding . this save even more bandwidth
atm we assume transcoding is done on decompression block
if it's not velocity will be a meh solution in case for XsX imo.
 
Last edited:

Panajev2001a

GAF's Pleasant Genius
BC7 textuire is not uncompressed in RAM, it remains that way all the way to GPU cache on both consoles..

There is no BC1-7 unpacking in hardware decoders on either console, as BC1-7 is the native format for GPU Caches, that is the bit people are mixing

I get that, same thing as formats such as PVR, ASTC, ETC and more which are GPU native. I was not saying that, but I referenced raw as you can use zlib/kraken to compress and decompress non texture data too.

For textures only data on XSX:
* Texture encoded in GPU native format —> encoded in proprietary “BCPack“ format -> zlib compressed -> SSD -> loaded and passed to BCPack decoder -> texture inflated and converted into GPU native texture format -> GPU loads texture -> GPU uses texture

For textures only data on PS5:
either

* Texture encoded in GPU native format —> texture processed with BC7Prep -> kraken compressed -> SSD -> loaded and passed to Kraken decoder -> texture inflated and converted into BC7 texture format -> GPU loads texture -> GPU decompresses it with async compute jobs -> GPU uses texture

or

* Texture encoded in GPU native format —> texture processed with Oodle Texture -> kraken compressed -> SSD -> loaded and passed to Kraken decoder -> texture inflated and converted into GPU native texture format -> GPU loads texture -> GPU uses texture

u21jzcx.jpg


BC7Prep and Oodle Texture alone are lossless, both combined are superior but only “near lossless”: http://cbloomrants.blogspot.com/2020/06/oodle-texture-bc7prep-data-flow.html
 
Last edited:

oldergamer

Member
A lot of interest in how BCPack could work and XVA yet... not even a comment when others find something oldergamer oldergamer Bernkastel Bernkastel :p...?

I stopped speculating on this a while ago when we had no additional info. Let me know when you get to the interesting part?

I see you're suddenly making lot of assumptions and speculating (something you seemed to be against earlier in this and other thread) no? ;) Taking a guess at how it all works is suddenly more fun? So what changed outside of someone saying PS5 has a new RDO format available? This was expected.

Regardless, we still don't have all the details on how it works for Xbox, or factors into the velocity tech.
 
Last edited:

martino

Member
I stopped speculating on this a while ago when we had no additional info. Let me know when you get to the interesting part?

I see you're suddenly making lot of assumptions and speculating (something you seemed to be against earlier in this and other thread) no? ;) Taking a guess at how it all works is suddenly more fun? So what changed outside of someone saying PS5 has a new RDO format available? This was expected.

Regardless, we still don't have all the details on how it works for Xbox, or factors into the velocity tech.

discovering rate distortion optimizations was fascinating for me :D
 

Panajev2001a

GAF's Pleasant Genius
I stopped speculating on this a while ago when we had no additional info. Let me know when you get to the interesting part?

I see you're suddenly making lot of assumptions and speculating (something you seemed to be against earlier in this and other threads) no? ;) Taking a guess at how it all works is suddenly more fun? So what changed outside of someone saying PS5 has a new RDO format available?

Regardless, we still don't have all the details on how it works for Xbox, or factors into the velocity tech.

Haha, the use of RDO to prepare the texture for better compression was speculated and mentioned on one of the famous Twitter threads already and months or so ago.
I am not against speculating/trying to reason about with the available data... just not about making baseless claims and treating them as gospel :).

Sony licensing Oodle Texture could make BCPack look better not worse if you assume Sony’s equivalent bandwidth assumed Oodle Texture preparation (as they had already started working with it before announcing the license acquisition) or at least explain why BCPack is more efficient (2x compressed equivalent bandwidth, in order to claim a similar compression efficiency claim Sony would have to hide a hidden shader based decompression cost).
Not sure why you are taking the console war angle :/...
 
Last edited:

oldergamer

Member
Haha, the use of RDO to prepare the texture for better compression was speculated and mentioned on one of the famous Twitter threads already and months or so ago.
I am not against speculating/trying to reason about with the available data... just not about making baseless claims and treating them as gospel :).

I've heard you say that before, but from what i could tell, nobody was taking anything as gospel, it was just speculation on what it was or how it worked ( not different then now ).

Sony licensing Oodle Texture could make BCPack look better not worse if you assume Sony’s equivalent bandwidth assumed Oodle Texture preparation (as they had already started working with it before announcing the license acquisition) or at least explain why BCPack is more efficient (2x compressed equivalent bandwidth, in order to claim a similar compression efficiency claim Sony would have to hide a hidden shader based decompression cost).
Not sure why you are taking the console war angle :/...
Interesting, perhaps that could be the clue we were wondering about, but is that more speculation, or should we treat that as gospel ;) I'm not taking a console war angle. Remember this?

Panjev: "A lot of interest in how BCPack could work and XVA yet... not even a comment when others find something... "

Who called out whom after that sentence ? :) common man, you say it's war-ing when someone else does it, but not when you do it? I think we can agree there is nothing wrong with speculation in the absence of data.
 
Last edited:

geordiemp

Member
I get that, same thing as formats such as PVR, ASTC, ETC and more which are GPU native. I was not saying that, but I referenced raw as you can use zlib/kraken to compress and decompress non texture data too.

For textures only data on XSX:
* Texture encoded in GPU native format —> encoded in proprietary “BCPack“ format -> zlib compressed -> SSD -> loaded and passed to BCPack decoder -> texture inflated and converted into GPU native texture format -> GPU loads texture -> GPU uses texture

For textures only data on PS5:
either

* Texture encoded in GPU native format —> texture processed with BC7Prep -> kraken compressed -> SSD -> loaded and passed to Kraken decoder -> texture inflated and converted into BC7 texture format -> GPU loads texture -> GPU decompresses it with async compute jobs -> GPU uses texture

or

* Texture encoded in GPU native format —> texture processed with Oodle Texture -> kraken compressed -> SSD -> loaded and passed to Kraken decoder -> texture inflated and converted into GPU native texture format -> GPU loads texture -> GPU uses texture

u21jzcx.jpg


BC7Prep and Oodle Texture alone are lossless, both combined are superior but only “near lossless”: http://cbloomrants.blogspot.com/2020/06/oodle-texture-bc7prep-data-flow.html

No, Bc1-7 is the native format of GPU cache, any BC1-7 format is not uncompressed by hardware decoders, its ready gto be used by the GPU anyway, so no.

I will try again, textures only

Normal prep on say PC options

RDO optional (lossy) + into GPU formats used by GPUs = BC1-7

Prep on XSX

RDO optional (lossy) + into GPU formats used by GPUs = BC1-7 + Zlib

That above is caled BCpack

Prep on ps5

RDO optional (lossy) + into GPU formats used by GPUs = BC1-7 + Kraken

Hardware decoders on console

Zlib = XSX. Kraken = ps5

Thats it, there is no other decompressors of GPU textures that are already in GPU cache format.. why lol

GPU formats read from memory into GPU cache

BC1-7 all of them, including PC

Optional additional BC7PREP is new compression over and above all that is done at prep, but decoded by GPU in the cache,. it saves MEMORY bandwidth and is totally unrelated.##

If you decode BC7Prep in a hardware decoder, your adding 15 % onto memory bandwidth requirement to get it into GPU Cache.
 
Last edited:

Panajev2001a

GAF's Pleasant Genius
I've heard you say that before, but from what i could tell, nobody was taking anything as gospel, it was just speculation on what it was or how it worked ( not different then now ).


Interesting, perhaps that could be the clue we were wondering about, but is that more speculation, or should we treat that as gospel ;) I'm not taking a console war angle. Remember this?

Panjev: "A lot of interest in how BCPack could work and XVA yet... not even a comment when others find something... "

Who called out whom after that sentence ? :) common man, you say it's war-ing when someone else does it, but not when you do it? I think we can agree there is nothing wrong with speculation in the absence of data.

Pointing out an angle that makes XSX BCPack look better is now console warring? Weird...

I am speculating based on hard data, benchmarks provided by Sony, MS (compressed vs uncompressed), Oodle engineers, and seeing how they are tied together not trying to imagine some magical 2-3x increase in bandwidth based on the assumption an comment without detail actually meant XYZ because it would be so cool if it meant it and thus I make a baseline of comparison up (SFS improving bandwidth usage by more than 2-3x as well as memory usage over PRT and software page management).
 

Panajev2001a

GAF's Pleasant Genius
No, Bc1-7 is the native format of GPU cache, any BC1-7 format is not uncompressed by hardware decoders, its ready gto be used by the GPU anyway

I never said it was, how are you reading what I said there to imply that? Again, BC1-7 is like ATSC/ETC/S3TC/PVR... I get that: GPU reads and does not have to uncompress them (they stay compressed in the GPU cache too).

I just was making the assumption that when I write “GPU native format” you can fill in any of those formats wherever I write it :).

Optional additional BC7PREP is new compression over and above all that is done at prep, but decoded by GPU in the cache,. it saves MEMORY bandwidth and is totally unrelated.##

If you decode BC7Prep in a hardware decoder, your adding 15 % onto memory bandwidth requirement to get it into GPU Cache.

Yup, but you save GPU performance as you are not decoding it in software and memory if you have temporary storage for the async compute job to decode blocks into (and less complexity not having to sync with those GPU decompressor shader tasks).
You’d trade off memory bandwidth between GPU and main RAM (which XSX has plenty of) to maximise SSD I/O and get better compression rates/better SSD I/O performance. It would be a pretty smart tradeoff: memory bandwidth cost to pay for better SSD effective bandwidth. It would explain better equivalent compressed data rates and how they can achieve that (2x the raw uncompressed bandwidth vs ~1.45-1.6).
Trying to make sense of the uncompressed vs compressed SSD I/O numbers and how they were explained.

BTW, I am not suggesting BCPack HW decoder uncompresses to raw RGBA or anything crazy :).
 
Last edited:
Although early games shown by playstation 5, The difference between the 2 systems is very evident in their hardware choices and software choices. Most of Sony's game offerings show 4K30 FPS Or the other end of the spectrum Sub 4K60. As some people have said a ssd can not replace a fast GPU or cpu.
 
Top Bottom