Support NeoGAF

[Heisenberg007]

streamed data constantly at 4gb? inwhat instance respawn ?

They didn't specify if it was during respawn only. That couldn't be the case because they would have just increased the load time if that was the case. Based on the entire conversation surrounding that sentence, the implication was that data streaming at 3 to 4 Gb/s was more frequent and very "normal".

Either way, we have an actual example now of data streaming at 4 Gb/s by a developer, so that 500 mb/s theoretical data can no longer be considered valid.

 

[Panajev2001a]

streamed data constantly at 4gb? inwhat instance respawn ?

Not sure the speed they stream at, but watch the video around the 19 minutes mark, they explain this concept (or you can read the thread and see other instances of the same explanation you are refusing to acknowledge ).

 

[MonarchJT]

They didn't specify if it was during respawn only. That couldn't be the case because they would have just increased the load time if that was the case. Based on the entire conversation surrounding that sentence, the implication was that data streaming at 3 to 4 Gb/s was more frequent and very "normal".

Either way, we have an actual example now of data streaming at 4 Gb/s by a developer, so that 500 mb/s theoretical data can no longer be considered valid.

why increase the time if your system is capable of? ...the problem are assets ..there aren't enough in game to saturate both ssd of both console in the average game

btw I'll check this video later )

 

[Bernd Lauert]

PRT reduces the amount of assets (portions vs entire texture) you have to stream, SFS is about the HW doing work for you to help you understand what you need to load next and get it loaded there.

PRT alone still overshoots by up to three times and wastes a shitload of memory capacity and bandwidth in the process. That's why SF is so important.

 

[MonarchJT]

They didn't specify if it was during respawn only. That couldn't be the case because they would have just increased the load time if that was the case. Based on the entire conversation surrounding that sentence, the implication was that data streaming at 3 to 4 Gb/s was more frequent and very "normal".

ps. and anyway we are talking about a game with very high resolution textures .. and stream of 3 or 4gb / s this alone should make you understand how overkill both systems are.

 

[Heisenberg007]

why increase the time if your system is capable of? ...the problem are assets ..there aren't enough in game to saturate both ssd of both console in the average game

btw I'll check this video later )

Edit: I rewatched some sections of the video again just now, and they basically confirm that this data streaming wasn't just done when you're respawning or moving b/w different worlds (new levels). They said it applies even when you're in the same level, playing the game normally, moving from rooms to rooms, etc.

 

[Panajev2001a]

PRT alone still overshoots by up to three times and wastes a shitload of memory capacity and bandwidth in the process.

I do not see any evidence of that and the SFS related evidence I see quoted qualified the savings of 2-3x as loading portions of a texture in memory instead of the whole texture (or portions of a mip level instead of the entire mip level).
Nobody attributed 2-3x savings to “overshooting”.

 

[muteZX]

"Includes SFS" seems to oversimplify it. The entire point of SFS is to reduce the amount of assets you have to stream in the first place, so it has nothing to do with bandwidth throughput. Or to stick with Three's example, the PS5 is pushing 500 MB, the XSX is pushing 250 MB, but ideally both have the same asset quality because of SFS.

Exactly. Speed of SFS is - raw speed + compression. Not - raw+compression+whatever index you wish for.

 

[Bernd Lauert]

why increase the time if your system is capable of? ...the problem are assets ..there aren't enough in game to saturate both ssd of both console in the average game

btw I'll check this video later )

The TL;DW of the video is that they're still using a chunking system, just way more aggressively with regards to timing and amount of detail. It's not a constant stream, and it's not only during respawns.

 

[MonarchJT]

I do not see any evidence of that and the quotes SFS evidence I see qualified the savings of 2-3x because you are loading portions of a texture in memory instead of the whole texture (or portions of a mip level instead of the entire mip level).
Nobody attributed 2-3x savings to “overshooting”.

yes is that the memory saving of sfs

 

[Panajev2001a]

