# DirectStorage samples: reading game assets without the CPU in the way

> The microsoft/DirectStorage repository holds the Windows samples for the DirectStorage API, four sample projects plus a GDeflate reference codec, showing how a game reads assets from an NVMe drive and decompresses them on the GPU. The interesting engineering is in the read path, not in the rendering, and the API is read-only by design.

**microsoft/DirectStorage** — DirectStorage for Windows is an API that allows game developers to unlock the full potential of high speed NVMe drives for loading game assets.

- Repository: https://github.com/microsoft/DirectStorage
- Stars: 905 · Forks: 111
- Language: C++
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/microsoft-directstorage

## The problem is CPU overhead, not raw bandwidth

The reason DirectStorage exists is stated in the opening paragraph, and it is narrower than the claim of getting the most out of a high speed NVMe drive suggests. The drive can deliver multiple gigabytes a second of small reads, on the order of 64kb each, with minimal CPU overhead. It is possible to saturate a drive with traditional ReadFile-based IO, but the CPU overhead increases non-linearly as the size of the individual reads decreases. The second problem compounds the first: most games store assets compressed on disk to reduce the install footprint, and decompressing them on the fly as they load costs CPU, and that cost becomes increasingly expensive as bandwidth increases. So the target is a load path where neither the read pattern nor the decompression eats the CPU that the game needs for everything else. The repository frames the work as a Windows counterpart to what consoles do, since the Xbox Series X and S address the same issues by offloading parts of it to hardware, using the NVMe hardware queue to manage IO and hardware accelerated decompression.

## The Xbox API shape is kept so ports stay cheap

One design decision explains a lot about the API's shape. DirectStorage already exists on Xbox, and the stated goal is to ease porting of titles between Xbox and Windows, so the two APIs are kept as similar as possible. For a studio shipping on both, that is the whole argument for the technology: a title built against the console API can move to the PC with a thin layer rather than a rewrite of the asset loading code. For a developer working only on Windows, it is a constraint rather than a benefit, because you are learning an API shaped by a different platform's requirements, including the console's hardware queue model. The other boundary worth knowing before you design around it is short and absolute: DirectStorage only supports read operations. If your pipeline needs to write back into a package, or to write a cache, that part of the work happens through the normal file APIs, and DirectStorage is not involved in it.

## Four samples, each isolating one problem

The Samples directory is the useful part of the repository, and the four samples are chosen so that each answers a question a developer actually has. HelloDirectStorage is described as rudimentary and exists to get you acquainted with the runtime: it reads the contents of a file and writes them out to a buffer on the GPU using DirectStorage, which is the smallest end to end path and the one to start with. BulkLoadDemo demonstrates DirectStorage together with GPU decompression and custom CPU decompression, which is the interesting combination because it puts the two paths side by side. GpuDecompressionBenchmark is a measuring tool: it reads a file, compresses it, then decompresses it in several ways while tracking bandwidth and CPU usage, with the GPU and the CPU compared. EnqueueRequestsDemo covers the request API specifically, showing EnqueueRequests and the destination type DSTORAGE_REQUEST_DESTINATION_MULTIPLE_SUBRESOURCES_RANGE, which is how a single request targets several subresources of a texture. Each sample has its own README and a screenshot in the repository.

## GDeflate is a reference implementation, not a dependency

The GDeflate directory holds codec source and sample code demonstrating how to use GDeflate, which is the format DirectStorage expects for GPU-decompressible assets. Calling it a reference implementation matters, because it tells you what the files are for. This is Microsoft's own implementation of the codec, sitting in the repository so you can read it, build it and see how it is used, and so you have a working encoder for your asset pipeline rather than having to find one. The GDeflate format is the part of DirectStorage that game studios have to adopt in their content pipeline even if they never call a DirectStorage function, because a game that wants GPU decompression has to write its assets in a format the GPU can unpack. That makes the codec directory the part of this repository with the longest reach outside the DirectStorage API itself. The sample code in that directory demonstrates usage, and the codec source is there to be read, since the format's details are what determine how well your assets compress and how fast they unpack.

## Cloning needs submodules, and the build needs Visual Studio

The repository uses submodules, and the README is explicit about the flag, so this is the step that catches people out. When you clone, pass --recurse-submodules to the git clone command, and if you forget, the recovery is to run git submodule update --init. The build is Visual Studio based and the requirement is stated as Visual Studio 2019 or higher. There is no single solution file at the root; the instructions say to open the following Visual Studio solutions and build, which means you build the samples individually:

