Next-Generation NVMe SSD and I/O Technology [PC, PS5, XBSX|S]

Sigh.....Quick resume is not Direct Storage.

EDIT: Reading that article where do they say Direct Storage is tied to Quick Resume?

And parts of Velocity Architecture can be used without using Direct Storage API.

But back on point, AC Valhalla doesn't use Direct Storage as proven by its load times.
Quick resume depends on DS. What the author writes is contradictory to what MS states as Ronald says the possibility of QR on PC is dependent on DS being on PC in a stable form.

Velocity Arch core components are the nvme SSD, DS, SFS and decompressors. The most relevant components for QR would be the SSD and DS.

Why would you write an api that allows you to bypass the cpu and write data directly into gpu memory only to offer a QR solution that makes no use of it?

QR basically involves saving the state and storing 13.5 GBs of the current title to the SSD and loading in 13.5 GBs and state of the targeted game. DS removes the need to copy and shuffle data around once it hits RAM.

AC Valhalla is doing this in 5 seconds. The length of load times of ACV is an issue that exists outside of DS.
 
Last edited:
People forget two or three things.

First the PS5 API is easier to use and Mark Cerny told most of the work is hidden to the dev. This fact was confirmed by DigitalFoundry heard from developers feedback in a DF direct. Basically the dev just need to load files by batch in uncompressed format with a priority for each one and the job is done. Other side of the job is to package the data correctly using the Sony packaging tools. The tools automatically compress the data and this is great because some indie dev don't compress data at all. This is visible with much smaller game size for PS5 version of some PS4 indie game.

They call the API integrated I/O around 3:49

Second part the impression the gamer feels about loading data is more than the I/O stuff and the game engine can reach a bottleneck elsewhere. In R&C Rift Apart, Matrix Awakens demo and Forspoken this is the initialization of entity in a level or a world partition. Insomniac game use a custom allocator because standard C/C++ malloc is too slow and it was one of the reason loading data was so fast.

Third most of the stuff will be invisible to gamers out of loading speed and better assets quality. For example in the future maybe games will have better transition between biome too but I am not sure people will see it. People won't have any idea how designer and programmer life is simplified by fast storage and I/O. People didn't understand the R&C portals makes developers life easier. People forget in some game there are some loading screen between interior and exterior. In Spiderman post mortem at GDC, Elan Ruskin told a sequence with a transition from exterior to the interior building took months to be done because they needed to created a cinematic to hide the loading time and timed the stuff perfectly. The pacing of AAA games is dictated by slow storage stuff like the dimension stuff between portals in God of war or elevator in Bioware games or Meridian city in Horizon Zero Dawn. Cinematics or elevator are made for hide loading.

 
Last edited:
Quick resume depends on DS.
No it doesn't.........as proven by the article you linked to... "DirectStorage is a foundation that could pave the road to Quick Resume on PC, but it doesn’t inherently make that feature tick"

Right there in black and white from your own article, QR doesn't depend on Direct Storage.
Velocity Arch core components are the nvme SSD, DS, SFS and decompressors. The most relevant components for QR would be the SSD and DS.
Direct Storage is not a feature QR depends on as quoted above from your article.

It's only storing the game state to the HDD which can be done without Direct Storage.
QR basically involves saving the state and storing 13.5 GBs of the current title to the SSD and loading in 13.5 GBs and state of the targeted game.
I know how Direct Storage works.
The length of load times of ACV is an issue that exists outside of DS.

False....

But you're confusing how QR actually works and how it's integrated.

QR is not a game feature, it's an OS feature so a game doesn't need to use Direct Storage to take advantage of QR as the OS handles it, not the game.

Why do you think QR works on Xbox 360 and Xbox One games? Because QR doesn't need or depend on Direct Storage being used by the game.

So once again, AC Valhalla is not using Direct Storage.
 
CPU's are programable and can decompresses pretty much anything, so decompressing GDelflate won't be an issue for them, the only thing is the speed at which they do it.

So a game could very well have a pure Direct Storage compression format and still use the slower CPU route for users who do not have a fully Direct Storage compliant system.

Pretty sure GDeflate has fallbacks, including ability to run on CPU's if required.

Yeah I did reference this further down in the paragraph:

