GoogleCodeExporter
commented
9 years ago To know if a libyuv function will be fast path, a rule of thumb is the width
needs to be a multiple of 16, and the image pointer/stride should also be
aligned to 16.
The pointer/stride alignment is less of a concern on Neon and AVX2, but most
functions are optimized for aligned width.
Your suggested solution is overread/overwrite. libyuv will allow you to do
that, and its a good solution.
Allocate extra pad bytes for rows and/or images.
Conversion functions will check if width == stride and treat the image as one
large row. You can do that yourself, and pad out the total (width * height +
15) & ~15;
Scaling can't be row coalesced, but you can allocate aligned rows.
Allocate buffers with stride = (width + 15) & ~15; and image_size = stride *
height;
In the case of scaling to 1/2, the destination needs to be a multiple of 16, so
source would be a multiple of 32.
I did experiment with overreads/overwrites, but it was deemed unsafe. So the 2
solutions I've come up with are 'any' functions, and row coalescing.
any functions on intel still prefer an aligned pointer, but handle 'any' width,
by doing the multiple of 16, and then handling the remainder. Most handle the
remainder using C code, but some functions redo work on the 'last16' pixels,
which is an overread/overwrite of data already processed, but within the row.
This is supported for conversions, but not scaling.
The unittests check for overread/write by allocating images at the end of a
page, and are run thru valgrind.
So the action item here is to implement scale_any.cc which has a wrapper for
each scale row function that handles odd sizes.
Its not hard, and it may even exist already for 1/2 size, since that comes up
in conversions/effects.Original comment by fbarch...@chromium.org on 21 Feb 2014 at 11:27
Original issue reported on code.google.com by
noah...@google.comon 14 Feb 2014 at 7:54