there aren't enough in game to saturate both ssd of both console

Yes there are as you are “re”-loading them in RAM over and over and over. Like we are repeating this over and over instead of writing tons of posts with unique content we are trying to hammer the same few points back in this case over and over again .

 

[Heisenberg007]

ps. and anyway we are talking about a game with very high resolution textures .. and stream of 3 or 4gb / s this alone should make you understand how overkill both systems are.

I'd disagree with you here. I love the fact that Demon's Souls used such high textures. if you know me, i've mentioned it multiple times even on this forum that higher quality textures are way more important to me than resolution or even ray tracing.

If you can stream such high-quality texture and fidelity data, you can basically use the 8K megascans in UE5 games that the demo showed. That made the biggest difference in that UE5 demo, and games will be able to look that beautiful with high-quality 8K megascan textures -- which ultimately depend on the I/O pipeline.

 

[Panajev2001a]

yes is that the memory saving of sfs

No, for sure not according to the quotes you provide that are saying the opposite of that.

Please look at BOTH Stanard quotes below, not only one of the two… but both .

 

[Heisenberg007]

No, for sure not according to the quotes you provide that are saying the opposite of that.

Please look at BOTH Stanard quotes below, not only one of the two… but both .

Good post. Also, it reminds us that 4.8 Gb/s remains 4.8 Gb/s and does not get multiplied further.

 

[Boglin]

PRT alone still overshoots by up to three times and wastes a shitload of memory capacity and bandwidth in the process. That's why SF is so important.

If PRT overshot by 3x wouldn't it literally be doing nothing and streaming in the entire mip?

ps. and anyway we are talking about a game with very high resolution textures .. and stream of 3 or 4gb / s this alone should make you understand how overkill both systems are.

You can use the speeds in bursty situations too rather than continuous. Like a fantasy game character could temporarily summon and stream in a rarely used, but resource intensive monster so it isn't constantly leaching RAM. Or it could be similar to something like Tekken Tag Tournament but the tag partner doesn't stay in memory.
I have no doubt that developers will take advantage of the crazy bandwidth even without increasing game sizes to a terabyte. They are more creative than we are.

 

[muteZX]

you talking about SF he was talking about SFS ...and yes in correlation to SF .. is a big big thing

SFS - This document describes a Direct3D 12 runtime feature .. hence not XSX exclusive.​

We have indications that M. Cerny and co. with the PS5 GPU have made several hits that got this GPU out of the standard RDNA2 classification. It's naive to think that on a PS5 with a very customized SSD IOP they didn't even go in the direction of PRT data optimization. Finally, we don't know as simple a thing as how much RAM space the OS takes up and how much is for games. However, the UE5 demo shows the huge throughput of the system with just small mem buffer pool .. guess why ..

 

[Three]

"Includes SFS" seems to oversimplify it. The entire point of SFS is to reduce the amount of assets you have to stream in the first place, so it has nothing to do with bandwidth throughput. Or to stick with Three's example, the PS5 is pushing 500 MB, the XSX is pushing 250 MB, but ideally both have the same asset quality because of SFS.

This assumes that the game doesn't also already stream only what is visible on PS5. It will.

What leviathanGamer2 says here is not entirely true but he clarified later about the streaming visual presentation :



The visual presentation of spiderman while traversing is limited by streaming speed. While you traverse the quality is entirely bottlenecked by the streaming speed of the HDD until you stop moving

 

[Bernd Lauert]

If PRT overshot by 3x wouldn't it literally be doing nothing and streaming in the entire mip?

No, PRT still saves a lot of data compared to classic texture streaming. But it also wastes a lot of data without sampler feedback.

 

[SpokkX]

In matter of I/O throughput? No, not even close. XSX won’t magically close the very significant hardware/processing power/speed gap with fantasy theories. As to GPU/CPU performance, you are right.

well doubtful about GPU since series x has more hardware functions (ignoring the more CU:s)

imo the gpu difference will be more noticable than the io difference in 2-3 years

