[PATCH] libcamera: debayer_cpu: Sync output buffer

[Robert Mader]

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).

Regards,

Robert

-- 
Robert Mader
Consultant Software Developer

Collabora Ltd.
Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
Registered in England & Wales, no. 5513718