On 4/8/20 10:45 AM, Sowjanya Komatineni wrote:
On 4/8/20 7:21 AM, Dmitry Osipenko wrote:
External email: Use caution opening links or attachments
08.04.2020 03:00, Sowjanya Komatineni пишет:
...
I suppose that taking a shot takes at least few milliseconds, which
should be unacceptable to waste.
As long as buffers are in queue we have to keep processing each
buffer and between buffers obviously we have to wait for previous
frames to finish and this why we have separate thread for frame
finish where we can have next buffer capture ready and issue while
previous frame memory write happens
Also we specified numbers buffers as 3 to vb2 queue. So this is rare
case but to prevent issuing more than 2 at a time as VI HW is only
double buffered and syncpt fifo max depth is 2 added this to be safer.
To be more clear, when more buffers are enqueued from userspace always
capture list will be full and thread will be busy in capture till
either
error or stop stream request happens.
If kthreads take more than 1% of CPU time during capture (video) with
more than 2 buffers in queue, then it's not good and I think you should
do something about it. If kthreads stay at ~0%, then it should be okay
as-is.
VI outstanding requests max can only be 2 as syncpt fifo depth is 2
and waiting to issue next capture when already 2 captures are inflight
happens only during beginning of streaming where buffers allocated go
thru capture for first time after queuing.
same buffers are returned to userspace after capture and same
allocated buffers will be queued back for subsequent captures.
So this case of holding to issue single shot when already single shot
is issue for 2 frames simultaneous happens only during beginning of
start stream and also we set num_buffers to allocate for queue as 3
although 2 is good enough where we will not hit this case even during
streaming start with 2 buffers
As 2 buffers are good enough to be clear will update in v7 to use 2
buffers so we don't need to check for more than 2 outstanding buffers.
