Can't achieve a flat frame time graph in RTSS in many emulators with Freesync

Talk about AMD's FreeSync and VESA AdaptiveSync, which are variable refresh rate technologies. They also eliminate stutters, and eliminate tearing. List of FreeSync Monitors.
Post Reply
xenphor
Posts: 69
Joined: 28 Feb 2018, 11:47

Can't achieve a flat frame time graph in RTSS in many emulators with Freesync

Post by xenphor » 27 Mar 2021, 00:35

I was under the impression that Freesync would "just work" with emulators (at least MAME and Retroarch) but, according to RTSS's frame time graph, that doesn't seem to be the case. In MAME for example, if I try the game Galaxian with RTSS's frame time graph enabled, there will be consistent, slight variations, despite Freesync being enabled. This is with all vsync options disabled in MAME and throttle enabled. However, if I input the refresh rate in RTSS that MAME reports upon boot: 60.606061, then the graph will be flat.

I've noticed the same thing in Retroarch with various cores like beetle-saturn, genesisplusgx, mupen and mesen. I have Retroarch set up to use Freesync, but the RTSS frame time graph will show consistent, slight variations. I've been able to achieve a flat graph in those cores by inputting a 59.94 limit in RTSS.

In RPCS3 for at least one game, using a 59.94 limit was need for a flat graph.

In Dolphin I needed to use a 59.97 limit for a flat graph.

Curiously, trying a game in Xenia didn't need any special limit for a flat graph.

I've been using Freesync in the aforementioned emulators for awhile now and didn't notice perceivable stutter, so I'm not sure if RTSS is measuring frame time variance that I've not noticed or if it's not functioning properly for this use case. I'm using an Alienware aw2521hf 240hz monitor. RTSS is version 7.3.1.

User avatar
RealNC
Site Admin
Posts: 3740
Joined: 24 Dec 2013, 18:32
Contact:

Re: Can't achieve a flat frame time graph in RTSS in many emulators with Freesync

Post by RealNC » 27 Mar 2021, 07:47

Freesync has nothing to do with producing flat graphs. What it does is, no matter how the graph looks, it will show each frame close to whatever time the graph's value indicates.

Also, a "flat graph" doesn't give you anything. Some variation is normal and has no effect on anything, especially with freesync. A flat graph is only beneficial when not using freesync and trying to instead use "low latency vsync," where exact frame timing is important due to having a fixed refresh rate. With freesync, exact frame timing is not important at all.
SteamGitHubStack Overflow
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: Can't achieve a flat frame time graph in RTSS in many emulators with Freesync

Post by Chief Blur Buster » 30 Mar 2021, 00:37

VRR is software-timed refresh cycles.

Emulator framerate caps are not usually as accurate as RTSS framerate caps. RTSS is the backup cap for imperfect emulator frame pacing.

For maximum precision, you can combine both emulator cap & RTSS cap, where emulator cap imperfections is backstopped by RTSS framerate caps.

Combining emulator cap + RTSS cap is fine for VRR. In this case, you want to be careful that RTSS cap does not interfere with the emulator -- some emulators prefer RTSS cap slightly higher than emulator cap, rather than lower -- but it varies by emulator.

So what you are doing is a good workaround for imperfect software framepacing (since VRR is software-timed refresh cycles), creating a backup framerate cap for imperfect in-game framerate caps, when your priority is motion fluidity (e.g. emulators)

Since in-game/in-emulator capping is lower lag -- you will get the lowest lag by making sure your RTSS backup framerate cap is ever slightly higher than the in-game/in-emulator cap (preferably fractionally like 0.001 difference). But some software may also require RTSS to be same or below the actual framerate output.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

Post Reply