| Message ID | 20260405191443.1209948-3-laurent.pinchart@ideasonboard.com |
|---|---|
| State | New |
| Headers | show |
| Series |
|
| Related | show |
Hi Laurent On Sun, Apr 05, 2026 at 10:14:34PM +0300, Laurent Pinchart wrote: > 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 <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> > --- > 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 > -- > Regards, > > Laurent Pinchart >
Hi Laurent On Sun, Apr 05, 2026 at 10:14:34PM +0300, Laurent Pinchart wrote: > 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 <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Thanks j > --- > 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 > -- > Regards, > > Laurent Pinchart >
2026. 04. 05. 21:14 keltezéssel, Laurent Pinchart írta: > 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 <laurent.pinchart@ideasonboard.com> > --- Reviewed-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com> > 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
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
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 <laurent.pinchart@ideasonboard.com> --- 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