mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nicolas Dufresne <nicolas@ndufresne.ca>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Tomasz Figa <tfiga@chromium.org>
Cc: "Karl Mehltretter" <kmehltretter@gmail.com>,
	linux-media@vger.kernel.org,
	"Marek Szyprowski" <m.szyprowski@samsung.com>,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	"Hans de Goede" <hansg@kernel.org>,
	"Hans Verkuil" <hverkuil@kernel.org>,
	"Benjamin Gaignard" <benjamin.gaignard@collabora.com>,
	"Tomasz Stanislawski" <t.stanislaws@samsung.com>,
	"Sumit Semwal" <sumit.semwal@linaro.org>,
	"Christian König" <christian.koenig@amd.com>,
	dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/4] media: videobuf2: add opt-in DMA-BUF CPU access
Date: Wed, 21 Oct 2026 17:03:19 -0400	[thread overview]
Message-ID: <3084b9bc0d4b5593d2bfbfecb0ce272cb813ece9.camel@ndufresne.ca> (raw)
In-Reply-To: <20261021175900.GG15441@killaraus.ideasonboard.com>

[-- Attachment #1: Type: text/plain, Size: 2366 bytes --]

Hi,

Le mercredi 21 octobre 2026 à 20:59 +0300, Laurent Pinchart a écrit :
> > It sounds like this series focuses on uvcvideo and vivid, which likely
> > means that 1) alone would be enough to fix the original problem. WDYT?
> 
> I think the dma-buf API doesn't give us what we need. Cleaning the CPU
> cache through end_cpu_access() when the producer is done writting to the
> buffer is right in some use cases, but not in all of them. It assumes
> that the next consumer will access the data through DMA, which isn't
> always the case. What I think we need is to track the state of the
> cache(s) in the dma_buf, and perform cache management operations
> accordingly when needed. In the uvcvideo -> display use case for
> instance, the dma_buf should track that the CPU cache is dirty when
> finishing CPU access, and should be cleaned on the display side before
> performing the DMA. In a use case where the producer would DMA to the
> buffer, cache management would be skipped as the dma_buf would see that
> the cache is not dirty.

I also second this as the only viable option. Its not only about uvcvideo, but
any memory imported by a driver doing DMA (which is not also the exporter). That
includes udmabuf usage. These days, cache artifacts are visible with Intel
display controllers, and Intel mobile GPU drivers. Note that GStreamer properly
signal CPU read/write using DMABuf sync ioctl.

For most Intel laptop user with GStreamer 1.28, these example produce artifacts
on movement. To me, the solution is to track the cache state according to the
access signalling (either userspace or driver), and let DMA user/consumer decide
if a cache flush is needed. There is a obvious challenge in keeping this state
coherent whenever there is multiple consumer, of if some broken application do
concurrent write. Result for the last will always be undefined, but the dmabuf
CPU cache state should not be undefined.

UVC reproducer:
  gst-launch-1.0 v4l2src ! waylandsink

udmabuf reproducer:
  gst-launch-1.0 videotestsrc pattern=ball ! waylandsink

Nicolas

p.s. since Intel GPU these days is also affected, you can swap waylandsink with
glimagesink and you will also see artifacts. One may blame Intel, I believe they
made the choice of performance over correctness in absence of capable HW or
dmabuf signalling.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  reply	other threads:[~2026-10-21 21:03 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-19  7:14 [PATCH 0/4] media: synchronize CPU access to imported DMA-BUFs Karl Mehltretter
2026-10-19  7:14 ` [PATCH 1/4] media: videobuf2: finish prepared buffers in VIDIOC_REMOVE_BUFS Karl Mehltretter
2026-10-21 16:00   ` Tomasz Figa
2026-10-22  3:21     ` Karl Mehltretter
2026-10-19  7:14 ` [PATCH 2/4] media: videobuf2: add opt-in DMA-BUF CPU access Karl Mehltretter
2026-10-21 16:20   ` Tomasz Figa
2026-10-21 17:59     ` Laurent Pinchart
2026-10-21 21:03       ` Nicolas Dufresne [this message]
2026-10-22  4:04         ` Karl Mehltretter
2026-10-22  3:56     ` Karl Mehltretter
2026-10-19  7:14 ` [PATCH 3/4] media: uvcvideo: synchronize imported DMA-BUFs for " Karl Mehltretter
2026-10-19  7:14 ` [PATCH 4/4] media: vivid: " Karl Mehltretter
2026-10-19 12:44 ` [PATCH 0/4] media: synchronize CPU access to imported DMA-BUFs Laurent Pinchart
2026-10-19 14:48   ` Christian König
2026-10-19 15:01     ` Laurent Pinchart
2026-10-20  3:24       ` Karl Mehltretter
2026-10-20  3:09     ` Karl Mehltretter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3084b9bc0d4b5593d2bfbfecb0ce272cb813ece9.camel@ndufresne.ca \
    --to=nicolas@ndufresne.ca \
    --cc=benjamin.gaignard@collabora.com \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hansg@kernel.org \
    --cc=hverkuil@kernel.org \
    --cc=kmehltretter@gmail.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mchehab@kernel.org \
    --cc=sumit.semwal@linaro.org \
    --cc=t.stanislaws@samsung.com \
    --cc=tfiga@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®