Created Latency and unlimited frame rates (markdown)

Latency-and-unlimited-frame-rates.md

@@ -0,0 +1,79 @@
+Over the years in the osu! community, high frame rates have been seen of as somewhat of a goal or "holy grail". Ruling out hardware and PC performance as a limiting factor of skill is a good goal for players, and higher numbers leading to lower reported "latency" numbers is a good way of setting the mind at ease.
+
+That said, there's a few concerns we need to address going forward, as we introduce osu!(lazer) with its new efficient multi-threading model and push forward towards using newer graphical APIs. The main one being that I think a change in perception and understanding is required – unlimited frames is not the holy grail you may think it is.
+
+## Changes to "Unlimited" frame limiter
+
+From this release of osu!(lazer), "Unlimited" has been renamed to "Basically Unlimited" and now caps the game at 1,000hz draw and update.
+
+Until now have not taken a hard stance against "unlimited" frame limiter, even though we have known it is counter-productive. As time goes on, we have seen more and more users experience stuttering or performance issues during gameplay, and many cases are resolved by changing the frame limiter from "unlimited".
+
+The majority of these users have chosen "unlimited" on advice from others, or because it seems like the most performant option.
+
+This can be counter-productive due to the various overheads that come with running a game at high frame rates. Overheads can include:
+
+### Allocation overhead can lead to excess garbage collection
+
+We're generally pretty good at not allocating on a per-frame basis, but there are situations where this has not yet been optimised. osu!(stable) is not affected by this but for the time being, lazer is.
+
+### GPU overhead can lead to unexpected pipeline blocking
+
+GPU manufacturers write drivers and test cards using 3d workflows. It is very rare for a game or application to run at over 1,000 fps in the first place, so the drivers are generally not optimised for such scenarios.
+
+Especially while we are still using Open GL, it is very possible for a pipeline blocking operation to lead to a stutter. This can sometimes be caused by us (rare) but more regularly by an external application (ie. an overlay). When this occurs, a visual stutter can quite often be avoided if running at a lower frame rate.
+
+### CPU/GPU overheating
+
+Especially the case on laptop PCs (or desktops with sub-optimal thermal setups), pushing hardware to their extremes can cause heat generation and subsequent clock reduction and throttling.
+
+Many use the retort that "osu! is a 2D game and shouldn't cause such issues", but 2D rendering at very high throughputs is actually one of the worst case scenarios for power consumption of GPUs.
+
+### Negligible returns
+
+Your input hardware generally polls at 125~1,000 hz. We harvest input at 1,000hz. To put it simply, rendering frames at a rate close to or higher than this has negligible benefit.
+
+As we are handling input on a separate thread in lazer, the benefits drop off earlier as well. We have future work which will basically mean that running the update thread will have no effect over input precision (ie. what some people identify as "clumping of lines" on the hit error meter).
+
+## Latency Certifier mini-game
+
+Rather than try and convince you with words, we have decided to create a blind test mini-game which you can test this for yourself. It is available in osu!(lazer) 2022.611.0 or later and accessible by searching "latency" in the settings menu (or scrolling all the way to the bottom and clicking the button).
+
+The mini-game does explain itself, so if you don't have niggling questions, feel free to carry on and enjoy game. The rest of this page will go over the caveats and reasoning behind the implementation in probably more detail than you need.
+
+/* TODO */
+
+## Going forward
+
+In the future, we hope to also revamp the other frame limiter options to be more similar to osu!(stable), providing "power saving" and "optimised" modes. The current "2x/4x/8x monitor refresh" are quite situational and can actually be pretty bad for higher refresh rate monitors.
+
+## FAQ
+
+### Does this affect osu!(stable)? Will changes be back-ported?
+
+No
+
+### Can I apply the same knowledge and results to my osu!(stable) frame limiter choice?
+
+Yes, with the settings we've chosen while running the latency certifier, it matches roughly with how osu!(stable) handles input and rendering.
+
+### Does it matter if I run lazer in single-thread or multi-threaded mode?
+
+Multi-threaded is recommended if your PC can handle it as it will give you higher performance (your update and input frame rates will not be bottlenecked by your GPU).
+
+### Why is it not testing audio?
+
+Audio latency is a completely different issue. The accuracy of audio and its relevance in the scheme of things is not tied to the update frame rate.
+
+Also, in lazer we process audio on its own thread that always runs at 1,000 hz.
+
+### Why is the latency certifier running at unlimited draw frames?
+
+The goal here is to help change perception. By only limiting one thread's frame rate, we can minimise the variables (to one) and still convey the same message. We chose to use unlimited draw frames to make sure some users are not convinced by the game's output frames being capped.
+
+Note that in practice, we do not want this, and from this version in normal gameplay draw frames are also capped at 1,000hz in "Basically Unlimited". As mentioned above in rationale
+
+### Why doesn't it let me retry at the current level?
+
+To keep things simple, we are looking for 100% results. If you get a wrong answer at the current level (and it wasn't a mis-click), the next step is to drop down a level and confirm that you can 100% see the difference at that level.
+
+You can then set your frame limiter one level above your result to ensure you will never feel the difference.