Frametime issues

[Plasma-O]

edit:

My updated views on the issues

please feel free to ask me questions about things that aren't clear or where you need more data.
Im sorry in advance for lacking info or errors.

frame pacing

The primary thing I think can be improved quite easily is how threads idle on windows. The current approach uses a waitable timer, which has an accuracy of 0.5-1ms.

Assuming an average CPU frametime of 1ms the worst case performance loss just from a long sleep call is (frametime + oversleep) doubling frametimes and halving fps to 500. (do keep in mind that there is no guarantee when the sleep call might resume)

Adjusting the time to sleep dynamically based on how accurate the previous sleep was gets compensates how much time performance was lost on average, but doesn't fix the stutters.
500fps is still really good, but encroaches on skipping frame presentations on high refresh rate monitors on systems that should realistically never skip a single one.

Most games don't use or offer any fps limiters above ~300fps for that reason.

waitable timer

target	min	max	mean	median	std. dev.	SE
0µs	3	504	4.28	3	16.247	0.514
32µs	45	1208	520.77	513	58.285	1.843
128µs	466	1173	539.21	522	55.149	1.744
256µs	447	1412	580.52	530.5	144.355	4.565
512µs	522	1540	848.82	972.5	231.566	7.323
1024µs	1029	2223	1739.12	1960	353.473	11.178
2048µs	2058	3522	2808.96	2975	320.828	10.146
4096µs	4105	5298	4822.96	4966.5	297.950	9.422
8192µs	8206	9407	8815.20	8932.5	286.145	9.049

A simple spin lock loop calling yield() on idle practically guarantees the next frame will start when it's supposed to and not 1ms later. With the downside of maxing out that core.

yield() spin lock

target	min	max	mean	median	std. dev.	SE
0µs	0	25	0.04	0	0.938	0.030
32µs	32	48	32.03	32	0.672	0.021
128µs	128	151	128.13	128	1.408	0.045
256µs	256	294	256.15	256	1.685	0.053
512µs	512	529	512.06	512	0.948	0.030
1024µs	1024	1049	1024.11	1024	1.432	0.045
2048µs	2048	2097	2048.22	2048	2.191	0.069
4096µs	4096	4128	4096.24	4096	1.987	0.063
8192µs	8192	8226	8192.17	8192	1.786	0.056

(benchmarks are done in C++ directly via the win32 api or intrinsics where needed)

If the goal is maximum performance this is the perfect solution. If saving resources is the goal this doesn't help.
Sleep calls are optimized by the OS for long sleep times. Luckily CPU makers have special instructions for very precise and energy efficient core parking/sleeping.

Intels WAIT_PKG instruction set (Specifically the tpause instruction) is purspose built for user space programs that frequently need to sleep for very short amount of times. Unfortunatly .NET support for WAIT_PKG is approved, but still in the backlog for .NET 11 dotnet/runtime#120362 and AMDs equivalent isn't in the discussion at all.

Older instructions meant for spins locks are still available in .NET (like x86's __mm_pause() or ARM's YIELD). They achieve indentical performance vs a yield() spin lock while reducing power draw.
Another benefit is not having to pay the cost of context switches on yield() or a timer.

Most windows games implement a spin loop with __mm_pause() for the last second and use a waitable timer for every duration above that.

Render API

Most of the frametime issues are due to the use of the outdated veldrid library for every non opengl render backend.

Veldrid is based of OpenGL 3. An API design very far removed from modern GPUs of every vendor.

The OpenGL backend runs on every platform except apple and performance the best currently.

Newer APIs offer very useful new features (VRR, virtually no input lag in borderless mode, nvidia Reflex/ AMD Anti-Lag 2)

• Vulkan has conforment and performent drivers on every platform (including apple).
• DirectX12 runs on windows, almost identical to vulkan.
• Metal 4 runs on apple devices. Performance and features very close to Vulkan and DirectX12.

The 4ms jumps in Frametime-Display as shown in the videos of my original post due to lacking VRR support.

imo veldrid should be replaced with a modern purpose built vulkan backend on every platform.
(non veldrid) OpenGL + Vulkan covers every device Osu!lazer could (or should) run on.

heavy stutters while decoding video

apparently that's a know issue on AMD windows drivers. Unfortunate, because osu maps with a video playing in the background trigger this bug.

---

original:

This isn't an Idea, but an analysis of lazers bad frame pacing and the pipeline freeze bug. I choose not to put it into an issue, because spaceman_atlas told me to put it here.

---

Ever since I switched to lazer, my game has randomly massiv stutters, but every time I looked at the ingame fps/frametime counter there was no issue. After testing a bit I found the cause of the stutters.

game running smooth, every frame presented perfectly on time, when testing with no background apps running.

in a normal play session with video running in the background the stutters are back:

each individual frame is rendered on time and with time to spare, but the frames consistently only reach the display in ~16ms.
This hints at three possible causes:

