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 >
