This was before Oodle texture. I suppose we will see game well above 10 GB/s with it. if no Sony would have gone with a slower decompressor, it would have been cheaper.
Blazing Fast NVMEs and Direct Storage API for PCs *spawn*
- Thread starter DavidGraham
- Start date
This was before Oodle texture. I suppose we will see game well above 10 GB/s with it. if no Sony would have gone with a slower decompressor, it would have been cheaper.
Are we sure that PS5/XSX decompression parts aren't built into the GPU/RDNA2?
If you see the road to PS5 Sony use fixed function decompessor, same for XSX.
That would be pretty interesting if Direct Storage were not only a new IO Standard to avoid Windows bottlenecks and serialisation, but also a standard compression Format from MS as well. It makes a lot of sense to me when you put it like that and also point out the 2:1 bit.
I spent those 60 seconds decompressing
I'm still not convinced Oodle texture wasn't accounted for in Sony's original numbers. They would have known about RDO texture compression long before then and presumably had the relationship with Oodle to know it was in the pipeline. Plus, while I've seen some wildly different compression ratio's stated for Kraken and Kraken+Oodle texture, the more consistent ones put Kraken+Oodle texture more in line with Sony's already advertised 1:1.64 as far as I can tell.
Most likely yes, im not convinced they where actually designing something not knowing anything about the different compression ratios.
I think what matters if its random access. If the compression format isn't random access, it's pretty much pointless. You're going to retrieve the whole texture to display a fraction of it. It's much more efficient to send the portions you need to see only instead of sending the whole texture.
I'm fairly positive that zlib, kraken and BC Pack are all random access (for images). AFAIUnderstand How many threads isn't not as important on the GPU because you're going to assign the texture blocks accordingly so you can decompress all you need across how many available threads you have.
Last edited:
Yea, what's important is getting the level of throughput up to a reasonable baseline.
Even if it was slower than the dedicated blocks, it doesn't matter, as it has compute to spare where consoles don't.
If latency isn't as good, also doesn't matter as games need to be able to handle the variety of performance that pc's have, inc wide range of ssd speeds.
Wondered if it wasn't demoed due to direct storage not being 100% ready, or them not having drivers for it yet. Looks like sort of thing they would've demoed.
D
Deleted member 13524
Guest
We don't know what's in RDNA2, but it's definitely not what's in both consoles since they're using different approaches.
@Dictator using what compression formats and assuming what compression ratio? Is it counting with delta color compression on the GPU or not?
Those 14GB/s just seem like 2x the maximum raw throughput of a NVMe 4x PCIe 4.0 (7GB/s), but unless there's a lot more info other than that single slide (which ambiguously throws directstorage software optimizations into the mix), then those are some pretty hefty claims out of very little data.
Thanks.
Impressive, gotta see DF star citizen comparisons with slower alternatives. And between multiplat games ofc.
Infinisearch
Veteran
Didn't AMD have something like this for a long time now?well nvidia just announced hardware on their new cards to enhance data transfers
I forgot what it was called but when gpuopen had both the graphics side and the professional compute side, there was something that was about direct to gpu over the pcie bus.
All without cpu intervention... I'll see if I can track down the name...
edit - direct gma from AMD's firepro line. In case the link wasn't enough.
https://web.archive.org/web/20160318200424/http://gpuopen.com/compute-product/direct-gma/
Last edited:
Infinisearch
Veteran
Is this oodle thing for already installed games as well? or only developers? It seems interesting.
The following quotes from the article really make it sound like you'll need an nvme that supports DirectStorage, and maybe other components as well.
https://devblogs.microsoft.com/directx/directstorage-is-coming-to-pc/
https://devblogs.microsoft.com/directx/directstorage-is-coming-to-pc/
Silent_Buddha
Legend
While it may not be dedicated hardware, it isn't necessarily using general compute shader cores. Considering the limitation (Turing and Ampere) it's far more likely that it's doing it on the Tensor cores. Something that doesn't generally get fully utilized in games.
It'll certainly be interesting to see how AMD approaches this. Considering that MS was the key driver for having packed int4 and int8 added to the GPU in XBSX, I could see this potentially getting leveraged for DirectStorage if AMD decide to adopt packed int4 and int8 into RDNA2, assuming of course that NV's support is reliant on their Tensor cores.
Another possibility is the dual issue fp32. Considering that may or may not get leveraged much in games, it's possible that NV could use some of that capability for DirectStorage without hindering game performance.
Regards,
SB
I was thinking in something like MKV for games. A package made of (code+shaders+audio/music+assets).
All of those assets compressed in the new format.
If your system has Direct Storage, the GPU is in charge, if not a classic installation is needed.
This was interesting, especially the DirectStorage API thing.
@SebAaltonen: DirectStorage:
https://t.co/i0Zt0e886k
Seems like a great improvement. But no mention about directly memory mapping the SSD as a GPU visible resource. That would be true next gen.
@SebAaltonen: DirectStorage:
https://t.co/i0Zt0e886k
Seems like a great improvement. But no mention about directly memory mapping the SSD as a GPU visible resource. That would be true next gen.