Blur Busters Forums

Chief Blur Buster wrote:Ideally we need a future RTSS that dynamically changes the cap automatically to prevent framebuffer backpressure.

Do we know if this is in the works?

Litzner wrote:

Chief Blur Buster wrote:Ideally we need a future RTSS that dynamically changes the cap automatically to prevent framebuffer backpressure.

Do we know if this is in the works?

No. It was suggested months ago. But I pinged the RTSS author again. I hope he adds this. It's very easy to implement in its purest, non-fancy form (just a fixed delay without calculating anything.)

(Note that this is only useful for VRR or vsync off though. With non-VRR vsync, you just configure a fractional cap anyway.)

RealNC wrote:

Litzner wrote:

Chief Blur Buster wrote:Ideally we need a future RTSS that dynamically changes the cap automatically to prevent framebuffer backpressure.

Do we know if this is in the works?

No. It was suggested months ago. But I pinged the RTSS author again. I hope he adds this. It's very easy to implement in its purest, non-fancy form (just a fixed delay without calculating anything.)

Thanks. You should link the original post that I made in this regards -- search for it and link to it

Is RTSS aware of when VSYNC occurs?

How does it "inject" itself to the game to framerate limit it? Is it keeping the game in swap buffers call as long as it has to? Is it presenting the latest rendered buffer and then delays returning from the call or it is also delaying the presentation of the last rendered buffer for "better" timing?

I am browsing through the forum about external limiters and seeing graphs like this but I still don't get exactly how they work.

Chief Blur Buster wrote:Thanks. You should link the original post that I made in this regards -- search for it and link to it

Your suggestion (and offer for a bounty) was a bit different and more involved in the implementation. I'm scared I'll piss him off

The fixed throttling thingy should be easy to add, and he replied that he'll add it for the next beta and send it along for testing. This should help a lot with many "latency hog" games (meaning mostly single player ones) in VRR mode. I can test lag differences in very low frame rates myself (20-ish FPS), but for high frame rates, we'd need someone with proper gear.

petrakeas wrote:Is RTSS aware of when VSYNC occurs?

Nope.

How does it "inject" itself to the game to framerate limit it?

There's many injection methods, but at the base of them all it's about replacing specific function memory addresses with your own. A frame limiter and OSD injector for example needs to intercept the various API functions of DirectX, OpenGL and Vulkan that send frames to the driver to be displayed on the monitor. When the game tries to execute those functions, RTSS has "rewired" things in such a way, that the CPU jumps to the RTSS code. The RTSS code can then do its thing, and at the end jump to the actual original function the game tried to execute.

Is it keeping the game in swap buffers call as long as it has to? Is it presenting the latest rendered buffer and then delays returning from the call or it is also delaying the presentation of the last rendered buffer for "better" timing?

In the case of the frame limiter, RTSS will block execution for a while if the function call from the game took less time than the user-configured target frame time. For a 100FPS cap, that's 10ms. If the last function call from the game was 5ms ago, that means the current frame would 200FPS, so RTSS blocks for 5ms before returning from the function and giving control back to the game.

petrakeas wrote:How does it "inject" itself to the game to framerate limit it? Is it keeping the game in swap buffers call as long as it has to? Is it presenting the latest rendered buffer and then delays returning from the call or it is also delaying the presentation of the last rendered buffer for "better" timing?

RealNC is correct. There are APIs that exist.

If you run unthrottled, VSYNC ON will pile up framebuffers.

Many games with an unthrottled VSYNC ON work flow works like this:
Present() - Render - Present() - Render - Present() - Render - Present()

