From patchwork Sun Apr 5 19:14:34 2026 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Laurent Pinchart X-Patchwork-Id: 26418 Return-Path: X-Original-To: parsemail@patchwork.libcamera.org Delivered-To: parsemail@patchwork.libcamera.org Received: from lancelot.ideasonboard.com (lancelot.ideasonboard.com [92.243.16.209]) by patchwork.libcamera.org (Postfix) with ESMTPS id 049DCBEFBE for ; Sun, 5 Apr 2026 19:14:52 +0000 (UTC) Received: from lancelot.ideasonboard.com (localhost [IPv6:::1]) by lancelot.ideasonboard.com (Postfix) with ESMTP id 892D862D71; Sun, 5 Apr 2026 21:14:50 +0200 (CEST) Authentication-Results: lancelot.ideasonboard.com; dkim=pass (1024-bit key; unprotected) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="unWif23d"; dkim-atps=neutral Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64]) by lancelot.ideasonboard.com (Postfix) with ESMTPS id 724DA62D6E for ; Sun, 5 Apr 2026 21:14:48 +0200 (CEST) Received: from killaraus.ideasonboard.com (2001-14ba-703d-e500--2a1.rev.dnainternet.fi [IPv6:2001:14ba:703d:e500::2a1]) by perceval.ideasonboard.com (Postfix) with UTF8SMTPSA id DB70F6AF for ; Sun, 5 Apr 2026 21:13:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1775416402; bh=lltzW5OQTptxKLMhQYICrK37oioitarQSr3O2IKaDn8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=unWif23dj8491jMXF4MEAg4S32TbyW/fXyYLL35WYgUpkmU4jMokBkYyGak9tC5ba oT//9Jo0/tabYP/r2FPUWC5v/HxYAj8mXbPZ60AEpfShmGgV2gp8YdnXzj+6Vswo+v ErK6f+iJsYulWgwuPhggMLK+XrvI7zr07E4Olal8= From: Laurent Pinchart To: libcamera-devel@lists.libcamera.org Subject: [PATCH 02/11] libcamera: software_isp: Move GPU TODO items to TODO.md Date: Sun, 5 Apr 2026 22:14:34 +0300 Message-ID: <20260405191443.1209948-3-laurent.pinchart@ideasonboard.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260405191443.1209948-1-laurent.pinchart@ideasonboard.com> References: <20260405191443.1209948-1-laurent.pinchart@ideasonboard.com> MIME-Version: 1.0 X-BeenThere: libcamera-devel@lists.libcamera.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libcamera-devel-bounces@lists.libcamera.org Sender: "libcamera-devel" There's no need to store GPU-specific TODO items in a separate file, that clutters the software_isp directory. Move them from gpuisp-todo.txt to TODO.md. Signed-off-by: Laurent Pinchart --- src/libcamera/software_isp/TODO.md | 47 ++++++++++++++++++++++ src/libcamera/software_isp/gpuisp-todo.txt | 40 ------------------ 2 files changed, 47 insertions(+), 40 deletions(-) delete mode 100644 src/libcamera/software_isp/gpuisp-todo.txt diff --git a/src/libcamera/software_isp/TODO.md b/src/libcamera/software_isp/TODO.md index bdd4a7421766..036cf2b7f9ce 100644 --- a/src/libcamera/software_isp/TODO.md +++ b/src/libcamera/software_isp/TODO.md @@ -182,3 +182,50 @@ lower the CPU consumption, but at the same time I don't feel comfortable building up on top of an implementation that may work a bit more by chance than by correctness, as that's not very maintainable. ``` + +## GPU-based implementation + +The TODO items are listed in perceived order of ease. + +### Denoising + +WIP + +### Dead pixel correction + +WIP + +### Lense shading correction + +WIP + +### Use dma-buf handle to generate upload texture + +`eglCreateImageKHR` can be used to generate the upload texture i.e.to feed the +bayer data into the GPU. + +### processFrame() to run in its own thread + +`processFrame()` runs in the context of the Debayer::process() thread. Robert +Mader suggested and it seems like a good suggestion too to run processFrame() +in its own thread. + +### Multi-pass shaders + +- This needs some rewiring the idea is to have a list of algorithms as is done + in cpuisp iterating through the list in a for() loop. +- The logic managing the loop has an initial input buffer and the final output + buffer. +- The higher level logic must then inform each of the algorithms either to + generate an internal working buffer or pass the final output buffer to the + last shader in the list +- This will allow for multi-pass shaders with the final algorithm presenting + data not to its internal buffer but to the final output buffer + +### 24 bit output support + +Need to implement compute shader to do this. + +### Lense flare correction + +Not WIP still TBD diff --git a/src/libcamera/software_isp/gpuisp-todo.txt b/src/libcamera/software_isp/gpuisp-todo.txt deleted file mode 100644 index 8930da120962..000000000000 --- a/src/libcamera/software_isp/gpuisp-todo.txt +++ /dev/null @@ -1,40 +0,0 @@ -List the TODOs in perceived order of ease. - - -Denoising: - - WIP - -Dead pixel correction: - - WIP - -Lense shading correction: - - WIP - -Use dma-buf handle to generate upload texture: - - eglCreateImageKHR can be used to generate the upload texture i.e. - to feed the bayer data into the GPU. - -processFrame() to run in its own thread: - - processFrame() runs in the context of the Debayer::process() - thread. Robert Mader suggested and it seems like a good - suggestion too to run processFrame() in its own thread. - -Multi-pass shaders: - - This needs some rewiring the idea is to have a list - of algorithms as is done in cpuisp iterating through the - list in a for() loop. - - The logic managing the loop has an initial input buffer - and the final output buffer. - - The higher level logic must then inform each of the - algorithms either to generate an internal working buffer - or pass the final output buffer to the last shader - in the list - - This will allow for multi-pass shaders with the final - algorithm presenting data not to its internal buffer - but to the final output buffer - -24 bit output support: - - Need to implement compute shader to do this. - -Lense flare correction: - - Not WIP still TBD