[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b7b053603323ca241caa42cd5a6599b9263b9864.camel@ndufresne.ca>
Date: Mon, 27 Jun 2022 10:30:30 -0400
From: Nicolas Dufresne <nicolas@...fresne.ca>
To: Lucas Stach <l.stach@...gutronix.de>,
Christian König <christian.koenig@....com>,
Pekka Paalanen <ppaalanen@...il.com>
Cc: "Sharma, Shashank" <Shashank.Sharma@....com>,
lkml <linux-kernel@...r.kernel.org>,
dri-devel <dri-devel@...ts.freedesktop.org>,
linaro-mm-sig@...ts.linaro.org,
Sumit Semwal <sumit.semwal@...aro.org>,
linux-media <linux-media@...r.kernel.org>
Subject: Re: DMA-buf and uncached system memory
Le lundi 27 juin 2022 à 16:06 +0200, Lucas Stach a écrit :
> Am Montag, dem 27.06.2022 um 09:54 -0400 schrieb Nicolas Dufresne:
> > Le jeudi 23 juin 2022 à 11:33 +0200, Lucas Stach a écrit :
> > > >
> > > > See for example on AMD/Intel hardware most of the engines can perfectly
> > > > deal with cache coherent memory accesses. Only the display engines can't.
> > > >
> > > > So on import time we can't even say if the access can be coherent and
> > > > snoop the CPU cache or not because we don't know how the imported
> > > > DMA-buf will be used later on.
> > > >
> > > So for those mixed use cases, wouldn't it help to have something
> > > similar to the dma_sync in the DMA-buf API, so your scanout usage can
> > > tell the exporter that it's going to do non-snoop access and any dirty
> > > cache lines must be cleaned? Signaling this to the exporter would allow
> > > to skip the cache maintenance if the buffer is in CPU uncached memory,
> > > which again is a default case for the ARM SoC world.
> >
> > Telling the exporter for every scan is unneeded overhead. If that information is
> > made available "properly", then tracking it in attach/detach is sufficient and
> > lightweight.
>
> That isn't sufficient. The AMD GPU is a single device, but internally
> has different engines that have different capabilities with regard to
> snooping the caches. So you will likely end up with needing the cache
> clean if the V4L2 buffer is going directly to scanout, which doesn't
> snoop, but if the usage changes to sampling you don't need any cache
> flushes.
>
> Also I don't see a big overhead when comparing a kernel internal call
> that tells the exporter that the importer is going to access the buffer
> without snooping and thus needs the cache clean once every frame and
> the need to always clean the cache before DQBUF when a potentially non-
> snooping importer is attached.
Ack, thanks for the information.
>
> Regards,
> Lucas
>
Powered by blists - more mailing lists