Vortice.Windows VS DirectStorage

There are quite a lot actually, even if we ignore engines and frameworks (though some of them are quite low level). Some of the biggest are Silk.NET, Vortice.Windows, SharpDX (the last one is dead but it still should work well).

In C#, that means you'll need something like Vortice.Windows or Silk.NET. If you just want WIC (and not a bunch of DirectX stuff, there's also a plain old WIC interop library. And if you don't mind a well-tested, yet end-of-life library, there's SharpDX.

These days, you're better off with Vortice.Windows or Silk.NET.

For those looking for an alternative to SharpDX, Vortice.Windows is an option.

Microsoft has refused to support it. There have been community-made managed wrappers for DirectX, but SlimDX died years ago and SharpDX was abruptly abandoned and its github archived in early 2019. There's a new one called Vortice that seems to be trying to pick up where SharpDX left off.

I don't think the GPU decompression optimizations is in this driver. I updated and using the Bulk Loader Demo test I'm actually seeing lower throughput than before. I used to hit around 24-25GB a sec, now I'm only hitting like 21GB a sec. Although it's possible but I doubt it, it could be related to the Windows 11 March update reducing SSD bandwidth. I haven't run the test in months so it might be related.

The data is compressed with GDeflate, not deflate. The single stream is designed to use the parallelism of a GPU. It is described here:

https://github.com/microsoft/DirectStorage/blob/main/GDeflat...

The GPU decompression benchmark I linked earlier allows you to specify a single file that it will compress with GDeflate (and zlib for comparison). The numbers presented in the docs that come with the benchmark and presented elsewhere are consistent with my own runs using a source file that is highly compressible.

Part of the trick of achieving this speedup is to read the data fast enough. I don't know of any NVMe drive that can reach full speed with a queue depth of 1. While running the benchmark in a windows VM with a GPU passed through, on the linux host I observed that the average read size was about 512k and the queue depth was sometimes over 30.

We already have GDeflate, with permissive sources available for both CPU compression/decompression and GPU decompression in the DirectStorage GitHub repo. I haven't personally played with it yet, but I'll be implementing it in a project I'm working on in the next few months and am pretty excited to do so.

Wrong: https://github.com/microsoft/DirectStorage/blob/main/Docs/diagrams.mmd

The github repo has some command line parameters.

Only the final test where the results of several SSDs are displayed in the graph is a synthetic one. The first two both support DirectStorage and are designed with Microsoft's recommendations for DirectStorage in mind. That is, random reads of 32k or greater block sizes with high queue depths. This is because you need a high queue depth to be able to saturate NVMe drives.

For most it'll be a background element they're not aware of, if you're running up to date win10 onwards you have DS capabilities, you can get the sample from microsoft build it and run it fine.

Direct Storage github Samples: https://github.com/microsoft/DirectStorage