Try to address the DMA-buf coherency problem

Rob Clark robdclark at gmail.com
Fri Nov 18 19:32:19 UTC 2022


On Thu, Nov 17, 2022 at 7:38 AM Nicolas Dufresne <nicolas at ndufresne.ca> wrote:
>
> Le jeudi 17 novembre 2022 à 13:10 +0100, Christian König a écrit :
> > > > DMA-Buf let's the exporter setup the DMA addresses the importer uses to
> > > > be able to directly decided where a certain operation should go. E.g. we
> > > > have cases where for example a P2P write doesn't even go to memory, but
> > > > rather a doorbell BAR to trigger another operation. Throwing in CPU
> > > > round trips for explicit ownership transfer completely breaks that
> > > > concept.
> > > It sounds like we should have a dma_dev_is_coherent_with_dev() which
> > > accepts two (or an array?) of devices and tells the caller whether the
> > > devices need explicit ownership transfer.
> >
> > No, exactly that's the concept I'm pushing back on very hard here.
> >
> > In other words explicit ownership transfer is not something we would
> > want as requirement in the framework, cause otherwise we break tons of
> > use cases which require concurrent access to the underlying buffer.
>
> I'm not pushing for this solution, but really felt the need to correct you here.
> I have quite some experience with ownership transfer mechanism, as this is how
> GStreamer framework works since 2000. Concurrent access is a really common use
> cases and it is quite well defined in that context. The bracketing system (in
> this case called map() unmap(), with flag stating the usage intention like reads
> and write) is combined the the refcount. The basic rules are simple:

This is all CPU oriented, I think Christian is talking about the case
where ownership transfer happens without CPU involvement, such as via
GPU waiting on a fence

BR,
-R


More information about the dri-devel mailing list