On 4/8/20 12:38 PM, Sowjanya Komatineni wrote:
On 4/8/20 11:58 AM, Sowjanya Komatineni wrote:
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.
correction: With 3 buffers, as soon as buffer is available capture
starts. So right most times I see it waiting for few ms before 3rd
capture to get through.
As only 2 frames single shot can be issued in sequence (inflight
requests), instead of waiting for 1 of the request to finish, we can
use 2 buffers and avoid waiting as 2 buffers are good enough. Will
change this in v7.
Tested with 3 buffers and by checking outstanding buffers in process by
VI hw and holding to start capture till one outstanding buffer in
process by HW.
Also tested with 2 buffers without checking for outstanding buffers.
In both cases, I see same %CPU for the kthreads and is < 1%
