Commit Graph

12 Commits

Author SHA1 Message Date
Yuxuan Shui 615924cc4a
core: disable realtime scheduling by default
And add a --realtime option for enabling it.

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2024-03-03 15:20:52 +00:00
Yuxuan Shui 9e5e6ae99b
vblank: fix use of uninitialized variables
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2024-02-18 19:36:20 +00:00
Yuxuan Shui 23d4d31d1f
vblank: set SCHED_RR for the SGI_video_sync thread
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2024-02-16 19:58:39 +00:00
Maxim Solovyov 53dd8a4e66
fix most of build warnings on openbsd
sorry openbsd people, we're not going to use the snprintf function.
2024-02-14 02:19:16 +03:00
Yuxuan Shui eb723eee29
backend: gl: use libepoxy
There is actually no specification what symbols are exported from a
libGL implementation. The (extremely outdated) OpenGL ABI specification
says only GL 1.2 functions are guaranteed. Don't know how relevant that
is now, but different libGL implementations do export different set of
symbols. On Linux we are most likely to be linked with libglvnd, which
has everything we need. But on other platforms this is not necessarily
the case, for example on OpenBSD we are missing glGetQueryObjectui64v.

Use libepoxy so we can outsource this problem and never worry about it
ever again. Plus it also saves us from calling GetProcAddress ourselves.

Changes other than trivial build fixes I have to make:

1. Can't use eglCreatePlatformWindowSurface/eglGetPlatformDisplay.
   libepoxy checks for EGL 1.5 when resolving these functions. But
   without a current context, libepoxy assumes we only have EGL 1.4.
   This creates a chicken and egg problem - we need a display to call
   eglGetPlatformDisplay. We have to use the *EXT version instead.

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2024-02-10 20:36:02 +00:00
Yuxuan Shui 238c3cc833
vblank: reset SGI_video_sync scheduler if it's getting nonsense
If resetting fails, set a flag so all future schedule calls will fail.

Fixes #1168

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2024-01-30 22:41:03 +00:00
Yuxuan Shui 14a345a817
vblank: make init fallible
Improve error handling in sgi_video_sync_scheduler_init a bit.

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2024-01-29 22:11:01 +00:00
Yuxuan Shui 5fba210ad6
vblank: make schedule fallible
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2024-01-29 22:07:04 +00:00
Yuxuan Shui f3bdd01dc8
vblank: don't use symbols from backend/gl/glx.h
sgi video sync runs in a separate thread, we don't want to have
potential races between threads.

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2024-01-29 17:52:44 +00:00
Yuxuan Shui db9b808bfb
vblank: add GLX_SGI_video_sync based scheduler
Present extension based scheduler doesn't work well on NVIDIA drivers.
GLX_SGI_video_sync is less accurate, but is rumoured to work. See
[kwin's usage](https://invent.kde.org/plasma/kwin/-/blob/master/src/
backends/x11/standalone/x11_standalone_sgivideosyncvsyncmonitor.cpp)

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2023-12-19 23:27:12 +00:00
Yuxuan Shui c42e6cef0a
vblank: winding down vblank events instead of stopping immediately
I noticed sometimes full frame rate video is rendered at half frame rate
sometimes. That is because the damage notify is sent very close to
vblank, and since we request vblank events when we get the damage, we
miss the vblank event immediately after, despite the damage happening
before the vblank.

       request  next  ......  next next
damage  vblank vblank          vblank
   |    |       |     ......      |
   v    v       v                 v
---------------------->>>>>>---------

`request vblank` is triggered by `damage`, but because it's too close to
`next vblank`, that vblank is missed despite we requested before it
happening, and we only get `next next vblank`. The result is we will
drop every other frame.

The solution in this commit is that we will keep requesting vblank
events, right after we received a vblank event, even when nobody is
asking for them. We would do that for a set number of vblanks before
stopping (currently 4).

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2023-12-19 23:27:08 +00:00
Yuxuan Shui 1430d28116
core: refactor frame pacing
Factored out vblank event generation, add abstraction over how vblank
events are generated. The goal is so we can request vblank events in
different ways based on the driver we are running on.

Tried to simplify the frame scheduling logic, we will see if I succeeded
or not.

Also, the logic to exclude vblank events for vblank interval estimation
when the screen off is dropped. It's too hard to get right, we need to
find something robust.

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2023-12-19 23:26:59 +00:00