It's tough to diagnose these cases, but:
For emulator use, you ideally need the following:
(1) An emulator with excellent frame pacing;
(2) Emulator should have the ability to throttle the frame rate to
sub-millisecond accuracy.
(3) For VRR drivers, VSYNC OFF versus VSYNC ON should not have to matter since you won't hit your GSYNC maximum.
(4) Emulator software should be configured as VSYNC OFF because there's no concept of "waiting for vsync" -- and should instead aim to very accurately framepace to avoid microstutter on a VRR display. 8-bit games were not designed VRR so framepacing problems still show microstutter problems even despite VRR's attempt to help. So framepacing ideally should be impeccable for VRR to benefit emulators with the latency-reducing benefits of VRR without adding microstutter.
One alternative workaround techique is to let the emulator run unthrottled (let emulator run as fast as possible), and then use RivaTuner/RTSS to cap the emulator frame rate to 60 (NTSC) or 50 (PAL). That intentionally slows down the emulator to realtime operation, and the frame pacing is fixed because RTSS has excellent frame pacing, and the stutter is fixed on VRR.
This technique does not work with all emulators but may be an additional option for compatible emulators. RTSS often has more accurate frame pacing capability than the frame-cappers built into emulators. However, RTSS may add more lag than the emulator's framerate throttle. So it's better for the emulator author to properly program RTSS precision into their emulator. If your microstutter disappears when using RTSS, then the emulator's framepacing is at fault, and the emulator developers can do better. If your RTSS test suceeds in the fix, then submit a bug report (BugZilla at the RetroArch site, linking to this post.
Decision matrix:
-- First, try the recommendations in
Issue #1633 at RetroArch's bug tracker.
If this suceeds, then you're finished, the emulator frame pacing issue is fixed.
-- Failing that, try removing your framerate throttle, and use RTSS to throttle your emulator.
If this succeeds, then the emulator's frame pacing is confirmed defective, and the emulator authors should read the below paragraph.
<FOR SOFTWARE DEVELOPERS>
Skip this paragraph if you don't know how to develop software.
NOTE: This is for other creators who visits Blur Busters Forums -- including emulator programmers / app developers / authors, please pay attention to your emulator's framepacing issues -- you want sub-millisecond timing accuracy in executing pageflips such as Direct3D Present() calls and such to avoid microstutters on VRR displays. A 1ms error in framepacing accuracy means a 1-screenwidth-per-second space shooter scroller or Super Mario scroller, will end up having a 1/1000 screenwidth microstutter (equivalent to 2 pixelwidths on a 1920x1080 display). This type of microstutter from 1ms framepacing error is noticeable when framepacing errors happens at regular intervals. 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 (record a microsecond timestamp everytime you do a framebuffer flip, and align the next framebuffer flip as exactly as your software allows you to -- timer events add microstutter for fixed-Hz material on VRR displays, so pad the beginning of your timer event routine with a micro-busywait since last event, if you're using a timer event). RTSS does this sort of pageflip accuracy magic already. It's not rocket science. You might be using another method. But if you're using a timer event as your framepacing method....Then trigger your timer event approximately 1ms early and do a micro-busywait to microsecond accuracy. Timer jitter gone. No more microstutter. Problem solved. PC games don't have to worry about this as much as their framerates are designed to fluctuate, but emulators & videos are not designed to, so you have to improve your framepacing programming game, to the microseconds level in your own app/software that you create.
</FOR SOFTWARE DEVELOPERS>