Okay, I think this is now ready for initial round of review. Still has some hacks but I have no idea how to rid of them. And I'll try to test this version again with various games I happen to have installed, for now I know that at least vk_streamline sample works with this.

Feel free to ask about strange stuff in there; I lived with a variant of this code for months so I might have got used to the weirdness.

Tested with Enshrouded, Portal RTX and Portal Prelude RTX, appears to work fine with them. Still no idea how to convince No Man's Sky and Indiana Jones and the Great Circle to let me activate Reflex.

Remaining titles that would be nice to have tested (that I know of):

• Path of Exile 2
• Red Dead Redemption 2
• Tom Clancy's Rainbow Six Extraction
• Tom Clancy's Rainbow Six Siege? Does it still have its Vulkan renderer?

I figured out the problem NMS and Indy had: Streamline was thinking that NvLowLatencyVk.dll shipped with the game wasn't correctly signed, most likely due to Wine not implementing the signature verification functions (correctly?). With that issue… sidestepped, both NMS and Indy load the library and make Reflex calls, but:

• NMS only calls SetSleepMode and SetLatencyMarker, it doesn't seem to be performing the actual latency sleeps.
• Indy works, but spams the log with unsupported NV_VULKAN_LATENCY_MARKER_TYPE (13) which doesn't exist as a Vulkan latency marker type but is likely related to PCLMarker::eControllerInputSample.

Thanks for the PR! Cool to have Vulkan Reflex.

I did a first pass on the nvapi side of things for some initial thoughts. The gist is more or less that it would be nice to integrate more with the existing structure:

• nvapi_vkreflex.cpp should be nvapi_vulkan.cpp to be consistent with other entry points file (due to NvAPI_Vulkan_ )
• On the D3D side we have NvapiD3dLowLatencyDevice, what about introducing NvapiVulkanLowLatencyDevice for details and Vulkan initialization so that the entry point files are mostly for logging, arguments checking and status codes? The VkReflexContextData is I guess already quite close to this.
• Other global things do live in nvapi_globals, the context map (or map of VulkanLowLatencyDevices) could also live there.
• With the mind of tests it would be cool to reuse and extend the existing Vulkan class for abstracting the VK calls. Creating should still go through ResourceFactory::CreateVulkan with a new overload for just the library name.

Indy works, but spams the log with unsupported NV_VULKAN_LATENCY_MARKER_TYPE (13) which doesn't exist as a Vulkan latency marker type but is likely related to PCLMarker::eControllerInputSample.

Impressive find. Probably a good idea to log only once per invalid marker type (also on the D3D side).

• nvapi_vkreflex.cpp should be nvapi_vulkan.cpp to be consistent with other entry points file (due to NvAPI_Vulkan_ )

I actually tried that first, only to be told to go away with my nonsense by Meson:

ERROR: Multiple producers for Ninja target "src/nvapi64.dll.p/nvapi_vulkan.cpp.obj". Please rename your targets.

I think nvapi_vulkan.cpp somehow collides with nvapi/vulkan.cpp, but that sounds incredibly stupid.

• nvapi_vkreflex.cpp should be nvapi_vulkan.cpp to be consistent with other entry points file (due to NvAPI_Vulkan_ )

I actually tried that first, only to be told to go away with my nonsense by Meson:

ERROR: Multiple producers for Ninja target "src/nvapi64.dll.p/nvapi_vulkan.cpp.obj". Please rename your targets.

I think nvapi_vulkan.cpp somehow collides with nvapi/vulkan.cpp, but that sounds incredibly stupid.

ah yeah, it is exactly this... I remember hitting this when playing with nvofapi initially. Meson flattens paths by converting the separator to underscore which conflicts in this case. Maybe rename nvapi/vulkan.cpp to nvapi/vk.cpp?

through

Sorry to ask here, but does the latest patch, and/or Indiana update2 fix proton black screen with dlss3 frame gen? Or is at least a step in the right direction?

It does not. For now you should assume that any game with Vulkan renderer that isn't Portal RTX won't have DLSS Frame Generation function correctly.

Indy is a bit more of a special case because it's trying to use VK-CUDA interop for DLFG, we are investigating this here: SveSop/nvcuda#9

@Saancreed thanks for keeping me up to date.. will follow that thread

Pushed new version, but with changes (when compared to previous revision) as fixup commits, to hopefully make reviewing them easier. Now to figure out what Proton's mingw wants me to do to make it happy…

Looking at the layer, some initial thoughts:

• The layer itself looks fine at first look, also good idea to use vkroots.
• We should also built the layer as part of CI including proper naming of the artifact on a tag
• We also need to document building and installing in a user home. May be separate readme in the layer directory with link from the main readme?
• May be we can repeat the version.h generation and log the version on Init()?
• Not sure yet if we should use different env names for the layer. May be it is easier to reuse the existing names.

LGTM wrt the NVAPI side. Suggested change for avoiding a nullptr check for the resource factory (because that already happens in NvAPI_Vulkan_InitLowLatencyDevice) and for keeping the Initialize() signature identical with e.g. adapter registry:

