[PATCH] libcamera: debayer_cpu: Sync output buffer

[Laurent Pinchart]

On Mon, Sep 02, 2024 at 12:56:31PM +0200, Robert Mader wrote:
> On 01.09.24 13:39, Robert Mader wrote:
> >
> > On 01.09.24 13:07, Laurent Pinchart wrote:
> >> Hans, would you be able to test this on an IPU6-based device, and check
> >> the performance impact ? I don't expect expensive cache management
> >> operations on an x86 device.
> >>
> >> Bryan, could you do the same with camss ?
> 
> Heads up that in my initial testing around different Gstreamer pipelines 
> on arm64 I saw mixed results:
> 
> 1. Cases involving successful dmabuf import to the GPU are (much) less 
> prone to glitches while not seeming to regress much in terms of frame 
> rates. This includes running Gnome-Snapshot or waylandsink on devices 
> like the Librem5, PinePhone or Pixel 3a (generally qcom).
> 
> 2. Cases where Gst mmaps the buffers seem to get a noticeable 
> performance hit.
> 
> Crucially this applies to common fallback paths like in following example:
> 
>   - glupload tries to import the buffer as dmabuf
> 
>   - fails due to stride requirements...
> 
>   - uses the "raw" importer that mmap the buffer
> 
> This case is almost tragic IMO. The buffer data ends up only getting 
> accessed by the CPU but we flush the catches/sync to the GPU *twice* - 
> just to upload a copy in the end.
> 
> And while I see potential to improve this scenario in the other parts of 
> the stack, I don't see anything we can about it in libcamera right now 
> (apart from not landing a patch like this).

It's a bit late, but maybe there's a possibility to submit a lightning
talk/BoF topic for LPC in two weeks ? Cache handling is a topic that
crosses many subsystem boundaries, and I think we'll have quite a few
people with relevant expertise in Vienna.

-- 
Regards,

Laurent Pinchart