Em 18-02-2011 08:31, Laurent Pinchart escreveu:
It's a trade-off between memory and speed. Preallocating still image
capture buffers will give you better snapshot performances, at the
expense of memory.
The basic problems we have here is that taking snapshots is slow with
the current API if we need to stop capture, free buffers, change the
format, allocate new buffers (and perform cache management operations)
and restart the stream. To fix this we're considering a way to
preallocate still image capture buffers, but I'm open to proposals for
other ways to solve the issue :-)
On Fri, 18 Feb 2011 13:33:12 +0100, Mauro Carvalho Chehab wrote:
From the above operations, considering that CMA is used to reserve a
non-shared memory with enough space for the new buffer size/qtd, I don't
think that the most expensive operation would be to realloc the memory.
The logic to stop/start streaming seems to be the most consuming one, as
driver will need to wait for the current I/O operation to complete, and
this can take hundreds of milisseconds (the duration of one frame).
How much time would CMA need to free and re-allocate the buffers for,
let's say, something in the range of 1-10 MB, on a pre-allocated, non
shared memory space?
Like I said, if memory is shared with page allocator this can potentially
take a lot of time. If device driver could preallocate some space and
then spit it into buffers when needed, it could be a better solution then
to free chunk and allocate a new one. CMA was not designed with very low
latency in mind.
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +-----<email/xmpp: mnazarewicz@xxxxxxxxxx>-----ooO--(_)--Ooo--
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
