| Message ID | 20250526214224.13631-1-stefan.klug@ideasonboard.com |
|---|---|
| Headers | show |
| Series |
|
| Related | show |
The RFC patchset from Stefan works to enable an application to request
more than 4 buffers for the rkisp1. But when using a number higher than
8 it breaks, as the bufferCount value is also used to determine the
amount of parameter/statistic buffers to allocate.
But as the patchset already limits the number of queued buffers, the
amount of parameter/statistic buffers can can also be just this fixed
value. Therefore adapt Nicolas patch, which already did this from my
rebased patch series [1].
This allows (on my hardware setup) up to 32 buffers to be allocated.
@Stefan: With this patch included, feel free to add a
Tested-By: Sven Püschel <s.pueschel@pengutronix.de>
[1] https://lists.libcamera.org/pipermail/libcamera-devel/2025-April/050029.html
Hi Stefan, do you plan to send a v2 patchset? Sincerely Sven On 5/26/25 23:42, Stefan Klug wrote: > Hi all, > > In the rkisp1 pipeline the value of StreamConfiuration.bufferCount is > reset to 4 on validate(). This effectively limits the number of buffers > that are in the loop to 4. As soon as the consumers > (gstream/pipewire...) of the buffers need more than 1 buffer at a time, > we start to see frame drops. Sven resurrected an old series [1] that > solves the issue at the expense of an additional control and breaking > changes in the API. > > In the IoB code camp two weeks ago there were some discussions regarding > improvements in the rkisp1 regulation and per-frame-control (PFC). PFC > has been an ongoing topic for quite some time now and it seems to slowly > converge. Still we were hesitant in breaking the API or introducing new > controls before the overall concepts have stabilized enough. > > To mitigate the pain mentioned above we came up with a minimal changeset > that allows to request more than 4 buffers. Only 4 (or the pipeline > depth reported by the pipeline) buffers are queued into the device. > This has the same benefits as [1] but doesn't require an API break. > > I'm not available this week so I post the patches as RFC only for others > to try out as these were not thoroughly tested. Any feedback is greatly > appreciated. > > Best regards, > Stefan > > > [1] https://patchwork.libcamera.org/project/libcamera/list/?series=5148 > > Stefan Klug (4): > libcamera: pipeline_handler: Move waitingRequests_ into camera class > libcamera: internal: Allow to limit the number of queued requests > pipeline: rkisp1: Limit the maximum number of buffers queued in > pipeline: rkisp1: Prperly handle the bufferCount set in the stream > configuration > > include/libcamera/internal/camera.h | 2 + > include/libcamera/internal/pipeline_handler.h | 8 ++-- > src/libcamera/pipeline/rkisp1/rkisp1.cpp | 12 +++++- > src/libcamera/pipeline/rkisp1/rkisp1_path.cpp | 6 +-- > src/libcamera/pipeline/rkisp1/rkisp1_path.h | 4 +- > src/libcamera/pipeline_handler.cpp | 37 +++++++++++++------ > 6 files changed, 46 insertions(+), 23 deletions(-) >
Hi all, In the rkisp1 pipeline the value of StreamConfiuration.bufferCount is reset to 4 on validate(). This effectively limits the number of buffers that are in the loop to 4. As soon as the consumers (gstream/pipewire...) of the buffers need more than 1 buffer at a time, we start to see frame drops. Sven resurrected an old series [1] that solves the issue at the expense of an additional control and breaking changes in the API. In the IoB code camp two weeks ago there were some discussions regarding improvements in the rkisp1 regulation and per-frame-control (PFC). PFC has been an ongoing topic for quite some time now and it seems to slowly converge. Still we were hesitant in breaking the API or introducing new controls before the overall concepts have stabilized enough. To mitigate the pain mentioned above we came up with a minimal changeset that allows to request more than 4 buffers. Only 4 (or the pipeline depth reported by the pipeline) buffers are queued into the device. This has the same benefits as [1] but doesn't require an API break. I'm not available this week so I post the patches as RFC only for others to try out as these were not thoroughly tested. Any feedback is greatly appreciated. Best regards, Stefan [1] https://patchwork.libcamera.org/project/libcamera/list/?series=5148 Stefan Klug (4): libcamera: pipeline_handler: Move waitingRequests_ into camera class libcamera: internal: Allow to limit the number of queued requests pipeline: rkisp1: Limit the maximum number of buffers queued in pipeline: rkisp1: Prperly handle the bufferCount set in the stream configuration include/libcamera/internal/camera.h | 2 + include/libcamera/internal/pipeline_handler.h | 8 ++-- src/libcamera/pipeline/rkisp1/rkisp1.cpp | 12 +++++- src/libcamera/pipeline/rkisp1/rkisp1_path.cpp | 6 +-- src/libcamera/pipeline/rkisp1/rkisp1_path.h | 4 +- src/libcamera/pipeline_handler.cpp | 37 +++++++++++++------ 6 files changed, 46 insertions(+), 23 deletions(-)