no matter - the arguments are useless. Time will tell

 

[MonarchJT]

SFS - This document describes a Direct3D 12 runtime feature .. hence not XSX exclusive.​

We have indications that M. Cerny and co. with the PS5 GPU have made several hits that got this GPU out of the standard RDNA2 classification. It's naive to think that on a PS5 with a very customized SSD IOP they didn't even go in the direction of PRT data optimization. Finally, we don't know as simple a thing as how much RAM space the OS takes up and how much is for games. However, the UE5 demo shows the huge throughput of the system with just small mem buffer pool .. guess why ..

sfs can be done through software (been done from long time) ....is the hw in the sxs that is unique

 

[muteZX]

RDNA2 has "it" as a new HW feature and SONY voluntarily ignored it. IMHO .. a highly unlikely scenario.

 

[Boglin]

No, PRT still saves a lot of data compared to classic texture streaming. But it also wastes a lot of data without sampler feedback.

I know SFS is more efficient due to built in caches for the residency map and that's why in the past I was digging to find just how much more efficient SFS is compared to plane Jane PRT. Fortunately I got this reply from my BFF who is a developer.

I'm unclear at how much more efficient SFS is than PRT because I haven't been able to find any comparisons. This demo did not clear that up because its purpose was not to make that comparison.

Assuming same block-size and compression used, the I/O difference would be marginal at most. The main trade-off is some extra compute costs for visibility determination and manual handling of filtering edge-cases in shaders.

If you have a source which shows some quantifiable numbers that compare SFS to the regular PRT, I'd love to learn more.

 

[MonarchJT]

We don't know if the PS5 GPU supports it. It's certainly not a guarantee that it does, but let's assume that it does even if I personally doubt it. Then in such a scenario PS5 is even more insanely faster than Series X still if it does, but with what the Series X will be capable of already at what point will we be at "fast enough?"

As I said in my 22GB texture request hypothetical.

22GB becomes 8.8GB due to SFS

8.8 / 2.4GB/s / 2 = 1.83 seconds. An insane effective I/O rate of 22GB/sec.

or

14GB texture request hypothetical.

14GB becomes 5.6GB due to SFS

5.6GB / 2.4GB/s / 2 = 1.16 seconds. An awesome effective I/O rate of 14GB/s

When would such a crazy thing NOT be enough? 2 on screen equivalent results that without SFS would easily exceed the RAM capacity of Series X, but is possible thanks to SFS. There is no way this will never be enough for this generation. If both consoles had way more than just 16GB of RAM, and more than 13.5GB-14GB of usable ram, then perhaps then the 2.4GB/s raw for the Series X SSD could become an issue, but that will never be the case for this generation of games.

it's a discussion which will never be accepted .. probably the best place to talk about these technicalities is b3d

 

[MonarchJT]

RDNA2 has "it" as a new HW feature and SONY voluntarily ignored it. IMHO .. a highly unlikely scenario.

there isn't any rdna2 GPU with hw sfs..he is 100% wrong

 

[muteZX]

there isn't any rdna2 GPU with hw sfs..he is 100% wrong

he is a ..

AMD Developer Central -
The official channel for AMD Developer Central with news, webinars and info about heterogeneous computing, OpenCL, C++AMP, LiquidVR, GPUOpen, development tools, training and resources.

 

[sinnergy]

The lead architects explained what they did with SFS and why .. even on Twitter , why is it So hard to believe them ? It’s not in DX12 ultimate . But take anything Cerny as gospel , question is , will it be widely used on Xbox.

 

[Lysandros]

well doubtful about GPU since series x has more hardware functions (ignoring the more CU:s)

imo the gpu difference will be more noticable than the io difference in 2-3 years

no matter - the arguments are useless. Time will tell

I assume that you have a fair grasp about PS5's GPU advantages while saying that.. Well just agree to disagree about the outcome then.

 

[Bernd Lauert]