```text
Samples\HelloDirectStorage\HelloDirectStorage.sln
Samples\BulkLoadDemo\BulkLoadDemo.sln
Samples\GpuDecompressionBenchmark\GpuDecompressionBenchmark.sln
Samples\EnqueueRequestsDemo\EnqueueRequestsDemo.sln
```

The project language is C++, and the tree includes a .clang-format file, which is what you would use to keep the source style consistent if you patch it. The primary language recorded for the repository is C++, and there is a NuGet.Config in the Samples directory, which is there because the samples pull packages.

## Where DirectStorage is the wrong choice

There are clear cases where this API is not worth the work. If your game streams a modest amount of data, the traditional read path is fine and DirectStorage adds a content pipeline change, a GPU decompression path and a compatibility surface for a benefit you will not measure. If your platform target does not include an NVMe drive with a hardware queue, the premise of the API does not apply, and the console-style architecture that shaped it becomes a liability. And if you are not on Windows, none of it is available, since this is a Windows API with a Windows sample set. The honest framing is that DirectStorage is for a specific shape of problem, a game with a large compressed asset set on a PC with fast storage, and the samples are the way to find out whether your project has that shape before you commit an asset pipeline to it. Reading the developer guidance document in the Docs directory is the sensible first step, and it is linked from the README for exactly that reason.

## MIT code, a Microsoft CLA and trademark rules

The licensing has two layers and it is worth separating them. The code is published under the MIT licence, with a LICENSE file at the repository root and a NOTICES.txt alongside it, so the sample source and the GDeflate codec can be read, copied and modified under permissive terms with the notice kept. Contributions are a separate matter. The project states that most contributions require agreeing to a Contributor License Agreement that declares the right to grant the rights to use the contribution, with the agreement hosted at the Microsoft open source CLA site, and that a bot will check each pull request and say whether a CLA is needed, with the instruction that this only has to be done once across all repositories using that CLA. There is also a trademark clause: the project may contain trademarks or logos, authorised use is governed by the Microsoft trademark guidelines, and use of Microsoft marks in a modified version must not imply sponsorship. A SECURITY file and a SUPPORT file sit at the root, and the project has adopted the Microsoft Open Source Code of Conduct. The last push was on 2026-10-16, so the samples are being maintained, and there are no GitHub releases to track.

## Conclusion

DirectStorage samples suit a Windows game developer who is loading large compressed asset sets and wants to see the read path and GPU decompression in working code before designing an asset pipeline around it. It does not suit a project that only needs fast file reads, since a plain ReadFile approach still works and is far simpler, and it does not give you writes of any kind. Before you start, check the developer guidance document in the repository, clone with submodules because the GDeflate codec lives in one, and be aware that the project asks contributors to sign a Microsoft Contributor License Agreement.

## FAQ

### What does DirectStorage actually do?

It is a Windows API for reading game assets from high-speed NVMe drives while keeping CPU overhead low, including hardware accelerated decompression. The documentation notes that although a drive can be saturated with traditional ReadFile-based IO, the CPU overhead rises non-linearly as individual reads get smaller, and that decompressing compressed assets on the fly becomes more expensive as bandwidth increases.

### Can DirectStorage write files?

No. The documentation states plainly that DirectStorage only supports read operations. Any writing back into a package or cache is done through the normal file APIs.

### Which samples does the DirectStorage repository contain?

Four: HelloDirectStorage for reading a file into a GPU buffer, BulkLoadDemo for DirectStorage with GPU and custom CPU decompression, GpuDecompressionBenchmark for measuring decompression bandwidth and CPU usage, and EnqueueRequestsDemo for the EnqueueRequests API and the multiple subresources destination type.

### How do I clone and build the DirectStorage samples?

Clone with the --recurse-submodules flag, or run git submodule update --init afterwards, because the repository uses submodules. You need Visual Studio 2019 or higher and then open and build each of the four sample solution files under the Samples directory.

## Sources

- [Issues](https://github.com/microsoft/DirectStorage/issues)
- [License: MIT](https://github.com/microsoft/DirectStorage/blob/main/LICENSE)
- [microsoft/DirectStorage on GitHub](https://github.com/microsoft/DirectStorage)
- [README](https://github.com/microsoft/DirectStorage/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microsoft-directstorage