The drivers will block inside the Present() call to wait for the previous frame to finish displaying, and then begin displaying the next framebuffer. One big problem is there's a queue of framebuffers waiting, usually 1 extra frame buffer between the game and the screen. So Present() tries to add a framebuffer that's now waiting for a framebuffer that's waiting to be scanned out of the video output. Drivers block returning, until the frame queue is down below the queue maximum. (You can change this value in NVInspector as maximum pre-rendered frames). So there's often 2 VSYNC intervals that pass before the framebuffer delivered via Present() gets to be turned into photons hitting your eyeballs. It's like a First-In-First-Out queue. Present() only blocks if the queue is full. So that's why VSYNC ON caps your game to refresh rate, while also adding lots of input lag (because of the framebuffer queue). In the Olden Days we used to just have crude double buffering (slightly less lag than the modern frame queue used in today's NVIDIA drivers), but a queue really helps make game motion much, much smoother. But it's a double edged sword (latency!). You can do things like NVIDIA Fast Sync to eliminate the queue and make Present() replace the buffer waiting to be refreshed (much like old-fashioned "3Dfx voodoo Triple Buffering"). But that can add microstutter since gametimes are not in sync with refresh cycle times.

Now, framecapping slightly below refresh rate (e.g. 59.99fps for 60Hz), the display is refreshing framebuffers faster than the game is presenting them. If the queue is full, that slowly empties the framebuffer queue, so to the point where you Present() the frame buffers, it's first in the line for the next refresh cycle. The equilibrium point has low lag. Unfortunately, there's a slow-slewing effect between refresh intervals and delivery intervals, so while latency is lower, the latency can slowly sawtooth ([+0...16.7ms]) while inserting one stutter every few seconds.

Game programming can reduce input lag by rendering and presenting only when there's no waiting framebuffers (queue empty), having delayed input reads until fairly close to the VSYNC interval. But most developers just Present-Render-Present-Render-Present-Render....

What we want is a RTSS with a dynamic framecap that automatically relieves framebuffer backpressures via intentional delays that are somewhat more timed to the refresh cycles. So that we don't have to manually cap slightly below Hz. This will enable games (that has the ability to deliver framebuffers at practically clockwork intervals) to still run smooth, while having less lag than just running unthrottled (and clogging up the full latency's worth of framebuffer queue).

@Chief Blur Buster, @RealNC thank you for the detailed response. I have also wrote an article where I gather those tips found in BlurBuster's guides and my experience using VSYNC + limiting just below the framerate.

If I understand this correctly, when the old-school VSYNC with double buffering is used, when the game "presents", it blocks until the next VSYNC happens. So, the input lag should be a steady 1/60 sec in a 60Hz monitor with MPRF set to 1. In this case, limiting would make no difference, right?

So, limiting just below the framerate only improves input lag in triple buffered VSYNC? When triple buffering is used, 1 buffer is waiting to be read and an additional one can be queued, right? So, limiting can help avoid queueing the 1 extra buffer. However according to your tests, limiting seems to have decreased the input lag by a whopping 50 ms while VSYNC is enabled!

By the way, I noticed that 3d Mark FireStrike DX11 benchmark uses double buffered VSYNC because when fps get below 60 fps, it results to 30 fps. If triple buffering is enabled (from 3D mark's settings), it results to a smoother framerate to whatever number below 60 fps. I also noticed that the MPRF (maximum pre-rendered frames) didn't affect the outcome (still 30 fps) when triple buffering is disabled. So, are you sure that the MPRF is the same as enabling triple buffering? I think MPRF affects the frame queue (that queues commands before they are rendered to a buffer) that is not the same as the buffer queue, but it can still contribute to input lag additionally.

In the case of the frame limiter, RTSS will block execution for a while if the function call from the game took less time than the user-configured target frame time. For a 100FPS cap, that's 10ms. If the last function call from the game was 5ms ago, that means the current frame would 200FPS, so RTSS blocks for 5ms before returning from the function and giving control back to the game

In this example, RTSS will also delay the actual presentation of the buffer by 5 ms, so 5ms of input lag will be added. Ideally, we would want RTSS to present the buffer immediately and then block from returning for 5 ms?

petrakeas wrote:

In the case of the frame limiter, RTSS will block execution for a while if the function call from the game took less time than the user-configured target frame time. For a 100FPS cap, that's 10ms. If the last function call from the game was 5ms ago, that means the current frame would 200FPS, so RTSS blocks for 5ms before returning from the function and giving control back to the game

In this example, RTSS will also delay the actual presentation of the buffer by 5 ms, so 5ms of input lag will be added. Ideally, we would want RTSS to present the buffer immediately and then block from returning for 5 ms?

I don't know. I guess this is not the case, since presenting immediately would violate the target frame time. If I set 100FPS as the cap, that means I want the frames to be spaced 10ms apart. If the limiter would present it immediately when it arrives only after 5ms, then it wouldn't be 10ms apart from the previous frame anymore. Frame times would become less accurate and more unpredictable. This is probably what happens with in-game limiters. They probably present first and block later. They give lower input lag, but they have jitter and are thus not suitable for the low latency vsync cap. (Note: emphasis on "probably." I haven't checked any in-game limiters out lately.)