DirectStorage API Now Available on PC

[V3N1X]

Ok, just ran the demo again... reads at 4-5 GB/s using 16K textures with the Hubble demo :)

I just uploaded the binaries https://mega.nz/file/ZFEX0QyL#CYzxvlHsPSSZU7pb2D9-g0tBB3mQaR8zjX10pX5S7HM (compiled for x64 versions of Windows against Win 11 SDK), Virus Total: https://www.virustotal.com/gui/file...3338cc13d1fbfe850849726f0d4f1ec2b8d/detection

Please, do NOT trust any links on the Internet, kindly compare the hash of the 7z file with the VirusTotal result before running any executables on your PC.

The binaries do not include the 16K textures, but you can download them from the Github repository on this link: https://github.com/GameTechDev/SamplerFeedbackStreaming/releases/download/1/hubble-16k.zip and then extract to the media dir

You can run the demo using the following command (from CMD/Powershell), and if you want to stress the SSD/Streaming Solution you can try benchmark mode

.\demo-hubble.bat -mediadir .\media\hubble-16k\

Edit: Note: the demo intentionally amplifies the conditions in which data needs to be streamed from disk and thus is not reflective of real-world gaming scenarios.

This repository contains an MIT licensed demo of DirectX12 Sampler Feedback Streaming, a technique using DirectX12 Sampler Feedback to guide continuous loading and eviction of small portions (tiles) of assets allowing for much higher visual quality than previously possible by making better use of GPU memory capacity. Sampler Feedback Streaming allows scenes consisting of 100s of gigabytes of resources to be drawn on GPUs containing much less physical memory. The scene below uses just ~200MB of a 1GB heap, despite over 350GB of total texture resources. (Objects could have shared streaming resources, but the intent of the demo is to show the potential of using many unique textures).

Click to shrink...

 

[Edward850]

Like guys, please for the love of god... stop blaming issues like this on the SDK when it's not at fault.

Click to shrink...

Absolutely correct. DX12 is a very powerful API, but with great power comes something something you know the words already.
Namely, the key difference is that it's designed around no longer being able to surprise the GPU with an entirely new rendering state, those kinds of structures are now pre-arranged. Previous rendering APIs could change the state whenever and to whatever, and if your GPU driver did any predictive work as to how to render the scene that turned out to be wrong, all that work had to be chucked out and restarted. This was the critical reason why Nvidia drivers were so much faster than ATI/AMD back in the days of OpenGL (remember RAGE/idTech4?), because Nvidia would spend a lot of time optimizing work loads for specific games and around smarter speculative caching.

DX12 bridges that gap and no longer requires the driver to do speculative work to push out performance, but the catch is now it's the developers job to design smarter pipeline states that are configured ahead of time. What's happening with games like Elden Ring is that some developers seem to be unaware, unwilling, unable, or just don't know how to design a rendering pipeline this way. It's something that needs to change your thinking on how to do rendering to adapt to, if you were already used to how DX9 and OpenGL did things (old examples but they are common APIs everyone starts with). This is what contributes to the stuttering, DX12 can still change these states "on the fly" but you're now waiting for a new pipeline state to compile in order to do so, where as what you're supposed to be doing is designing your pipelines in advance OR creating a sandbox in which all render states in your game can be generated in advance.