• either the games draw thread is preoccupied by work other than drawing (unlikely)
• or the draw thread for some reason begins to randomly sleep for 16ms every time another process uses accesses some part of the PCs resources, that the game is using.
• a very obscure rdna3 specific driver or hardware bug, that somehow hasn't been noticed by anyone at AMD for at least 2 years.

I stumbled across this exact sleep issue when I programmed a very simple bare bones osu!std clone as a learning project. The game couldn't be fps limited to anywhere remotely close to the target frame rate above 500fps.
As it turns out Windows Sleep() runs at a default resolution of 16.6ms and Sleep(0) makes the thread lose it's time slice and has to wait "sleep" until Windows gives it a new time slice.

To fix this you have to set the global system timer interrupt frequency to the highest available resolution of glorious 1ms or 1000hz with timeBeginPeriod(1). Only caveat being that this setting effects the timers of every program running on the PC and can be changed by any program on the PC. Best practice is therefore to only use it when necessary and check the current timer resolution before every Sleep() call and setting it to the required resolution if necessary with timeBeginPeriod(1) and reset it once your done requiring it with timeEndPeriod(1).

Even after this complicated setup a Sleep(1ms) is just a guarantee to sleep atleast 1ms and the timer resolution might have changed before calling Sleep() already.

Modern spin lock implementations instead wait on the compositor clock / the swapchain or a waitable timer created with any of the various timer APIs. The first two don't use a timer and the last can have a Sleep() duration guarantee as low as 0.5ms

If you need to precisely wait until a known time it is recommended to not sleep only sleep for longer durations and instead busy wait the last 1ms. Power Efficiency can be improved with Thread.Yield() and/or the cpus equivalent of intels _mm_pause() instruction.

---

The bug being triggered by OBS being open or running - 30fps

2026-03-11.13-51-29.mp4

60fps

2026-03-11.14-37-33.mp4

---

All recordings and tests are done with the "Direct3D 11" Renderer, but all (Windows) APIs exhibit similar or identical behavior.
I haven't thought about every possibility and am happy to be reminded about something I have missed.
I also want to talk about the specific implementation in the osu!framework.

[bdach]

you have to set the global system timer interrupt frequency to the highest available resolution of glorious 1ms or 1000hz with timeBeginPeriod(1). Only caveat being that this setting effects the timers of every program running on the PC and can be changed by any program on the PC. Best practice is therefore to only use it when necessary and check the current timer resolution before every Sleep() call and setting it to the required resolution if necessary with timeBeginPeriod(1) and reset it once your done requiring it with timeEndPeriod(1).

I dunno about that one.

Prior to Windows 10, version 2004, this function affects a global Windows setting. For all processes Windows uses the lowest value (that is, highest resolution) requested by any process. Starting with Windows 10, version 2004, this function no longer affects global timer resolution. For processes which call this function, Windows uses the lowest value (that is, highest resolution) requested by any process. For processes which have not called this function, Windows does not guarantee a higher resolution than the default system resolution.

Maybe we can skip some of the stupidity if the windows docs aren't lying. (Not that I confirmed that any of this is true, just did a basic truth check on the aforementioned claim because it seemed borderline too stupid. There are other Windows APIs this stupid but I always gotta double-check past a certain threshold.)

Other relevant info:

Starting with Windows 11, if a window-owning process becomes fully occluded, minimized, or otherwise invisible or inaudible to the end user, Windows does not guarantee a higher resolution than the default system resolution. See SetProcessInformation for more information on this behavior.

Setting a higher resolution can improve the accuracy of time-out intervals in wait functions. However, it can also reduce overall system performance, because the thread scheduler switches tasks more often. High resolutions can also prevent the CPU power management system from entering power-saving modes. Setting a higher resolution does not improve the accuracy of the high-resolution performance counter.

[Plasma-O]

Maybe we can skip some of the stupidity if the windows docs aren't lying.

That is likely.

This seems to be such a big issue, that Intel and AMD and probably more are working on alternative user space instructions to replace Sleep() and Pause() for short sleep durations.

Core power consumption can be reduced by ~20% ~70% compared to the usage of PAUSE. The latency for waking a core in user idle reflects the underlying hardware architecture with tens (desktop architecture with shallow idle states) to hundreds (server architecture with deep idle states) of nanoseconds at nominal frequencies.

But these instructions are relatively new.

[peppy]

We already set the windows mm timer, of course. This is common knowledge and you can't really make a game without doing so.

You should be able to confirm this by reading our codebase.

