Re: [PATCH 2/4] media: videobuf2: add opt-in DMA-BUF CPU access

[Nicolas Dufresne]

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: signature.asc
Description: This is a digitally signed message part