syncobj: use eventfd instead of stalling fd checks

[gulafaran]

use eventfd and add it to the event loop and when it recieves a signal release the buffer, this means we dont stall entire compositor when waiting for materilisation of the fd. and change its related usage, this also means we need to store release points that can popup in a container and signal them all on buffer release.

im not sure why directscanout previously manually tried to signal releasepoints. remove that and let the buffers releaser handle it.

should solve a lot of "compositor 5 fps while ingame overlay shows 300fps" and other similiar weird stalls.

on nvidia this shuffles compositor stalls to sometimes a noticeable rendering stutter, technically the acquire point isnt signaled fast enough so the buffer is stuck and nothing gets rendered until it is. pretty much the same stall as seen before only now its per surface rendering. but that i contribute to nvidia driver being simply shit, and is visible on other compositors.

NVIDIA/open-gpu-kernel-modules#777
NVIDIA/open-gpu-kernel-modules#743

Possibly fixes:
#7857

[vaxerski]

huge if works

[ikalco]

wait... for ds, shouldn't we release the wl_buffer whenever DRM signals the out fence?
so the client can reuse that buffer, and the output won't artifact cause drm said scanout is done

edit:
uuuh it seems HL just isn't using the out fence lol, am I missing something?
for reference (https://docs.kernel.org/gpu/drm-kms.html)

“OUT_FENCE_PTR”:
Use this property to pass a file descriptor pointer to DRM. Once the Atomic Commit request call returns OUT_FENCE_PTR will be filled with the file descriptor number of a Sync File. This Sync File contains the CRTC fence that will be signaled when all framebuffers present on the Atomic Commit * request for that given CRTC are scanned out on the screen.

[gulafaran]

wait... for ds, shouldn't we release the wl_buffer whenever DRM signals the out fence? so the client can reuse that buffer, and the output won't artifact cause drm said scanout is done

edit: uuuh it seems HL just isn't using the out fence lol, am I missing something? for reference (https://docs.kernel.org/gpu/drm-kms.html)

“OUT_FENCE_PTR”:
Use this property to pass a file descriptor pointer to DRM. Once the Atomic Commit request call returns OUT_FENCE_PTR will be filled with the file descriptor number of a Sync File. This Sync File contains the CRTC fence that will be signaled when all framebuffers present on the Atomic Commit * request for that given CRTC are scanned out on the screen.

There is a lot wrong at the moment, explicit sync currently relies on new buffer attached, the client can commit multiple times on the same buffer if it wants to, and does sometimes, and this PR probably exposed that quirk even more, and yeah direct scanout i havent begun reading into but removed that buffer manual buffer shenanigans because it was conflicting with the changes i made, there is also a few other things im checking that has popped up while testing

[gulafaran]

wait... for ds, shouldn't we release the wl_buffer whenever DRM signals the out fence? so the client can reuse that buffer, and the output won't artifact cause drm said scanout is done

edit: uuuh it seems HL just isn't using the out fence lol, am I missing something? for reference (https://docs.kernel.org/gpu/drm-kms.html)

“OUT_FENCE_PTR”:
Use this property to pass a file descriptor pointer to DRM. Once the Atomic Commit request call returns OUT_FENCE_PTR will be filled with the file descriptor number of a Sync File. This Sync File contains the CRTC fence that will be signaled when all framebuffers present on the Atomic Commit * request for that given CRTC are scanned out on the screen.

And "releasing" when it comes to explicit sync is sending the release point not the buffer .release

[UjinT34]

output->state->enableExplicitOutFenceForNextCommit() should be called before the commit if out fence is needed. It fills output->state->state().explicitOutFence.
Who should handle that fd?

Note that OUT_FENCE_PTR shouldn't be used when tearing is allowed.

[JunaidQrysh]

I tested this pr & it fixed glmark2 lag but minecraft lag is still the same and also it introduced slight lag in other areas like workspace switching and cursor lag when wlogout is opened.

[ikalco]

output->state->enableExplicitOutFenceForNextCommit() should be called before the commit if out fence is needed. It fills output->state->state().explicitOutFence. Who should handle that fd?

Note that OUT_FENCE_PTR shouldn't be used when tearing is allowed.

we use that fd, i think we import it as a sync_file, then wait for it to signal, meaning aq plane is done with the primary buffer

[gulafaran]

I tested this pr & it fixed glmark2 lag but minecraft lag is still the same and also it introduced slight lag in other areas like workspace switching and cursor lag when wlogout is opened.

yeah got a few very broken things to figure out, im trying tho.