I know SFS is more efficient due to built in caches for the residency map and that's why in the past I was digging to find just how much more efficient SFS is compared to plane Jane PRT. Fortunately I got this reply from my BFF who is a developer.



If you have a source which shows some quantifiable numbers that compare SFS to the regular PRT, I'd love to learn more.

This is the closest I found (official Xbox blog).

Apparently last gen games didn't even use PRT? I know about Megatexture and Virtual Texturing but they don't seem to be the same thing.

 

[Boglin]

This is the closest I found (official Xbox blog).

Apparently last gen games didn't even use PRT? I know about Megatexture and Virtual Texturing but they don't seem to be the same thing.

Thanks for going out of your way to try to find some info. It's very elusive so you know this stuff isn't being used everywhere.

 

[Three]

there isn't any rdna2 GPU with hw sfs..he is 100% wrong

This is essentially the precursor for SFS from AMD

http://developer.amd.com/wordpress/media/2013/12/TexelShading_EG2016_AuthorVersion.pdf

This is the closest I found (official Xbox blog).

Apparently last gen games didn't even use PRT? I know about Megatexture and Virtual Texturing but they don't seem to be the same thing.

I mean it clearly mentions it right there

"load an entire mip level even in cases where they may only samle a very small portion of the overall texture."

If you are loading the entire mip level then it isn't a Partially Resident Texture it's completely loaded. virtual textures are essentially what allow PRT and megatextures. They are the same principle.

 

[Bernd Lauert]

This is essentially the precursor for SFS from AMD

http://developer.amd.com/wordpress/media/2013/12/TexelShading_EG2016_AuthorVersion.pdf

I mean it clearly mentions it right there

"load an entire mip level even in cases where they may only samle a very small portion of the overall texture."

If you are loading the entire mip level then it isn't a Partially Resident Texture it's completely loaded. virtual textures are essentially what allow PRT and megatextures. They are the same principle.

And yet Microsoft says that last gen, games had to load in the entire mip level and often took up 200% more memory than they actually needed.

 

[Boglin]

"load an entire mip level even in cases where they may only samle a very small portion of the overall texture."

And yet Microsoft says that last gen, games had to load in the entire mip level and often took up 200% more memory than they actually needed.

Erm... Aren't you guys saying the same thing? Streaming in entire mips were the norm last generation, not PRT. We still don't have a head to head PRT vs SFS comparison which will be used heavily this generation.

 

[Three]

And yet Microsoft says that last gen, games had to load in the entire mip level and often took up 200% more memory than they actually needed.

I think you are alluding to the fact that we have had sparse virtual textures for a while, however that doesn't mean that you are streaming in data for PRT in most last gen games. They load the entire mip level in most games as speed and seek is slow on a HDD anyway. Using that RAM is better than constantly trying to load things from the HDD because it's too slow.

Games with PRT/Megatextures like Rage would not benefit as much as games that just load the whole mip level.

 

[DForce]

SFS is proprietary technology to Microsoft and it uses custom hardware piece. PS5 does not have an analogue. Nor HW supported, not SW. If they had, they would have talked about it. Sure they can develop SW accelerated solution, of course. But their focus was SSD and I/O performance itself, not optimizing asset size that need to be loaded in the first place.

Microsoft even talked about bringing it on PC. But they added that is will be software accelerated. They would have said: "you will get HW accelerated SFS on RDNA2 gpus". But no. They custom designed it on Xbox, not available on other RDNA2 configurations.

PRT was VERY limited in it's adoption rate and overall performance in last gen. Because you simply did not have storage fast enough to handle it. Not my words. I am quoting MS developer from Game Stack Event.

Timestamp included.

Unreal Engine 4's Streaming Virtual Texturing

Streaming Virtual Texturing (SVT) is an alternative way to stream textures in your project from disk, having several advantages—along with some disadvantages—when compared to existing mip-based Texture Streaming in Unreal Engine 4 (UE4).