Highly unlikely. The games will either ship pre-compressed in the DirectStorage compression format (GDeflate) or they will ship in some other, CPU decompressable format and thus be unable to use GPU decompression. There won't be any install time detection of hardware capabilities that can change the compression rate of the game. Not unless the devs package two different versions of the game and allow the user to download the one appropriate for their hardware capabilities. I find this very unlikely because the vast majority of PC hardware will already be capable of hardware decompression (any GPU since Maxwell or GCN), and where that hardware doesn't exist, DirectStorage still has a CPU fallback path. It's also free for developers to use unlike some of the more popular CPU based compression formats, so there's simply on reason for developers not to use it.

What we don't know at present is whether GDeflate has a better, worse, or similar compression ratio vs something like Kraken and so there may still be some variation in install sizes vs say the PS5.
 
Valhalla may take 27 to load from start up. It takes 5 from quick resume. Quick resume is tied to Direct Storage as QR is reliant on the Velocity arch on Series console.


Great article. Answers a lot of questions about Quick Resume on PC that I'd wondered about myself. I may also try that process suspend trick to see how well that works. The site really needs to autoload the desktop site though when accessed from a desktop! Reading the mobile version on a 38" ultrawide in landscape mode is not a pleasant experience lol.
 
Last gen game engines don't just magically gain the ability to use all new hardware features.
Perhaps I'm being naive, but if you're using the API calls, they basically should. The file is on storage in a format. You call a system function to fetch that data into RAM. Originally this was raw, or a compressed file you decompressed yourself. To change for XBS*, route to the new IO call and compress the file.

I suppose if the engine is using a finer-grained data file and streaming piecemeal or somesuch, you couldn't swap in a new IO system. But loading complete assets as is typical should surely just be a case of swapping the old LoadFile("filename") to the new LoadCompressedFile("Filename") and have the OS route the IO through the hardware to get it from storage into RAM.
 
No it doesn't.........as proven by the article you linked to... "DirectStorage is a foundation that could pave the road to Quick Resume on PC, but it doesn’t inherently make that feature tick"

Right there in black and white from your own article, QR doesn't depend on Direct Storage.

Direct Storage is not a feature QR depends on as quoted above from your article.

It's only storing the game state to the HDD which can be done without Direct Storage.

I know how Direct Storage works.


False....

But you're confusing how QR actually works and how it's integrated.

QR is not a game feature, it's an OS feature so a game doesn't need to use Direct Storage to take advantage of QR as the OS handles it, not the game.

Why do you think QR works on Xbox 360 and Xbox One games? Because QR doesn't need or depend on Direct Storage being used by the game.

So once again, AC Valhalla is not using Direct Storage.

Direct Storage is just the API. Unless the Xbox also makes the legacy Win32 storage API available to developers then by default all games should be using Direct Storage. That doesn't necessarily mean they'll be using the hardware decompression block though as developers may choose to use a different compression format which it doesn't support. Also as chris1515 mentioned, other aspects of the loading process may be causing the bottleneck at load time rather than the IO stack. In fact from what I've read, most games are probably bottlenecked by the CPU rather than the IO system both on consoles and PC.
 
Perhaps I'm being naive, but if you're using the API calls, they basically should. The file is on storage in a format. You call a system function to fetch that data into RAM.

So why isn't Direct Storage working in every new game if that were the case?

Why does Xbox Series X/S have games that take longer than 5 seconds to load?

