RTSS 6.7.0 beta 1

There is no any “ visual bug”.

 

Hehe. RTSS framerate limiter is useless, it has no idea how to limit framerate and just doesn't work at all, period. LOL.

https://steamcommunity.com/groups/S...0700856110421443/?ctp=60#c3557193237107800804

Hope one day that nice developer will learn to promote his own software and framerate limiter in a bit more fair way.

 

I cannot disclose details yet, but some more skins by Chris are around the corner.

 

Some development news:

There will be some changes in Vulkan hooking implementation in the next beta. If you followed Vulkan specs, then you probably heard about nice concept of Vulkan layers. Layers are aimed to provide official mechanism, allowing to intercept 3D application’s Vulkan API calls, i.e. do exactly what each third party overlay hook is doing. Layers indeed greatly simplify the task of API hooking and minimize the risk of conflicts between multiple simultaneously running Vulkan overlays. However, concept of layers has one rather serious disadvantage: each implicit Vulkan layer installed in the system is _always_ active and passively monitor intercepted API calls even when overlay software is not running. So any bug in Vulkan overlay, which is implemented as Vulkan layer, may easily prevent Vulkan applications from running, even if you simply install such application with bugged overlay without actually running it (that was the case in Vulkan overlay/videocapture layer of one competing videocapture software for example).

I strongly dislike the idea of having something RTSS overlay related permanently active in the system when you even don’t start RTSS, so I’m still using traditional API hooks to manually intercept Vulkan API calls exactly like under DirectX/OpenGL APIs.

However, such implementation (i.e. Vulkan overlay working as traditional API hook) has disadvantages too. Vulkan is a low-level API, so many things like parameters validation or software readbacks from ICD are purposely missing in API in favor of optimizing performance. Lack of readback interfaces means that API will not allow you to read a logical or physical Vulkan owner device from swapchain for example. So to implement Vulkan overlay via traditional API hooks you absolutely need to intercept Vulkan device and swapchain creation. That’s exactly why Vulkan OSD in RTSS is invisible if you dynamically start RTSS while Vulkan application is already running – hook needs to be active during Vulkan application initialization to know which physical device creates logical device and which logical device creates the swapchain. That’s also the reason why special RTSS configuration can be necessary for certain Vulkan applications, which load Vulkan runtimes dynamically (e.g. setting application detection level to high for Rage 2).

In the next RTSS beta I’ll try to combine both approaches. There will be new tiny RTSS Vulkan bootstrap layer (just 30Kb total), which will be always active and do nothing but monitor Vulkan device and swapchain creation, precache device and swapchain handles and provide interface for RTSS overlay to read that data from bootstrap layer. So actual overlay renderer will be still implemented as traditional API hook, loaded only when RTSS process is active. This way the risk of affecting the system by bootstrap layer will be minimal. At the same time it will allow seeing Vulkan overlay with dynamic RTSS start scenario. It will also remove the need of special profile configuration for Vulkan applciations like Rage 2.

 

Correct, those registry keys are the places where Vulkan layers are registered. Of course you can add the layer on RTSS start and remove it on close, but from functionality point of view it will be close to equal to what we have now. This way you still won't be able to render Vulkan overlay if you first launch Vulkan application then start RTSS while Vulkan app is running.