diff --git a/src/nvapi/nvapi_vulkan_low_latency_device.cpp b/src/nvapi/nvapi_vulkan_low_latency_device.cpp
index 7472aac..f53e434 100644
--- a/src/nvapi/nvapi_vulkan_low_latency_device.cpp
+++ b/src/nvapi/nvapi_vulkan_low_latency_device.cpp
@@ -5,21 +5,18 @@ namespace dxvk {
     std::unordered_map<VkDevice, NvapiVulkanLowLatencyDevice> NvapiVulkanLowLatencyDevice::m_lowLatencyDeviceMap = {};
     std::mutex NvapiVulkanLowLatencyDevice::m_mutex = {};
 
-    bool NvapiVulkanLowLatencyDevice::TryInitialize(ResourceFactory* resourceFactory) {
+    bool NvapiVulkanLowLatencyDevice::Initialize(ResourceFactory& resourceFactory) {
         std::scoped_lock lock{m_mutex};
 
         if (m_vk && m_vk->IsAvailable())
             return true;
 
-        if (resourceFactory == nullptr)
-            return false;
-
-        m_vk = resourceFactory->CreateVulkan("vulkan-1.dll");
+        m_vk = resourceFactory.CreateVulkan("vulkan-1.dll");
 
         if (m_vk && m_vk->IsAvailable())
             return true;
 
-        m_vk = resourceFactory->CreateVulkan("winevulkan.dll");
+        m_vk = resourceFactory.CreateVulkan("winevulkan.dll");
 
         return m_vk && m_vk->IsAvailable();
     }
diff --git a/src/nvapi/nvapi_vulkan_low_latency_device.h b/src/nvapi/nvapi_vulkan_low_latency_device.h
index fbeb9f8..55b086d 100644
--- a/src/nvapi/nvapi_vulkan_low_latency_device.h
+++ b/src/nvapi/nvapi_vulkan_low_latency_device.h
@@ -6,7 +6,7 @@
 namespace dxvk {
     class NvapiVulkanLowLatencyDevice {
       public:
-        static bool TryInitialize(ResourceFactory* resourceFactory);
+        static bool Initialize(ResourceFactory& resourceFactory);
 
         [[nodiscard]] static std::pair<NvapiVulkanLowLatencyDevice*, VkResult> GetOrCreate(VkDevice device);
         [[nodiscard]] static NvapiVulkanLowLatencyDevice* Get(VkDevice device);
diff --git a/src/nvapi_vulkan.cpp b/src/nvapi_vulkan.cpp
index 74ff113..43449be 100644
--- a/src/nvapi_vulkan.cpp
+++ b/src/nvapi_vulkan.cpp
@@ -16,7 +16,7 @@ extern "C" {
             return ApiNotInitialized(n);
 
         static std::once_flag initialized{};
-        std::call_once(initialized, []() { NvapiVulkanLowLatencyDevice::TryInitialize(resourceFactory.get()); });
+        std::call_once(initialized, []() { NvapiVulkanLowLatencyDevice::Initialize(*resourceFactory); });
 
         auto device = reinterpret_cast<VkDevice>(vkDevice);
         auto semaphore = reinterpret_cast<VkSemaphore*>(signalSemaphoreHandle);

Weird, when I initially tried passing as reference clangd complained about binding to temporary value. But your version works so I applied it, thanks.

I've played with the current version with RDR2 and seems to work nicely (according to the logs, my reflexes wont feel the difference ;)). Also the layer setup is really simple now by just pointing VK_ADD_IMPLICIT_LAYER_PATH to the layer directory and declaring DXVK_NVAPI_VKREFLEX=1. Very nice!

As (partially) discussed:

• I'm fine to enable the layer by default so that explicitly setting DXVK_NVAPI_VKREFLEX is not needed. Manually setting up the layer setup is needed anyway, at least for Proton. Up to you with what you are comfortable with.
• Also no strong preference here: may be easier to keep the environment variable for logging the same with nvapi/nvofapi, thus DXVK_NVAPI_LOG_LEVEL with info and trace. We can introduce e.g. warn if that fits.
• I think it makes sense to issue a clear log statement in NvAPI_Vulkan_InitLowLatencyDevice i.c.w. VK_ERROR_EXTENSION_NOT_PRESENT to guide users to a missing/wrong layer setup.

• I'm fine to enable the layer by default so that explicitly setting DXVK_NVAPI_VKREFLEX is not needed. Manually setting up the layer setup is needed anyway, at least for Proton. Up to you with what you are comfortable with.

I'd prefer to keep it disabled by default, even if manual setup is required to set it up. I don't trust myself that it won't interfere with other stuff just yet, and once installed it would activate it in other games for no reason.

• Also no strong preference here: may be easier to keep the environment variable for logging the same with nvapi/nvofapi, thus DXVK_NVAPI_LOG_LEVEL with info and trace. We can introduce e.g. warn if that fits.

I kind of like having it separate.

• I think it makes sense to issue a clear log statement in NvAPI_Vulkan_InitLowLatencyDevice i.c.w. VK_ERROR_EXTENSION_NOT_PRESENT to guide users to a missing/wrong layer setup.

Right, will do.

I also added a notice about potential glibc version mismatches because our CI is running on Arch, so less surprises for Ubuntu users is probably a good idea 🐧