MSI AB / RTSS development news thread

Sure, but I'm almost certain that it is a case of AMD's frame generation implementation which simply presents two frames almost immediately with no extra framepacing applied to it. So you see something like 15,7 .. 1 .. 15,7... 1...15.7 .. 1 for real 60 FPS bumped to 120 with their FG. That's probably why they have explicit minimum FPS recommendation for it.

 

Found AMD's own info on frame generation, where they declare that zig-zag pattern on frametime graph for enabled FG can be by design and expected:

"A game using AMD FSR 3 in this configuration will show a “zig-zag” pattern on frame time / present-to-present timing graphs. This is expected."

 

If you ever tried to use NVIDIA DLSS Frame Generation with a third party framerate limiter, then you most likely know that attempt to limit framerate with any external solutions fundamentally breaks NVIDIA Frame Generation logic. It breaks motion estimation AI making any movement pretty stuttery, even when framerate is high. The only limiter compatible with FG is NVIDIA's own one, which is integrated directly into the driver so Frame Generation may internally adopt itself to it. This video shows what is happening to camera movement when you try to enable Frame Generation with external RTSS framerate limiter enabled. It also demonstrates small workaround I've added to deal with this issue - now RTSS framerate limiter can be switched to NVIDIA Reflex framerate limiting mode, which will allow it to use NVIDIA's own implementation, compatible with DLSS Frame Generation.

 

To allow flip queue to be full you need to submit frames on CPU side_faster_ than your GPU can process them. You do 180 degrees opposite thing with a limiter, you cannot expect such functionality from it, sorry.

 

It is by design and documented. Quote from the release notes:

§ Added <IF>/<ELSE> and <SWITCH>/<CASE> hypertext extension tags support. Power users may embed these extension tags directly into hypertext instead of “Visibility source” setting to make some parts of layer visible depending on some condition. Please take a note that nested conditional blocks are not supported, so new <IF> tag always closes the previous open conditional block or immediately opens new one. Also, more complex expressions are not allowed into hypertext too, you can only use boolean data sources there. The only exception is ! (NOT) symbol, which is allowing you to invert value reported by boolean data source. Also, please take a note that <IF>/<ELSE>/<SWITCH>/<CASE> tags are extension tags parsed at OverlayEditor plugin level. They are not native hypertext tags, so you cannot use them to format hypertext inside external applications like CapFrameX or AIDA

 

Considering that I recently added NVIDIA Reflex framerate limiting mode to provide compatibility with DLSS Frame Generation, I also decided to add support for detailed latencies reported by Reflex itself in Reflex enabled games. This small video demonstrates how Reflex latencies distribution change when you switch between unlimited framerate (the first few seconds) and hybrid scanline sync modes (JIT presentation scenario).

 

I cleaned the thread again, please avoid using it for random questions. This way news about features in upcoming builds, which I post here, is just getting lost into walls of unnecessary text.

 

I've already replied, please accept "no" as an answer. You _cannot_ achieve that by limiting presentation at rendering pipeline input (that's what any application-side framerate limiters do), you achieve absolutely opposite effect with that. To saturate a queue you need to limit rendering pipleine _output_ instead. That's not a job for a framerate limiter.
Also, please read the post right above.

 

Forza Motorsport 2023 was released yesterday, and I noticed that latency timebands displayed in new NVIDIA Reflex Analyzer can be rather confusing as is in this specific title. GPU Render timeband is most confusing one, because it shows that GPU is busy rendering all the time during each frame (approximately 16.6ms on 60 FPS), which is not the case in reality. GPU render timeband reflects period of time between executing the very first and the very last command buffer by GPU during frame rendering. But there can be multiple gaps in GPU render period of time, when GPU idles. To address that I added new metric to Reflex Analyzer: GPU Active time. It is equal to GPU render time excluding GPU idle time, so it is expected to be lower (up to twice lower in this specific game). NVIDIA Reflex Analyzer's GPU Active metric is rather close to Intel's GPU Busy.

 

In addition to the previous post, I'm still thinking about proper way to visualize GPU Active time on frame timebands. There are no exact timings for idle gaps inside GPU Render timeband, it is just a cumulative GPU Active time excluding all GPU idle intervals. So it cannot be shown as is, but probably I'll just show it as some virtual interval ending at GPU Render end timeband and starting somewhere in the middle of it, concept is something like that:

 

Nope, you cannot add them! Those are independent execution stages existing in parallel, they are displayed on the same time scale as is. For example, on the screenshot above "Driver" timeband starts right after "Render submit" stage and ends before the end of "Present" stage. Sim-To-Render latency is a time difference between front edge of "Simulation" timeband and back edge of "GPU Render" timeband. Interpret is as a time between the moment when application starts 3D world simulation for current frame (front edge of Simulation timeband) and time when GPU finish asynchronous rendering of this frame and it is ready for composition/display (back edge of GPU render timeband). See it as the major part of PC latency. But keep in mind that Reflex doesn't track display and composition timings, so full latency will additionally include it too.

 

I don't think there is better representation form for that. Horizontal timebands is a native representation form for such timing data in various graphics debuggers, and NVIDIA prefer something like that themselves. So I'll use the same, I just added color identification for different timebands so you can easily identify the timeband of your interest. Considering that SpecialK provides similar timebands, I used exactly the same color encoding for unification for those who switch between the products.