wayland_vk: use FIFO if commit-timing and fifo protocols are available #15056
Conversation
|
We should probably wait a few months after a new Mesa release is cut with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26150 |
|
I'm hoping compositor implementations would only signal clients if it knows the drivers can actually use the protocols. But I didn't really look at how it was implemented. We still have to wait for the next wayland-protocols release anyway. |
Dudemanguy
force-pushed
the
wayland-fifo
branch
3 times, most recently
from
043de5b
to
3113c9a
Compare
There is no way for compositors to do this. I've ranted at length about this here: libsdl-org/SDL#10937 (comment) I also don't see why the compositor should be in charge of telling an application what features a library supports. If application A wants to know what features library B supports, then it should ask library B instead of compositor C. |
|
Hmm that's unfortunate. I guess that means this will just have to wait some arbitrary time after the next mesa release. I guess the semantics of |
Dudemanguy
force-pushed
the
wayland-fifo
branch
2 times, most recently
from
f8234a9
to
e84aa5e
Compare
|
Reworked |
|
Download the artifacts for this pull request: |
Dudemanguy
force-pushed
the
wayland-fifo
branch
2 times, most recently
from
a8a0070
to
9133df2
Compare
With the upcoming fixes to FIFO in wayland, it should be preferable to use FIFO instead of our own hacky heuristic. This means --wayland-disable-vsync should become a tristate option with an "auto" behavior (not implemented in this commit). The semantics have to slightly change so introduce --wayland-internal-vsync and deprecate --wayland-disable-vsync.
Dudemanguy
force-pushed
the
wayland-fifo
branch
2 times, most recently
from
6471b74
to
0841139
Compare
|
It looks like the mesa implementation will work with presentation time v1 so I loosened up the restriction a bit. |
it'll work but only for fixed refresh rate outputs. It'll go back to the old behavior as soon as VRR is enabled. See: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26150/diffs?commit_id=e7aa09688bf20a5b4e664437f302762be606c783#8b9326d5e797a10c9d7bf33ddb5420c06e700768_2135_2270 implementing v2 is trivial for any compositor that'll go through the trouble of implementing fifo-v1 and commit-timing-v1, so I don't see any issue with requiring all 3 |
Dudemanguy
force-pushed
the
wayland-fifo
branch
from
0841139
to
44b8f4e
Compare
|
Added it back in. |
Dudemanguy
force-pushed
the
wayland-fifo
branch
from
44b8f4e
to
35a00d7
Compare
A very long time annoyance with wayland was compositors indefinitely blocking our vo thread if the surface gets occluded in some way. We've worked around this by using mailbox and our own custom vsync function. Thankfully it looks like people are finally solving this and with these two protocols it should be possible to guarantee forward progress on vulkan which means all the workarounds we do shouldn't be needed. So we can just request fifo in this case as a default since all we want is standard vsync blocking.
Dudemanguy
force-pushed
the
wayland-fifo
branch
from
35a00d7
to
62f6cda
Compare
|
The latest mesa supports this now, so this should be fairly safe to merge once we confirm a compositor implementation works as expected. |
A very long time annoyance with wayland was compositors indefinitely blocking our vo thread if the surface gets occluded in some way. We've worked around this by using mailbox and our own custom vsync function. Thankfully it looks like people are finally solving this and with these two protocols it should be possible to guarantee forward progress on vulkan which means all the workarounds we do shouldn't be needed. So we can just request fifo in this case as a default since all we want is standard vsync blocking.
It's not tested at the moment, but SDL essentially does the same thing.