marfrit-packages/upstream-submissions/kwin-fourier/kde-mr-body.md

# invent.kde.org/plasma/kwin merge request body

**Title**: `wayland/transaction: poll dmabuf fd directly instead of EXPORT_SYNC_FILE`

**Branch**: `master` (forward-port to `Plasma/6.6` will be requested via
backport label after master lands).

---

## Summary

`Transaction::watchDmaBuf` calls `DMA_BUF_IOCTL_EXPORT_SYNC_FILE`
on every plane of every imported dmabuf and parks the transaction
on a `QSocketNotifier(POLLIN)` waiting for the resulting sync_file
fd to become readable. This is correct, but unnecessary.

The dma-buf core (`drivers/dma-buf/dma-buf.c`, `dma_buf_poll`) has
supported `poll(POLLIN)` on the dmabuf fd directly since
implicit-sync was introduced. The sync_file we obtain via
`EXPORT_SYNC_FILE` wraps the same set of fences that polling the
dmabuf fd directly would wait on. The export-then-poll round-trip
costs:

- one ioctl into the kernel (`DMA_BUF_IOCTL_EXPORT_SYNC_FILE`)
- one sync_file allocation + struct + ref-count
- one extra dup'd fd we hand to QSocketNotifier

…per fence per plane per frame on every wp_linux_dmabuf-v1 client.
For a single 1080p video stream at 30 fps with 2 NV12 planes,
that's 60 ioctls/sec/client of pure overhead with no semantic
difference vs. polling the dmabuf fd directly.

This patch dup()s the dmabuf fd we already have and hands it to
TransactionFence directly. Same `QSocketNotifier(POLLIN)` wait
semantics, fewer syscalls.

## Why this matters

On Mali-class hardware (RK3566 / RK3588 / mainline kernel +
panfrost or panthor mesa) running KWin Wayland, the per-frame
ioctl overhead is a measurable contributor to compositor latency
spikes. During a wider investigation into a chrome-on-KWin video
playback stall (chromium-fourier campaign, see
https://github.com/marfrit/fourier), the watchDmaBuf path was
identified as one of two contributors to the deadlock; the other
is a kernel-side gap (V4L2 producers don't populate the dmabuf's
`dma_resv` exclusive fence, so the sync_file we export is a
stub-signalled `dma_fence_get_stub()` representing nothing real).

A separate kernel patch series (sent to linux-media) addresses the
producer-side gap. With that kernel patch in place, the wait
genuinely waits on a producer fence — but the export-then-poll
round-trip is still pure overhead. This MR addresses the KWin side
of the latency.

## Side effect

Removes the dependency on `<linux/dma-buf.h>` and `<xf86drm.h>`
from `transaction.cpp`'s includes, since they were only present
for `DMA_BUF_IOCTL_EXPORT_SYNC_FILE` / `drmIoctl()`. The
`exportWaitSyncFile()` static helper is removed for the same
reason.

## Alternative considered

Adding a timeout to the existing path (e.g. 16 ms ≈ one 60 Hz
vsync). That preserves more of the existing code shape but doesn't
remove the per-frame ioctl overhead. Polling the dmabuf fd
directly is the cleaner fix and matches what the dma-buf API
documents as the recommended primitive for this case.

## Validation

Built and run on PineTab2 (RK3566 / Mali-G52 / mainline kernel
6.19.10 / panfrost mesa 26.0.5 / KDE Plasma 6.6.4 Wayland). KWin
session starts cleanly, multi-window OpenGL workloads (Brave,
plasma-overview, kate, dolphin) render normally — no regression.

### Honest finding from `strace -e trace=ioctl` on `kwin_wayland`

In 30 s of 1080p30 H.264 playback under chromium-fourier
(wp_linux_dmabuf_v1 client, V4L2-stateless decode capable):

- **Zero `DMA_BUF_IOCTL_EXPORT_SYNC_FILE`** calls.
- 29,128 ioctl calls total, dominated by:
  - `DRM_IOCTL_PANFROST_*` (rendering)
  - `DRM_IOCTL_SYNCOBJ_*` (≈ 7,800 — explicit-sync syncobj operations)

The same shape holds with stock Brave + 60 s playback (96,120 total
ioctls, 0 EXPORT_SYNC_FILE).

KWin 6.6.4 with a modern client negotiates `wp_linux_drm_syncobj_v1`
**explicit sync** — `Transaction::watchDmaBuf` is not on the hot path
in this configuration. The function still exists and runs for clients
that don't advertise drm-syncobj support (older Wayland clients,
some video pipelines that import implicit-sync producer dmabufs
without wrapping them), but on a current Plasma + drm-syncobj-aware
client stack, the call frequency we initially expected (≈ 60
ioctls/sec/client at 1080p30) does not materialize.

