tree 46bfb0a0a9772f9107a465e40c9605cad3eacd6b
parent eefc722e664fa19d5ba9f23cf777d858eae9370e
author Jonas Larsson <ljonas@google.com> 1566857983 -0700
committer Jonas Larsson <ljonas@google.com> 1566857983 -0700

gldownload: don't pre-allocate ion buffers

NXP's gldownload fastpath requests 3 ION buffers to be created in the
pool without any upper bound. That means 3 buffers are allocated the
moment the pool is activated and there's no upper bound on how many
the pool can allocate.

This is an issue when working with larger buffers as we can easily
run out of CMA memory. The cost of allocating an ION buffer when
needed is negligible. glupload for example doesn't even use a pool.
Since gldownload is using a pool the already negligible cost is
hidden further.

In most common cases (i.e. downstream doesn't hold on to downloaded
buffers) this change results in only one buffer being allocated.
For a 1080p YUY -> RGBA conversion that's downloaded that's a
CMA savings of ~16 MB. For downstream elements that hold on to buffers
(e.g. certain double buffered sinks) more buffers will be allocated as
needed, up to 3 to prevent OOM.

Change-Id: I68172d7e9d1bf634900cb639f90843768ac525ae