Traditional mip-based texture streaming performs offline analysis of material UV usage and then at runtime decides which mip levels of a texture to load based on object visibility and distance. This process can be limiting because streaming data considered is the full texture mip levels. When using high-resolution textures, loading a higher mip level of a texture can potentially have significant performance and memory overhead. Also, mip-based texture streaming decisions are made by the CPU using CPU-based object visibility and culling. Visibility is more conservative—meaning something is more likely to be loaded than not—to avoid objects popping into view. So, if even a small part of the object is visible, the entire object is considered visible. The object loaded including any associated textures that may be required to stream in.

In contrast, the virtual texturing system only streams in parts of the textures that are required to be visible. It does this by splitting all mip levels into tiles of a small, fixed size. The GPU determines which of the of the visible tiles are accessed by all visible pixels on the screen. This means that when an object is considered visible, it's communicated to the GPU which loads the required tiles into a GPU memory cache. No matter the size of the texture, the fixed tile size of the SVTs only consider the ones that are visible. Tile visibility is computed on the GPU using standard depth buffers causing SVT requests to only happen for visible parts that affect pixels.

Inside Unreal Engine 5: how Epic delivers its generational leap

"With Nanite, we don't have to bake normal maps from a high-resolution model to a low-resolution game asset; we can import the high-resolution model directly in the engine. Unreal Engine supports Virtual Texturing, which means we can texture our models with many 8K textures without overloading the GPU." Jerome Platteaux, Epic's special projects art director, told Digital Foundry. He says that each asset has 8K texture for base colour, another 8K texture for metalness/roughness and a final 8K texture for the normal map. But this isn't a traditional normal map used to approximate higher detail, but rather a tiling texture for surface details.

If Sony worked close with Epic on this demo, then I'm sure they're well aware of techniques being used.

 

[assurdum]

Are you a hardware engineer? Or is anyone posting here an engineer? You see what I was talking about? You believe you are correct but you have no first hand knowledge of what you're talking about. The poster you are alluding to is in the same boat as you, third hand information, which to put it frankly is unreliable.

Try and stick to what you know, and you may not come across so patronising.

I mean the people who repeatedly says series X is more powerful in every face off who won are maybe hardwares engineer?

 

[SirTerry-T]

FFS ..the arguing over seconds, not hours, not minutes...seconds.

I'm an old fart, so I remember these things...

Just enjoy your games.
Or argue about them, either/either.

 

[Panajev2001a]

No, PRT still saves a lot of data compared to classic texture streaming. But it also wastes a lot of data without sampler feedback.

Again, there is no proof of that and it is not what Stanard said either (it clearly says what the 2.5x efficiency boost comes from in one quote and in the other summarises what SFS is). Nobody has claimed SFS allows you to get 2-3x the memory savings (bandwidth and storage) over best in class PRT and that 2.5x multiplier was actually qualified and matches word by word with the same person’s description of PRT (if you just want to go by his words alone for example).

See below:

Is SFS making it easier to implement an accurate streaming engine? Yes. Is it saving time and resources instead of asking devs to add more shader calculations to achieve the same functionality? Yes. Is SFS delivering 2.5-3x improvements over PRT which delivers 2.5-3x improvements loading full textures? That is the point that I disagree with and the claim I see no support for.

 

[Fafalada]

No, PRT still saves a lot of data compared to classic texture streaming. But it also wastes a lot of data without sampler feedback.

No it doesn't - let's make that clear. The 'naive' implementation of PRT - trigger a read on page-fault, aka, how virtual memory worked since it's inception 30-40 years ago, is literally the most efficient you can be in terms of disc-reading only the data that is actively being accessed inside a frame. Naive - because such an approach would be loaded with I/O stalls, no matter how impressively fast your SSD is. What you want is a pre-fetch mechanism that can trigger I/O requests before they are explicitly made by the processor, but still remain close to accurate, especially since rendering is a predictable workload.

