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.
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.
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.
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.
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.
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.
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
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 went set 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
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
À big advantage of Retroarch is that it can use vrr even on windowed mode. Vast majority of other retro emulators require fullscreen
1 Like
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).
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.
I’m getting good pacing on a 240hz monitor myself. At least for the games that i know they have locked frame rates. I don’t consider games with unlocked frame rates a good test for this.
I also always make sure RetroArch is on a high performance profile. I remember getting sound issues on Bsnes when i didn’t do that.
Hi, Tatsuya! Thanks for taking the time to participate in this thread.
I have tried removing this condition, also this swap 4 limit, but at that point I realized something:
I think what some of us are seeing here is an effect of emulators having variable frame times.
That’s why, having working VRR setups, we only see this subtle effect in RetroArch and not in native games: as I said, even OpenTyrian, Taradino or Chocolate Doom, which are 35 FPS games, have good frame pacing. In Ship of Harkinian, I can set framerate to 54 FPS or some other crazy exotic value and it looks perfectly smooth.
But on emulation, it’s different once we leave the classic “activate vsync and synchronize emulation to that” paradigm: you let the emulator impose the framerate, the frame times won’t be steady and the monitor won’t be able to keep up with these variable frame times.
I have found more information this old thead on the BlurBusters forum. It’s administrator is the most knowledgeable person in the world for this kind of problems, and has contributed with libretro in the past. From there:
For proper fluidity on VRR displays, your refresh cycles is controlled by the exact timing of the pageflip. So…when you’re in VSYNC OFF mode or VRR mode please use microsecond clocks for timing your framebuffer flips in your emulator source code!. This will reduce microstutter issues for software-triggered display refresh cycles (which is what GSYNC and FreeSync essentially is) especially for strongly fixed-Hz content such as videos and emulators. Basically, when programming for a VRR display, you’re now doing the equivalent of software-based VSYNC ON that’s lower lag than waiting for a monitor’s next fixed refresh cycle (for a non-VRR display). To successfully display fixed-Hz material (emulators, videos, etc) in a way that is as microstutter-free as true VSYNC ON, but without lag of VSYNC ON, you have to have really pristine framepacing accuracy. Do not use uncompensated millisecond-accurate timers, you may have to intentionally do a micro-busywait loop (a few tens or hundreds microseconds) within your timer event, to intentionally re-align your next frame buffer pageflip to a more exact interval since the last framebuffer flip […]
@GemaH The effect we’re talking about (essentially “movement is not as smooth with Sync to Exact ON as it is with classic VSYNC only”) is very, very subtle, and I dare to say most people won’t even notice it unless purposely looking at it, and even so, I bet it depends on how each person perceives movement “continuity”.
I am glad you don’t see it, but I think the problem is there on any monitor because apparently it has do do with how emulation itself works (unless somehow compensated for, as apparently standalone MAME does).
Oh believe me, if it’s there i can see it. I’m very sensitive of it. And if you could see my posting history in most other forums, you would see countless posts about PC games having “microstutters”. I’m talking about a couple of frames lost every now and then, it drives me crazy. Which is exactly why i got a VRR display in the first place.
I can assure you i don’t have this issue in MOST cores. Though i still have frame pacing issues in Dolphin, when i play 30fps games but that’s a Dolphin issue, not a RA issue.
I can share my RA cfg if you want in case there’s something different. But i feel like the difference lies elsewhere. Maybe it’s the GPU/Drivers. I use Nvidia and i always have VSync-ON via the driver. I also make sure the “power management mode” is at “high performance” when i run RA.
Maybe it’s Windows? I still use Windows 10, i have no idea how this performs on Linux or Windows 11.
Honestly i want to help because i know how annoying this issue can be. But saying “you have the issue. you just can’t see it” is a bit condescending. I have said it in the past myself for other people but only in simpler cases. RetroArch is a chain of many things so you can never be sure what other people are getting from it.
@GemaH I am truly sorry if I sounded condescending here. I didn’t mean it. I have read you countless times around here, and I know you are quite an advanced RetroArch user, but since the issue is so subtle, I thought it could be a perception difference. I think from what you told me, that probably you don’t have this issue: NVidia tech (NVidia drivers are closed source so we can’t really know) may be in the way and somehow doing it’s own thing which is not what my graphics stack based on AMD Radeon graphics based around an opensource compositor and MESA 3D Vulkan/GL implementation does.
No worries.
Yes, having a different GPU/drivers could be a factor. Though i have no idea how the options are in AMD GPUs.
I assume you have those options correct? Is there anything there that relates to giving your GPU full power at all times and not letting it “sleep” when nearly idle? RetroArch and emulators don’t use much of the GPU most of the time so there’s a chance it jumps from idle to not idle and changing this state randomly could cause microstutters like this.
I also assume you are on a Desktop and not on a power-saving adjusted Laptop or something like that.
Can’t say much else when it comes to your system outside RetroArch. But here is my Retroarch.cfg if you want to compare it with your’s. Oh, and i don’t use RTSS with RetroArch.
This is for a 240hz monitor. Adjust the refresh rate accordingly.
Could you also suggest me a scenario that i can try myself? Like a specific game and core? To make sure we are on the same page.
I have vimdiff-ed your config and mine, and I don’t see any relevant differences in the video synchronization.
As for GPU energy management, on modern GNU/Linux I can simply do:
Set high performance mode:
echo high | sudo tee /sys/class/drm/card0/device/power_dpm_force_performance_level
Verify:
cat /sys/class/drm/card0/device/power_dpm_force_performance_level
Watch the GPU running at highest freq unconditionally:
cat /sys/class/drm/card0/device/hwmon/hwmon*/freq1_input
…But that doesn’t make any difference for this issue.
That’s unfortunate. Since you tried the same cfg as mine i can’t offer anything else since i know nothing about Linux.
Do you have any Windows based PC you could try this on? This way you could confirm the issue is with RA on Linux specifically, if that’s the case.
@Tatsuya79 A frontend that works correctly with VRR/AdaptiveSync monitors without closed-source drivers is JGRF
Talking with it’s author, he helped me to understand it’s screen refresh algorithm. It goes like this:
// Divide the core framerate by the monitor refresh
runframes = (corefps / screenfps);
// Collect the remainder of the same division operation
collector += (corefps / screenfps) - runframes;
// When sufficient remainder has been collected, run an extra frame
if (collector >= 1.0) {
++runframes;
collector -= 1.0;
}
for (int i = 0; i < runframes; ++i)
exec_frame();
video_render(runframes); // re-render if runframes is non-zero
video_swapbuffers(); // swap whatever is in the video buffer every frame
It results on a constant VFreq of 120 Hz reported by the monitor and perfect movement with ~60 Hz emulated systems under JGRF. It wasn’t designed towards VRR, but it works for ~60Hz content on a 120 Hz monitor perfectly. It’s similar to having in RA: VSYNC ON, Swap Period AUTO/2 (on a 120Hz display), and Sync to Exact OFF. Except for one difference: JGRF always swaps buffers, thus resulting in these constant 120 Hz VFreq on the monitor OSD. Maybe swapping unconditionally even with Exact Sync is ON could help? That wouldn’t be VRR anymore, of course… That would be VSYNC + Swap Period…
So in the end, I suspect that the problem lies in emulation frame times. And as the BlurBusters founder says, RetroArch should re-align each next frame buffer pageflip to a more exact interval since the last framebuffer flip.