### What this means for the patch

The patch is still correct and worth taking, but the *value
proposition* shifts from "measurable per-frame win on V4L2 video
playback" to "remove a kernel round-trip on the legacy implicit-sync
path that still services older Wayland clients and V4L2 producers
that don't go through drm-syncobj-aware compositor paths".

The structural improvement is real wherever `Transaction::watchDmaBuf`
fires; we just couldn't construct a benchmark on this hardware that
fires it heavily enough to put a percentage on. Reviewers with
older client baselines (Plasma 5 era apps, GTK on older Wayland,
xwayland passing implicit-sync buffers in some configurations) may
see the call site fire more often.

### What is reproducible

- No regression: 60-second video playback, no fps loss, no rendering
  artifacts, no compositor stalls.
- Strace evidence available at
  https://git.reauktion.de/marfrit/marfrit-packages
  under `upstream-submissions/kwin-fourier/measurements/`:
  - `stock-6.6.4-bbb1080p30-60s.txt` — `strace -c -f` summary
  - `stock-cr-fourier-ioctls-30s.log` — full per-ioctl trace under
    chromium-fourier playback
- Patch correctness: the dmabuf fd's `poll()` semantics are
  documented in `Documentation/driver-api/dma-buf.rst` "Implicit
  Fence Poll Support" and match what `EXPORT_SYNC_FILE`+poll
  observes.

### Subjective field-use note

I have been running a more aggressive earlier version of this fix
(simply *skipping* the `watchDmaBuf` wait — i.e. presenting without
waiting for the producer fence at all) downstream as part of the
fourier campaign on this hardware. Plasma feels measurably snappier
under that variant; latency spikes during heavy compositor activity
are gone. That earlier variant has different observable semantics
than the patch in this MR (it can present unfinished frames if the
producer is racing), so the subjective improvement *cannot* be
directly attributed to the present patch — but the same hardware
running the present patch does not regress against either the
skip-the-wait variant or stock, so on this hardware/stack it's at
worst a performance no-op and at best preserves whatever benefit
the wait-skip variant was providing on the watchDmaBuf-firing path.

Reviewers should treat this as anecdotal and weigh the patch on its
correctness/cleanup merits.

## Future work (out of scope here)

Per the dma-buf documentation (`Documentation/driver-api/dma-buf.rst`,
"Implicit Fence Poll Support"), some V4L2 producers do not
populate `dma_resv` exclusive fences, which makes both this
direct-poll path and the existing `EXPORT_SYNC_FILE` path
stub-resolve immediately for those buffers. Filed as a separate
kernel patch series at linux-media-devel.

---

# KDE submission notes

(Per https://invent.kde.org/plasma/kwin and KDE's typical
contribution flow.)

## Account setup (one-time)

1. Create account at https://invent.kde.org
2. Sign KDE's CLA at https://contributoragreement.kde.org
3. SSH key configured at https://invent.kde.org/-/profile/keys

## Fork + branch

```sh
# On the github web UI: fork plasma/kwin to your namespace
git clone git@invent.kde.org:<your-namespace>/kwin.git
cd kwin
git remote add upstream https://invent.kde.org/plasma/kwin.git
git fetch upstream
git checkout -b transaction-poll-dmabuf-fd-directly upstream/master
git am path/to/kwin-fourier/0002-transaction-poll-dmabuf-fd-directly-upstream-shape.patch
git push origin HEAD
```

Then create the MR via the web UI (a banner appears on the
git push output linking to the create-MR page).

## Reviewers / labels

Recommended reviewers (these tend to handle KWin Wayland MRs):
- Vlad Zahorodnii (vladz) — KWin Wayland scene/transaction owner
- Xaver Hugl (zamundaaa) — KWin DRM / present pipeline
- David Edmundson — KWin generally

Labels to suggest:
- `Component::Wayland`
- `Performance`
- After acceptance, request a `Backport::Plasma/6.6` (or whichever
  LTS branch is current) for downstream distros.