UE5 virtualises most assets like textures and geometry so that they are only streamed as needed, consequently it doesn't need Direct Storage as much and Epic's main focus currently seems to be on improving Lumen and Nanite which are still pretty rough around the edges still.
Streaming on demand is actually exactly what Direct Storage is intended to greatly improve. The classic storage APIs have a lot of overhead, but this wasn't a big deal when we had HDDs, because those have a lot of overhead for every request as well. After all, they need to move the head to the right location on the disc. This is a physical operation that takes a relatively long time. So HDDs aren't suitable for reading lots of small things from random locations, which is why games have traditionally read an entire collection of assets and then kept it in memory.
This is not particularly efficient since you often read and store much more than is needed at that time, but it is more efficient than reading all assets separately and having huge seek costs for each asset.
In contrast, NVMes have seek times that are way faster and so the entire calculation changes, because it now makes sense to just get what you need, which also means that you use the bus and VRAM more efficiently.
However, the classic storage APIs were designed for HDDs where you only have a few read operations at a time and where each important read operation is a bulk operation with large seek times, so it doesn't matter that much if the storage API is a bit slow or if you store a relatively large amount of data in memory to keep track of the request.
In contrast, with NVMes, you ideally want to be able to just fire off a ton of separate IO requests with low overhead. So this why Direct Storage was developed, which can very efficiently handle a huge number of requests without bogging down.
It is possible for UE5 to stream assets from RAM to the GPU without having Direct Storage, but I don't see how they can stream from the NVMe to the RAM. They will still have to do bulk reads and thus have long load times.
Note that the end goal, which we'll probably only achieve step by step, is for assets to go directly from the NVMe to the GPU. To do that, we need GPU decompression (and compression formats optimized for GPUs) so the GPU can unpack the textures without needing the CPU to do it and for the GPU's to have their own Direct Storage implementation, so they can retrieve individual textures and such with very low overhead.
This removes a lot of very inefficient data movement, because right now a large collection of textures goes from the NVMe to the CPU which then sends it to the RAM, then when the GPU needs the texture, it asks the CPU for it, which then retrieves it from RAM, decompresses it and sends it to the VRAM. Because it is uncompressed, this takes a long time to send. In the future, the compressed texture will go directly from the NVMe to VRAM, which will mean less load on the CPU and much faster load times.
wccftech.com
Facebook
Twitter