Detecting refresh rate changes

[flibitijibibo]

An FNA developer ran into an interesting performance issue that turned out to be caused by the framerate limiter on SteamOS:

The compositor on Steam Deck will stall your main thread to control frame pacing. I assumed it would adjust the Hz of the display, but it actually doesn't: eg, on OLED, after setting it to 60Hz, it still reports to SDL that it's a 90Hz display.

This negatively affected my game because I time slice my main thread to build geometry in the background. I time how long update and draw calls run for to heuristically determine how much work I can do. The compositor stalling my thread made my engine think that it had no time left for background processing.

This makes sense in practice since you wouldn't want to perform a whole entire modeset every time you moved the framerate limit slider, but it made me wonder two things:

• Is SDL currently set up to detect refresh rate changes, like we already do for other display mode changes? If so, does this work on x11?
• Does either gamescope or the SteamOS overlay expose the user's intended framerate limit in some way? Should gamescope be sending display events for this somehow?

[misyltoad]

Hello,

SteamOS/Gamescope does not stall applications by itself. It is very likely the game is stalling itself by eating all its swapchain backpressure. When running at lower rates, we naturally hold onto images from the game for longer.
You should use vkWaitForPresentKHR in order to manage the queue depth yourself to avoid stalling out in vkAcquireNextImage.
For prior art here, looking at how DXVK's max present latency is implemented might be a good idea.

Gamescope intentionally does not expose a mode change when the refresh rate/fps slider changes as most games typically do not handle the mode changing out from under them, either breaking or hanging or crashing.

For apps that want to be aware of target refresh cycle changes, they can use VK_GOOGLE_display_timing and vkGetRefreshCycleDurationGOOGLE. VK_EXT_display_timing will be implemented eventually in a future SteamOS version, but will take a little while to become available.

[flibitijibibo]

I think this happens even with OpenGL, but this may be an SDL_GPU task either way... here's the CPU-side loop (I think it's using variable step, so IsFixedTimeStep should be false):

https://github.com/FNA-XNA/FNA/blob/master/src/Game.cs#L423

... this is the Present call:

https://github.com/FNA-XNA/FNA3D/blob/master/src/FNA3D_Driver_SDL.c#L1113

... and Vulkan presentation in SDL:

• Acquire
• Present

I think we were talking about display timing in #14540 for Metal so that may be worth checking as well.

CC @thatcosmonaut, @riverrunninggames

[misyltoad]

Unfortunately with OpenGL, I am not aware of any generic ways of limiting your present latency in a similar way. Maybe the weird glx osm sync control stuff? I have never used that, sorry.