From 6c50354afbb2d297ddafa82d583b0fd48e9abac6 Mon Sep 17 00:00:00 2001 From: Markus Fritsche Date: Wed, 29 Apr 2026 19:19:06 +0000 Subject: [PATCH] upstream-submissions/kwin-fourier: add subjective field-use note MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit User has been running the more aggressive 0001 variant (skip the watchDmaBuf wait entirely) downstream and reports Plasma feels measurably snappier — fewer latency spikes under heavy compositor activity. The present 0002 MR has different (correct) wait semantics so the perceived gain can't be directly attributed, but calling it out gives reviewers an honest signal that the patch at least preserves whatever benefit was on the table downstream. Co-Authored-By: Claude Opus 4.7 (1M context) --- .../kwin-fourier/kde-mr-body.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/upstream-submissions/kwin-fourier/kde-mr-body.md b/upstream-submissions/kwin-fourier/kde-mr-body.md index 69348022f..3d3e22373 100644 --- a/upstream-submissions/kwin-fourier/kde-mr-body.md +++ b/upstream-submissions/kwin-fourier/kde-mr-body.md @@ -128,6 +128,25 @@ see the call site fire more often. 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`,