In Unity 6.4, we introduced Direct Storage for Windows and Xbox Series X|S. In our own internal testing, we found performance improvements of up to 40%, and it was amazing to see so many of you getting similar performance improvements in your real projects. There’s no substitute for real world user testing, so I want to thank you again for all your feedback.
We wanted to share a bit more about the behind the scene changes we made to enable Direct Storage, as well as some future plans.
Prior to Unity 6.4, all asynchronous reads in the engine were handled by the AsyncReadManager. Under the hood, this is a queue that defers synchronous reads, allowing the calling thread to detach and do other useful work while waiting. Despite this, the resulting read pipeline was still largely synchronous.
Content archives in Unity are internally split into many compressed chunks. When reading a compressed archive, we need to read and decompress each chunk individually. Because the entire content archive is scheduled to the AsyncReadManager as a single read, this results in one long I/O pipeline where an archive needs to be fully read from disk and decompressed before another archive can begin.
Unity 6.4
In Unity 6.4, we added true asynchronous read support to our low level systems. The key difference to the AsyncReadManager is that we no longer internally treat high level jobs, such as an entire content archive, as a single read request. We now break up the read into chunks, and schedule all low level reads to a new, simpler queue. This allows the decompression of those chunks to be jobified, resulting in a far more parallel read pipeline.
With DirectStorage enabled, this low level queue is replaced with a Direct Storage queue. This provides a much tighter integration with both the operating system and the hardware queues in NVMe SSDs. Direct Storage also removes the need to switch from user to kernel mode for every single read request - when we have a separate read per chunk, these add up quickly. All of these benefits allow us to achieve even better performance with Direct Storage than our new I/O architecture would alone.
Unity 6.5
Starting from Unity 6.5, our C# AsyncReadManager interface has been rewritten to use the new low level I/O architecture on Windows. This allows you to make use of Direct Storage for your own custom reads without having to adopt any new APIs.
What’s Next?
Zstandard
At GDC we announced that we’re working with Microsoft to adopt Zstandard as a compression backend for Windows. Our current testing has shown compression ratio improvements of 35% compared to LZ4, enabling large disk size reductions for Unity games.
Direct Storage 1.4 adds native support for Zstandard which we are integrating to improve performance further. This also unlocks GPU accelerated decompression of Zstandard content in Unity projects when using both Direct Storage and DX12.
Texture Loading Improvements
We recognise that textures are one of the biggest I/O bottlenecks for most Unity games - we’re currently exploring techniques to further reduce the latency of getting textures from the SSD to the GPU. Stay tuned for more information.
More Data Types
In Unity 6.4 we only use Direct Storage for textures, meshes, and ECS DOTS data. This is because many other data types still go through the old I/O path - we are working to move more internal reads over to our modern I/O architecture, which will in turn increase the usage of Direct Storage
Increased Platform Support
The new low level I/O architecture we’ve introduced is currently exclusive to Windows and Xbox Series X|S. We’re exploring migrating other platforms to this architecture in future Unity releases to improve I/O performance for other platforms you may be targeting.