aaa48bb276
List the series of things to do in GPU ISP in perceived order of difficulty. Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Milan Zamazal <mzamazal@redhat.com> Tested-by: Robert Mader <robert.mader@collabora.com> Tested-by: Hans de Goede <johannes.goede@oss.qualcomm.com> # ThinkPad T14s gen 6 (arm64) ov02c10 + X1c gen 12 ov08x40 Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com> # Lenovo X13s Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
41 lines
1.2 KiB
Plaintext
41 lines
1.2 KiB
Plaintext
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
|