core: wait for dmabuf readiness

[ikalco]

Describe your PR, what does it fix/add?

this pr makes it so that dmabuf buffers, without drmsyncobj acquire points, can only be read when they are ready
this is done by waiting on the dmabuf's implicit sync read fence before using it

the goal here is to ensure we only read buffers that are ready to be read

Is there anything you want to mention? (unchecked code, possible bugs, found problems, breaking compatibility, etc.)

Is it ready for merging, or does it need work?

yes

[ikalco]

draft cause I know @gulafaran wanted to use DMA_BUF_IOCTL_EXPORT_SYNC_FILE instead of just fd readabilty

dd47b80 is something that probably is wanted but i never proceeded with because it requires some more things than just checking the dmabuf fd itself, because of

Userspace can perform a DMA_BUF_IOCTL_EXPORT_SYNC_FILE to retrieve the current set of fences on a dma-buf file descriptor as
a sync_file. CPU waits via poll() or other driver-specific mechanisms typically wait on whatever fences are on the dma-buf at the 
time the wait begins. This is similar except that it takes a snapshot of the current fences on the dma-buf for waiting later instead 
of waiting immediately. This is useful for modern graphics APIs such as Vulkan which assume an explicit synchronization model 
but still need to inter-operate with dma-buf.

something like

    dma_buf_export_sync_file request{
        .flags = DMA_BUF_SYNC_READ,
        .fd = -1,
    };
    if (drmIoctl(FD, DMA_BUF_IOCTL_EXPORT_SYNC_FILE, &request) == 0) {
        return CFileDescriptor(request.fd);
    }

but that is linux only. https://dri.freedesktop.org/docs/drm/driver-api/dma-buf.html#c.dma_buf_export_sync_file

but afaik just checking readabilty of the dmabuf fd does the same thing no?
https://www.kernel.org/doc/html/latest/driver-api/dma-buf.html#implicit-fence-poll-support

Userspace can query the state of these implicitly tracked fences using poll() and related system calls:

• Checking for EPOLLIN, i.e. read access, can be use to query the state of the most recent write or exclusive fence.

[PlasmaPower]

My only question there would be if exporting the fence from the dmabuf allows us to get better support for Nvidia and e.g. eliminate electron/old chromium flickering, but it doesn't sound like it'd allow us to.

[ikalco]

gulafaran found this
https://invent.kde.org/plasma/kwin/-/merge_requests/7389/diffs?commit_id=2f8822874f8bb51604ff027761388c235bc01755
https://gitlab.gnome.org/GNOME/mutter/-/commit/c47730894e125d63b1abe7d8a1c3e8e46fd9409f

basically implicit sync through poll() sucks in some drivers

so yeah I'll implement the export ioctl method

[ikalco]

ready for review
also works with and without explicit, I did all the same tests as the last pr and it all worked fine
although thats on nvidia, haven't tested AMD cause I'd have to take apart my pc again lol

edit (after the ds syncrhonize commit):
ok fr this time lol

[vaxerski]

ikalco can you also maybe look into DS + Tearing as we are doing this? There's an open discussion around some weirdness with that. DS + Tearing should be allowed and work together. (there's this one !tearing in the if before DS checks, that should be yeeted)

[ikalco]

ikalco can you also maybe look into DS + Tearing as we are doing this? There's an open discussion around some weirdness with that. DS + Tearing should be allowed and work together. (there's this one !tearing in the if before DS checks, that should be yeeted)

bet, see #10020, def some weird stuff with tearing though, old and new code colliding i think
also we hit 10k in gh 🎉

[gulafaran]

gone through some of the normal testing, minecraft/cs2/wine/gtk havent found any issues so far.

[fxzzi]

also been running it for a while, everything looking good

[vaxerski]

saucy