From: Lucas Stach <l.stach@pengutronix.de>
To: Pavel Machek <pavel@ucw.cz>,
kraxel@redhat.com, vivek.kasireddy@intel.com,
dri-devel@lists.freedesktop.org, sumit.semwal@linaro.org,
benjamin.gaignard@collabora.com, Brian.Starkey@arm.com,
jstultz@google.com, tjmercier@google.com,
linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org,
kernel list <linux-kernel@vger.kernel.org>,
laurent.pinchart@ideasonboard.com,
linux+etnaviv@armlinux.org.uk, christian.gmeiner@gmail.com,
etnaviv@lists.freedesktop.org, phone-devel@vger.kernel.org
Subject: Re: DMA-BUFs always uncached on arm64, causing poor camera performance on Librem 5
Date: Thu, 10 Jul 2025 10:42:02 +0200 [thread overview]
Message-ID: <aecd03f464f25d50f379be405a8596261f247897.camel@pengutronix.de> (raw)
In-Reply-To: <aG94uNDrL1MdHJPM@duo.ucw.cz>
Hi Pavel,
Am Donnerstag, dem 10.07.2025 um 10:24 +0200 schrieb Pavel Machek:
> 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:
>
> 1) 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?
If you need to touch the buffers using the CPU then you are either
stuck with uncached memory or you need to implement bracketed access to
do the necessary cache maintenance. Be aware that completely flushing
the cache is not really an option, as that would impact other
workloads, so you have to flush the cache by walking the virtual
address space of the buffer, which may take a significant amount of CPU
time.
However, if you are only going to use the buffer with the GPU I see no
reason to touch it from the CPU side. Why would you even need to copy
the content? After all dma-bufs are meant to enable zero-copy between
DMA capable accelerators. You can simply import the V4L2 buffer into a
GL texture using EGL_EXT_image_dma_buf_import. Using this path you
don't need to bother with the cache at all, as the GPU will directly
read the video buffers from RAM.
Regards,
Lucas
>
> 2) Does anyone have patches / ideas / roadmap how to solve that? It
> makes GPU unusable for computing, and camera basically unusable for
> video.
>
> Best regards,
> Pavel
next prev parent reply other threads:[~2025-07-10 8:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-10 8:24 DMA-BUFs always uncached on arm64, causing poor camera performance on Librem 5 Pavel Machek
2025-07-10 8:42 ` Lucas Stach [this message]
2025-07-10 8:49 ` Pavel Machek
2025-07-10 21:52 ` Laurent Pinchart
2025-07-10 16:01 ` Nicolas Dufresne
2025-07-13 19:54 ` Mikhail Rudenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aecd03f464f25d50f379be405a8596261f247897.camel@pengutronix.de \
--to=l.stach@pengutronix.de \
--cc=Brian.Starkey@arm.com \
--cc=benjamin.gaignard@collabora.com \
--cc=christian.gmeiner@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=etnaviv@lists.freedesktop.org \
--cc=jstultz@google.com \
--cc=kraxel@redhat.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux+etnaviv@armlinux.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=phone-devel@vger.kernel.org \
--cc=sumit.semwal@linaro.org \
--cc=tjmercier@google.com \
--cc=vivek.kasireddy@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).