Recently noticed frame pacing issues when using VRR in Retroarch

RetroArch
#1

Setup: 13600k, RTX 4070 546.33 driver, 32gb DDR5 6400, Windows 11 22H2

RetroArch 1.16.0 (Git 191ca8d)

Alienware 2521HF 240hz Freesync monitor

I’ve recently noticed that using Freesync instead of traditional vsync causes some additional frame time hiccups in Retroarch on my setup. I use the Genesis Plus GX core with the 240p test suite drop shadow test to verify this since I’ve never had issues with that core. With my display locked to 60hz and regular vsync enabled, the shadow pulses at an even cadence with no interruptions. When I switch to VRR at 240hz native refresh, the drop shadow pulses become more uneven and sporadic.

The problem doesn’t seem to be isolated to one core. For example, in Mega Man X4 (Beetle PSX core), the scrolling text when selecting either Mega Man or Zero will stutter quite a bit with VRR but will be mostly smooth with 60hz traditional vsync.

I’ve tried switching from vulkan to gl but it didn’t help. I’ve also tried using an RTSS fps limit which didn’t help.

Has it always been like this or am I just noticing it now? Has anyone else noticed this?

#2

Are you disabling vsync when you set ‘sync to exact content framerate’? Vsync needs to be enabled and the refresh rate set to your monitor’s native/max refresh rate–in this case 240 hz.

#3

No, vsync is still enabled and the monitor is at the native 240hz refresh rate when using VRR. I should add that freesync seems to be working normally in regular games.

#4

You mean video_refresh_rate in the retroarch.cfg? This value needs to be “240.0”

#5

Right now it’s technically at 239.757004 which is what I assume Retroarch is detecting itself.

edit: Letting Retroarch sample it for awhile changes it to 239.578339.

#6

and it’s still stuttery? If so, that’s all I got, but maybe someone more knowledgeable about this can help out, such as @Tatsuya79

#7

Yes it still not as smooth at a 60hz regular vsync. It’s possible it was always like this and I never noticed but when doing a drop shadow test I can tell a difference.

#8

it should definitely be smooth with ‘sync to exact content framerate’ and a freesync-compatible monitor with those settings. Something must be wonky, but I’m afraid I don’t know what it could be. I guess make sure your GPU control panel is set to “let the application decide” or whatever for all sync stuff. I know you can use scanline sync stutter-free, as well (or instead, I guess) but I don’t know any details on that.

#9

Yeah I’ve used Retroarch for a long time now with VRR displays and it seemed to be as smooth as regular vsync so I don’t know what changed. My control panel is setup correctly and VRR still works fine in regular games.

#10

I’ve noticed small judders in the 240p test suite video scrolling test in various cores ever since I built my new PC and got an LG C2 to replace my IPS monitor. If I use swap interval 2 at 120hz with sync to exact off, those smaller more regular judders go away, but I get a longer more noticeable stutter every once in awhile.

I never noticed the VRR judders on the IPS monitor. I thought maybe the G-Sync module in that was doing something special that the HDMI Forum VRR on the C2 can’t do. Or maybe OLED’s fast response shows the judders more clearly than IPS. At this point I just try not t look for them and they don’t bother me much anymore.

#11

I have an LG screen with the gsync module, it’s smooth in 240p-suite genesis+gx.
That’s my only setup for that, can’t really do much.

#12

Are those small judders when using VRR? Do they go away if you set the display to 60hz with regular vsync?

I had a Alienware 2521H 360hz G-sync native display up until a month ago. In Retroarch I never noticed a difference, but it was smoother in games using frame generation like Cyberpunk 2077. Unfortunately I had to get rid of it due to eye strain so I can’t test it now.

#13

Yes to both. Though running at 120hz with swap interval 2 is better since you get the same frame pacing as 60hz with less display lag.

#14

I would like to resurrect this thread as I believe this issue is still relevant. If people with VRR displays can share their results with the 240p drop shadow test so we can have more data points, that would be beneficial.

