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>
It's kind of dumb anyway. If we get damage event right after a vblank
event, we would waste the whole vblank.
Instead improve the frame scheduling logic to target the right vblank
interval. This only affects smart_frame_pacing anyway.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Right now we rely on `reschedule_render_at_vblank` being scheduled for
the render finish check. Which means we will only know if a frame has
finished rendering the next time we queue a render. And we only check at
vblank boundary, which means when a render is queued we have to wait for
the next vblank, when had we checked earlier, we will be able to start
rendering immediately
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
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>
present_notify_msc with divisor == 0 has undocumented special meaning,
it means async present notify, which means we could receive MSC
notifications from the past.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Also, vblank event callback should call schedule_render to queue renders
instead of starting the draw timer directly, so that the CPU time
calculation will be correct.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Disable timing estimation based pacing by default, as it might not work
well across drivers, and might have subtle bugs.
You can try setting `PICOM_DEBUG=smart_frame_pacing` if you want to try
it out.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
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>
This is where we keep temporary, short living, private debug options.
Adding and removing command line and config file options are
troublesome, and we don't want people adding these to their config
files.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
We unredirect because we receive bad vblank events, and also vblank
events at a different interval compared to when the screen is on. But it
is enough to just not record the vblank interval statistics when the
screen is off.
Although, unredirecting when display is off can also fix the problem
where use-damage causes the screen to flicker when the display is turned
off then back on. So we need something else for that.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Previously everytime we receive a vblank event, we always request a new
one. This made the logic somewhat simpler. But this generated many
useless vblank events, and wasted power. We only need vblank events for
two things:
1. after we rendered a frame, we need to know when it has been displayed
on the screen.
2. estimating the refresh rate.
This commit makes sure we only request vblank events when it's actually
needed.
Fixes#1079
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Make it simpler to stop requesting PresentCompleteNotify when there is
nothing to render.
Related: #1079
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
I mistakenly assumed that PresentCompleteNotify event signifies the end
of a vblank (or the start of scanout). But actually this event can in
theory in sent at any point during a vblank, with its timestamp pointing
to when the end of vblank is. (that's why we often find the timestamp to
be in the future).
Add a delay so schedule_render is actually called at the end of vblank,
so it doesn't mistakenly think the render is too slow to complete.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
paint_process would return NULL for both of these cases, but we should exit in
the failure case, and continue going in the other.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
This usually means there is another compositor running. If we don't do
this picom will spin forever.
Fixes#1104
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
One annoying thing is C23 still defines auto as a storage class despite
it now being used for type inference. As a consequence we must write
"auto const" instead of the more natural "const auto".
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
