Re: DMA-BUFs always uncached on arm64, causing poor camera performance on Librem 5 - Linaro-mm-sig

10 Jul 2025

      Hi Pavel,
Le jeudi 10 juillet 2025 à 10:24 +0200, Pavel Machek a écrit :
...
Hi!
It seems that DMA-BUFs are always uncached on arm64... which is a
problem.
I'm trying to get useful camera support on Librem 5, and that includes
recording vidos (and taking photos).
memcpy() from normal memory is about 2msec/1MB. Unfortunately, for
DMA-BUFs it is 20msec/1MB, and that basically means I can't easily do
760p video recording. Plus, copying full-resolution photo buffer takes
more than 200msec!
There's possibility to do some processing on GPU, and its implemented here:
https://gitlab.com/tui/tui/-/tree/master/icam?ref_type=heads
but that hits the same problem in the end -- data is in DMA-BUF,
uncached, and takes way too long to copy out.
And that's ... wrong. DMA ended seconds ago, complete cache flush
would be way cheaper than copying single frame out, and I still have
to deal with uncached frames.
So I have two questions:

Is my analysis correct that, no matter how I get frame from v4l and

process it on GPU, I'll have to copy it from uncached memory in the
end?

Does anyone have patches / ideas / roadmap how to solve that? It

makes GPU unusable for computing, and camera basically unusable for
video.
If CPU access is strictly required for your use case, the way forward is to
implement V4L2_BUF_CAP_SUPPORTS_MMAP_CACHE_HINT in the capture driver. Very
little drivers enable that.
Once your driver have that capability, you will be able to set
V4L2_MEMORY_FLAG_NON_COHERENT while doing REQBUFS or CREATE_BUFS ioctl. That
gives you allocation with CPU cache working, but you'll get the invalidation (or
flush) overhead by default. When capture data have not been read by CPU, you can
always queue it back with the V4L2_BUF_FLAG_NO_CACHE_INVALIDATE. But for your
use case, it seems that you want the invalidation to take place, otherwise your
software will endup reading old cache data instead of the next frame data.
Please note that the integration in the DMABuf SYNC ioctl was missing for a
while, so make sure you have recent enough kernel or get ready for backports.
The feature itself was commonly used with CPU only access, notably on ChromeOS
using libyuv. No DMABuf was involved initially.
regards,
Nicolas
[0] https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/vidioc-reqbuf...
...
Best regards,
   							Pavel