| Message ID | 20251210005354.44726-27-bryan.odonoghue@linaro.org |
|---|---|
| State | Superseded |
| Headers | show |
| Series |
|
| Related | show |
Bryan O'Donoghue <bryan.odonoghue@linaro.org> writes: > List the series of things to do in GPU ISP in perceived order of > difficulty. > > Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com> > Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> > --- > src/libcamera/software_isp/gpuisp-todo.txt | 40 ++++++++++++++++++++++ > 1 file changed, 40 insertions(+) > create mode 100644 src/libcamera/software_isp/gpuisp-todo.txt > > diff --git a/src/libcamera/software_isp/gpuisp-todo.txt b/src/libcamera/software_isp/gpuisp-todo.txt > new file mode 100644 > index 000000000..b9910d17d > --- /dev/null > +++ b/src/libcamera/software_isp/gpuisp-todo.txt > @@ -0,0 +1,40 @@ > +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 rewriging the idea is to have a list rewriting? > + of algorithms as is done in cpuisp iterating through the > + list in a for() loop. > + - The logic manging the loop has an initial input buffer managing? > + 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 Another question is how to initialise shader variables, which are different for each of the shaders. I think a two-pass solution would be easier and able to handle almost everything (pre-debayer stuff + debayering in the first pass, post-debayer stuff in the second pass). Well, possibly with some exceptions like this one: > +24 bit output support: > + - Need to implment compute shader to do this. implement > + > +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 new file mode 100644 index 000000000..b9910d17d --- /dev/null +++ b/src/libcamera/software_isp/gpuisp-todo.txt @@ -0,0 +1,40 @@ +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 rewriging the idea is to have a list + of algorithms as is done in cpuisp iterating through the + list in a for() loop. + - The logic manging 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 implment compute shader to do this. + +Lense flare correction: + - Not WIP still TBD