-
Ever wanted an RSS feed of all your favorite gaming news sites? Go check out our new Gaming Headlines feed! Read more about it here.
Gamingbolt: Xbox Series X’s BCPack Texture Compression Technique Reportedly Better than the PS5’s Kraken
- Thread starter Garrison
- Start date
2:1 ratio just isn't how lossless compression works. Both numbers will be inflated under some scenarios, ultimately it will depend more on the game dataset how close to that it lands rather then algorithms.
Makes a lot more sense when you look at it this way. Thank you
This too. I would imagine their hardware engineers thought long and hard about what SSD speeds they needed when they built this machine. Sony and MS just decided to spend their budgets differently, and that's ok. PS5 will stream assets faster and hide pop-in, Xbox will render with greater fidelity.
What I recall in xb360(i think it was back then) days was splitting lut and colors into separate blocks that compress better on average(and potentially use different compressor for each to maximize efficiency).
It's not something you need specialized silicon(assuming you have a codec like zlib already) for, the "non standard bit" is mem-copying two decompressed buffers into interleaved texture at the end.
Of course maybe its all something different for SXS but given they still implement LZ support in their asic as well, I kind of doubt its radically changed.
its funny, the article and a site isn't reliable but let that site give Death Stranding GoTY and it doesn't matter.
Consoles will be out soon and games for them will be shown sooner. I know this won't shut up people, but it will be good to get things calm around here.
Consoles will be out soon and games for them will be shown sooner. I know this won't shut up people, but it will be good to get things calm around here.
Is that Ging Sama person in the tweet the same person that posts here? The person is insufferable
The Series X is an incredibly designed piece of hardware. Can't wait for Microsoft to reveal more about some of the stuff they've kept hidden close to the vest.
A powerful and innovative console indeed.
A powerful and innovative console indeed.
lol you can often get an idea of whose concern trolling or low key warring by their social accounts outside of ERA. Don't wanna derail, see his timeline and you'll find your answer.
Because they use the best case (this is why they did not use the typical into the spec sheet). They use the BCPack best case scenario a 2 to 1 compression ratio and use it like texture will be the only type of assets.
Probably at least 2.5 more months of this til some does a E3 time reveal of games. At least there are some new AAA games to preoccupy people now.
Ah yes, that brings back memories of the early PS3 era and compiler auto vectorization. I'd forgotten about that, thank you. :)
When he gets attention basically. In this case tho, he appears to work in this specific field.
Even though the guy's an expert in the field I'm sure someone will say "hey don't listen to him, he don't know what he's saying"
Ignoring all this platform warring bullshit on Era for a moment, as a Dev, are you excited for next gen? Would love to hear your thoughts.
What's odd is if you were going to do a piece like this, why not do it on the reserved 100GB of the SSD that is supposedly allowed near ram speeds due to the Velocity Architecture. Granted we know next to nothing about that at this point, but that didn't stop them here, and that seems far more likely to bridge the SSD gap then this although I expect Sony to still maintain the edge.
No this is the 6 G/s and they did not lie. They just gave a theoretical number. This is the reason they did not write typical. For Sony it means in current game using the SSD the range is typically 8 to 9 GB/s.
massive advantage? How will this "massive advantage" translate in 3rd party multiplatform games?
How much does Sony pay more for the SSD itself and for the cooling of the SSD just to gain this advantage?
I would say, Microsoft approach is way smarter and in real world scenarios for 3rd party multiplatform games we won't see much of a difference except for loading screens. But MS is paying for that way less.
User Banned (2 Weeks): Platform Warring and Antagonizing Other Users; Prior Bans for Platform Warring
what is it at the moment with all these accounts with low post counts yet just shitting on the ps5 and promoting the series x in every next gen thread with nearly every post?
is the same happening with People shitting on series x and promoting ps5 with low posts?
you can spot them straight away, no avatar and clearly warring.
we don't know how 3rd parties will use the ssd until we see games or 3rd party devs openly speak about it. I can imagine rockstar might use it.
Xbox x has a large power advantage over pro and you barely see many 3rd parties doing much with it Except for higher res at sometimes the cost of the performance.
Well, bish had to bring out the lawnmower back at the old place at the start of this gen because there were so many marketing accounts active at the time, so maybe we're seeing a repeat of that.
Or maybe people just dusted off their alts / created new alts for platform warring.
I don't know, especially if everything is countered with "but company X can do that, too!".
Of course Microsoft can use Kraken, Sony didn't buy RAD. They "only" implemented Kraken in hardware, like MS did with Zlib and perhaps both do more on their ASIC. We just don't know the specifics but do know that both thought it would be important for their consoles to put lossless codecs into a dedicated chip to save CPU cycles.
I remember house marketing accounts, I didn't think they would try that again... but people seriously making alts to platform war though that's next level sad.
That's not how this works. the 4.8 GB/s number for XSX and 9 GB/s for PS5 is with BCPack and Kraken in use. As many posters have pointed out, the XSX numbers show a significantly higher boost going from 2.4 to 4.8, compared to the PS5 SSD bandwidth going from 5.5 to 8/9.
That's exactly what this article is talking about. Microsoft is getting more bang-for-the-buck with their compression scheme. It's still not nearly enough to match the PS5 SSD though.
There is also the possibility of using it as non-volatile, slower RAM. The PS5 SSD can match mid-tier DDR2 RAM without compression, low/mid-tier DDR3 if the compression numbers hold up. That's fast enough to potentially be used as RAM for some workloads, depending on the latency. While nothing concrete has been said about that so far, we do know that the PS5 SSD controller supports an unusually high number of priority levels. That does seem to indicate that they expect it to need to handle some very low-latency operations.
Incidentally, the XSX SSD is equivalent to mid-tier DDR1 w/o compression, and low/mid-tier DDR2 if their compression numbers hold up. That's a huge difference.
'there are lots of things being talked about on both sides that can actually end up being standard rdna 2 features or MS/Sony adaptations vis drivers etc) of those features. going to take a while to see which ones are properly available on which platform
Sampler feedback does seem like a potentially big one - effectively reducing bandwidth used will help a lot
Yes, of course. :D I'm looking forward to more stuff getting announced and the consoles releasing. ;)
Unless I missed something there's no confirmation about hw decoding for BCPack. And it's probably not necessarily needed. Usually formats like these are created with decompression speed in mind, it's not unusual to decompress on the CPU at nearly RAM speed. The biggest win of dedicated hw wouldn't be the throughput, but the removal of that burden from the CPU to a dedicated hw block. It's a tradeoff between the cost of additional silicon and the CPU decompression cost. This is another thing where sampler feedbacks would help, as you wouldn't waste time (ideally) decompressing mip levels you don't need.
It's all theoretical ofc until actual public figures are released, but BCPack has the chance to be much more efficient than BC7 in terms of space. I've seen texture compressor compress BCn data up to x20 times smaller with little degradation in quality. BCn is a format that's not compressing much at all, it's meant to be very cheap to decompress transparently on the fly by the GPU, but it's very unoptimised for disk space/storage. Even with only loseless compression you can easily reach 4-5x additional compression on top of it.
Yeah until Sony publicly confirms exactly what went inside of PS5 from the standard set of RDNA2 features it's hard to tell.
Features like samplers feedback require a modified texture unit to work and cannot be emulated via software tho (I cannot think of a way to do it at least).
Maybe I've picked up on it wrong, but it seems like the logical conclusion of work that (afaik) started with Lionhead's work on megameshes and for milo&kate - which basically was a kind of feedback based virtual texturing system. They rendered a low res version of the scene up front and used that to determine which textures and what levels to bring into their physical memory page. You could do it at full res also as part of an early-z pass. Then defer your texture sampling as late as possible in the frame, in the hope that by the time you need the textures, more of what you pinpointed you would need in that early pass will be in memory.
With lower latency and higher bandwidth streaming it might be possible to do that now without, or with fewer, temporal artifacts. I wonder how much texture data you could shuttle from ssd to memory in - say - 10ms. I think ideas like that might come back en vogue, or more 'precise'/aggressive versions of that might come to the fore again, if the performance is there to bring in texture data intra-frame, or even within 1 or 2 frames. (And funnily enough, this is one area where I think the sky is the limit on useful SSD performance).
Sampler feedback sounds like a way to make this easier and/or more precise. But if you were trying to do the same in software, I think you probably wouldn't try to emulate the texture unit behaviour used therein - you'd skin the cat a different way. You'd approach the problem from another vector, like an early pass over the scene, or a copy-back of the last frame as in occlusion culling. I think independent of new hardware support, I think you'd see new experimentation in virtual texturing purely because of the bumps in gpu and ssd performance - although I hope Sony also has new supports like that in hardware too, just because it would make that work easier.
I'm fairly certain the hardware support for SFS is part of RDNA2. Microsoft's own Github page on the feature mentions that there are already multiple GPU's compatible with the feature.
Oh yeah, in theory it can be done. All you need are screen space UV derivatives to estimate the needed mip.
In practice I'm not sure it's doable without doing more harm than good. And this is leaving aside the galaxy-scale pain in the ass that would be developing and debugging such a system.
It's kinda like TAA, everything will start to look like a wrong mip artefact :p
Possibly it'd be easier and more manageable by limiting the scope of it, applying it only to something like the virtual texturing system used for terrain in Far Cry, but even then it's just speculation. I guess some real R&D is needed.
I *think* the original research and idea for it came from Microsoft, and if that's the case it's not unreasonable to think Sony did not have access to it even tho the base architecture is still RDNA2. It would be nice for Sony to publicly confirm all these details but I suspect it's gonna be quite a while before it happens.
Again, I'm just going by the DirectX Github that says multiple GPU's can support the feature (it says to contact GPU vendors to confirm which GPU's support it, but it also gives a command to type in to check if the GPU you're currently working on supports it). It's basically a more advanced version of PRT, and apparently is sometimes referred to as PRT+.
OP
OP