A CRT shader that implements interlacing (like my Scanline Classic Shader will look terrible with VRR enabled as it relies on smooth frame timing to give a strobing effect when an interlaced signal is detected.

If it’s true that true G-Sync displays and VRR / G-Sync compatible displays give a different result with the same settings, that should be noted.

On D3D12:

I can get smooth strobing if make a custom resolution for the exact framerate through Nvidia Control Panel, enabling Vsync in RA, and setting the exact framerate in RA.

With V-sync on, setting RA to 120 Hz without ‘Sync to Exact Refresh Rate’, and Swap Interval to Auto, I get decently smooth strobing with a consistent judder. VRR being enabled on the TV doesn’t matter for this.

With same settings but ‘Sync to Exact Refresh Rate’, I get more judder, with some frames being held so long the drop shadow clearly appears as a solid object.

I haven’t tried V-Sync off yet, but I was under the impression that was required for VRR. There may be some misconceptions in how the settings should be configured.

If I have time, I will also try the Vulkan driver. If anyone wants me to take video, I can do that as well.

Using other techniques like shader subframes is not a viable solution as the performance requirements seem high. At least, I can’t get audio to sync smoothly when so many video frames are getting generated, and I have a very fast system relative to what most people are using for RA. It seems completely unnecessary for what I’m trying to accomplish anyway.

1 Like
#15

Follow up on my post, it seems the frame pacing issues are significant on only certain cores. The BSNES and Beetle PSX HW cores are two that have issues. Beetle is basically not usable. It may just be a performance issue I need to work out. For BSNES, switching to bsnes-jg gives me better performance and more stable frame timing.

Also, shader subframes are fine on emulators like Mesen, bsnes(-jg). It seems I was only have performance issues with subframes when using Beetle PSX (HW).

2 Likes
#16

Greetings, I too have experienced frame pacing issues with VRR enabled on more than one setup. On some cores, things seemed better with Sync To Content Refresh Rate enabled in addition to Vsync and on some cores it seemed like Vsync needed to be disabled.

That was in the past. I’ve also seen strange frame pacing issues when the desktop refresh rate was set to anything other than 60Hz.

Fast forward to now and I’ve been running my desktop refresh rate at 100Hz, I too was having severe frame pacing issues until I clicked on “Set Display Reported Refresh Rate”.

This is my setup for all cores when it comes to Output and Synchronization:

Do remember to turn off Frame Delay if using Sync To Content Refresh Rate.

In addition to this I use RTSS to limit frames to 60Hz in RetroArch and whatever is my Refresh Rate/Target Frame Rate in other scenarios.

1 Like
#17

Thanks for your input. I will do some testing when I get a chance. I haven’t tried it with Beetle PSX, but when I turn off audio in BSNES it smooths things out greatly. I know that bsnes-jg modifies the audio processing to be smoother for lower latency. The way certain cores handle audio may be the source of the problem. I am very sensitive to audio latency and like to keep it as low as possible. However, 8 ms is not very much time. I wonder if audio could stream at 60 Hz instead of 120 Hz, or if we could have a ‘threaded audio’ option or something. I use HDMI audio and WASAPI.

1 Like
#18

À big advantage of Retroarch is that it can use vrr even on windowed mode. Vast majority of other retro emulators require fullscreen

2 Likes
#19

Hello there. I’m glad this topic is active because it’s been bugging me for years now. I’m using computer monitors (VRR-capable Alienware 240Hz, different Viewsonic 120/240Hz models) and I always get the same results with RetroArch:

120/240 Hz physical refresh rate + VSync ON + VSync Swap Interval AUTO + Sync to Exact OFF = perfect frame pacing (no micro-stuttering) on near-60Hz games.

120/240 Hz physical refresh rate + VSync ON + VSync Swap Interval AUTO + Sync to Exact ON = bad frame pacing (micro-stuttering) on near-60Hz games.

This is on an VRR-capable system on GNU/Linux:

  • AdaptiveSync LabWC Wayland compositor
  • VRR capable monitors.
  • FreeSync is active on the monitor and AdaptiveSync is active on the Wayland compositor
  • AdaptiveSync is reported working by wlr-randr which is the modern equivalent to xrandr on Wayland-based systems.

The whole chain is correct.

Native games have perfect frame pacing (even 35 fps games on 120/240Hz video modes, like OpenTyrian, Chocolate Doom, etc) and, most interestingly, standalone MAME does have it too for games with all kinds of exotic framerates like MK, Caveman Ninja, Demon’s World… everything is absolutely perfect as expected with regards to VRR/AdaptiveSync, except in RetroArch (and dosbox-stanging… but that’s a different story).

For reference, MAME has to be set up like this:

Video options:
    Window Mode - Off
    Synchronized Refresh - Off
    Wait Vertical Sync - Off

Advanced options:
    Throttle - On
    Adjust speed to match refresh rate - Off
    Low latency - Off

I know this is NOT about standalone MAME, but since standalone MAME does VRR/FreeSync correctly, I want to give all the possible information.

As things are, on RetroArch, perfect frame pacing with “Sync to Exact” is only possible with severe compromises, but it may give valuable information:

  • If Audio Sync is disabled, Sync to Exact provides perfect frame pacing in every core and game, but there are occasional (and expected) audio cracklings.
  • Setting a 60Hz physical refresh rate on the monitor (instead of 120/240Hz, which are usually the recommended / default rates for these monitors), it’s also possible to have good frame pacing with Sync to Exact, but since VSYNC is also needed, this defeats the purpose and introduces input lag (60Hz + VSync will always introduce input lag no matter what).
#20

I made the vrr code and it’s just setting as monitor refresh what the core is giving as its timing (also bypassing the timing_skew for sound DRC, and a fast forward hack/fix).

I see some things I didn’t touch (or were added later? not sure) you can try changing.
It’s forcing swap interval 1 when exact sync is enabled, you could try removing that condition.

There’s a limit at swap 4 there, I’m not sure why.

I’m still on my now old 120hz gsync chip inside monitor so I can’t test high refresh and multiples yet.
Maybe there’s a need to bypass the timing_skew or bring the swap multiplier into the vrr_runloop later.

2 Likes