Microsoft Flight Simulator's cloud debut comes with upsides for devs

Currently, when you have a game with say 10k separate asset files, you either place 10k asset files in the file system (which is slow because NTFS) or you develop some sort of your own virtual read-only filesystem on top of that (which has been done for decades too, see e.g. the WAD format created for Doom). And there have been many implementations for these, and yet they suffer from two things: the OS filesystem cache can't know which parts of such a package file (aka the index) are relevant to always keep in memory, and the game has to copy the assets to the GPU.

The general idea, if I get it right, is that DirectStorage provides a standardized layer that:

- cuts down on filesystem-related overhead by providing its own optimized filesystem (e.g. omitting journals because the purpose of the storage is 99.99% read vs write), or even if they don't go that far and use a-blob-on-NTFS at least to cut down on fopen, fclose etc.

- provides a standard way for game developers to deal with the problem "how to package and distribute tons of tiny assets and compressing and decompressing them"

- saves context switches across the road, e.g. as mentioned eliminate fopen and fclose calls or by copying the file contents to the GPU entirely in kernel mode

Nevertheless I'm not sure what outside of copying assets to the GPU in kernel mode actually will be the benefit of DirectStorage as almost everyone these days uses one of the major engines that have all these problems dealt with for ages.

Hence the API.

Many (maybe most, still) games have embarrassingly single-threaded game logic (i.e., there's still one "runloop" thread which manages game state), but almost universally at this point there's a separate thread for loading data, decompressing data, asset / script compilation, and audio. Many games also use a separate thread for physics as well, and some use worker threads for AI / rules engine NPC behavior as well.

Anyway, loading data is where the parallel and batched nature of modern gaming workloads comes in - almost all games at this point do some kind of constant background asset loading to avoid the need for load screens between areas. This asset loading is almost always done in a background thread and is pretty much a 1:1 match for an NVMe queue - request the blocks containing the data you need, ask to be flagged when a block has been DMAed into the memory area you want it in, and then decompress it in the background.

This clearly isn't aimed at your average Unity game. I've not seen any big AAA game in the last decade that's "laughably single threaded" when it comes to asset handling, which this API is all about.

Single-threaded computation is for serialized state mutations in the main game loop. Everything else, like loading data, can and does happen on other threads. The latest engines use a job dispatch system with fractured/sharded state to distribute work as much as possible across cores.

As far as this topic, loading new data is already done in parallel, and can now be further parallelized at the block level with built-in APIs with the typical OS overhead or custom virtualization layer.

1. People who game alot or are just well off might have 32GB, but game publishers need to support much lower configs than that (the recommended minimum for GTA5 is 8GB and it technically supports 4, for the newer Cyperpunk 2077 those figures are still only 12GB and 8). Last time I saw Steam hardware survey results less than 50% of machines surveyed had 16GB or more RAM.

2. Even if we consider with 16GB to be the minimum for a serious gamer, you aren't going to use most of that for caching assets. Even if you could use 10GB worth, with a massively open play area¹ how easy is it to manage which 10GB of the assets do you load? Both the games I've mentioned weigh in at about 70GB. If the user skimped on RAM and GPU to get a nice large fast NVMe drive, being able to stream data as directly as possible between that drive and the graphics RAM is going to be an attractive optimisation, both from initial load and as new assets are needed mid-game.

The core game engine not taking full advantage of 16 cores with of CPU when they are present[2] doesn't mean that more direct transfer of data from storage to GPU, keeping CPU use to a minimum³, can't be useful. Having spare cores lying around is nice, but someone with only 4 might not have that luxury, and even if you have some cores otherwise doing nothing that doesn't mean skipping the CPU as much as possible³ can't be noticeably better than using a fast core. Even if the CPU does still have to be involved, APIs like this could massively reduce user↔kernel transitions which can be pretty expensive.

[1] this is less of an issue for games that can be easily split into more manageable chunks

[2] again, think about the larger part of the market: 4 cores is still very common

[3] let the game logic running on the CPU decide a transfer should happen, then have the transfer go directly over the bus instead of via the CPU and/or main memory at all

What you say is probably true of most indie games. That's a whole different world. But the 'state of the art' is perfectly accurately described by 'batched and parallel workloads'.