The new hardware units (And API's) still need to be integrated in to game engines to work.
 
So why isn't Direct Storage working in every new game if that were the case?
That's precisely the question. ;)

From your perspective looking from results, it must require some effort otherwise all games would be using it.
From the other perspective looking at how IO calls are integrated with game engines, it can't be that big a job to update a game if it's using DX calls. This assumes a certain level of transparency in how DXS works though and maybe it's not a straight-forward interface, for whatever reason?
 
It must require some effort otherwise all games would be using it.
Exactly.

There's likely many reasons for it.

But PS5 is also in the same boat, how many games take advantage of its solution outside of Insomniacs games?

Insomniac have ven said there engine isn't best suited to working with PS5's fast storage and will need some work.

What's to say other engines aren't also not ideally set up to handle fast storage?
 
Why does Xbox Series X/S have games that take longer than 5 seconds to load?

Where is the information showing its actually spending time in loading from storage? Ie: it's busy doing other things not related to IO at all.
 
Exactly.

There's likely many reasons for it.

But PS5 is also in the same boat, how many games take advantage of its solution outside of Insomniacs games?
Well that could be explained by PS titles tending to use lower level libraries. XBS* is a best-case scenario as it's using the high-level abstractions. That is, more titles on XB will be using system level calls for IO than potentially PS where there's more chance of the loading management being more dependent on the developers implementing it.
Insomniac have ven said there engine isn't best suited to working with PS5's fast storage and will need some work.

What's to say other engines aren't also not ideally set up to handle fast storage?
Spider-Man is a somewhat optimised streaming game. Open world games are more likely to use fine granularity of the data. Many games use wholesale assets though. I can't see why the API isn't simply a case of requesting the loading of a compressed file from storage. however, I don't know how DXS fits in with the other system IO and maybe it's not as easy as that?

I'm just positing, though. Someone with access to documentation to be able to explain!
 
Well that could be explained by PS titles tending to use lower level libraries. XBS* is a best-case scenario as it's using the high-level abstractions. That is, more titles on XB will be using system level calls for IO than potentially PS where there's more chance of the loading management being more dependent on the developers implementing it.

Spider-Man is a somewhat optimised streaming game. Open world games are more likely to use fine granularity of the data. Many games use wholesale assets though. I can't see why the API isn't simply a case of requesting the loading of a compressed file from storage. however, I don't know how DXS fits in with the other system IO and maybe it's not as easy as that?

I'm just positing, though. Someone with access to documentation to be able to explain!

The I/O part is only one part of the equation. When they optimize the I/O, Insomniac arrive at 5 GB/s and the bottleneck was the CPU and the initialization of entities and they needed to optimize this part of the engine cannot keep up with storage speed. Elan Ruskin(lead game engine programmer) told on twitter Insomniac use a custom memory allocator because the standard C/C++ malloc is not performant enough. He verify how the game engine teams does there allocation if one dev use more than 1% of the resources he receive a bug notification and it helped reach 5 GB/s. They probably can go further but it was not the priority for R&C Rift Apart.

Naughty Dog told they had a very sophisticated streaming engine and they ditch it totally for Uncharted legacy collection because storage is fast enough.

Some slowdown between world partition in the Matrix Awakens demo wasn't a problem of I/O at all but initialization of entities was not fast enough. They probably optimize this part because the city sample was not running at 60 fps locked on a powerful PC CPU until UE 5.1. Forspoken developer told the current bottleneck is not the I/O but initialization of entities but they did at least partially some optimizations.

Fabian Giesen(RAD tools game) helped developer using Kraken and said developers need to change how they use the I/O first but said there are other parts of the game engine where performance need to improve or some bug like in Bethesda case with loading data linked to refresh rate of the TV/monitor. Game engine aren't tailored around fast storage, for example many engines are loading one file at a time and not in batch, or some operation are single threaded like initialization of entities because it was not a bottleneck. Every part of the game engine running when loading a level can bottleneck the loading.
 
No it doesn't.........as proven by the article you linked to... "DirectStorage is a foundation that could pave the road to Quick Resume on PC, but it doesn’t inherently make that feature tick"

Right there in black and white from your own article, QR doesn't depend on Direct Storage.

Um? Quick Resume needs Direct Storage to work on PC and on Xbox Series consoles, it's right there in the article.

To even enable Quick Resume, you’d essentially need a mirror of Xbox’s Velocity Architecture, which combines a fast PCIe SSD, the Direct Storage API, hardware decompression blocks, and sampler feedback streaming.

Note how the DirectStorage API is required. It isn't the only requirement, but it is one of the required elements for it to even work.

So, according to one of the architects of QuickResume and the Xbox Series consoles I/O subsystem, you need at least the following to enable Quick Resume on PC.
  • a fast PCIE SSD
  • Direct Storage API
  • Hardware Decompression
  • Sampler Feedback Streaming
Those are the foundations required before you can even think of enabling Quick Resume on PC because those are what is required for it to word on Xbox Series consoles. If any of those are missing, then Quick Resume is a no go.

Heck, Dobwal even posted a quote containing the relevant quote from the architect that states in no uncertain terms that Direct Storage is required.

Ronald said that Quick Resume wouldn’t be possible “unless DirectStorage was [on PC] and stable in the ecosystem,” but it’s important to keep in mind that it took over two years for the Xbox team to get it stable on a closed console ecosystem.

Or to think of it another way. Any game using Quick Resume is by the very definition of what is required for Quick Resume to work ... using Direct Storage when using Quick Resume.

It doesn't matter whether or not the game code takes advantage of Xbox Series consoles Velocity architecture. When using Quick Resume all data is stored and loaded from SSD using it.

Regards,
SB
 
Last edited:
Why would DirectStorage be required? Makes absolutely no sense, and I'd say that Jason Ronald is just giving it as an excuse. There's plenty of other issues I could see getting in the way.. before DirectStorage.
 
Um? Quick Resume needs Direct Storage to work on PC and on Xbox Series consoles, it's right there in the article.



Note how the DirectStorage API is required. It isn't the only requirement, but it is one of the required elements for it to even work.

So, according to one of the architects of QuickResume and the Xbox Series consoles I/O subsystem, you need at least the following to enable Quick Resume on PC.
  • a fast PCIE SSD
  • Direct Storage API
  • Hardware Decompression
  • Sampler Feedback Streaming

I read that part of the article as being the authors own statement rather than a Microsoft quote. He's simply listing the components of the "Velocity Architecture" there but I don't see why sampler feedback streaming (or just sampler feedback) would in any way be required for quick resume. In fact besides Direct Storage itself I'd say none of that is required. Although the NVMe and hardware decompressor will obviously help make the quick resume quicker vs doing it on a CPU.
 
I read that part of the article as being the authors own statement rather than a Microsoft quote. He's simply listing the components of the "Velocity Architecture" there but I don't see why sampler feedback streaming (or just sampler feedback) would in any way be required for quick resume. In fact besides Direct Storage itself I'd say none of that is required. Although the NVMe and hardware decompressor will obviously help make the quick resume quicker vs doing it on a CPU.

It's possible, but the author does indicate that they've consulted with Jason Ronald extensively for the article. So much that they went back to him multiple times for clarification of aspects of the article before publishing it.

Regardless, Jason Ronald is directly quoted multiple times indicating that without Direct Storage, Quick Resume is not possible on PC. They won't even think about making Quick Resume work on PC until they have a stable Direct Storage API that works across a wide range of hardware stably. And that's just the starting block for them to even think about whether Quick Resume can work reliably on PC. No Direct Storage API, no possibility of Quick Resume.

“I don’t want to say never,” Ronald said. “But right now, our focus is on bringing things like DirectStorage to the PC, and that could open up the possibility in the future.”

Regards,
SB
 
It's possible, but the author does indicate that they've consulted with Jason Ronald extensively for the article. So much that they went back to him multiple times for clarification of aspects of the article before publishing it.

Regardless, Jason Ronald is directly quoted multiple times indicating that without Direct Storage, Quick Resume is not possible on PC. They won't even think about making Quick Resume work on PC until they have a stable Direct Storage API that works across a wide range of hardware stably. And that's just the starting block for them to even think about whether Quick Resume can work reliably on PC. No Direct Storage API, no possibility of Quick Resume.



Regards,
SB
It just makes no sense. Unless bypassing components of the Windows security and storage stack are requirements.. ?
 
Um? Quick Resume needs Direct Storage to work on PC and on Xbox Series consoles, it's right there in the article.

So explain how Quick Resume works on Xbox 360 games via backwards compatibility mode as those games won't be using Direct Storage, same for Xbox One games, no Direct Storage but yet still support Quick Resume.

Quick Resume will work completely fine without Direct Storage on PC as saving states is something we can do on PC already in virtual machines and emulators.

Would it save/load states without Direct Storage fast enough to be called Quick Resume? Who knows but that's a whole different conversation.
 
Last edited:
So explain how Quick Resume works on Xbox 360 games via backwards compatibility mode as those games won't be using Direct Storage, same for Xbox One games.

Quick Resume will work completely fine without Direct Storage on PC as saving states is something we can do on PC already in virtual machines and emulators.

Would it save/load states without Direct Storage fast enough to be called Quick Resume? Who knows but that's a whole different conversation.
Exactly. The speed at which it resumes.. really has no bearing on how the actual process is required to work. Whether it is fast or not would depend on your storage... but not whether it would work or not.
 
Back
Top