[SOLVED] RetroArch and 0.1% frametime deviation on GNU/Linux: It IS possible.

[vanfanel]

NOTE ON HOW TO DIRECTLY SOLVE THIS

To reach 0.1% frame time deviation in RetroArch (120Hz video mode) in frametime on GNU/Linux, simply disable C-STATES and DF C-STATES in BIOS.
On my BIOS (X600TM-ITX motherboard):
- Advanced\AMD CBS\CPU Common Options" and disable both "GLOBAL C-STATES" and "CORE PERFORMANCE BOOST"
- Advanced\AMD CBS\DF Common Options" and disable "DF CSTATES"

If your BIOS doesn't have these options, pass "processor.max_cstate=1" to the kernel to achieve a low-enough deviation around 1.7% which is enough for smooth "Sync to Exact" in well optimized cores like MAME and UAE. You'll still have DF C-STATES active, which are the "Infinity Fabric" C-STATES, but I don't know how to disable that from the Linux side of things.

ORIGINAL MESSAGE

Hi there,

I initially noticed that VSYNC offers perfectly smooth scrolls/movement with RetroArch (GenesisPlusGX core + 240p Test Suite is used for testing) on GNU/Linux + in-kernel AMDGPU + latest stable MESA (25.0.2).

The problem: I noticed that also enabling "Sync to Exact Content Framerate" makes scroll/movement not-so-perfect: there's no tearing, movement is "almost" perfectly smooth... but I see "something" is wrong, like a continuous imperfection in movement that is NOT present if I disable "Sync to Exact Content Framerate".

This happens when using both plain KMS/DRM graphics and also using Wayland (I have zero interest on X11, but X11 does the same thing). So, all in all, Wayland can be ruled out as a culprit here.

There are no processes causing CPU usage spikes. Nothing. This is a very light system where every service that is running has been allowed by me.
This is also using plain ALSA audio ONLY, no PulseAudio or any other audio servers are running here.

This happens in every video frequency I have tried (120hz, 140Hz, 240Hz on the higher-end displays...), except if I set a 60Hz mode and run ~60Hz content: in that case, with "Sync to Exact Content Framerate" enabled, I get perfect scrolls and movement, as good as with plain VSYNC without "Sync to Exact Content Framerate".
Of course that only works for ~60Hz content... 70Hz DOS games can't sync properly because of the 60Hz cap, and PAL/50Hz content doesn't move correctly either, so setting a 60Hz mode is not the solution.

This is with all my available monitors: Viewsonic XG2401, Viewsonic XG2431 and Alienware 2724HF. They all do the exact same thing.

Now, I have noticed that, with a 120Hz video mode, RetroArch detects ~120Hz correctly, but with a frametime deviation of 3.1% by default.
Supposedly, for optimal video sync on RetroArch, a frametime deviation of ~0.1% is desired, as documented in Libretro's "optimal-vsync" guide, so I suspect this deviation is what could be causing the strange "micro-micro-stuttering" I am seeing with "Sync to Exact Content Framerate" activated!

I could take that down to 1.2-1.3% by setting the performance level on my AMDGPU with:

Code: Select all

echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level

But after that, I wasn't able to make the frametime deviation any lower than that: I rebuilt my kernel with a 1000Hz timer rate, but it actually increased the frametime deviation, and same happened with a Real-Time kernel build.

I also tried setting the CPU governor to "performance" and verified it was indeed being used, but that made zero improvements, there's no way I can lower the frametime deviation from that 1.2-1.3%!

20250401_21h06m24s_grim.png (42.82 KiB) Viewed 1842 times

I also asked in the RetroArch discord, but even if I got some nice support, we didn't get to any conclusion. Do you guys have an idea on what could be going on here? What could be getting me that 1.3% frametime deviation at 120Hz on GNU/Linux?

[RealNC]

You need to verify freesync is actually active and working. If the monitor has a current Hz indicator in its OSD that shows the current VRR refresh rate, use that. If at 120Hz it says 60Hz, then it's working.

[vanfanel]

You need to verify freesync is actually active and working. If the monitor has a current Hz indicator in its OSD that shows the current VRR refresh rate, use that. If at 120Hz it says 60Hz, then it's working.

Yes, it's working: both the monitors (I have several models as I mentioned) and the Linux side of things report it's working.
Also, I can see the fluctuating ~60 framerates in 120Hz mode on the monitor overlay.

The problem is, as I said, that high frametime deviance seems to be causing not-so-smooth movement (or "perceived smoothness" if you will) as with plain VSYNC.

[Chief Blur Buster]

Heads up. I released a superior refresh rate calculator to Apache 2.0 open source. Github RefreshRateCalculator by BlurBusters + DuckWare (VSyncTester). It's one of the refresh rate calculator engines behind TestUFO.

Apache 2.0. Please steal our code for RetroArch!

Also, I suspect that Retroarch will need an optimization where one core gets a busyloop on RTDSC (not a timer or event), to do ultra-accurate framepacing. I had to do busyloops for microsecond-accurate tearlines in Tearline Jedi from a few years ago. RTSS Scanline Sync uses the busyloop technique too. And needs to temporarily bypass CPU/GPU power management, since the computer often goes to sleep between frames and wakeups can jitter the framepacing. I even had to add an optional TestUFO power-burn busyloop to the gear icon at www.testufo.com for MacBook's due to power management stutter where low-GPU loses perfect framepacing during low CPU/GPU utilization.

P.S. With a proper busyloop-based framepacer, RetroArch should be able to have VRR + CRT simulator simultaneously. It's possible, see this github comment I added, if you are a software developer.

[vanfanel]

I finally fixed this by disabling C-STATES (be it on BIOS or by passing "processor.max_cstate=1" to the Linux kernel) and DF C-STATES (needed for 0.1% deviation: without it, a 1.7% deviation at 120Hz is still present which is enough for apparently smooth "Sync to Exact" to work on the cores where it works).