[Next] Framerate fluctuation and camera stuttering on Linux
Before 3ba48ba4:
After 3ba48ba4:
Not terribly noticeable, but I can definitely feel the difference when playing them back to back (especially at/near 35fps).
There's also this strange issue where the camera stutters every couple seconds while turning:
It only happens at 35fps though - setting the cap to anything else will cause it to go away.
Tested on Debian 12 x64.
Activity
assigned to @LoganAir
@Alam could you reproduce on your Debian system? I don't have a real Debian system, but I can run one under Windows 11 WSL2, and I can't reproduce this issue.
@WumboSpasm Could you try open console by pressing title key, then enter "cpusleep 0"?
If you make that change, does the stutter goes away?
added OpenGL renderer Rendering SDL Uncapped labels
removed Rendering label
Compile the following program with
gcc -O2and post the output here:#include <time.h> #include <stdio.h> int main(void) { struct timespec ts = { .tv_sec = 0, .tv_nsec = 1, }; struct timespec start; struct timespec end; size_t i; for (i = 0; i < 20; i++) { clock_gettime(CLOCK_MONOTONIC, &start); clock_nanosleep(CLOCK_MONOTONIC, 0, &ts, NULL); clock_gettime(CLOCK_MONOTONIC, &end); printf("%d\n", end.tv_nsec - start.tv_nsec); } }This will measure the accuracy of
nanosleep20 times with nanosecond precision, so we can tell how accurate your nanosleep is. I just want to double-check that there isn't something on your system that causesnanosleepto be less accurate than 50 microseconds, since we might need to add a toggle fornanosleepsleeping in that case.EDIT: I went ahead and did a hybrid with the old and new system anyway to compensate for the inaccuracies, since although I don't really notice any difference even with the versions side-to-side, it at least looks better when measuring with MangoHUD. Still, I advice you to run this test anyway just to make sure this isn't an issue.
Edited by Hanicef-
Did some further measurements here and found the following:
- FreeBSD has an accuracy of about 6 microseconds, with spikes of up to 20 microseconds (I assume this is actual hardware accuracy level).
- Haiku seems to fluctuate between 5 to 30 microseconds in accuracy, but can't measure with nanosecond precision (it rounds off to microseconds - possibly inaccurate clock?).
All in all, it looks like Linux is the least accurate here, surprisingly enough. While I don't know why, it does seem to indicate that there's more at play here than just hardware, since these tests makes it very clear that Linux is not utilizing the accuracy that the hardware is capable of providing. However, it does show that
nanosleepshould be enough to be able to provide sufficient accuracy, but it seems like the standard Linux kernel is not built to take advantage of this.All of this makes me wonder what the fuck Windows is doing with it's 2 millisecond accuracy, though. How can it be more than 100 times less accurate than everything else, especially when the hardware is very clearly capable of a much higher accuracy than that?
mentioned in merge request !2583 (merged)
closed with merge request !2583 (merged)
mentioned in commit 209ba5e7
