More technical mumbling for those interested ![]()
Based on some more analysis of the DLLs and some disassembly, this is how Iâm guessing it works:
-
Streamline SDK works by exposing properties to set things up, and then the app has to âtagâ resources with specific marker (âhey this is the image from the gameâ, âhey this is a depth bufferâ, âhey this is where you should place the supersampled image outputâ). This is information you can find in the Streamline documentation (but none of the DLSSG specific bits yet of course).
-
Strings analysis shows some new properties and markers related to interpolation:
-
Strings
DLSSG.*correspond to input properties to the DLSS API. Stringssl.dlss_g.*correspond to Streamline properties and markers for the application to use. These are the ones we care about. -
The app must create a texture to receive the result of the frame interpolation, and tag it with
sl.dlss_g.interpolated.buffer. -
The app also provides all the traditional input for regular DLSS,
sl.dlss_g.depth.buffer,sl.dlss_g.mvec.buffer, and all the other input parameters such as sub-pixel jitter for the frame etc, and also tag a destination texture to received the supersampled (anti-aliased) non-generated image (sl.dlss_g.real.buffer) -
Upon calling the traditional DLSS âEvaluateâ function, DLSS will now produce two outputs: the
sl.dlss_g.real.buffersupersampled image for the input, and thesl.dlss_g.interpolated.bufferimage to fit between the previous output and the current output. -
It is then the responsibility of the game to asynchronously present the two frames (interpolated then real) at the appropriate time.
That last bit is quite important, because it needs the game engine to understand the concept of interpolated frame, and write extra logic to display the frame at the right time. If that bit is not there in the game engine, it cannot just be hacked up (in something like OpenXR Toolkit for example
)
But none of this helps with solving the latency issue mentioned in my earlier post
thatâs still the biggest blocker in even considering frame generation for VRâŠ