Are you implying otherwise? I'm quite confused by this whole discussion because we're already doing (or have trialled not-yet-implemented because it's not hugely worthwhile, aka spinloops / hybrid approaches) everything you have suggested.

I'm also struggling to understand what your graphs are showing, or what is providing them. We cannot reproduce your issues, so I'd suggest it may be a driver or other application bug as you hypothesise.

I'd suggest you follow our standard practices as this is likely a localised issue to your configuration. Here's a page with some self-help troubleshooting you can go through https://osu.ppy.sh/help/wiki/Performance_Troubleshooting, and report back if you figure what was causing the issue.

[smoogipoo]

Additionally the post goes to mention:

or a waitable timer created with any of the various timer APIs

We do this, too. See:

osu-framework/osu.Framework/Timing/ThrottledFrameClock.cs

Lines 40 to 43 in 2140bf7

	if (RuntimeInfo.OS == RuntimeInfo.Platform.Windows)
	nativeSleep = new WindowsNativeSleep();
	else if (RuntimeInfo.IsUnix && UnixNativeSleep.Available)
	nativeSleep = new UnixNativeSleep();

[Plasma-O]

You should be able to confirm this by reading our codebase.

I indeed have confirmed this now. Pretty much everything except a spin loop is already in the code the best way I can think of.
The timer resolution just wont be better than 1-0.5ms.

Are you implying otherwise? I'm quite confused by this whole discussion because we're already doing (or have trialled not-yet-implemented because it's not hugely worthwhile, aka spinloops / hybrid approaches) everything you have suggested.

Im not trying to imply anything contrary. This is on me for not reading the entire Code related to Sleeping (I didn't look into WindowsNativeSleep()). I definitely should have finished and double checked my research before posting anything.
What you guys have tested/considered internally is outside of reach of what I can know without asking directly.

What I took from smoogipoos message on Discord is, that you guys ended the research somewhere halve way and focused on things other then the Sleep() itself. Maybe I can dig in further and improve this.

---

I'm also struggling to understand what your graphs are showing, or what is providing them.

The program providing the data is "Intel PresentMon" a tool developed by Intel with good data visualization options for pinpointing stutters. To my knowledge it is the most accurate accessible tool available and the backend for most modern videogame benchmarking tools.
GPU Busy and CPU-Busy represent the time the CPU and GPU where doing work for that frame. Frametime-Display is the Time between each frame presented to the display. Frametime-App is the time between the CPU beginning work on the last Frame and the current Frame.

The combination of flat CPU Busy numbers and sudden massive lag spikes in Frametime-App hints strongly at the CPU pausing/sleeping randomly for ~16ms.

---

Originally when I first messaged on Discord I had two distinct Problems.

1. The sudden lag spikes without any noticeable additional load on the CPU or GPU
2. Very inconsistent frametimes at any target framerate, that (depending the exact settings used) either oscillated around the target framerate or constantly undershot it

It's totally on me to conflate these two issues and present them as one in the hopes of solving/avoiding both issues by avoiding to sleep for short time intervals.

---

We cannot reproduce your issues, so I'd suggest it may be a driver or other application bug as you hypothesise.

My current working theory on issue 1. is that that bug is only triggered under very specific hardware combinations and software usage patterns. I don't expect anyone to run into the same symptoms under the same usage pattern.

I have updated my BIOS, reinstalled windows completely and tripple checked, that I have the newest driver available installed and there aren't any matching known issues. The only difference and improvement I noticed are that the game doesn't cause a graphics driver crash anymore.

Another thing to note is that the CPU usage "sleep" time anomaly follows a saw tooth pattern similar to the RAM usage of garbage collected languages like seen in image 1 and this profiling run done with the vulkan renderer.
(do note, that i don't have any idea how to interpret this info. Im just throwing this out there.)

Brown represents the CPU doing work and red represents spin loops (including waiting on synchronization objects).

---

Issue 2. on the other hand I expect most people to reproduce with the same test.
Yes 0.5-1ms variance isn't much, but causes any of these issues:

• big stutters relative to the framerate
• constantly overshooting the sleep target / undershooting the target frame rate
• dropped/skipped frames even at 60hz as shown here:

---

A busy wait loop for the last 1-1.5ms will definitely fix the frame pacing issue (2.), but at the cost of a lot of CPU time and energy being wasted. (the video goes into more detail about why and how to fix it)
Both AMD and Intel have implemented instructions to retain full precision without the energy cost of a busy wait.
Unfortunately AMDs MONITORX and MWAITX instructions aren't available in .NET yet and Intels WaitPkg instructions are api-approved but only in the backlog for .NET 11.
Both are therefore out of the picture for at least a couple more years and would only work on relatively new CPUs (12th gen intel and AMD excavator).

I don't know the exact requirements for osu!lazer, but I would really appreciate a toggle between both busy wait and Sleep() for people with the hardware to spare.

---

Im once again sorry for bothering you guys with halve finished research and writing such a long wall of text.

[marcan]

I'm not sure why I'm tagged here, I know nothing about any of this.

[Plasma-O]

sorry for tagging you here then. I wanted to tag spaceman_atlas, but Github was adamant the correct user account would be yours. Please ignore, if you're not involved with osu!lazer development.