6 ms·

This piece from the article was interesting: "NVMe devices are not only extremely high bandwidth SSD based devices, but they also have hardware data access pip

This piece from the article was interesting: "NVMe devices are not only extremely high bandwidth SSD based devices, but they also have hardware data access pipes called NVMe queues which are particularly suited to gaming workloads. To get data off the drive, an OS submits a request to the drive and data is delivered to the app via these queues. An NVMe device can have multiple queues and each queue can contain many requests at a time. This is a perfect match to the parallel and batched nature of modern gaming workloads. The DirectStorage programming model essentially gives developers direct control over that highly optimized hardware."

sidewndr46 5y ago
> This is a perfect match to the parallel and batched nature of modern gaming workloads This sounds like marketing speak. Some 'AAA' games now make use of parallelism at the CPU level. Almost all games today aren't just single threaded, they are laughably single threaded. At the GPU level, rendering has been parallel to some degree since special purpose 3D accelerators showed up decades ago. More recently, arbitrary shaders have allowed some logic that was previously done of the CPU to be moved to the GPU. Video games are not "parallel" in any sense.
- bri3d 5y ago
  > Almost all games today aren't just single threaded, they are laughably single threaded. 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.
- magicalhippo 5y ago
  > Almost all games today aren't just single threaded, they are laughably single threaded. 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.
- manigandham 5y ago
  Modern games use multiple threads for more than a decade now. 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.
- dspillett 5y ago
  A large part of loading delay, either initial load or between levels/areas, in some games is getting high-res textures and other bulk data from storage into the graphics memory. You might think “just cache it in RAM, my 6GB graphics card is far smaller than the 32GB sat on my motherboard”, but there are two issues there: 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
  - paulmd 5y ago
    1. "people who are well-off might have NVMe SSDs, but most people are using much lower specs than that" 2. "even taking NVMe SSDs to be the minimum, even the people who do have them usually can't afford to allocate up to 250GB for a single game, let alone when a shitty patching system requires double that to apply a patch". it's certainly a step forward as far as loading technology, don't get me wrong, but it's not about people with low-spec systems at all, you need NVMe as a minimum ask for this, and you need quite a bit of it.
- psyc 5y ago
  I think this assertion is terribly outdated for 'serious' (Console/AAA) games and 'professional' game developers. I can remember as far back as 2007 interviewing for an XBox360 job, and being asked to describe in detail how I would keep all the threads busy. A professional game developer working on a serious high-detail/low-latency game would not be taken seriously if they don't know how to make a work queue. 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'.
Animats 5y ago
That's a real thing for game consoles. The PS5 has 16GB of RAM, which is directly accessable by the CPUs, GPU, and SSD controller. So you can load an asset directly from SSD to GPU memory without a recopy. In a PC, you'd have copies from disk to disk drive cache to OS memory to user space to GPU memory. Also, in a console, where you know exactly what the hardware configuration is, you can store the assets in exactly the form the GPU wants. This has nothing to do with "cloud", though.
- sidewndr46 5y ago
  I can see Microsoft making it a requirement to be logged in to a cloud service to take advantage of DirectStorage.
MrFoof 5y ago
>An NVMe device can have multiple queues and each queue can contain many requests at a time. To put this into perspective, whereas AHCI/SATA (NCQ and TCQ) has one command queue with a depth of 32 commands (SAS has a queue depth of 254 commands), NVMe is designed to have up to 65,535 queues with as many as 65,536 commands per queue.

sidewndr46 5y ago

> This is a perfect match to the parallel and batched nature of modern gaming workloads This sounds like marketing speak. Some 'AAA' games now make use of parallelism at the CPU level. Almost all games today aren't just single threaded, they are laughably single threaded. At the GPU level, rendering has been parallel to some degree since special purpose 3D accelerators showed up decades ago. More recently, arbitrary shaders have allowed some logic that was previously done of the CPU to be moved to the GPU. Video games are not "parallel" in any sense.

bri3d 5y ago
> Almost all games today aren't just single threaded, they are laughably single threaded. 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.
magicalhippo 5y ago
> Almost all games today aren't just single threaded, they are laughably single threaded. 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.
manigandham 5y ago
Modern games use multiple threads for more than a decade now. 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.
dspillett 5y ago
A large part of loading delay, either initial load or between levels/areas, in some games is getting high-res textures and other bulk data from storage into the graphics memory. You might think “just cache it in RAM, my 6GB graphics card is far smaller than the 32GB sat on my motherboard”, but there are two issues there: 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
- paulmd 5y ago
  1. "people who are well-off might have NVMe SSDs, but most people are using much lower specs than that" 2. "even taking NVMe SSDs to be the minimum, even the people who do have them usually can't afford to allocate up to 250GB for a single game, let alone when a shitty patching system requires double that to apply a patch". it's certainly a step forward as far as loading technology, don't get me wrong, but it's not about people with low-spec systems at all, you need NVMe as a minimum ask for this, and you need quite a bit of it.
psyc 5y ago
I think this assertion is terribly outdated for 'serious' (Console/AAA) games and 'professional' game developers. I can remember as far back as 2007 interviewing for an XBox360 job, and being asked to describe in detail how I would keep all the threads busy. A professional game developer working on a serious high-detail/low-latency game would not be taken seriously if they don't know how to make a work queue. 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'.

Animats 5y ago

That's a real thing for game consoles. The PS5 has 16GB of RAM, which is directly accessable by the CPUs, GPU, and SSD controller. So you can load an asset directly from SSD to GPU memory without a recopy. In a PC, you'd have copies from disk to disk drive cache to OS memory to user space to GPU memory. Also, in a console, where you know exactly what the hardware configuration is, you can store the assets in exactly the form the GPU wants. This has nothing to do with "cloud", though.

sidewndr46 5y ago
I can see Microsoft making it a requirement to be logged in to a cloud service to take advantage of DirectStorage.

MrFoof 5y ago

>An NVMe device can have multiple queues and each queue can contain many requests at a time. To put this into perspective, whereas AHCI/SATA (NCQ and TCQ) has one command queue with a depth of 32 commands (SAS has a queue depth of 254 commands), NVMe is designed to have up to 65,535 queues with as many as 65,536 commands per queue.