Predicting what will be needed during real draw calls is where SF comes into play, making such heuristics easier to implement. However, the end result is only as accurate as the chosen heuristics/algorithm (ie. the software) - it's not simply a function of hardware implementation itself.

Apparently last gen games didn't even use PRT? I know about Megatexture and Virtual Texturing but they don't seem to be the same thing.

Megatexture is a specialized implementation of the same thing.
Virtual Texturing became something of an umbrella term over the decades - it includes the above, but I've seen it used(or abused) for all manner of other things, including paging between different tiers of memory (as opposed to external storage), and not necessarily operating on partial-residency (but potentially whole mips/chains).

As for how often PRT got used - some games did, but with the amount of memory and I/O speeds on hand, streaming textures on per-mipmap basis was efficient enough to not really warrant jumping through extra hoops of other approaches. I/O stacks are already often neglected and dark-places of modern codebases (and changing them has significant workflow implications as well) so if you're going to change the paradigm the benefits need to be really significant.

 

[SenjutsuSage]

If you read what he has written it only confirms it. Notice he says SFS is PRT + SF.
The purpose of PRT is to only have the required parts of the texture in VRAM.

This is where most of your memory saving is. Determining residency and streaming can even be software based, as for hardware support any turing card supports it (way before XVA). SFS is essentially identical to PRT+. They are in fact interchangeable terms.

The 2-3x effective multipliers that MS have given are compared to xbox one games. This is because not many of them actually use PRT+/SFS to stream textures as needed.

On the contrary, the multiplier isn't compared to Xbox One Games at all, it's compared to a 9th gen console optimized Xbox Series X streaming system with an SSD, but one that isn't using SFS. In the below pic see the bar all the way to the top? That's the Xbox One X bar. The bar SFS is being compared to is a 9th gen console that uses a fast SSD, aka that's Xbox Series X if it weren't using SFS.

]


They even point out that the middle bar is unrealistically optimistic and would actually be using more memory due to over-streaming, meaning the SFS advantage is even bigger. If SFS on Series X were being compared to the Xbox One X or Xbox One era, the multiplier would actually be much higher. It would be 4.4x. But compared to the next gen equivalent to Series X, SFS' advantage is between 2.5x-3x.

Below is the part where they tell you that only the top bar is Xbox One X, not the middle bar, which is what the SFS bar is being compared to.





Xbox One X games can't use Xbox Velocity Architecture. Notice what the Sampler Feedback Streaming bar is being compared to? It's being compared to Xbox Velocity Architecture without Sampler Feedback Streaming.

 

[Dozer831]

Mass Effect is a PS4/X1 game

He said that it’s not because of Kraken but there is something he can’t talk about. Wonder what the issue is and why they can’t talk about it unless it’s unfixable.

 

[Thief1987]

He said that it’s not because of Kraken but there is something he can’t talk about. Wonder what the issue is and why they can’t talk about it unless it’s unfixable.

Because he doesn't know anything, it's just another pretend to be insider.

 

[jroc74]

That's kinda the idea behind storage this fast and ASICs that handle the compression. Moving away from complexities of bespoke file-formats and 40 years old I/O access patterns into treating graphics data on disk as extension of memory. That's what MS meant when they referenced 'virtual memory' and it's also the backbone of things Cerny referenced in his talks. It's a paradigm shift though - and doesn't come for free, software stacks and pipelines need to be rewritten/adapted etc.

Yeah, I remember some ppl not really into PC's or PC gaming going crazy when MS mentioned virtual memory, lol.

I cant wait for the deep dive into how Rift Apart was made.

 

[SenjutsuSage]

Just to emphasize, here is the timestamp from the demo where they emphasize that the top bar is simulating Xbox One X, and the middle bar is simulating a next gen console, aka Series X without SFS. The multiplier effect is absolutely not being compared to Xbox One era games. The middle bar that SFS is being compared to is a 9th gen console with a fast SSD, but without SFS.



