Retroarch and GSYNC... stutter again

[gordon81]

Hello, I'm having stuttering issues on Windows 10. My system specs are an AMD 5800X with 64GB of RAM, Nvidia 4070ti, and NVMe Gen4. The monitor is a Gigabyte that supports up to 270Hz with options for 120Hz, 165Hz, 200Hz, 240Hz, and 270Hz.

Currently, I have the monitor set at 165Hz. Using Custom Resolution Utility, I can force other refresh rate configurations, but the key is that RetroArch has issues when I don't limit the FPS to 59.9. If I don't use RivaTuner and let RetroArch detect up to 165Hz = 162fps (always limiting 3 or 4 fps for optimal Gsync), there seem to be problems.

The issue is that even with Gsync enabled, if a game has 60fps and I run RetroArch, it doesn't seem to work properly. The GPU fluctuates a lot, and stuttering occurs.

Can you recommend any configurations?

What am I doing wrong?

[gordon81]

Hello,

First all, thank you for this forum.

It seems that Vsync in RetroArch is mandatory if you want to use Gsync, as without it, the latter does not activate or work (source: [link](https://www.libretro.com/index.php/upco ... ync-users/)).

NVIDIA panel configuration.



If I don't limit the FPS in RetroArch, for example, if I leave it at 141fps to play OpenLara at more than 120fps, it causes stuttering in 60fps games.





By limiting the FPS to 59.9 using MSI Afterburner, I manage to achieve a smooth experience, meaning perfect framerate without stuttering.



RetroArch configuration: Vsync on (mandatory to enable Gsync).



RivaTuner configuration.



In other words, if I limit it to 59.9, I fix most games, but it affects Dosbox Pure and OpenLara, where the former reaches 72fps and the latter reaches 1440fps. In OpenLara, it's not as noticeable, but in Dosbox, it ruins pinball games.


I'm not sure if someone can help me, but I understood that VRR (gsync or freesync) precisely limits the frames to what the game requires, and I realize that if I leave the FPS unlimited at 59.9, it's as if VRR (variable refresh rate) doesn't work.

I'm having stuttering issues on Windows 10. My system specs are an AMD 5800X with 64GB of RAM, Nvidia 4070ti, and NVMe Gen4. The monitor is a Gigabyte that supports up to 270Hz with options for 120Hz, 165Hz, 200Hz, 240Hz, and 270Hz.

Currently, I have the monitor set at 165Hz. Using Custom Resolution Utility, I can force other refresh rate configurations, but the key is that RetroArch has issues when I don't limit the FPS to 59.9. If I don't use RivaTuner and let RetroArch detect up to 165Hz = 162fps (always limiting 3 or 4 fps for optimal Gsync), there seem to be problems.

The issue is that even with Gsync enabled, if a game has 60fps and I run RetroArch, it doesn't seem to work properly. The GPU fluctuates a lot, and stuttering occurs.

Can you recommend any configurations?

What am I doing wrong?"

All of this is with a freshly formatted Windows 10, no background programs, everything optimized.

[RealNC]

See if the "Ryzen Balanced" or "High Performance" power plan in Windows fixes it. Also, don't use external FPS limiters with RetroArch, and do not force vsync in the nvidia panel. Games running in emulators are very different to native games when it comes to frame pacing.

[Chief Blur Buster]

Some of what is being done is rather interesting;

Unfortunately, some operating systems adds stutters (even in VRR) that forces you to concurrently use an in-game cap and an RTSS cap. I've seen it de-stutter some games before. If stutter-reduction is numero uno priority over latency and other issues, multiple moats of caps can sometimes, indeed, be beneficial -- but it's tricky to tune.

If you must do an external frame rate cap with RetroArch internal framerate limiter -- then it is usually best to cap it slightly beyond only as a fallback cap as a backup, e.g. RTSS 61fps or 62fps or 60.5fps cap.

You can try to tighten the fallback cap, but try to swing above, not below. Most emulators run at 59.94fps, so don't cap below 59.94. Use www.testufo.com/refreshrate if you need a more precise refresh rate measurement. For certain emulator modules this helps smooths the frametime graph a smidge.

The only purpose of an external frame rate cap is as kind of a babysitter/cop on flawed internal framepacing of an emulator.

Ideally, for good framepacing and avoiding interference between capping algorithms -- the external cap should never activate before the internal cap. Meaning, the configured external cap should always be higher than the internal cap or internal throttle (e.g. simulated refresh rate of an emulator).

It's usually bad to use an external cap to throttle the average frame rate of RetroArch, because of its internal framepacing logic can have some nasty glitches when throttled by an external cap. 59.9 may usually work OK, but try 60 instead of 59.9 if your emulator modules are running at 59.94

Now, another method is to simply uncap RetroArch completely (so its cap logic doesn't glitch, and RTSS is completely in control of application framerate instead) and use RTSS Scanline Sync at 60Hz.

External capping works better if you let the emulator run at infinite frame rate (runs too fast), aka if you're running the emulator uncapped. This means if you turn off Scanline Sync, the emulator will run at scorching speeds (e.g. 2x to 5x+ too fast), so make sure you know what you're doing.

It's a game of pick-poisons, because I definitely sometimes (not always) get better results when utilizing an external cap (instead or simultaneous) -- but it has to be done in a way that doesn't cause the internal cap to glitch.

Sometimes tiered caps are used as layers of stutter protection during VRR -- but if you do this, try for progressively bigger for more-exterior.
- Lowest is internal-based throttle (e.g. in-game cap), then
- higher RTSS-based throttle (e.g. RTSS cap), then
- higher driver-based throttle (e.g. NVIDIA driver cap), then
- Higher monitor-based throttle (e.g. Monitor's max Hz whenever not using VSYNC OFF).

Caps further away from the game must be higher than the previous cap, to prevent cap-algorithm interference and/or race conditions that sometimes amplify stutters. Being that said, I wouldn't bother using too many moats (I never use RTSS and NVIDIA driver caps simultaneously).

TL;DR: You're simply using a backup cap as frametime-valley infill for a lower cap tier that accidentally creates a sharp frametime dip (e.g. frame is released a bit too early for whatever algorithmic reason).

[RealNC]

Most emulators run at 59.94fps

Actually, they don't. Most emulators run at either exactly 60 (when the VRR option is disabled in RetroArch), or at the emulated system's refresh rate (which can be anything, like 59.7Hz or 60.1Hz.) And arcade emulators can be using really anything between 50 and 70Hz, depending on the original refresh rate of the arcade PCB.

In RetroArch, you can enable "Display Statistics" in "Settings, On-Screen Display, On-Screen Notifications, Notification Visibility". This can also be bound as an on/off keyboard toggle in the RetroArch hotkeys.

[Chief Blur Buster]

That being true about 50-70 Hz!

Now that being said, about 59.94 Hz -- that's the NTSC standard, but yes, the NTSC emulators (consoles etc) do not necessarily run at that speed.

[thatoneguy]

That being true about 50-70 Hz!

Now that being said, about 59.94 Hz -- that's the NTSC standard, but yes, the NTSC emulators (consoles etc) do not necessarily run at that speed.

The thing is that old console tech pretty much never adhered to NTSC spec. It was almost always off-spec and all over the place. It varied with each hardware, some hardware could run at 59.71hz another hardware could run at 60.09hz, but they practically never ran at the NTSC spec refresh rate of 59.94hz.