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 the queued surfacestate, this means we dont stall entire compositor when waiting for materilisation of the fd. and change its related usage.

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

fixes:
#7857
#9340
#9340
#8588
#7643
#7317
#9376

potentially helps:
#6617
#9011

remaining quirks to be fixed

• resizing rendering window like vkcube is delayed hard
• [x ] walker crashes https://paste.pika-os.com/upload/bat-tiger-jaguar
• Doesn't seem to work on GTK4:4.16 wmww/gtk4-layer-shell#50 requires gtk4-layer-shell 1.0.4
• test and see if implicit/explicit sync didnt break hard or some other card/vendors AMD/Intel/etc
• test and see if gpu/cpu usage didnt regress into other areas. not resetting damage or similiar
• syncobj points for async buffers

[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.

[JunaidQrysh]

@gulafaran you did amazing work, now everything runs smoothly. I ran various gpu stress tests, they ran without any lag.
This will be a major change in hyprland for nvidia users. I can finally ditch kde plasma for gaming.

[ikalco]

for this part

// #TODO does this apply to explicit sync?
    if (!syncobj && previousBuffer && previousBuffer->buffer && !previousBuffer->buffer->isSynchronous()) {

the lockedByBackend is unlocked when page flip buffer swap happens, so technically that's when we should signal release point since DRM scanout is no longer using the buffer
but also, im pretty sure this is what the DRM out fence does, so you could use that instead of lockedByBackend

[czM1K3]

I can also say that this fixed my issue with my RX 580 so it might fix something like #8119 and others.

[gulafaran]

I can also say that this fixed my issue with my RX 580 so it might fix something like #8119 and others.

Probably will, and also some minecraft flickering and other things, im pushing soon a fix for a gtk issue and hyprlock issue so its not quite flawless yet 👍

[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.

should be in a better state now, but not done yet.