Another time-stamp where they stress that the multiplier will ring true even in more complex games built for Series S and Series X, which is what they mean when they say the 10 or 16GB in our consoles. They're referring to Xbox Series S|X. They say the multiplier will ring true in more visually complex games that use a lot more memory than the demo.

"I should also mention the absolute numbers you see in the memory bars here. They aren't all that high, especially compared to the 10 or 16GB of memory in our consoles. Our content in this tech demo is fairly simple A real AAA title would likely have significantly more complex materials and more objects visible. Crucially however, the comparison between sfs and traditional mip streaming holds true regardless of material complexity. The numbers will scale with content and the multiplier will still ring true."



From 13:55 to 15:40 you see mip streaming with a next gen console and SSD, and after you see the clear difference with how SFS works.

 

[sinnergy]

No it doesn't - let's make that clear. The 'naive' implementation of PRT - trigger a read on page-fault, aka, how virtual memory worked since it's inception 30-40 years ago, is literally the most efficient you can be in terms of disc-reading only the data that is actively being accessed inside a frame. Naive - because such an approach would be loaded with I/O stalls, no matter how impressively fast your SSD is. What you want is a pre-fetch mechanism that can trigger I/O requests before they are explicitly made by the processor, but still remain close to accurate, especially since rendering is a predictable workload.

Predicting what will be needed during real draw calls is where SF comes into play, making such heuristics easier to implement. However, the end result is only as accurate as the chosen heuristics/algorithm (ie. the software) - it's not simply a function of hardware implementation itself.


Megatexture is a specialized implementation of the same thing.
Virtual Texturing became something of an umbrella term over the decades - it includes the above, but I've seen it used(or abused) for all manner of other things, including paging between different tiers of memory (as opposed to external storage), and not necessarily operating on partial-residency (but potentially whole mips/chains).

As for how often PRT got used - some games did, but with the amount of memory and I/O speeds on hand, streaming textures on per-mipmap basis was efficient enough to not really warrant jumping through extra hoops of other approaches. I/O stacks are already often neglected and dark-places of modern codebases (and changing them has significant workflow implications as well) so if you're going to change the paradigm the benefits need to be really significant.

Thanks for all your explanations, if MS automates most of these changes , so to speak , their tools stack is up to snuff , this could work very well.

On the other hand I think the solution by Sony, doing it all hardware wise could turn out the better choice.

 

[Shane89]

 

[Dodkrake]

Let's clarify something real quick.

Comparing BCPack to Kraken alone is not entirely correct, though it's mostly fair.

BCPack texture compression – details?

Hi all – BCPack is apparently an all-new texture compression codec developed by Microsoft for the new Xbox Series X console. They seem to have implemented it in a hardware decompression chip mated to the SSD, much like Sony did with Kraken on the PlayStation 5. Does anyone know more about what...

encode.su

Emphasis mine

BC1-7 encoding is lossy. BCPack is a lossless coder on top of the lossy BCn data. As such, comparing to Kraken is fair.

For BC1-5 there are several well-known, easy lossless transforms that tend to significantly increase compression ratio (5-15% reduction is common, depending on the BCn format and the data) with your usual LZ. This is really simple stuff. For example, a 64-bit BC1 block is 32 bits of color endpoints then 32 bits of 2-bit indices for every pixel in the 4x4 block. Reordering data to separate endpoints from indices, putting them into separate blocks (and so they get separate Huffman tables in say a Deflate stream), helps massively for coders that don't use the low-order bits of the position in the stream as context. This is a lot better than straight Deflate/Kraken on this type of data and both the Xbox Series S/X and the PS5 support it as part of their output write from the decompressor to memory. (Not quite free, but very nearly so.)

BCPack is more sophisticated than that, PS5 decided that the basic reordering plus Kraken was good enough.

So, let's break down the main differences, starting by another excellent post, this time from this very own thread:

XsX has hardware decompression engines Zlib /general data/ + BCPack /textures/.
PS5 has hardware decompression engines Kraken /general data/ + Oodle /textures/.

