Title: Issue with CPU Instruction Queue Limitation

Body

I am a user from China, and I want to give my sincere thanks to the developers of Special K. However, I have run into a frustrating problem.

My monitor operates at a clock rate of 60.02 Hz — to be exact, 60.020425… Hz. It seems Special K can only detect up to three decimal places for this value from the system. When playing Outer Wilds, the game engine fails to align with this timing. I’ve noticed this issue plagues most Unity engine games; I encountered the exact same problem in Hollow Knight too. I have tried the thread synchronization options, but they do not fix the root cause.

For this timing mismatch, I rely on Latent Sync. This feature requires the CPU frame instruction queue to not be capped at 60 FPS. My CPU has relatively weak performance, so the frame rate occasionally drops below 120 FPS. Once that happens, the CPU frame instruction queue gets locked to 60 FPS. It will only randomly return to above 120 FPS when the frame rate fluctuates again later.

After numerous tests, I confirmed that enabling Fast Vertical Sync in the NVIDIA Control Panel can stop this frame lock. Sadly, Latent Sync no longer works properly with this setting enabled. The continuous timing desync leads to accumulated errors, which greatly impacts my experience.

I have carefully read the official Wiki and tried troubleshooting with AI assistance, but none of these methods resolved the problem.

I truly hope the development team can notice this issue and patch it in future updates. Thank you so much for your dedication and work!

Below are screenshots of my settings. I apologize for using the Chinese localized interface, but you can get a clear idea of my general configuration from the UI layout.

i’m not sure what you mean when you say “This feature requires the CPU frame instruction queue to not be capped at 60 FPS…” or why you’re mentioning 120 fps when apparently your display’s refresh rate is less than 120hz…

anyway, it’s not that SK doesn’t have the precision to measure numbers with more digits. it’s just that sk’s control panel truncates decimals at 3 digits to make it easier on the eyes. you can still manually type in a larger number in the SpecialK.ini, in the control panel while in-game (after hitting enter, the number shown will be truncated and that’s fine — sk can still read a larger number), or right click the fps limiter and select an fps factor from the dropdown list that’s based on the display’s current max refresh rate etc.

if your fps is suddenly getting cut in half because of a weak PC… it sounds to me like you’re using vsync on with 2 buffers and using fixed refresh (instead of gsync/vrr), in which case yes fast sync can stop that big fps drop, but you may see judder if your fps is not a factor of your display’s max refresh rate while using fixed refresh. also, keep in mind that fast sync does not work with d3d12 games.

you could try using latent sync and stop forcing vsync on. make sure in nvidia’s app you have vsync set to use the 3d application setting.

you may also want to try adjusting in-game setting for better performance..

and, at least if the game is using d3d11, another thing you can do is set buffer count to 3 in sk’s swapchain management section inside sk’s control panel while in-game. a buffer count of 3 may increase performance and prevent fps from getting cut in half while using vsync…

Thank you for your reply and suggestions. I don’t actually have any issues with the refresh rate decimal precision display. My core problem remains the 60 FPS lock-in of the CPU instruction queue.

When Latent Sync is active, if the CPU instruction queue gets capped at 60 FPS, it introduces excessive waiting time for CPU instructions, resulting in stuttery visuals and drastically elevated input latency. While Latent Sync within Special K theoretically removes the hard 60 FPS limit, the queue still snaps to 60 FPS automatically whenever my frame output dips below 120 FPS.

My monitor is indeed a native 60 Hz panel, but raising the ceiling of the frame instruction queue far above 60 is necessary to cut input lag and maintain stable timing synchronization between frames and the display.

This issue is fairly nuanced, and I’m still unsure whether the root cause stems from underlying Windows scheduling mechanisms or a compatibility quirk within Special K itself.

i don’t think there’s any compatibility quirk with special k going on…

that said, I’m not sure what you mean by “CPU instruction queue” here.

are you talking about the fps limiter ? you can cap fps at 1:1 from the dropdown menu option with latent sync and increase the delay bias percentage towards input to lower latency. did you try that ? having fps above the display’s max refresh rate shouldn’t be necessary…

and, then again, if your fps is suddenly getting cut in half or snaps to 60 fps automatically whenever your frame output dips below 120 fps… it sounds to me like you’re using vsync on with 2 buffers and using fixed refresh (instead of gsync/vrr) and it doesn’t sound like you’ve tried what i suggested.

setting the buffer count to 3 with sk can normally stop those fps drops:

image

i’d also recommend to try without vsync.

use latent sync and the sync offset slider to hide the tearline… and, if you can’t consistently keep the tearline hidden with just adjusting latent sync’s sync offset slider, then you could use the additional options for adaptive vsync (try sk’s “adaptive (prefer off)” tearing mode option) or disable tearing… AND also try increasing the input delay bias towards input to lower latency.

i’d try increasing the delay bias towards input until the mouse icon in the latent sync menu shows a negative number; then lower the input bias percentage one level or until the number by the mouse icon is no longer negative — and/or try latent sync’s autobias option.

(if the number by the mouse icon in the latent sync area is negative, it’s generally recommended to lower the input bias percentage to avoid pacing issues… ideally the mouse number should be low but not negative)

for reference:

image

you could also try the adaptive tearing option(s):

also, i’d suggest doing a full installation of special k with the special k installer.

it doesn’t look like you can see the game’s current presentation mode here:

image

that section is supposed to show the presentation model that the game is currently using and this is important…

ideally (for better performance and lower latency), the game should be using an independent flip presentation model as shown here:

image