[{"id":31025,"web_url":"https://patchwork.libcamera.org/comment/31025/","msgid":"<20240901004959.GE3811@pendragon.ideasonboard.com>","date":"2024-09-01T00:49:59","subject":"Re: [PATCH] libcamera: debayer_cpu: Sync output buffer","submitter":{"id":2,"url":"https://patchwork.libcamera.org/api/people/2/","name":"Laurent Pinchart","email":"laurent.pinchart@ideasonboard.com"},"content":"CC'ing Hans, Milan and Bryan.\n\nOn Sat, Aug 31, 2024 at 09:05:11PM +0200, Robert Mader wrote:\n> Using `DMA_BUF_IOCTL_SYNC` is required for dmabufs in order to ensure\n> correct results. Not doing so currently results in occasional tearing\n> and/or backlashes in GL/VK clients that use the buffers directly for\n> rendering.\n> \n> Signed-off-by: Robert Mader \n> ---\n> src/libcamera/software_isp/debayer_cpu.cpp | 22 ++++++++++++++++++++++\n> 1 file changed, 22 insertions(+)\n> \n> diff --git a/src/libcamera/software_isp/debayer_cpu.cpp b/src/libcamera/software_isp/debayer_cpu.cpp\n> index 077f7f4b..6c953b03 100644\n> --- a/src/libcamera/software_isp/debayer_cpu.cpp\n> +++ b/src/libcamera/software_isp/debayer_cpu.cpp\n> @@ -11,7 +11,9 @@\n> \n> #include \"debayer_cpu.h\"\n> \n> +#include \n> #include \n> +#include \n> #include \n> \n> #include \n> @@ -733,6 +735,16 @@ void DebayerCpu::process(FrameBuffer *input, FrameBuffer *output, DebayerParams\n> \t\tclock_gettime(CLOCK_MONOTONIC_RAW, &frameStartTime);\n> \t}\n> \n> +\tfor (const FrameBuffer::Plane &plane : output->planes()) {\n> +\t\tconst int fd = plane.fd.get();\n> +\t\tstruct dma_buf_sync sync = { DMA_BUF_SYNC_START };\n> +\n> +\t\tsync.flags |= DMA_BUF_SYNC_WRITE;\n> +\n> +\t\tif (ioctl (fd, DMA_BUF_IOCTL_SYNC, &sync) < 0)\n> +\t\t\tLOG(Debayer, Error) << \"Syncing buffer FD \" << fd << \"failed: \" << errno;\n> +\t}\n> +\n> \tgreen_ = params.green;\n> \tred_ = swapRedBlueGains_ ? params.blue : params.red;\n> \tblue_ = swapRedBlueGains_ ? params.red : params.blue;\n> @@ -760,6 +772,16 @@ void DebayerCpu::process(FrameBuffer *input, FrameBuffer *output, DebayerParams\n> \n> \tmetadata.planes()[0].bytesused = out.planes()[0].size();\n> \n> +\tfor (const FrameBuffer::Plane &plane : output->planes()) {\n> +\t\tconst int fd = plane.fd.get();\n> +\t\tstruct dma_buf_sync sync = { DMA_BUF_SYNC_END };\n> +\n> +\t\tsync.flags |= DMA_BUF_SYNC_WRITE;\n> +\n> +\t\tif (ioctl (fd, DMA_BUF_IOCTL_SYNC, &sync) < 0)\n> +\t\t\tLOG(Debayer, Error) << \"Syncing buffer FD \" << fd << \"failed: \" << errno;\n> +\t}\n> +\n> \t/* Measure before emitting signals */\n> \tif (measuredFrames_ < DebayerCpu::kLastFrameToMeasure &&\n> \t ++measuredFrames_ > DebayerCpu::kFramesToSkip) {","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 2EBCCC324C\n\tfor ;\n\tSun, 1 Sep 2024 00:50:34 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 5C11E6345D;\n\tSun, 1 Sep 2024 02:50:33 +0200 (CEST)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 2B1AB618FE\n\tfor ;\n\tSun, 1 Sep 2024 02:50:31 +0200 (CEST)","from pendragon.ideasonboard.com (81-175-209-231.bb.dnainternet.fi\n\t[81.175.209.231])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id AE3044AD;\n\tSun, 1 Sep 2024 02:49:20 +0200 (CEST)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"DDqHGya1\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1725151760;\n\tbh=7bEX53QOMiT7vFFC32oqsMMa7/mdytLrsaCl0dQZWOA=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=DDqHGya1xT4HLY5W6vdVR2vzkPnJ4mSHbRk9XYNwo2iA4hB1URlbvaI1XtA+sUmjP\n\tbP5dZ044eDHdOF7Tcdj4TFop5h5m5za7zVxQ4Fq3oUSOAKCB8saJwlRdMSVlqEt41d\n\t6eTCYRFfTPy7DZbQ+bkeF1zkV9bkWcHLRhX/P18k=","Date":"Sun, 1 Sep 2024 03:49:59 +0300","From":"Laurent Pinchart ","To":"Robert Mader ","Cc":"libcamera-devel@lists.libcamera.org, Hans de Goede ,\n\tMilan Zamazal ,\n\tBryan O'Donoghue ","Subject":"Re: [PATCH] libcamera: debayer_cpu: Sync output buffer","Message-ID":"<20240901004959.GE3811@pendragon.ideasonboard.com>","References":"<20240831190511.128151-1-robert.mader@collabora.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","In-Reply-To":"<20240831190511.128151-1-robert.mader@collabora.com>","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":31026,"web_url":"https://patchwork.libcamera.org/comment/31026/","msgid":"<075f44b0-381a-4ef9-bf74-a24439efbe94@redhat.com>","date":"2024-09-01T10:56:10","subject":"Re: [PATCH] libcamera: debayer_cpu: Sync output buffer","submitter":{"id":102,"url":"https://patchwork.libcamera.org/api/people/102/","name":"Hans de Goede","email":"hdegoede@redhat.com"},"content":"Hi Robert,\n\nOn 8/31/24 9:05 PM, Robert Mader wrote:\n> Using `DMA_BUF_IOCTL_SYNC` is required for dmabufs in order to ensure\n> correct results. Not doing so currently results in occasional tearing\n> and/or backlashes in GL/VK clients that use the buffers directly for\n> rendering.\n> \n> Signed-off-by: Robert Mader \n\nThank you for your patch.\n\nI'm not a dmabuf expert, with that said the suggested change looks\nreasonable to me.\n\nOne small code-style remark inline below.\n\n> ---\n> src/libcamera/software_isp/debayer_cpu.cpp | 22 ++++++++++++++++++++++\n> 1 file changed, 22 insertions(+)\n> \n> diff --git a/src/libcamera/software_isp/debayer_cpu.cpp b/src/libcamera/software_isp/debayer_cpu.cpp\n> index 077f7f4b..6c953b03 100644\n> --- a/src/libcamera/software_isp/debayer_cpu.cpp\n> +++ b/src/libcamera/software_isp/debayer_cpu.cpp\n> @@ -11,7 +11,9 @@\n> \n> #include \"debayer_cpu.h\"\n> \n> +#include \n> #include \n> +#include \n> #include \n> \n> #include \n> @@ -733,6 +735,16 @@ void DebayerCpu::process(FrameBuffer *input, FrameBuffer *output, DebayerParams\n> \t\tclock_gettime(CLOCK_MONOTONIC_RAW, &frameStartTime);\n> \t}\n> \n> +\tfor (const FrameBuffer::Plane &plane : output->planes()) {\n> +\t\tconst int fd = plane.fd.get();\n> +\t\tstruct dma_buf_sync sync = { DMA_BUF_SYNC_START };\n> +\n> +\t\tsync.flags |= DMA_BUF_SYNC_WRITE;\n\nThese 2 lines are a weird way to write:\n\n\t\tstruct dma_buf_sync sync = { DMA_BUF_SYNC_START | DMA_BUF_SYNC_WRITE };\n\n?\n\n> +\n> +\t\tif (ioctl (fd, DMA_BUF_IOCTL_SYNC, &sync) < 0)\n> +\t\t\tLOG(Debayer, Error) << \"Syncing buffer FD \" << fd << \"failed: \" << errno;\n> +\t}\n> +\n> \tgreen_ = params.green;\n> \tred_ = swapRedBlueGains_ ? params.blue : params.red;\n> \tblue_ = swapRedBlueGains_ ? params.red : params.blue;\n> @@ -760,6 +772,16 @@ void DebayerCpu::process(FrameBuffer *input, FrameBuffer *output, DebayerParams\n> \n> \tmetadata.planes()[0].bytesused = out.planes()[0].size();\n> \n> +\tfor (const FrameBuffer::Plane &plane : output->planes()) {\n> +\t\tconst int fd = plane.fd.get();\n> +\t\tstruct dma_buf_sync sync = { DMA_BUF_SYNC_END };\n> +\n> +\t\tsync.flags |= DMA_BUF_SYNC_WRITE;\n\nSame here, why not use:\n\n\t\tstruct dma_buf_sync sync = { DMA_BUF_SYNC_END | DMA_BUF_SYNC_WRITE };\n\n?\n\n\n> +\n> +\t\tif (ioctl (fd, DMA_BUF_IOCTL_SYNC, &sync) < 0)\n> +\t\t\tLOG(Debayer, Error) << \"Syncing buffer FD \" << fd << \"failed: \" << errno;\n> +\t}\n> +\n> \t/* Measure before emitting signals */\n> \tif (measuredFrames_ < DebayerCpu::kLastFrameToMeasure &&\n> \t ++measuredFrames_ > DebayerCpu::kFramesToSkip) {\n\nRegards,\n\nHans","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id E3284C323E\n\tfor ;\n\tSun, 1 Sep 2024 10:56:18 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 2C64763469;\n\tSun, 1 Sep 2024 12:56:18 +0200 (CEST)","from us-smtp-delivery-124.mimecast.com\n\t(us-smtp-delivery-124.mimecast.com [170.10.129.124])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 7DD5663466\n\tfor ;\n\tSun, 1 Sep 2024 12:56:16 +0200 (CEST)","from mail-ej1-f71.google.com (mail-ej1-f71.google.com\n\t[209.85.218.71]) by relay.mimecast.com with ESMTP with STARTTLS\n\t(version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id\n\tus-mta-311-fSJuhwUtO7iBMF1W61QtLg-1; Sun, 01 Sep 2024 06:56:13 -0400","by mail-ej1-f71.google.com with SMTP id\n\ta640c23a62f3a-a86931aa0efso252191066b.3\n\tfor ;\n\tSun, 01 Sep 2024 03:56:13 -0700 (PDT)","from ?IPV6:2001:1c00:c32:7800:5bfa:a036:83f0:f9ec?\n\t(2001-1c00-0c32-7800-5bfa-a036-83f0-f9ec.cable.dynamic.v6.ziggo.nl.\n\t[2001:1c00:c32:7800:5bfa:a036:83f0:f9ec])\n\tby smtp.gmail.com with ESMTPSA id\n\ta640c23a62f3a-a8989196b89sm424479466b.114.2024.09.01.03.56.11\n\t(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n\tSun, 01 Sep 2024 03:56:11 -0700 (PDT)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key;\n\tunprotected) header.d=redhat.com header.i=@redhat.com\n\theader.b=\"EPqLemon\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n\ts=mimecast20190719; t=1725188175;\n\th=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n\tto:to:cc:mime-version:mime-version:content-type:content-type:\n\tcontent-transfer-encoding:content-transfer-encoding:\n\tin-reply-to:in-reply-to:references:references;\n\tbh=o0pQ60Ehy3EV9VfZeaFEAOnC2YqYkpB02/pxyUFB524=;\n\tb=EPqLemonssLK1SKEwQcBa3cW6+V8PjVSPTtG0a1cg3x/F+HOD420MAiz8z0wqutFbFK/dL\n\t3kndIyuTC2zKkztC+gZdGLOy3neJQuT6uZ73zgJhv9vhKtKrk05xUHCeIGn/zm/5cOcd33\n\tG7fUaNppaL2ONHkhtmo/QKqkNpbTBgI=","X-MC-Unique":"fSJuhwUtO7iBMF1W61QtLg-1","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20230601; t=1725188172; x=1725792972;\n\th=content-transfer-encoding:in-reply-to:from:content-language\n\t:references:to:subject:user-agent:mime-version:date:message-id\n\t:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;\n\tbh=o0pQ60Ehy3EV9VfZeaFEAOnC2YqYkpB02/pxyUFB524=;\n\tb=uYXv2h35ot9SuBOhy8nUfopud+95rTMKtJn5LjqZmMYOFqrIqqcsmgl8v9cHcQH60A\n\t/u/CnZ1jCtCVDINXe40D3/dr7j5qGUK4G75ZG2lcp+iXyWM2i6tv1wswY65h7Ovex5Lg\n\tLPwETeNRiw8F03yRpO37lCSuqZTsXAR93Y9tF2Ksz5DR8hRQCUry+YhtIHa8mcFpUfBw\n\tzw2S2T4EBd0h5tqBFgrteIPpG6/BAKTnE9i6NWTmicKSlB48Ijp7fhCkurpNbIsQvLRM\n\tTSN6RHQ0w5ZDABgblROhn4wllFxd+/nubjLsna5oa6Moqwh5IY/bGmdSfdmxt9sDpqPN\n\tHRtw==","X-Forwarded-Encrypted":"i=1;\n\tAJvYcCVGVpqubnVddnGBVrmXy8x7F83advZ7Yb7nWMTG0Ds1pvC4NG2loTH0xBXK7YILWkjqiPPFH7HAur7MBaZdboo=@lists.libcamera.org","X-Gm-Message-State":"AOJu0YxC0s4dNI4P0i9EuuqqxNfuAT4KrAo6oM6q8syYAbXLvO0Hqa1+\n\t45qM8n0x0AnNusSx0xvmXBlU3X2rQqgbTlNqpOdIPjxNcXNX0xYdsagtsnf2JjYCocpE0PLZMSd\n\tma22ncE5oqtG14/nVC0d/yNRNppU/uoyRaKu38jVKwUDnj9aUBKMh2yBbiGv5V+nKhi4DaIUPbd\n\ta99zc=","X-Received":["by 2002:a17:907:3da0:b0:a7a:ab8a:38f with SMTP id\n\ta640c23a62f3a-a897f930b73mr917480766b.41.1725188172457; \n\tSun, 01 Sep 2024 03:56:12 -0700 (PDT)","by 2002:a17:907:3da0:b0:a7a:ab8a:38f with SMTP id\n\ta640c23a62f3a-a897f930b73mr917479866b.41.1725188171866; \n\tSun, 01 Sep 2024 03:56:11 -0700 (PDT)"],"X-Google-Smtp-Source":"AGHT+IFKXcA6CytvxqrpWZkf2uzgiBwp7qsxqIPdEBS9P4Pisg0CDs4ixD8hci0QF1DlR1Uci3Nzmg==","Message-ID":"<075f44b0-381a-4ef9-bf74-a24439efbe94@redhat.com>","Date":"Sun, 1 Sep 2024 12:56:10 +0200","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH] libcamera: debayer_cpu: Sync output buffer","To":"Robert Mader ,\n\tlibcamera-devel@lists.libcamera.org","References":"<20240831190511.128151-1-robert.mader@collabora.com>","From":"Hans de Goede ","In-Reply-To":"<20240831190511.128151-1-robert.mader@collabora.com>","X-Mimecast-Spam-Score":"0","X-Mimecast-Originator":"redhat.com","Content-Language":"en-US, nl","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"7bit","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":31027,"web_url":"https://patchwork.libcamera.org/comment/31027/","msgid":"<20240901110707.GA6713@pendragon.ideasonboard.com>","date":"2024-09-01T11:07:07","subject":"Re: [PATCH] libcamera: debayer_cpu: Sync output buffer","submitter":{"id":2,"url":"https://patchwork.libcamera.org/api/people/2/","name":"Laurent Pinchart","email":"laurent.pinchart@ideasonboard.com"},"content":"On Sun, Sep 01, 2024 at 12:56:10PM +0200, Hans de Goede wrote:\n> Hi Robert,\n> \n> On 8/31/24 9:05 PM, Robert Mader wrote:\n> > Using `DMA_BUF_IOCTL_SYNC` is required for dmabufs in order to ensure\n> > correct results. Not doing so currently results in occasional tearing\n> > and/or backlashes in GL/VK clients that use the buffers directly for\n> > rendering.\n> > \n> > Signed-off-by: Robert Mader \n> \n> Thank you for your patch.\n> \n> I'm not a dmabuf expert, with that said the suggested change looks\n> reasonable to me.\n\nHans, would you be able to test this on an IPU6-based device, and check\nthe performance impact ? I don't expect expensive cache management\noperations on an x86 device.\n\nBryan, could you do the same with camss ?\n\n> One small code-style remark inline below.\n> \n> > ---\n> > src/libcamera/software_isp/debayer_cpu.cpp | 22 ++++++++++++++++++++++\n> > 1 file changed, 22 insertions(+)\n> > \n> > diff --git a/src/libcamera/software_isp/debayer_cpu.cpp b/src/libcamera/software_isp/debayer_cpu.cpp\n> > index 077f7f4b..6c953b03 100644\n> > --- a/src/libcamera/software_isp/debayer_cpu.cpp\n> > +++ b/src/libcamera/software_isp/debayer_cpu.cpp\n> > @@ -11,7 +11,9 @@\n> > \n> > #include \"debayer_cpu.h\"\n> > \n> > +#include \n> > #include \n> > +#include \n> > #include \n> > \n> > #include \n> > @@ -733,6 +735,16 @@ void DebayerCpu::process(FrameBuffer *input, FrameBuffer *output, DebayerParams\n> > \t\tclock_gettime(CLOCK_MONOTONIC_RAW, &frameStartTime);\n> > \t}\n> > \n> > +\tfor (const FrameBuffer::Plane &plane : output->planes()) {\n> > +\t\tconst int fd = plane.fd.get();\n> > +\t\tstruct dma_buf_sync sync = { DMA_BUF_SYNC_START };\n> > +\n> > +\t\tsync.flags |= DMA_BUF_SYNC_WRITE;\n> \n> These 2 lines are a weird way to write:\n> \n> \t\tstruct dma_buf_sync sync = { DMA_BUF_SYNC_START | DMA_BUF_SYNC_WRITE };\n> \n> ?\n> \n> > +\n> > +\t\tif (ioctl (fd, DMA_BUF_IOCTL_SYNC, &sync) < 0)\n> > +\t\t\tLOG(Debayer, Error) << \"Syncing buffer FD \" << fd << \"failed: \" << errno;\n> > +\t}\n> > +\n> > \tgreen_ = params.green;\n> > \tred_ = swapRedBlueGains_ ? params.blue : params.red;\n> > \tblue_ = swapRedBlueGains_ ? params.red : params.blue;\n> > @@ -760,6 +772,16 @@ void DebayerCpu::process(FrameBuffer *input, FrameBuffer *output, DebayerParams\n> > \n> > \tmetadata.planes()[0].bytesused = out.planes()[0].size();\n> > \n> > +\tfor (const FrameBuffer::Plane &plane : output->planes()) {\n> > +\t\tconst int fd = plane.fd.get();\n> > +\t\tstruct dma_buf_sync sync = { DMA_BUF_SYNC_END };\n> > +\n> > +\t\tsync.flags |= DMA_BUF_SYNC_WRITE;\n> \n> Same here, why not use:\n> \n> \t\tstruct dma_buf_sync sync = { DMA_BUF_SYNC_END | DMA_BUF_SYNC_WRITE };\n> \n> ?\n> \n> > +\n> > +\t\tif (ioctl (fd, DMA_BUF_IOCTL_SYNC, &sync) < 0)\n> > +\t\t\tLOG(Debayer, Error) << \"Syncing buffer FD \" << fd << \"failed: \" << errno;\n> > +\t}\n> > +\n> > \t/* Measure before emitting signals */\n> > \tif (measuredFrames_ < DebayerCpu::kLastFrameToMeasure &&\n> > \t ++measuredFrames_ > DebayerCpu::kFramesToSkip) {","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 791AFC324C\n\tfor ;\n\tSun, 1 Sep 2024 11:07:40 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id A1B3A63469;\n\tSun, 1 Sep 2024 13:07:39 +0200 (CEST)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[213.167.242.64])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 1B71963466\n\tfor ;\n\tSun, 1 Sep 2024 13:07:38 +0200 (CEST)","from pendragon.ideasonboard.com (81-175-209-231.bb.dnainternet.fi\n\t[81.175.209.231])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id 65BF94CF;\n\tSun, 1 Sep 2024 13:06:27 +0200 (CEST)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"Ny68/Uz9\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1725188787;\n\tbh=pA8I7Es8LxM1idU1BoBPQBf1P3MxpLxSajDIachV7Ko=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=Ny68/Uz9phuTqvnuK279KC8zXK00L0Z7P5jyqsKIE3mFaQOIqJP9QYnW6/cXm3j9M\n\tLg1XDDBOmSFt86NxjS8wrvZ8mIIvuCSdgzQXEXLgY96sNTifk5l0+DV9ogKFyyPxxI\n\t8jSmu9uSvxBXwmcsEhE5uBHz10QVyQIrSmOoZAs4=","Date":"Sun, 1 Sep 2024 14:07:07 +0300","From":"Laurent Pinchart ","To":"Hans de Goede ","Cc":"Robert Mader ,\n\tlibcamera-devel@lists.libcamera.org","Subject":"Re: [PATCH] libcamera: debayer_cpu: Sync output buffer","Message-ID":"<20240901110707.GA6713@pendragon.ideasonboard.com>","References":"<20240831190511.128151-1-robert.mader@collabora.com>\n\t<075f44b0-381a-4ef9-bf74-a24439efbe94@redhat.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","In-Reply-To":"<075f44b0-381a-4ef9-bf74-a24439efbe94@redhat.com>","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":31028,"web_url":"https://patchwork.libcamera.org/comment/31028/","msgid":"<0dca7aff-c65c-4385-8645-523ef4a236e0@collabora.com>","date":"2024-09-01T11:39:00","subject":"Re: [PATCH] libcamera: debayer_cpu: Sync output buffer","submitter":{"id":140,"url":"https://patchwork.libcamera.org/api/people/140/","name":"Robert Mader","email":"robert.mader@collabora.com"},"content":"On 01.09.24 13:07, Laurent Pinchart wrote:\n> On Sun, Sep 01, 2024 at 12:56:10PM +0200, Hans de Goede wrote:\n>> Hi Robert,\n>>\n>> On 8/31/24 9:05 PM, Robert Mader wrote:\n>>> Using `DMA_BUF_IOCTL_SYNC` is required for dmabufs in order to ensure\n>>> correct results. Not doing so currently results in occasional tearing\n>>> and/or backlashes in GL/VK clients that use the buffers directly for\n>>> rendering.\n>>>\n>>> Signed-off-by: Robert Mader \n>> Thank you for your patch.\n>>\n>> I'm not a dmabuf expert, with that said the suggested change looks\n>> reasonable to me.\n> Hans, would you be able to test this on an IPU6-based device, and check\n> the performance impact ? I don't expect expensive cache management\n> operations on an x86 device.\n>\n> Bryan, could you do the same with camss ?\n\nJust to let you know: I directly submitted this yesterday to start a \ndiscussion, however after a bit more thinking I figured we can probably \ndo even better by moving these calls to MappedFrameBuffer. I wrote \nhttps://gitlab.freedesktop.org/rmader/libcamera/-/commit/6b7d280634accd9c214d052df34565eb208652e7 \nfor that if you want to have look (will submit early next week).\n\n>> One small code-style remark inline below.\n>>\n>>> ---\n>>> src/libcamera/software_isp/debayer_cpu.cpp | 22 ++++++++++++++++++++++\n>>> 1 file changed, 22 insertions(+)\n>>>\n>>> diff --git a/src/libcamera/software_isp/debayer_cpu.cpp b/src/libcamera/software_isp/debayer_cpu.cpp\n>>> index 077f7f4b..6c953b03 100644\n>>> --- a/src/libcamera/software_isp/debayer_cpu.cpp\n>>> +++ b/src/libcamera/software_isp/debayer_cpu.cpp\n>>> @@ -11,7 +11,9 @@\n>>> \n>>> #include \"debayer_cpu.h\"\n>>> \n>>> +#include \n>>> #include \n>>> +#include \n>>> #include \n>>> \n>>> #include \n>>> @@ -733,6 +735,16 @@ void DebayerCpu::process(FrameBuffer *input, FrameBuffer *output, DebayerParams\n>>> \t\tclock_gettime(CLOCK_MONOTONIC_RAW, &frameStartTime);\n>>> \t}\n>>> \n>>> +\tfor (const FrameBuffer::Plane &plane : output->planes()) {\n>>> +\t\tconst int fd = plane.fd.get();\n>>> +\t\tstruct dma_buf_sync sync = { DMA_BUF_SYNC_START };\n>>> +\n>>> +\t\tsync.flags |= DMA_BUF_SYNC_WRITE;\n>> These 2 lines are a weird way to write:\n>>\n>> \t\tstruct dma_buf_sync sync = { DMA_BUF_SYNC_START | DMA_BUF_SYNC_WRITE };\n>>\n>> ?\n>>\n>>> +\n>>> +\t\tif (ioctl (fd, DMA_BUF_IOCTL_SYNC, &sync) < 0)\n>>> +\t\t\tLOG(Debayer, Error) << \"Syncing buffer FD \" << fd << \"failed: \" << errno;\n>>> +\t}\n>>> +\n>>> \tgreen_ = params.green;\n>>> \tred_ = swapRedBlueGains_ ? params.blue : params.red;\n>>> \tblue_ = swapRedBlueGains_ ? params.red : params.blue;\n>>> @@ -760,6 +772,16 @@ void DebayerCpu::process(FrameBuffer *input, FrameBuffer *output, DebayerParams\n>>> \n>>> \tmetadata.planes()[0].bytesused = out.planes()[0].size();\n>>> \n>>> +\tfor (const FrameBuffer::Plane &plane : output->planes()) {\n>>> +\t\tconst int fd = plane.fd.get();\n>>> +\t\tstruct dma_buf_sync sync = { DMA_BUF_SYNC_END };\n>>> +\n>>> +\t\tsync.flags |= DMA_BUF_SYNC_WRITE;\n>> Same here, why not use:\n>>\n>> \t\tstruct dma_buf_sync sync = { DMA_BUF_SYNC_END | DMA_BUF_SYNC_WRITE };\n>>\n>> ?\n>>\n>>> +\n>>> +\t\tif (ioctl (fd, DMA_BUF_IOCTL_SYNC, &sync) < 0)\n>>> +\t\t\tLOG(Debayer, Error) << \"Syncing buffer FD \" << fd << \"failed: \" << errno;\n>>> +\t}\n>>> +\n>>> \t/* Measure before emitting signals */\n>>> \tif (measuredFrames_ < DebayerCpu::kLastFrameToMeasure &&\n>>> \t ++measuredFrames_ > DebayerCpu::kFramesToSkip) {","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 4E2D9C323E\n\tfor ;\n\tSun, 1 Sep 2024 11:39:13 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 76F3A63469;\n\tSun, 1 Sep 2024 13:39:12 +0200 (CEST)","from sender4-pp-f112.zoho.com (sender4-pp-f112.zoho.com\n\t[136.143.188.112])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 82D4163466\n\tfor ;\n\tSun, 1 Sep 2024 13:39:09 +0200 (CEST)","by mx.zohomail.com with SMTPS id 1725190743302730.5253828484095;\n\tSun, 1 Sep 2024 04:39:03 -0700 (PDT)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key;\n\tunprotected) header.d=collabora.com\n\theader.i=robert.mader@collabora.com header.b=\"gPrr7hyx\"; \n\tdkim-atps=neutral","ARC-Seal":"i=1; a=rsa-sha256; t=1725190745; cv=none; \n\td=zohomail.com; s=zohoarc; \n\tb=JMfJ1VvqTdGdvxL5kp09go8vVG5CjLTFiWrCVlpD/RVprXXDso0tIRLsOOEawojSIQvoK2OZf9KtY5H02re7tn0QhEHRr3Aww0kyTgWiwBc411JcO1RU6fT5BlSBQRSoK7Es2QPrcggfRZT+llR6jTtKZyJbpWu5tEnhKy8IkAE=","ARC-Message-Signature":"i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; \n\ts=zohoarc; t=1725190745;\n\th=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To;\n\tbh=7v1kTNqJNftalZJsPdVpDWW9UHH11mQlJJTNu+m7du4=; \n\tb=aRcwUCEj77URnBHZxf2Rt/w03BqSpbCsijdb3+yMsmGRJiU2YE1z4pIPXZ6Aj8iKqmDOGWa5hnFnaVg3VpHauQY/vmm9f0nroi8ArwL/Vk97o/nkwCV3tlS8AO1c6K+QdbB7Wk648M0WOFB+QDZk5iG39894gU7y+reezy76ekk=","ARC-Authentication-Results":"i=1; mx.zohomail.com;\n\tdkim=pass header.i=collabora.com;\n\tspf=pass smtp.mailfrom=robert.mader@collabora.com;\n\tdmarc=pass header.from=","DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1725190745;\n\ts=zohomail; d=collabora.com; i=robert.mader@collabora.com;\n\th=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;\n\tbh=7v1kTNqJNftalZJsPdVpDWW9UHH11mQlJJTNu+m7du4=;\n\tb=gPrr7hyxUNrYqlLbKtU07dVLTTtyCEIqbT8key0rpDjkm63XItsYwjLu/ZXkFosE\n\t5SxIvSq7PYBXdzch4WjkgJ6PePqcQmMrg1Ed7jGSusl/29uNTB97VRLoFUuLB0iwTvB\n\tXzXRVF3URaN6paW5wHUqWY0tHkyLfWFLXEpxrnC8=","Message-ID":"<0dca7aff-c65c-4385-8645-523ef4a236e0@collabora.com>","Date":"Sun, 1 Sep 2024 13:39:00 +0200","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH] libcamera: debayer_cpu: Sync output buffer","To":"Laurent Pinchart ,\n\tHans de Goede ","Cc":"libcamera-devel@lists.libcamera.org","References":"<20240831190511.128151-1-robert.mader@collabora.com>\n\t<075f44b0-381a-4ef9-bf74-a24439efbe94@redhat.com>\n\t<20240901110707.GA6713@pendragon.ideasonboard.com>","Content-Language":"en-US, de-DE","From":"Robert Mader ","In-Reply-To":"<20240901110707.GA6713@pendragon.ideasonboard.com>","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"7bit","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":31041,"web_url":"https://patchwork.libcamera.org/comment/31041/","msgid":"<543e41bd-2eab-4521-84fa-ca2504c3d524@collabora.com>","date":"2024-09-02T10:56:31","subject":"Re: [PATCH] libcamera: debayer_cpu: Sync output buffer","submitter":{"id":140,"url":"https://patchwork.libcamera.org/api/people/140/","name":"Robert Mader","email":"robert.mader@collabora.com"},"content":"On 01.09.24 13:39, Robert Mader wrote:\n>\n> On 01.09.24 13:07, Laurent Pinchart wrote:\n>> Hans, would you be able to test this on an IPU6-based device, and check\n>> the performance impact ? I don't expect expensive cache management\n>> operations on an x86 device.\n>>\n>> Bryan, could you do the same with camss ?\n\nHeads up that in my initial testing around different Gstreamer pipelines \non arm64 I saw mixed results:\n\n1. Cases involving successful dmabuf import to the GPU are (much) less \nprone to glitches while not seeming to regress much in terms of frame \nrates. This includes running Gnome-Snapshot or waylandsink on devices \nlike the Librem5, PinePhone or Pixel 3a (generally qcom).\n\n2. Cases where Gst mmaps the buffers seem to get a noticeable \nperformance hit.\n\nCrucially this applies to common fallback paths like in following example:\n\n  - glupload tries to import the buffer as dmabuf\n\n  - fails due to stride requirements...\n\n  - uses the \"raw\" importer that mmap the buffer\n\nThis case is almost tragic IMO. The buffer data ends up only getting \naccessed by the CPU but we flush the catches/sync to the GPU *twice* - \njust to upload a copy in the end.\n\nAnd while I see potential to improve this scenario in the other parts of \nthe stack, I don't see anything we can about it in libcamera right now \n(apart from not landing a patch like this).\n\nRegards,\n\nRobert","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 4D0C5C324C\n\tfor ;\n\tMon, 2 Sep 2024 10:56:42 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id D646A634CB;\n\tMon, 2 Sep 2024 12:56:40 +0200 (CEST)","from sender4-op-o12.zoho.com (sender4-op-o12.zoho.com\n\t[136.143.188.12])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 6DC1A618FD\n\tfor ;\n\tMon, 2 Sep 2024 12:56:38 +0200 (CEST)","by mx.zohomail.com with SMTPS id 1725274593529534.8119652789995;\n\tMon, 2 Sep 2024 03:56:33 -0700 (PDT)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key;\n\tunprotected) header.d=collabora.com\n\theader.i=robert.mader@collabora.com header.b=\"HqTWJvSp\"; \n\tdkim-atps=neutral","ARC-Seal":"i=1; a=rsa-sha256; t=1725274596; cv=none; \n\td=zohomail.com; s=zohoarc; \n\tb=SkvpEnUU8BkIu+zQA6WH1F87M85gdzWs8hB84r9LG2UXwT7IltMHEzyBxxtCZcLRB2Cd08WZk7zJ0QhBwRc1OvdCExWhUdqskZSQ3w8R/OkOL+jcspc+gDmGypwJBZEO9PJXGFbB+uPz15/gKIK0UylNRUouQteo568/xVDCnAY=","ARC-Message-Signature":"i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; \n\ts=zohoarc; t=1725274596;\n\th=Content-Type:Content-Transfer-Encoding:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To:Cc;\n\tbh=Lp1tB/8+nb/yudQV/f4SCmx8EZv1wDB/bz9lf/HP1YQ=; \n\tb=gtQ9MTBvD18ab/IbqCFXcH6TitZlX4Rp4dJ+maPMqqvZS8DZxn5xETxA9rqQ2P/akTwM9k7+PM+5eWY/JPrtAXtAwMce/rm5P5OirSPaEybTO69kodPGeYBFtoHeTWkGWLD6Gq7oQAMsHZTLmlOujyW//MflKLijEBy28eqahew=","ARC-Authentication-Results":"i=1; mx.zohomail.com;\n\tdkim=pass header.i=collabora.com;\n\tspf=pass smtp.mailfrom=robert.mader@collabora.com;\n\tdmarc=pass header.from=","DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1725274596;\n\ts=zohomail; d=collabora.com; i=robert.mader@collabora.com;\n\th=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To:Cc;\n\tbh=Lp1tB/8+nb/yudQV/f4SCmx8EZv1wDB/bz9lf/HP1YQ=;\n\tb=HqTWJvSprj5ztWOBAWjjN678T+ihO1MLJsiqUDJl56UxPsbfwsQQiHOQq2dGUWJm\n\toEUsBUXvGoVgXwQbQo0QnOrTYY1JCgdlGd62mX9k30m68ujpPqT1jK9O4XiZWmVwsHy\n\tc3DBmb/ELsp7e+qR2r4crcQeAD5vZmNmkhFOS4xc=","Message-ID":"<543e41bd-2eab-4521-84fa-ca2504c3d524@collabora.com>","Date":"Mon, 2 Sep 2024 12:56:31 +0200","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH] libcamera: debayer_cpu: Sync output buffer","To":"libcamera-devel@lists.libcamera.org","References":"<20240831190511.128151-1-robert.mader@collabora.com>\n\t<075f44b0-381a-4ef9-bf74-a24439efbe94@redhat.com>\n\t<20240901110707.GA6713@pendragon.ideasonboard.com>\n\t<0dca7aff-c65c-4385-8645-523ef4a236e0@collabora.com>","Content-Language":"en-US, de-DE","From":"Robert Mader ","In-Reply-To":"<0dca7aff-c65c-4385-8645-523ef4a236e0@collabora.com>","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"8bit","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":31073,"web_url":"https://patchwork.libcamera.org/comment/31073/","msgid":"<20240902203204.GB27677@pendragon.ideasonboard.com>","date":"2024-09-02T20:32:04","subject":"Re: [PATCH] libcamera: debayer_cpu: Sync output buffer","submitter":{"id":2,"url":"https://patchwork.libcamera.org/api/people/2/","name":"Laurent Pinchart","email":"laurent.pinchart@ideasonboard.com"},"content":"On Mon, Sep 02, 2024 at 12:56:31PM +0200, Robert Mader wrote:\n> On 01.09.24 13:39, Robert Mader wrote:\n> >\n> > On 01.09.24 13:07, Laurent Pinchart wrote:\n> >> Hans, would you be able to test this on an IPU6-based device, and check\n> >> the performance impact ? I don't expect expensive cache management\n> >> operations on an x86 device.\n> >>\n> >> Bryan, could you do the same with camss ?\n> \n> Heads up that in my initial testing around different Gstreamer pipelines \n> on arm64 I saw mixed results:\n> \n> 1. Cases involving successful dmabuf import to the GPU are (much) less \n> prone to glitches while not seeming to regress much in terms of frame \n> rates. This includes running Gnome-Snapshot or waylandsink on devices \n> like the Librem5, PinePhone or Pixel 3a (generally qcom).\n> \n> 2. Cases where Gst mmaps the buffers seem to get a noticeable \n> performance hit.\n> \n> Crucially this applies to common fallback paths like in following example:\n> \n>  - glupload tries to import the buffer as dmabuf\n> \n>  - fails due to stride requirements...\n> \n>  - uses the \"raw\" importer that mmap the buffer\n> \n> This case is almost tragic IMO. The buffer data ends up only getting \n> accessed by the CPU but we flush the catches/sync to the GPU *twice* - \n> just to upload a copy in the end.\n> \n> And while I see potential to improve this scenario in the other parts of \n> the stack, I don't see anything we can about it in libcamera right now \n> (apart from not landing a patch like this).\n\nIt's a bit late, but maybe there's a possibility to submit a lightning\ntalk/BoF topic for LPC in two weeks ? Cache handling is a topic that\ncrosses many subsystem boundaries, and I think we'll have quite a few\npeople with relevant expertise in Vienna.","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 5265ABF415\n\tfor ;\n\tMon, 2 Sep 2024 20:32:40 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 59416634CB;\n\tMon, 2 Sep 2024 22:32:39 +0200 (CEST)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id B0B10618FD\n\tfor ;\n\tMon, 2 Sep 2024 22:32:37 +0200 (CEST)","from pendragon.ideasonboard.com (81-175-209-231.bb.dnainternet.fi\n\t[81.175.209.231])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id 7A08C4CE;\n\tMon, 2 Sep 2024 22:31:25 +0200 (CEST)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"uwUmYQO8\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1725309085;\n\tbh=t2AHYFoP5lKJM2u3syg23bt0hFZCRwUovf00SsNSGrk=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=uwUmYQO8tL6iPjHVfMZrUy6KMmkW00APzviMEHGGTUn4UibMfq9Agp/UXV1fdFRbT\n\tf3CxEfaVFo6jhCZSl4KWGKJu/Nm2Zv3ZCOKNgGiysosBYNIhNTXgm1kISBizWJRf8F\n\t2nllOjERhvEKWVZ++KUFLiNNVI9rWT6RN2fHx0p0=","Date":"Mon, 2 Sep 2024 23:32:04 +0300","From":"Laurent Pinchart ","To":"Robert Mader ","Cc":"libcamera-devel@lists.libcamera.org","Subject":"Re: [PATCH] libcamera: debayer_cpu: Sync output buffer","Message-ID":"<20240902203204.GB27677@pendragon.ideasonboard.com>","References":"<20240831190511.128151-1-robert.mader@collabora.com>\n\t<075f44b0-381a-4ef9-bf74-a24439efbe94@redhat.com>\n\t<20240901110707.GA6713@pendragon.ideasonboard.com>\n\t<0dca7aff-c65c-4385-8645-523ef4a236e0@collabora.com>\n\t<543e41bd-2eab-4521-84fa-ca2504c3d524@collabora.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<543e41bd-2eab-4521-84fa-ca2504c3d524@collabora.com>","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":31074,"web_url":"https://patchwork.libcamera.org/comment/31074/","msgid":"","date":"2024-09-03T07:21:54","subject":"Re: [PATCH] libcamera: debayer_cpu: Sync output buffer","submitter":{"id":34,"url":"https://patchwork.libcamera.org/api/people/34/","name":"Naushir Patuck","email":"naush@raspberrypi.com"},"content":"On Mon, 2 Sept 2024 at 21:32, Laurent Pinchart\n wrote:\n>\n> On Mon, Sep 02, 2024 at 12:56:31PM +0200, Robert Mader wrote:\n> > On 01.09.24 13:39, Robert Mader wrote:\n> > >\n> > > On 01.09.24 13:07, Laurent Pinchart wrote:\n> > >> Hans, would you be able to test this on an IPU6-based device, and check\n> > >> the performance impact ? I don't expect expensive cache management\n> > >> operations on an x86 device.\n> > >>\n> > >> Bryan, could you do the same with camss ?\n> >\n> > Heads up that in my initial testing around different Gstreamer pipelines\n> > on arm64 I saw mixed results:\n> >\n> > 1. Cases involving successful dmabuf import to the GPU are (much) less\n> > prone to glitches while not seeming to regress much in terms of frame\n> > rates. This includes running Gnome-Snapshot or waylandsink on devices\n> > like the Librem5, PinePhone or Pixel 3a (generally qcom).\n> >\n> > 2. Cases where Gst mmaps the buffers seem to get a noticeable\n> > performance hit.\n> >\n> > Crucially this applies to common fallback paths like in following example:\n> >\n> > - glupload tries to import the buffer as dmabuf\n> >\n> > - fails due to stride requirements...\n> >\n> > - uses the \"raw\" importer that mmap the buffer\n> >\n> > This case is almost tragic IMO. The buffer data ends up only getting\n> > accessed by the CPU but we flush the catches/sync to the GPU *twice* -\n> > just to upload a copy in the end.\n> >\n> > And while I see potential to improve this scenario in the other parts of\n> > the stack, I don't see anything we can about it in libcamera right now\n> > (apart from not landing a patch like this).\n>\n> It's a bit late, but maybe there's a possibility to submit a lightning\n> talk/BoF topic for LPC in two weeks ? Cache handling is a topic that\n> crosses many subsystem boundaries, and I think we'll have quite a few\n> people with relevant expertise in Vienna.\n>\n\nThis is quite a complicated topic indeed. The RPi camera stack\nswitched to using cacheable dma bufs for performance reasons (> 10%\nuplift in certain use cases) and we had to be very careful with how to\nhandle the DMA_BUF_IOCTL_SYNC calls at the application level.\nHowever, I don't think handling this in MappedFrameBuffer is the right\nthing for hardware based ISPs because of unexpected stale data\nflushing/invalidation. I can expand on this during our F2F in Vienna.\n\nNaush\n\n\n> --\n> Regards,\n>\n> Laurent Pinchart","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 41A23BF415\n\tfor ;\n\tTue, 3 Sep 2024 07:22:26 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 0B0CB634E4;\n\tTue, 3 Sep 2024 09:22:25 +0200 (CEST)","from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com\n\t[IPv6:2607:f8b0:4864:20::b31])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id D3FC96345D\n\tfor ;\n\tTue, 3 Sep 2024 09:22:21 +0200 (CEST)","by mail-yb1-xb31.google.com with SMTP id\n\t3f1490d57ef6-e1ce1fa3f29so140055276.2\n\tfor ;\n\tTue, 03 Sep 2024 00:22:21 -0700 (PDT)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (2048-bit key;\n\tunprotected) header.d=raspberrypi.com header.i=@raspberrypi.com\n\theader.b=\"Pf/N44mc\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=raspberrypi.com; s=google; t=1725348140; x=1725952940;\n\tdarn=lists.libcamera.org; \n\th=cc:to:subject:message-id:date:from:in-reply-to:references\n\t:mime-version:from:to:cc:subject:date:message-id:reply-to;\n\tbh=fo7ZI3CDwpArfBPO8Fzm0rcCbfbNsQlasQGMvg/e1WI=;\n\tb=Pf/N44mczyTlPd0aFzXOqImkr2xdgMIacFMlbjAZxrEOSsWPhtoPzOBXvLgr+LMBqg\n\tuXG+bpCRe9fACOKUiZRPwUDkunIBqh8Qw39BRBBG05AS3/WYVSz522ub+lUhG7WeUXQU\n\tBI/N+vDQKHhqyKlumMRX+I9aCn9MFvQYkfMj17PZh6NXELzumJSGqqK9rai+o4PQHiaU\n\tv4la21qCL00Gnopq3CFhC74PS3oaZh0HSXlwdUB+CATYiPIpGS/ehxdXNYlM/N33agWX\n\tF4FHJRl6DJZ/wEKT1JPmrcTMCHglVNbFsiD/QKPQVCS9GuoOxBmMTFSHaWg6C4wVvR9b\n\tiEQg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20230601; t=1725348140; x=1725952940;\n\th=cc:to:subject:message-id:date:from:in-reply-to:references\n\t:mime-version:x-gm-message-state:from:to:cc:subject:date:message-id\n\t:reply-to;\n\tbh=fo7ZI3CDwpArfBPO8Fzm0rcCbfbNsQlasQGMvg/e1WI=;\n\tb=Op5RweICVXro20GMLVTDpaX9wDQmoDLl/VNFJL9gn2Q9QGxrQGETGJ0z1nROeX85FT\n\tCi7w8w7JSv/HP69PkFGzRKeqpkAqvDu+jKLOWiKiQHzCQ9JSGrwckw7IlRgaX6cClDbw\n\t3PkGb1Q+9Fs8IYh03r4nKcaNDQLYYHEHCxqjwCTV6lOcQuAnFuNBpq41rJCQp9EsuKXp\n\tj0JNi3g0s4JDc+kaoFmnBt/yIkzrV2pEEf9xOhFhRBGfZzDvk75moBrxd20hKsIONlw1\n\tjL/OzLWRdRnR4V3GQ/V7VHkUOE8AZVclwV8WYcAq/8fJD6aRx7lLEugIEAZ6I8zwoc5G\n\tXYlw==","X-Forwarded-Encrypted":"i=1;\n\tAJvYcCXqFbzf2b1iK25KtEZkZIWXPqjcv5ZqjmrPrW9H7U5Xz7/mEWXQVlUyEkGI7dukD4OVRw/N7/2R2nyaGGYCkSE=@lists.libcamera.org","X-Gm-Message-State":"AOJu0YxCEkwtoAB7uoEiNgHNgV9A50rIuwYOIiIAqkaaFtJ6tazYEMgb\n\tCPwe4QmIk3niZVXFbRUEySL6uHsPPFDx5IoJQ+bym2KEYYF0Hnb8Srgs+ys5nLQ9+PsTikLWVCb\n\tbMqPDB+LfRgjMIFFWRuZUrDYCQtWuu7X44LWbfg==","X-Google-Smtp-Source":"AGHT+IHzdSGWO66QZwxPDWmHby7PhZ5gQz6sbf1Qtem4cz4Zi1HBbmeVXbMBl3ecJFqQVOvN5AM1mAc98u1tHL5pu60=","X-Received":"by 2002:a05:690c:fd6:b0:6c8:7827:f28c with SMTP id\n\t00721157ae682-6d40f43a22dmr82263407b3.6.1725348140446;\n\tTue, 03 Sep 2024 00:22:20 -0700 (PDT)","MIME-Version":"1.0","References":"<20240831190511.128151-1-robert.mader@collabora.com>\n\t<075f44b0-381a-4ef9-bf74-a24439efbe94@redhat.com>\n\t<20240901110707.GA6713@pendragon.ideasonboard.com>\n\t<0dca7aff-c65c-4385-8645-523ef4a236e0@collabora.com>\n\t<543e41bd-2eab-4521-84fa-ca2504c3d524@collabora.com>\n\t<20240902203204.GB27677@pendragon.ideasonboard.com>","In-Reply-To":"<20240902203204.GB27677@pendragon.ideasonboard.com>","From":"Naushir Patuck ","Date":"Tue, 3 Sep 2024 08:21:54 +0100","Message-ID":"","Subject":"Re: [PATCH] libcamera: debayer_cpu: Sync output buffer","To":"Laurent Pinchart ","Cc":"Robert Mader ,\n\tlibcamera-devel@lists.libcamera.org","Content-Type":"text/plain; charset=\"UTF-8\"","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":31079,"web_url":"https://patchwork.libcamera.org/comment/31079/","msgid":"<20240903132732.GA4523@pendragon.ideasonboard.com>","date":"2024-09-03T13:27:32","subject":"Re: [PATCH] libcamera: debayer_cpu: Sync output buffer","submitter":{"id":2,"url":"https://patchwork.libcamera.org/api/people/2/","name":"Laurent Pinchart","email":"laurent.pinchart@ideasonboard.com"},"content":"On Tue, Sep 03, 2024 at 08:21:54AM +0100, Naushir Patuck wrote:\n> On Mon, 2 Sept 2024 at 21:32, Laurent Pinchart wrote:\n> > On Mon, Sep 02, 2024 at 12:56:31PM +0200, Robert Mader wrote:\n> > > On 01.09.24 13:39, Robert Mader wrote:\n> > > > On 01.09.24 13:07, Laurent Pinchart wrote:\n> > > >> Hans, would you be able to test this on an IPU6-based device, and check\n> > > >> the performance impact ? I don't expect expensive cache management\n> > > >> operations on an x86 device.\n> > > >>\n> > > >> Bryan, could you do the same with camss ?\n> > >\n> > > Heads up that in my initial testing around different Gstreamer pipelines\n> > > on arm64 I saw mixed results:\n> > >\n> > > 1. Cases involving successful dmabuf import to the GPU are (much) less\n> > > prone to glitches while not seeming to regress much in terms of frame\n> > > rates. This includes running Gnome-Snapshot or waylandsink on devices\n> > > like the Librem5, PinePhone or Pixel 3a (generally qcom).\n> > >\n> > > 2. Cases where Gst mmaps the buffers seem to get a noticeable\n> > > performance hit.\n> > >\n> > > Crucially this applies to common fallback paths like in following example:\n> > >\n> > > - glupload tries to import the buffer as dmabuf\n> > >\n> > > - fails due to stride requirements...\n> > >\n> > > - uses the \"raw\" importer that mmap the buffer\n> > >\n> > > This case is almost tragic IMO. The buffer data ends up only getting\n> > > accessed by the CPU but we flush the catches/sync to the GPU *twice* -\n> > > just to upload a copy in the end.\n> > >\n> > > And while I see potential to improve this scenario in the other parts of\n> > > the stack, I don't see anything we can about it in libcamera right now\n> > > (apart from not landing a patch like this).\n> >\n> > It's a bit late, but maybe there's a possibility to submit a lightning\n> > talk/BoF topic for LPC in two weeks ? Cache handling is a topic that\n> > crosses many subsystem boundaries, and I think we'll have quite a few\n> > people with relevant expertise in Vienna.\n> \n> This is quite a complicated topic indeed. The RPi camera stack\n> switched to using cacheable dma bufs for performance reasons (> 10%\n> uplift in certain use cases) and we had to be very careful with how to\n> handle the DMA_BUF_IOCTL_SYNC calls at the application level.\n> However, I don't think handling this in MappedFrameBuffer is the right\n> thing for hardware based ISPs because of unexpected stale data\n> flushing/invalidation. I can expand on this during our F2F in Vienna.\n\nThat seems a good discussion topic to me.","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 2BC7EC324C\n\tfor ;\n\tTue, 3 Sep 2024 13:28:08 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 467D0634CB;\n\tTue, 3 Sep 2024 15:28:07 +0200 (CEST)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[213.167.242.64])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 5691A634A6\n\tfor ;\n\tTue, 3 Sep 2024 15:28:05 +0200 (CEST)","from pendragon.ideasonboard.com (81-175-209-231.bb.dnainternet.fi\n\t[81.175.209.231])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id 3A66D16A;\n\tTue, 3 Sep 2024 15:26:53 +0200 (CEST)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"cYQIw6VH\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1725370013;\n\tbh=+XiKLKaeSFW4IvY3ayTw45eGfJDjq1gQCEQIyfpMvss=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=cYQIw6VH2AX/5tPwWb1mdjpKG0hhXCdou/oWdeaUZmwfXpPghBtDDBfTAmvvkUdT7\n\t+OMb3djMdANE7Ltw1+SL+ElH9fwrdw+AsvorD/DwjFTardWoxn26mR/3ubWOifry0L\n\tbGn21/hVA1evvjkSgaPuEMAwnceWKYG4lJHz9aMU=","Date":"Tue, 3 Sep 2024 16:27:32 +0300","From":"Laurent Pinchart ","To":"Naushir Patuck ","Cc":"Robert Mader ,\n\tlibcamera-devel@lists.libcamera.org","Subject":"Re: [PATCH] libcamera: debayer_cpu: Sync output buffer","Message-ID":"<20240903132732.GA4523@pendragon.ideasonboard.com>","References":"<20240831190511.128151-1-robert.mader@collabora.com>\n\t<075f44b0-381a-4ef9-bf74-a24439efbe94@redhat.com>\n\t<20240901110707.GA6713@pendragon.ideasonboard.com>\n\t<0dca7aff-c65c-4385-8645-523ef4a236e0@collabora.com>\n\t<543e41bd-2eab-4521-84fa-ca2504c3d524@collabora.com>\n\t<20240902203204.GB27677@pendragon.ideasonboard.com>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","In-Reply-To":"","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":31080,"web_url":"https://patchwork.libcamera.org/comment/31080/","msgid":"","date":"2024-09-03T13:39:29","subject":"Re: [PATCH] libcamera: debayer_cpu: Sync output buffer","submitter":{"id":140,"url":"https://patchwork.libcamera.org/api/people/140/","name":"Robert Mader","email":"robert.mader@collabora.com"},"content":"On 03.09.24 15:27, Laurent Pinchart wrote:\n> On Tue, Sep 03, 2024 at 08:21:54AM +0100, Naushir Patuck wrote:\n>> On Mon, 2 Sept 2024 at 21:32, Laurent Pinchart wrote:\n>>> On Mon, Sep 02, 2024 at 12:56:31PM +0200, Robert Mader wrote:\n>>>> On 01.09.24 13:39, Robert Mader wrote:\n>>>>> On 01.09.24 13:07, Laurent Pinchart wrote:\n>>>>>> Hans, would you be able to test this on an IPU6-based device, and check\n>>>>>> the performance impact ? I don't expect expensive cache management\n>>>>>> operations on an x86 device.\n>>>>>>\n>>>>>> Bryan, could you do the same with camss ?\n>>>> Heads up that in my initial testing around different Gstreamer pipelines\n>>>> on arm64 I saw mixed results:\n>>>>\n>>>> 1. Cases involving successful dmabuf import to the GPU are (much) less\n>>>> prone to glitches while not seeming to regress much in terms of frame\n>>>> rates. This includes running Gnome-Snapshot or waylandsink on devices\n>>>> like the Librem5, PinePhone or Pixel 3a (generally qcom).\n>>>>\n>>>> 2. Cases where Gst mmaps the buffers seem to get a noticeable\n>>>> performance hit.\n>>>>\n>>>> Crucially this applies to common fallback paths like in following example:\n>>>>\n>>>> - glupload tries to import the buffer as dmabuf\n>>>>\n>>>> - fails due to stride requirements...\n>>>>\n>>>> - uses the \"raw\" importer that mmap the buffer\n>>>>\n>>>> This case is almost tragic IMO. The buffer data ends up only getting\n>>>> accessed by the CPU but we flush the catches/sync to the GPU *twice* -\n>>>> just to upload a copy in the end.\n>>>>\n>>>> And while I see potential to improve this scenario in the other parts of\n>>>> the stack, I don't see anything we can about it in libcamera right now\n>>>> (apart from not landing a patch like this).\n>>> It's a bit late, but maybe there's a possibility to submit a lightning\n>>> talk/BoF topic for LPC in two weeks ? Cache handling is a topic that\n>>> crosses many subsystem boundaries, and I think we'll have quite a few\n>>> people with relevant expertise in Vienna.\n>> This is quite a complicated topic indeed. The RPi camera stack\n>> switched to using cacheable dma bufs for performance reasons (> 10%\n>> uplift in certain use cases) and we had to be very careful with how to\n>> handle the DMA_BUF_IOCTL_SYNC calls at the application level.\n>> However, I don't think handling this in MappedFrameBuffer is the right\n>> thing for hardware based ISPs because of unexpected stale data\n>> flushing/invalidation. I can expand on this during our F2F in Vienna.\n> That seems a good discussion topic to me.\n>\nUnfortunately I won't be able to join that, but I'd be really interested \nto hear about ideas what could be done to improve the situation. :/","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id DA2FCBF415\n\tfor ;\n\tTue, 3 Sep 2024 13:39:39 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id E16C1634E6;\n\tTue, 3 Sep 2024 15:39:38 +0200 (CEST)","from sender4-pp-f112.zoho.com (sender4-pp-f112.zoho.com\n\t[136.143.188.112])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id B4749634A6\n\tfor ;\n\tTue, 3 Sep 2024 15:39:36 +0200 (CEST)","by mx.zohomail.com with SMTPS id 1725370772356321.44396979306896; \n\tTue, 3 Sep 2024 06:39:32 -0700 (PDT)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key;\n\tunprotected) header.d=collabora.com\n\theader.i=robert.mader@collabora.com header.b=\"V4fLsoSB\"; \n\tdkim-atps=neutral","ARC-Seal":"i=1; a=rsa-sha256; t=1725370773; cv=none; \n\td=zohomail.com; s=zohoarc; \n\tb=B/edGyGFdQUBVvL/cfFIKeOT66QHvr8j5hqJiRPB/w/irR6xXPjg48TKE66gdlpIREcdU1zQO5usWeqSm7s7tDPj51o+Akj5reMNRkPf2tKr+ERCspn8h7Sxkvdts4pZCn6RnOyQOl5N5Wmfl3R78LaSNnqM/oOgroA/71YivXY=","ARC-Message-Signature":"i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; \n\ts=zohoarc; t=1725370773;\n\th=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To;\n\tbh=Tmtpj3RofErVU+0cg0U4UzUb78agljhVopRJnBmTjdY=; \n\tb=JPnh0h347djNWDx+IqGjQuzCJnSP2PTWQk7eagourtvnqdt/+u5QHrv/OjTCOMH1VgRPHSSnxSjtw/LzhT5mlWuhRlxStcFuu44HYR0JHUvml/5F4lXjs+1UOgsH5Yq4u7jhwkPPGn9JEJWC+HwsdNS2Pe5xNQtgk3iR6EV7i9o=","ARC-Authentication-Results":"i=1; mx.zohomail.com;\n\tdkim=pass header.i=collabora.com;\n\tspf=pass smtp.mailfrom=robert.mader@collabora.com;\n\tdmarc=pass header.from=","DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1725370773;\n\ts=zohomail; d=collabora.com; i=robert.mader@collabora.com;\n\th=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;\n\tbh=Tmtpj3RofErVU+0cg0U4UzUb78agljhVopRJnBmTjdY=;\n\tb=V4fLsoSB704wYOu82DBOtJh2eHyINxbsFnNP9GOXuQxajHoP7SRQcLWT2V5ObtJV\n\t0NYBm83jUc2TPeWUpNz7WDX7hJtZEqcI5vJKfarTbrjPJZKBaoMLfpZBxLWAcjNYhZc\n\tuV9q9xERcQMIrhK+csIAFkZiPOtOpTqIzoI2nF10=","Message-ID":"","Date":"Tue, 3 Sep 2024 15:39:29 +0200","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH] libcamera: debayer_cpu: Sync output buffer","To":"Laurent Pinchart ,\n\tNaushir Patuck ","Cc":"libcamera-devel@lists.libcamera.org","References":"<20240831190511.128151-1-robert.mader@collabora.com>\n\t<075f44b0-381a-4ef9-bf74-a24439efbe94@redhat.com>\n\t<20240901110707.GA6713@pendragon.ideasonboard.com>\n\t<0dca7aff-c65c-4385-8645-523ef4a236e0@collabora.com>\n\t<543e41bd-2eab-4521-84fa-ca2504c3d524@collabora.com>\n\t<20240902203204.GB27677@pendragon.ideasonboard.com>\n\t\n\t<20240903132732.GA4523@pendragon.ideasonboard.com>","Content-Language":"en-US, de-DE","From":"Robert Mader ","In-Reply-To":"<20240903132732.GA4523@pendragon.ideasonboard.com>","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"7bit","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}}]