FreeSync : irrelevant actual monitor frequency

[bidinou]

Hi everyone !

After reading this thread : #1633, I tried to get FreeSync to work.

My setup is the following : Linux (Lakka), Nuc i5 iris 440 and recent Freesync compatible "gamer" Iiyama monitor.

When freesync is disabled : I get "almost perfectly" smooth scrollings in all systems. Not pixel perfect though (I use integer scaling). There are some minor glitches. It's acceptable, but I was wondering if this could be improved. I'm from the Amiga scene so butter smooth scrollings are kinda part of me :-) Retroarch reports a vertical frequency of 60.002 (0.5% deviation after a while). My monitor is at 60 Hz.

So I tried to enable freesync on my monitor OSD. For some strange reasons, my monitor OSD reports now a variable frequency around 70-75 Hz !! And Retroarch report a frequency around 55-59 Hz or so with a huge deviation (like 15%). Very unstable. Logically, games are clearly not smooth. It's not that terrible but far less smooth than in the case above. I tried to tweak the settings as indicated in the previous thread (audio sync, vsync, 1.0 run speed, delta 0.0) but it makes no significant difference. Apart from runspeed otherwise it's too fast with audio sync disabled.

I guess the issue is : why is my monitor vertical frequency set between 70 and 75 Hz to display 60 Hz games ? Also, strange thing : even if I disable Freesync I have to reboot Lakka otherwise my monitor gets stuck at this strange frequency. Not really a problem, the gfx stack must get confused if a monitor behaviour is altered.

Thanks a lot to everyone :-) Big retroarch / lakka fan !

Edit : of course, I tried many combinations of more common settings too (max swapchain 1 2 or 3, vsync on/off, I do use integer scaling, disabled shaders, etc etc.)

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[inactive123]

I don't have a Freesync/G-Sync monitor so I can't really comment on these other issues you are having. instead, I will invite @Themaister in this thread since he might be able to provide you with a clearer answer as to what kind of steps you could take to improve your situation.

As for higher than usual frame time deviations, are you able to test the Vulkan video drive there? GL drivers are kinda spotty there in general.

[bidinou]

Thanks for the reply ! I'm not sure Vulkan is available on Linux ATM ? Never really heard of it actually. I have no Windows box to make the comparison, unfortunately :-/ Been Linux-only user for 12 years :)

[hizzlekizzle]

You can use Vulkan in Linux with your Iris graphics.

[bidinou]

Hi ! I'm getting back to you as I'm completely clueless regarding this Vulkan gfx driver. I searched quite a lot and found no piece of information indicating its current state on Lakka, how to enable it, what is currently supported etc. Any pointer ? :-) There's no hurry, I can wait a couple of months or more for a Lakka version with Vulkan driver built-in if it's not mature.
Regarding Freesync : even without it, with the proper configuration, I get butter smooth scrollings anyway for systems close to 60 Hz (I guess 60 Hz is forced so it may alter a little gamespeed but I don't mind). Would be useful for the Amiga, Atari ST or PAL games.
Thanks :-)

[hizzlekizzle]

I haven't used it in Lakka, but as long as their Mesa libs are reasonably up-to-date, you should be able to go into settings > driver and change the video driver to vulkan and then just reboot. Note: libretro-gl cores like ppsspp and mupen/glupen won't work with vulkan.

[bidinou]

Hmm, apprently it's not in the current build. Only OpenGL driver (or "none") in Lakka / PC / x86-64. I'll wait :)

[blurbusters]

--crossposted from #1633, as it will also fix FreeSync support--

I am trying to help a user fix microstutter during variable refresh rate, and I have given them recommendations: https://forums.blurbusters.com/viewtopic.php?f=5&t=3903&p=31050#p31050

However, it is also the emulator author's responsibility to improve framepacing as much as possible, to minimize VRR microstutter.

This is what I have advised to the user, but I am cross-posting here because too many emulators fail in properly implementing VRR support. Many are already good (perhaps yours is) but I'm posting here as a public education notice.

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]

(Direct quote from Blur Busters Forums)

If microsecond-accurate framerate throttling does not yet exist in RetroArch, it is an easy fix. Please open a new issue here on this system, for the good of other VRR users. It is a pervasive problem with approximately 50% of emulators, and it's amazing how big a difference a single microsecond actually is -- but it makes sense because VRR (FreeSync, GSYNC) hands over refresh cycle trigger to a software clock instead of a hardware refresh rate.

If you are doing render-and-flip all at once -- then frame rendertime fluctuation issues will cause microstutter issues when mapping an emulated fixed Hz to a VRR display. Separate your rendering from your frame flipping, instead of "render-and-flip" all at once. Basically render, then micro-busywait, then framebuffer flip (microsecond-aligned to previous flip). You may want a configurable margin (e.g. 1ms, 2ms) depending on emulator, as your padding for rendertime variances.

Many developers are unaware that the exact time of framebuffer flip immediately triggers refresh cycles (photons hitting eyeballs) when it comes to a variable refresh rate display. Your computer just (essentially) commanded a VRR monitor, "display the frame NOW" when your app executes glutSwapBuffers() or Present() or whatever. Imperfect software timers equals microstutter! So... Wisely wield your new-found power of directly commanding refresh cycles :)

If RetroArch already has microsecond-accurate frame throttling, so truly appreciated.
If RetroArch does not have (best-effort) microsecond-accurate frame throttling, fix it, pretty-pretty-please.
G-SYNC and FreeSync users thank you very much for reading this public service notice --

Cheers,
Mark Rejhon
Founder, Blur Busters & TestUFO

P.S. TIP: VRR is good for video too. 48fps film, 59.94fps, 60fps, 120fps, 18fps, 23.97fps, 24fps, 25fps, whatever. Please verify your video players in RetroArch is fully VRR compatible. Many players configured into fullscreen mode automatically work with VRR (e.g. SMPlayer) but many video player authors unaware of VRR accidentally (in good intentions) mess things up when trying to improve things for a fixed-Hz monitor. Authors are unaware of how VRR works. VRR friendly video is easier than most think: It's simply executing frame pageflips at intervals as exactly-as-possible to the frame's timecode as possible -- and letting the VRR do the magic for you.

P.S. TIP 2: A 144Hz or 240Hz VRR Monitor is an excellent way of reducing 60Hz emulator lag. Occasionally, in certain cases, the lag savings is so huge that it can actually sometimes get less input lag than the original emulated machine connected to a slow-scanning 60Hz display. This is made possible because the individual refresh cycles are scanned-out in 1/144sec (for 144Hz VRR) or 1/240sec (for 240Hz VRR). So your 60Hz frame appears sooner than on many 60Hz displays, even though you're only running at 60fps on a high-Hz VRR display. Basically, perfect ultrasmooth 60Hz VSYNC ON appearance with most of the low-lag benefits of 144Hz/240Hz VSYNC OFF. The VRR trick for emulators (that has good frame pacing), can compensate a huge amount for emulator lag, and is part of why VRR is getting popular with emulator users as a lag-reducing technique.

[hizzlekizzle]

@bidinou is this still a problem with the 'sync to exact content framerate' option and your refresh rate set to your monitor's max refresh?