Evaluate DLSS-RR through NGX independently from DLSS-G through streamline

Hi,

I am trying to extend a vulkan application with frame generation. The application already has an integration of DLSS-RR through the NGX interface. I do not intend to replace the NGX integration with streamline as the application needs deployment on linux (where I can rather pass on frame generation, but not on ray reconstruction).

As I currently cannot see a way to get frame pacing with frame generation when using the frame generation interface from NGX, I concluded that I currently have to use streamline for this task. As my rendering architecture is plugin based, rendering of images and their presentation to the screen is completely separated. It is a plugin renderer based on vulkan that is integrated into multiple applications that have different UIs on top - these UIs are rendered and presented from dx11, gl and vulkan. So the streamline integration will be a part of the ui application level.

Now, when enabling DLSS-RR in the renderer plugin, and then enabling DLSS-G from streamline in the application I get this error spammed into cout (and frame generation refuses to work):

[2025-12-11 09:40:43] [tid:40116][DLSSGInstanceManager::InferDevice:557] Error: multiple active devices present, and a device was not specified
[09-40-43][streamline][error][tid:40116][32s:846ms:767us]commonEntry.cpp:596[createNGXFeature] NVSDK_NGX_VULKAN_CreateFeature((VkCommandBuffer)cmdList, feature, ctx.ngxContext.params, handle) failed 0xbad00005

However, when I enable FG first, and DLSS-RR afterwards, it kind of works (until FG is turned off and back on again).

So it seems like these "two" libraries are talking to each other in ways I don't want them to talk. How can I avoid this and use them without conflicting? Always enabling frame generation before DLSS-RR is not really an option.

Thanks for having a look!

More integration details:

• The renderer plugin that renders images into buffers:
  • Loads vulkan-1.dll directly dynamically, it does not use the streamline hooks.
  • Loads nvngx_dlssd.dll directly and uses the NGX interfaces.
  • Uses a separate device, queue, etc. from the ui application. The final images are exported from vulkan using opaque system handles and semaphores for synchronization.
  • Does not create a swapchain/surface/etc.
• The ui application that presents images to the screen:
  • Loads all vulkan functions through sl.interposer.dll. The dll is loaded at runtime.
  • Uses the streamline interface to enable frame generation.
  • Uses a separate device, queue, etc. from the renderer
  • Using eUseManualHooking or calling slSetVulkanInfo does not seem to prevent the issue.
  • Does create a swapchain/surface/etc. and uses it to display the rendered images into a window (plus some UI).

I am using an RTX 5000 Ada, a 581.80 driver on Windows 11 Enterprise 23H2 with streamline 2.9.0.

Start by reproducing the reported failure with the renderer plugin's direct nvngx_dlssd.dll integration and the UI application's sl.interposer.dll integration, using separate Vulkan devices and queues. Compare initialization order and the effects of eUseManualHooking and slSetVulkanInfo against the reported DLSSGInstanceManager and createNGXFeature errors. Done means DLSS-RR and DLSS-G can be enabled and toggled in either order without conflicts.