It seem that Kraken easily beats Zlib and lets say that Oodle and BCPack are equal, but we lack the exact data.

XSX/S

• Zlib for general game data
• BCPack for texture data

PS5

• Oodle Kraken for all game data
• Oodle Texture for texture data

Here's the deal - While most game data is comprised of Textures, the PS5 already has an advantage on other game data due to Kraken's advantage over Zlib. The compression ratio is already higher as a baseline, but the decompression stage is pretty much a no context. In theory, game devs can use higher compression on Kraken due to the time it takes to decompress said data (more compression = more time to decompress). So while a developer may settle on a 2:1 (made up numbers) with Zlib, it may go as far as 3:1 with Kraken, due to the time it takes to decompress being lower.

That said, the real advantage of BCPack comes with it being an all in one tool for both lossy and lossless compression. We don't know the exact numbers (as far as I'm aware, please correct me), but they could very well be better than Oodle Texture. The key difference comes to cost (2 hardware decompressors, with a tiny CPU impact vs single piece of hardware with no CPU cost). There's also nothing that prevents MS from using Kraken, but again, there would be added CPU cost (and wouldn't financially make sense)

Still, Microsoft's all in one solution is yet to yield better results on Next-Gen patched games (meaning games that are not gen aware, but actually patched to exploit next gen). This includes both decompression (Playstation loading times are more often than not ahead) but also games sizes (as evidenced by multiple games and patches).

On the topic of Compression and more in line with my fields of expertise, VFXVeteran do you have any idea if games using lossless audio files still run with WAV, or have they moved to Flac or other lossless compressed file formats?

 

[Techno_Inked]

Where are the games from Microsoft that showcases anything that people are claiming though?

 

[mrmeh]

He said that it’s not because of Kraken but there is something he can’t talk about. Wonder what the issue is and why they can’t talk about it unless it’s unfixable.

Maybe Sony PS plus deal, as noted the PS5 build had major code changes. They put in extra time re packaging assets, Xbox series version not so much.

Where are the games from Microsoft that showcases anything that people are claiming though?

I think there are bits here and there but I don't think direct storage has been fully released into the latest version of DX, maybe new first party games later this year will be able to show off some of the more interesting features. Same with the PS5 though, what games have been confirmed using Kraken/oodle? If the game isn't loading significantly faster on PS5 than X then it isn't. Still lots of cool stuff to come.

 

[Fafalada]

both the Xbox Series S/X and the PS5 support it as part of their output write from the decompressor to memory. (Not quite free, but very nearly so.)

Do we have any confirmation that both do this (as in the ASIC supporting re-ordering natively)? I assumed BCPack comes with this - but not sure what Kraken is implemented like.
Having to spend CPU cycles to reorder output would be a detractor from using alternate arrangements - you really want to run these hw-coders decoupled to get full benefit, especially at the throughput the SSDs afford.

Historical example - but MPEG2 decoding on PS2 took some jumping through hoops on arranging input streams(slight quality sacrifice, sadly) to get optimal output that 'just worked' for the GPU. Alternative where you had to constantly interrupt CPU processing to arrange things before GPU could use it was fiddly and just not very useable in high-performance scenarios, even if compressed quality was a bit nicer.

 

[Heisenberg007]

Maybe Sony PS plus deal, as noted the PS5 build had major code changes. They put in extra time re packaging assets, Xbox series version not so much.



I think there are bits here and there but I don't think direct storage has been fully released into the latest version of DX, maybe new first party games later this year will be able to show off some of the more interesting features. Same with the PS5 though, what games have been confirmed using Kraken/oodle? If the game isn't loading significantly faster on PS5 than X then it isn't. Still lots of cool stuff to come.

This is a weird take. I would perhaps have believed it if Control was the only game, but that's not the case anymore.

And unless the person can publicly say (and prove) exactly what it is, we should Ockham Razor this issue.