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

["Christian König" <christian.koenig@amd.com>]

On 10/30/26 02:40, Nicolas Dufresne wrote:
> Le jeudi 22 octobre 2026 à 06:04 +0200, Karl Mehltretter a écrit :
>> On Wed, Oct 21, 2026 at 05:03:19PM +0100, Nicolas Dufresne wrote:
>>>> 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.
>>>
>>
>> For a persistently mapped attachment, where would the transition to
>> device access happen? 
>>
>> dma_buf_map_attachment() may only run once, while the importer can
>> submit the buffer many times. Would this need a new per-attachment
>> operation before each submission, or can an existing event be used?
> 
> In my perception, the mechanism in place, attach/detach and begin/end only work
> for very specific cases and breaks in most other case I can think of.
> 
>>
>> I tested that distinction with one persistent V3D attachment on my Pi
>> 400 and Pi 500+:
>>
>> - If end_cpu_access() only recorded dirty state, with no sync before
>>   submission, V3D read stale data in all 64 frames on both boards.
>>
>> - Synchronizing the attachment immediately before submission produced
>>   64/64 matching frames on both boards.
>>
>> This only covers V3D, but it seems that a dirty bit still needs a
>> device-side use event. Is that the model you had in mind?
> 
> In my mind, we need to introduce new API. The problem with the being/end design
> is that it only works for specific pattern. Typically, on begin_cpu_access, you
> want to do specific action that ensure the CPU will see the right value in
> memory. One of these action could be to flush a device write cache for CPU read
> access. But unless only the exporter see these calls, and unless the device is
> the exporter, eveyrthing we have fall appart.
> 
> With the new trend of always allocating from unified memory using dma heap,
> udmabuf and other non-device specific allocator, both device cache just breaks
> everything. Just like, an importer that need CPU write to be flushed breaks
> today. This last one seems obvious, just flush, but if the data came from
> another device, you might just kill the performance.
> 
> I think if its just for the CPU cache state, to let importer that needs it know,
> we could introduce some sort of a bit mask (and some locking probably?) to help
> solve that. But we still leave the concept of device side memory cache broken.

Well the documented approach is that when the devices want to access a DMA-buf they must do so coherently with regards to what the CPU sees.

When a device has special requirements that when the CPU wants to access or has accessed the backing store it can use begin_cpu_access/end_cpu_access to do the necessary actions.

But the inter device requirement has always been that when you complete a dma_fence that the devices internal caches needs to be flushed before the fence signals. The same is true for invalidating internal caches before stating an operation.

So when a device for example can't import a buffer with dirty CPU caches then we intentionally doesn't support that.

Regards,
Christian.

> 
> Nicolas
> 
>>
>> Thanks,
>> Karl